DevOps登山指南

05-12

本文轉帖自我的Blog：martinliu.cn

全美互惠保險公司(Nationwide)美國公司。在2017年6月7日，《財富》2017年美國500強排行榜發布，全美互惠保險公司排名第68位。營業收入40074.1百萬美元。

這家公司是DevOps Handbook（DevOps實踐指南）書中的案例研究之一。這是一家DevOps水平較高的企業，是DevOpsDays大會上分享嘉賓的常客，也是各個DevOps工具廠商（New Relic）經常邀請的案例分享嘉賓。他們也經常參加DevOps企業峰會，曾多次做過自己的DevOps應用狀況案例分享。

本文分析和整理了他們在2017年11月舊金山站DevOps企業峰會上他們的演講，主題為《DevOps Handbook Experiments in Accelerating Delivery - Nationwide》（翻譯：使用DevOps Handbook在加速開發交付的過程中的實驗）

本文根據這個演講的YouTube視頻整理而成。視頻已經上傳到騰訊視頻，點這裡觀看該視頻。

DevOps登山指南手冊

我在翻譯DevOps Handbook的過程中，感覺書中所描述的這家公司的案例研究，並不像本演講里所說的這樣的精彩。

而時光已經很快的流轉到了將近2018年，他們的DevOps也經過了幾年的發展，本文案例向我們展示了一個金融行業（我們往往認為不太容易實施DevOps的行業）企業，在很大的企業規模了，所取得的令人敬佩的成就。

下面這張圖是本文的精華，先給各位呈現出來。他們使用攀登珠穆朗瑪峰做為比喻，對DevOps的實施做了生動的詮釋。

本圖在Nationwide公司內部的使用場景如下：

本圖將DevOps實施核心團指導產品開發團隊（也可以說是業務團隊、服務團隊、這樣的團隊他們有200多個）取得的經驗總結在一張紙上，供其它有實施DevOps想法的團隊參考。
該登山指南簡化了對其它非DevOps團隊的教育和指引。
他們將DevOps的實施分成三個階段，分別用大本營、北坡營地和頂峰作比喻。
這三個階段里的技術實踐都來自於DevOps Handbook，通過他們的篩選和整理，並根據自己的經驗做了分階段的規劃。

為了知其所以然，我們將繼續向下發掘，詳細了解這個案例分享所講的主要內容。下面的內容也包含了我對他們的分析和評論，欲了解原始資料，請請參看我上傳到騰訊的視頻。

主題：DevOps Handbook-在加速交付中的各種實驗

分享者介紹。

這個演講距2018年2月也就是三個月，還算是很新鮮的一個案例。Cindy是DevOps團隊中的核心人員之一，她的頭銜是Director，角色是夏爾巴人（後面會詳細解釋這個比喻的含義），為業務產品組提供內部的DevOps諮詢和輔導。Jim屬於業務條線/BU的Dev這一側，他是業務部門的解決方案架構師。

Nationwide的核心價值：保護對你最有價值的

公司簡介和狀況。

在很多險種上Nationwide都在業內排名第一名，包括：寵物保險、農場保險、公司壽險等等。
這是一家有90年歷史的老店
汽車保險也行業排名第八（後面就是用這個業務為例，來佐證DevOps實施的效果）
不光在財富500強企業排名68，還是財富所評選的前100個最佳的工作企業。

Nationwide IT的規模很大

IT組織的特點和相關數據。

IT組織龐大，結構複雜，業務條線眾多
在選擇應用某個DevOps實踐的時候，總是要考慮到規模因素，需要評估該實踐是否能在200多個業務開發團隊的規模上全面地推廣和實施
IT人員總數超過5100人，其中程序員和測試人員的數量超過2600人；在電腦世界的IT最佳工作地點的排行幫上位居第51名
該公司有用200多個產品開發團隊，他們服務於23個業務部門BU

Nationwide IT的組織結構

典型、複雜和龐大的組織結構

I&O是基礎架構和操作運維團隊，該組織不僅運維了所有的IT服務，還服務於所有的業務開發團隊。
多個共享服務團隊提供企業級的共享服務，包括Scrum測試等傳統開發服務，同時也為企業內部的DevOps實踐提供技術諮詢，他們支持所有類型的企業應用堆棧
業務部門如前所述有23個，有200多個開發團隊，Jim服務於金融業務BU
該公司的架構模型近似於典型的Dev、QA和Ops架構；他們的Ops組織也是集中式的；如此複雜的架構帶來了DevOps流水線的複雜度方面的挑戰，為某個業務BU實施的持續交付流水線會橫跨多個BU，有時候甚至需要三個BU的CIO級別領導一起來參與決策，這裡也會出現項目投資方和項目決策方不統一的難題。

從哪裡開始

應用DevOps的企業環境背景和定位。

IT組織十年以來追求的戰略目標：構建具有全球競爭力的內包式軟體開發能力；為此而採用了不同的管理框架和實踐，應用和開始的時間點也不同

Agile：敏捷軟體開發是10年前就開始的，定位和目標是通過敏捷軟體開發交付高質量的軟體
DevOps：今年加入了DevOps實踐，定位是如何實現速度、效率和降低風險。
Lean IT：定位是確保將IT管理的各種實踐（包括以上的敏捷和DevOps）提升和推廣到企業級規模。（他們認為在團隊級別上任何敏捷和DevOps相關的實踐都是很容易實現的，而企業級規模的推廣是更高等級的管理，是不容易達到的）
CMMI：使用行業規範的軟體開發成熟度標準評價和考量自身的軟體開發能力，為自身的不斷提高提供標準參考。

該公司DevOps實踐是最晚開始應用的，其它的三個方面使用的歷史比較長了，為了達成一個戰略目標，需要4個戰術層面實踐的支持，這些戰術的採用時期和定位不同；4個戰術從不同的側面支持了戰略目標的實現。該企業也在Lean IT的論壇上分享和演講過。

從哪裡開始（續）

應用DevOps的時間軌跡和歷程，各個時期的關鍵詞。

2015-簡化：DevOps小屋是入手DevOps實踐時，最早使用過的參考框架；他們分析梳理了所有相關的方法論；工具方面專註在部署工具的改進上，所有產品線採用了IBM UrbanCode作為統一的部署工具；可是這個階段接觸的實踐還是比較龐雜。
2016-組織：在獲得了高層領導的支持以後，他們同時在三個方向出擊：軟體開發模型、精益IT管理和供應鏈管理；在三個方面都直接提高和優化了DevOps的速度。
2017-實驗：在取得了天時地利人和之後，他們展開了所謂的「雙模實驗」的實踐道路；從業務需求入手（規划了使用了MMP最小化可市場產品的概念），逐漸拋開了紛繁複雜的實踐和方法論，他們開始聚焦在了「程序員體驗」上，通過各種實驗驗證DevOps Handbook中描述的實踐是如何影響並提升他們的。孵化和實驗各種DevOps Handbook書里的實踐。
2018-促動：如何把相關的工具推廣到200多個開發團隊，如何引入Google的SRE模型，將交付流水線作為產品對待，在複雜的組織中，實施跨部門的流水線的挑戰依舊不輕。
該公司的DevOps實踐道路是一步一個台階的持續改進過程，經歷了三年多時間，每個階段的關鍵詞代表了他們的成果和挑戰。

DevOps團隊間的交互模型

【重點】團隊組織結構和交互方式。

這是實驗各種DevOps實踐的團隊組織模型，開展每項DevOps實踐都遵循PDCA的持續改進方法。
所有團隊遵循著三個基礎原則：1速度，江湖武功唯快不破，這是他們清醒而簡單的唯一追求目標，成為檢驗所有優化改進的唯一驗收標準和條件。2實踐者之成功，他們做的並不是自頂向下的、政令式的強推，而是讓參與DevOps實踐的團隊自己提出工作想法，自己來決定在哪裡嘗試改進能提升速度。3範圍，從端到端的價值流全局看，既不推崇極左的做法，也不推崇極右的做法，他們將範圍限定在，從一張工作卡片進入DevOps產品代辦工作（Backlog）開始，直至將它的成果發布到生產環境中。
實施「雙模實驗」團隊的模型，兩個團隊都提出自己想做的實驗想法，雙方的工作內容都匯總到一個集中的DevOps產品代辦工作隊列中，每一項工作/卡片都是一項實驗，每一項實驗都由兩個團隊分別完成，A/B團隊的做法和實現結果可能不同，這樣也自然地應用到了A/B測試的模型。
DevOps Leadership Team團隊里是Cindy和Jim所在的團隊（應該是一個虛擬團隊組織），他們確保所有代辦工作都遵循以上的三個基礎原則，另外使用系統性思考來確保每種實驗如果取得了成功，在推敲是否它能推廣並應用到其它的200多個開發團隊。
DevOps平台團隊輔助和優化雙模實驗團隊的工作，例如雙模團隊可能都需要自動化變更流程（ITSM的管理範疇）的API，而這些工作就可以踢給平台團隊做，平台團隊負責設計實現這個API，並且保證它具有企業級規模的能力，然後交付雙模團隊使用即可。
治理團隊是由該公司的各個CIO級別的利益干係人組成的，上文說過某些複雜的DevOps持續交付流水線會跨三個以上的部門，這些BU的大佬會在這個團隊中；他們在每個迭代都會出現在雙模團隊的工作現場，一起現場查看狀況，現場解決問題。Jim認為他們親自臨場觀察和了解實驗工作的效果，遠遠比將實驗成果作出PPT後再給他們去彙報的效果要好。

EPIC史詩

【重點】DevOps團隊根據Handbook為基礎，提出了所有想實驗的工作內容。

開發團隊從尋找什麼拖慢了速度出發，尋找優化和改進工作內容的方法，在漸梳理和過濾以後，發現最後確定要做的工作都可以在Handbook中得到確認。甚至有些人在討論某個工作條目的時候，能清晰的告訴大家可以參考Handbook書中的章節和頁數。
DevOps產品代辦工作里的EPIC史詩工作必須是在Handbook書中能夠出現和參考到的，如果不是的話，團隊可能會對它表示質疑。
這裡Cindy簡述了自動化測試這項工作的實驗，故事是這樣的：開發團隊自己描述到，當前的Test Bed已經大到不可管理的程度，測試運行的時間太長了，因此不能保持測試的精簡和有效性，這樣的情況持續了一段時間以後，大家就失去了對自動化測試的信心。而且由於開發和測試人員不在同一個組織/團隊里，團隊之間必須進行工作交接（部門牆），導致了大量複測試案例的存在。他們的解決方法是，讓開發和測試人員結對子，這樣就減少了重複測試。當測試套件又變得精簡和綠色了以後，大家又開始相信這些自動化測試了，之後大家對自動化測試的文化轉變為：將自動化測試案例失敗視為零容忍事件（失敗的測試會導致全team的人停下來，並在1天內解決）。另外一個故事關於性能測試，性能測試是通過一個位於俄亥俄州的集中式性能測試團隊做的，任何開發團隊的申請時間是90天（被識別為最長時間的約束點），他們認為這個前置時間是無法接受的。解決方法是，將性測試腳本和運行許可權交還給了開發團隊，最後90天的性能周期被縮短為了2小時。
DevOps團隊和管理層對Handbook書里的實踐內容達成了共識和一致，上下一致的參考書中這些業界已經驗證過的實踐，節省了決策和探索DevOps做法和套路的時間。

開發者/程序員體驗：十八般神兵利器，大量的上下文切換

【重點】2017年的實踐核心是「開發者/程序員體驗」（程序員要「富養」）

在專註於開發者體驗優化的過程中，應用了大量DevOps工具，最後發現如果開發者把它們都用一遍的話，要花好幾個小時的時間。為了解決這個問題，他們體驗了Rocket.Chat工具，開發者們對此工具提出了一致好評。

為了讓公司領導層支持增加這個工具，他們請領導們到現場親自視察觀看開發人員在使用了Rocket.Chat之後，優化的體驗。領導們就這樣決策增加的這個工具。

開發者/程序員體驗：擁抱聊天機器人，減少上下文切換

優化後的開發者工具集如下所示。

開發者直接面對的工具精簡了很多，他們幾乎只需要專註於寫代碼和處理代碼的提交和PR即可。
之前開發者如果需要部署代碼，就需要手工的在UrbanCode里點擊十幾二十次滑鼠，才能完成一次部署操作。
在使用了聊天機器人之後，他們只需要對聊天機器人說：deploy；即可

DevOps登山指南

通過這一頁紙的手冊，為新來的DevOps實踐者提供了清晰的指導。

攀登高山隱喻了這是一個艱難的旅程。

北極星 - 前置時間

【重點】各項DevOps工作的唯一參考指標是「前置時間」（指南針）

選用這個指標的三個原因：

這個指標可以在橫向的200多個敏捷開發團隊里實施；在縱向的組織級、部門級和團隊級上，大家都能理解和認可這一指標，都能夠掌握前置時間的計算和測量方法。縮短前置時間的目標是清晰的：及時要加快交付速度。
各個開發團隊可以自行選擇優化前置時間的方法和路徑，其實這鼓勵了團隊的創造性。
對此指標的度量和持續改進，是可以按天實時進行的，同時還要保證實現部署的零宕機時間。

DevOps登山用品：地圖和裝備

DevOps實踐者基礎的精神和物質需求。

工具和DevOps實踐直接相關
每個工具都有其價值和應用場景（例如Rocket.Chat）
DevOps Handbook（中文書名：DevOp實踐指南）的作用是地圖，每個DevOps實踐團隊都進行至少每周一次的讀書俱樂部活動，每次都對書中具體的章節進行團隊討論和學習。

DevOps的支持模型

DevOps支持團隊的作用。

為了滿足企業級的支持規模，讓水平參差不齊的200多個開發團隊都能順利應用DevOps實踐，沒有這個支持模型是不可能走遠的。

夏爾巴人團隊的作用是支持和輔導DevOps實踐團隊，提升團隊的思想意識觀念和技能，幫助它們構建某些特定領域的工作能力。
參與DevOps實踐的開發團隊必須自己登上山頂，哪怕是爬也是自己爬上去。絕不勉強，不想進步的團隊就不要參與了。
逐漸開展了沉浸式配對的支持模式，讓低水平團隊的人員在DevOps高水平團隊中進行交叉培訓，讓他們現場看到相同的工作確實可以有不同的、更好的做法。
他們進行每月一次的DevOps道場，在道場里DevOps技術顧問現場指導和幫助前來提高的團隊。
將流水線視為產品，流水線的管理確實也是他們的痛點之一。

DevOps成功的那一刻

DevOps對業務有毛用？！

這個故事是該公司剛開始品嘗DevOps成功碩果的那一刻。颶風哈維（是2017年大西洋颶風季中的一個熱帶氣旋。2017年8月25日，登陸美國德克薩斯州沿岸，時速130英里）導致車輛涉水險的申報數量劇增。業務部門的人處理這些車險事件的過程中意識到，他們的業務流程對這個險種的索賠並不友好，於是就來找到了IT部門，提出想要優化這個險種報案和索賠處理。

這是第一次業務部門找上門來提出的業務需求，IT部門在當天就搞定的經歷。業務人員和IT部門的人用了一個小時的時間討論優化方案，決定去掉索賠流程里40%的多餘步驟。IT部門開始設計和實施這個想法，決定需要變更多個應用，他們在當天里，在剩下的7個小時內就完成了這些業務需求的開發和測試，這些業務變更的生產環境部署工作是在工作時段進行的，變更在當天的營業時間結束前就上線了。他們始終以速度為先的實踐原則在一年後，在這一天里得到了回報。以前需要至少90天的周期才能完成這樣的變更，性能測試會就會佔用一半以上的前置時間。而他們覺得這次在整個的設計、實施和部署過程中，其實並沒有感到什麼壓力和風險。

後記

本文的價值在於，向你展示一個有參考價值的DevOps案例。它的很多特徵和成功之處都值得借鑒和思考。本文的文字主要來源於對視頻中的敘述，其中也包含了大量我個人的觀點和分析；歡迎讀者在觀看本案例視頻後，與我分享和討論以上內容。