大规模开发团队如何实现DevOps转型？ 来自微软全球开发平台工程团队的实践经验
微軟全球開發平臺工程團隊從敏捷到DevOps的轉型
2013年11月13日，我們宣布了Visual Studio2013，以及微軟研發云Visual Studio Online (VSO)的正式商用。緊接著我們經歷了一次長達七小時的服務中斷。我們的服務運行在一個“彈性擴展單元”中，為大約一百萬用戶提供服務。當時恰逢峰值流量時間段，歐洲和美國東西海岸的用戶均已上線，在市場部門對外公布正式商用的同時，我們正在通過“功能開關”啟用各種本被隱藏的新功能。隨后發現負責服務間通信的IP端口，這個重要的網絡層組件未能如期生成我們需要的遙測數據。當時因為新功能發布，已經產生了大量請求。從技術的角度來看，這造成了一個很尷尬的情況，如圖1所示。當時的細節情況可以參閱這里。[i]
圖1：VS 2013的發布因為VS Online服務一系列尷尬的中斷而面臨窘境。
從市場的角度來看，本次發布活動無疑是一個巨大的成功。VS Online服務借助這一轉折點，成功地實現了兩位數的用戶數月增量。（增長的趨勢還在繼續，隨后一年里，百萬級別的用戶數順利翻倍。）
功能與后端保障之間的權衡
那段時間里，VSO只有一個托管在芝加哥數據中心內的彈性擴展單元。我們很清楚，需要通過多個單獨部署的彈性擴展單元進行橫向擴展，但我們總是更重視與功能有關的工作，忽略了使用多個彈性擴展單元為網站提供更周全的保障這件事情。發布會上遭遇的情況讓我們改變了自己的想法。相關團隊決定將本已計劃好的功能改進工作延期，全力解決后端的保障工作。我們需要通過某種方式對VSO的后續更新進行“金絲雀部署“。原本使用的芝加哥彈性擴展單元（我們稱之為SU1）保持不變，但我們打算在該彈性擴展單元之前增加另一個單元，新增的單元被命名為SU0。
在這一過程中，首先我們會將所有沖刺（sprint）版本部署至圣安東尼奧?(Scale Unit 0)，在這個位置運行一段時間。如果感覺一切正常，才會將其滾動部署至芝加哥的單元?(Scale Unit 1)，如圖2所示。當然，如果SU0遇到問題，還可以修復問題并重新啟動新一輪的部署。后來我們又在這個序列中加入了更多Azure數據中心。到2014年秋季，我們增加了阿姆斯特丹作為第五個數據中心。隨著業務繼續擴展至全球更多地區，很快我們還將加入澳大利亞。在以上過程中，我們都在使用Visual Studio Release Management來處理部署流程和自動化滾動更新等操作，每一個沖刺版本都是這樣部署的。
?
??圖2：2013年11月之后，VSO從原本的一個數據中心擴展至多中心，借此實現“金絲雀”部署和全球落地。
對于線上環境服務質量的重視立刻獲得了立竿見影的效果。從2014年4月服務月度點評（圖3）中可以看到，2013年11月共出現了43個線上問題（LSI），六個月后驟降至7個，其中僅兩個來自正式發布（非預覽）的服務。我們還在持續完善自己的DevOps實踐和運維實踐，注重保持線上環境的健康狀況，不過接下來還有很長的路要走。
圖3：到2014年4月，VSO僅觸發了7個LSI，六個月前這一數據還是43個。在這七個LSI中，只有兩個是已經正式發布的服務造成的。
我們如何從敏捷轉型為DevOps
七年來，微軟全球開發平臺工程團隊?(Developer Division, DevDiv)一直在擁抱敏捷。借助切實可行的工程實踐，我們從XP時代逐漸積累的技術債減少了15倍。我們為部門內部負責不同方向的團隊和產品負責人提供Scrum培訓，并將為客戶提供價值作為一切的核心。在發布Visual Studio 2010時，該產品線獲得了前所未見的客戶認可。[ii]
發布VS2010之后，我們很確定是時候將Team Foundation Server轉型為軟件即服務?(SaaS)的研發云產品了。該服務的SaaS研發云最早被命名為?Visual Studio Online (VSO)，現在已經改名為Visual Studio Team Services(VSTS)?研發云，托管于Microsoft Azure (不過在我們工程團隊內部還是習慣使用VSO來稱呼這個產品)。為了繼續延續之前的成功，我們需要開始采用更多的DevOps實踐，這也意味著我們需要將實踐從敏捷轉型為DevOps。這兩者有何差別？
DevOps文化的特點之一在于需要從使用中學習經驗。對于敏捷，有一種心照不宣的假設，認為產品負責人是無所不知的，能夠正確提出產品的規劃和新的需求列表。與之相反，在運行某種高度可靠的服務時，你可以用近乎實時的方式觀察用戶是如何使用不同功能的。你可以更頻繁地發布新版，通過實驗進一步完善，衡量并詢問客戶對不同改變的看法。這一過程中所收集的數據將成為后續一系列改進的依據。通過這種方式，DevOps產品的需求列表實際上是一系列假設，最終會變為軟件運行過程中所做的實驗，并可促成持續不斷的反饋循環。
如圖4所示，從敏捷中催生出的DevOps基于四大趨勢：
圖4：這四大趨勢推動了DevOps的演變。
與很多“生于云端”的公司不同，我們最開始并沒有SaaS產品，客戶主要在PC端本地環境中使用我們的軟件（Team Foundation Server最初發布于2005年，現已發布了2017版）。在開發VS Online，也就是現在的VSTS研發云時，我們決定為SaaS和“盒裝”版本的產品維護同一個代碼庫，但采取云為先的開發策略。工程師在推送代碼后將觸發持續集成流程。當為期三周的沖刺結束后，我們會發布到云端，進行4-5個沖刺后，會為“盒裝”產品發布一個季度更新，過程如圖5所示。
圖5：我們為VSTS研發云（SaaS產品）和TFS（本地運行產品）使用了同一個代碼庫。每三周，我們會將新功能部署至VSTS研發云。每季度，這些更新會滾動發布至TFS。在發布重大TFS更新，如2015版時，則會基于當時VSTS研發云的版本進行。
暴露控制
在開發服務的過程中，高頻率發布會讓我們獲益匪淺。在我們的工作中，我們會在為期三周的沖刺結束后發布。借此我們可以更及時地將工作成果展現給用戶，但我們需要對暴露的時機進行一定的控制。這方面我們遇到了一些問題：
l?如何處理需要多次沖刺才能完成的功能？
l?如果明確知道某個功能隨后需要改動，又該如何針對不同功能進行實驗以便了解使用情況和用戶反饋？
l?如何通過“灰度上線”在做好對外發布和公開推廣之前引入新的服務或功能？
對于所有這些問題，我們選擇了功能開關這種模式。功能開關是一種控制機制，決定了要將何種功能暴露給哪些用戶或用戶組。隨著團隊針對新功能開展工作，我們可以通過功能開關服務注冊一個開關，這種開關默認處于關閉狀態。在準備好讓某些用戶嘗試新的功能后，即可為這些用戶在生產環境中打開對應的開關，并根據需要決定何時關閉。如果要改動對應的功能，無需重新部署即可關閉這個開關，停止該功能的對外暴露。
通過這種方式實現漸進式的暴露控制，功能開關還提供了一種供我們在生產環境中進行測試的好方法。通常一開始我們會將新功能暴露給內部員工，隨后暴露給早期用戶，隨后逐步暴露給更廣泛的客戶群體。通過對性能和使用情況進行監控，可以確保新的服務組件在大規模環境中可以正常無障礙運行。
代碼速率和分支
當我們于2008年首次采用敏捷開發時，我們認為可以通過適當的質量門禁?(Quality gate)?和代碼分支結構開發出更高質量的代碼。早期的開發工作會使用一些異常復雜的代碼分支結構，只能接受按照嚴格定義編寫的代碼，通過封閉簽入（gated checkin）機制，確保新提交的代碼必須和主干代碼完成預合并，并經過構建策略的檢查后才能真正進入配置庫。
這種代碼分支結構造成了一種始料未及的后果：很多時候我們需要花費數周甚至數月的時間才能把葉子分支上的代碼逐層合并進入主干。而分支中的代碼將長時間處于未合并狀態，這又會為合并工作造成大量遺留債務。當工作成果已經準備好進行合并后，主干可能已經進行了大幅度的改動，導致出現合并沖突，進而需要花費大量人力物力進行協調。
2010年，我們采取的第一個措施是將代碼分支結構大幅“壓平”，僅保留很少的分支，并且保留的分支大部分也是臨時的。我們明確了目標，要優化代碼流動速度，換句話說，就是將代碼簽入和可被其他人獲取的間隔時間降至最低。
隨后我們使用Git打造了一個分布式版本控制系統，該系統目前也已被VSTS研發云和TFS所支持。我們的大部分客戶和同事依然在使用集中化的版本控制系統，因此VSTS研發云和TFS可以同時支持這兩種模式。Git的優勢在于可以實現非常輕量級的臨時分支。我們可以為工作項創建特性分支，并在將變更合并到代碼主干后進行立即清理掉該特性分支。
提交后的所有代碼位于Master（主干）中，同時Pull-request工作流結合了代碼審閱和質量門禁功能。借助這些能力，代碼合并工作已經可以通過簡單的小批次操作持續進行，每個人隨時都可以看到最新的代碼。
這種流程可以在短時間內對不同開發者的工作進行隔離，隨后以持續的方式集成在一起。這種臨時分支還降低了后期維護的開銷，可在不需要時徹底刪除。
Agile on?Steroids
我們依然在遵循Scrum的原則，但為了促進交流和跨地域擴展，只保留了其中的精髓。例如我們工作主要以功能小組?(Feature crew)?為單位，這類似于Scrum中團隊的概念，但產品負責人需要加入團隊并參加所有日常工作。產品負責人和工程主管聯手代表整個團隊。
我們還運用了團隊自治和組織整合?(Organizational alignment)?的原則，借此功能小組中產生了新的變化。團隊往往涉及多個領域，我們通過整合開發人員和測試人員的職業晉升路徑將這兩個角色統一成了一個工程角色（此舉大幅提升了士氣）。
所有團隊都是內聚的。每個小組有8-12名工程師，我們會盡可能確保他們至少可以共同工作12–18個月，很多團隊的合作時間甚至更長。如果因為工作原因需要調整，我們會建立第二個小組來處理積壓的工作，而不會讓工程師在不同小組間來回更替。每個功能小組都有自己的團隊辦公室，如圖6所示。這樣的辦公室并不是那種大面積開放式空間，而是一個專屬的房間，可供大家針對同一個領域開展工作并自如地交流。團隊辦公室旁邊還為可能的突發情況準備了小的“焦點辦公室?(Focus Room)”，這種辦公室中，我們也非常鼓勵自由的交流。到了每日站立會議時間時，大家都會站起來暢所欲言。
圖6：在同一個團隊辦公室中干活的功能小組成員。
根據經驗，我們最終選擇以三周為一個沖刺周期。事實證明對于我們這種需要全球協作的任務，很難在更短的時間里為客戶提供足夠多的價值，而如果選擇更長的周期，則會影響新功能的發布速度。微軟內部一些部門以兩周為一個沖刺周期，但也有一些部門甚至會每天多次針對新工作成果展開各種實驗，不會受到沖刺的約束。
從概念上來看，“完工”的定義其實很好理解。構建，運行，這樣就行了。當一次沖刺結束后，你的代碼會正式部署給數百萬用戶，如果代碼中存在任何問題，你（以及其他每個人）立刻就能知道，并可立即開始修復問題根源。
我們會輪流擔任ScrumMaster?這個角色，這樣每個人都有機會體驗Scrum Master的管理責任。在對外交流方面，我們會讓沖刺的儀式?(Ceremony)?盡可能簡潔。每次沖刺開始時，隊員從產品積壓工作列表?(Product Backlog)中領取任務，并通過一封篇幅不超過一頁的郵件就自己的沖刺計劃進行描述，郵件中需要添加指向VSTS研發云中產品積壓工作列表內容（PBI）的超級鏈接。大家可以通過回復這封郵件的方式共同對沖刺進行審閱，同時，團隊還會提供一個大約三分鐘左右時長的視頻。視頻中包含演示，會從客戶的角度介紹通過本次沖刺所能實現的目的。
我們還會確保計劃盡可能簡單。通常來說，會針對未來18個月的工作制定愿景，并朝著這個方向努力。愿景可以通過多種形式體現，例如技術尖峰?(Spike)、故事板?(Storyboard)、概念視頻，以及概括性文檔。我們以每6個月為一季，“春季”或“秋季”，在這段時間內我們會圍繞整個團隊的承諾和依賴關系堅持不懈地完成工作。每三次沖刺后，功能小組的領導者會聚在一起進行一次“功能溝通會”，借此分享希望達到的優先級，修正后續工作方向，與其他團隊交流尋求新的目標并確保所有團隊保持一致。例如可以使用功能溝通會重新對網站工作和用戶可見的功能進行劃分。
構建—度量—學習
在經典敏捷實踐中，由產品負責人對產品積壓工作項?(PBI)?進行優先級排序，大家會或多或少地將其視作一種需求。PBI?可能體現為用戶故事，形式可能非常簡單，但必須是確定無誤的。我們以前就是這樣工作的。
但現在不是了。為了遵循DevOps實踐，我們會將PBI視作“假設”。這些假設必須能轉化為實驗，借此獲得能夠支撐或減少實驗的證據，隨后，我們還可以從這些證據中學到切實可行的經驗。[iii]
進行一個足夠好的實驗，要求有具備統計學意義的樣本，同時還有用于對照的控制組，此外還需要理解不同因素的影響結果。例如圖7中的這個例子，我們遇到了一個問題：VSTS研發云的新用戶并沒有立刻創建團隊項目，而沒創建團隊項目會導致用戶無法執行其他絕大部分操作。圖7展示了在網頁上開始創建團隊項目時的界面。
圖7：原本的方法需要執行太多操作，并且很容易讓用戶分心，很多用戶希望能以更自然的操作來創建項目。
我們修改了Web端和IDE中的這部分體驗。圖8顯示了IDE中的新體驗，該體驗會鼓勵用戶通過兩個界面注冊VSTS研發云并建立項目。我們借助六個彈性擴展單元中的兩個對這個新體驗進行了實驗。
圖8：在兩個彈性擴展單位中為IDE實現了更完善的項目創建體驗實驗。
這次IDE實驗的影響如圖9所示。新客戶創建團隊項目的比例由3%增長至20%（增幅約七倍）！
圖9：IDE中的流程變動讓新用戶通過IDE創建項目的比例從3%增長至20%。
于此同時，我們還改進了Web界面的注冊過程，也獲得了非常明顯的效果。圖10展示了Web注冊所做的改動。
圖10：Web注冊通過類似的簡化可以在第二個界面上直接建立項目。
我們統計了在注冊帳戶當天就建立了團隊項目的用戶比例。這一比例從原本的約18%增長至30%（約1.7倍），如圖11中從綠色過渡至黃色的柱狀條所示。雖然結果喜人，但其實這一結果與我們預期相差較遠，同時與IDE方面的所取得的大幅提升之間有很大的差距。
圖11：Web帳戶創建的結果由于兩個實驗出乎意料的相互干擾而被誤導。排除這些因素后，結果就很清楚了。
后續調查中發現，我們其實還在同一時間進行了另一個實驗。在這個實驗中，位于漏斗頂端很多不符合要求的用戶也被鼓勵注冊帳戶，但他們并未這樣做。這也證明了我們的控制組不夠完善，兩個實驗相互之間產生了干擾。在停止了用于加速創建帳戶的實驗后，項目創建比例激增至50%，如圖中綠色柱狀圖所示（增加2.8倍，比IDE中的效果還要好2.5倍）。
這個故事的寓意在于，實驗的執行過程有好有壞，并不能總是很明顯地確定結果是否合理，是否可重現，以及是否受到了妥善的控制。
為DevOps打造的工程系統
VSTS研發云是一種24x7x365可用的全球化服務，提供了包含財務保障的99.9%高可靠性。但是要注意，99.9%的SLA并不是我們努力實現的目標，而是最低程度的保障，因為低于該標準我們就要給用戶退款。我們的目標是做到100%的高可用和客戶滿意：不因為維護而停機，無需全新安裝只需更新，整個過程完全自動化。這就要求所有服務必須相互解耦，具備明確的調用規則和清晰的版本控制。與很多客戶的系統類似，VSTS研發云也運行在Azure公有云上，整個基礎架構都由Azure提供。
自動化部署
該服務的部署和網站可用性工程是由一個名為服務交付?(SD)?的小型團隊管理的，該團隊直接向工程團隊負責。每次沖刺后的下一個周一，SD團隊會開始進行部署。部署過程可通過Visual Studio Release Management自動實現，如圖12所示。我們會在工作時間內進行部署，這樣一旦遇到問題也可以更方便地進行調查和補救。由于VSTS研發云中存儲了客戶數據，而數據庫架構經常需要更新，因此無法進行真正意義上的回滾，只能進行前滾。滾動操作會自動從一個彈性擴展單位延續到下一個彈性擴展單元，首先從金絲雀彈性部署單元SU0開始。借助這種方式，我們可以循序漸進地對功能暴露進行控制，檢查運行狀況和用戶體驗，以便推進下一步的部署。
圖12：VS Release Management控制著從一個彈性擴展單位按順序向著下一個彈性擴展單位進行部署。
每個部署都從SU0開始，部署完成后維持運行幾小時，隨后繼續進行下一單元部署。如果遇到問題，能在SU0順利解決是最理想的情況，我們會針對問題根源進行修復，隨后繼續部署。如果數據受損必須進行災難恢復（萬幸這種情況只出現過一次），我們也只會在SU0中針對自己的數據，而非客戶的數據進行恢復。
遙測
遙測機制可以說是VSTS研發云中最重要的代碼。如果服務本身有問題，監控機制也必須保持可用狀態。如果服務遇到問題，監控警報和儀表板需要能立刻匯報相應的問題。圖13展示了一個服務運行狀況概述的示例。
圖13：這是組成VSTS研發云服務遙測功能的眾多頂級圖表之一。
VSTS研發云每個組件都經過精心設計，能針對可用性、性能、使用情況，以及排錯提供360°視圖。遙測也遵循了類似原則。
我們寧愿做可能會沒有用的工作，也要盡可能收集一切信息。
我們會努力專注于各種切實可行的度量指標，而不是那些浮夸無用的指標。
除了反饋本身，我們還會度量各種結果和比例，借此來確定所采取的各類措施的效果。
平均每天我們會收集60GB-150GB的遙測數據。雖然可以向下挖掘至特定客戶的相關信息，但按照我們的隱私策略，除非客戶選擇與我們分享，否則所有的數據都會匿名化處理。我們收集的部分數據包括：
活動日志。我們會針對VSTS研發云服務收到的Web請求收集所有數據。借此可以追蹤每個命令的執行耗時和次數，進而判斷特定調用或依賴服務是否變得緩慢或需要頻繁重試。
跟蹤記錄。任何問題相關的堆棧跟蹤（Stack Trace）信息都會被記錄，并用于對調用序列進行調試。
作業歷史。作業是一種對跨越服務的活動進行編排的工作流。
性能計數器。這些計數器與執行性能排錯問題的計數器類似，可以追蹤系統資源運行狀況，VSTS研發云每天會生成約5千萬條事件。
Ping Mesh。這是一種對網絡基礎層進行快速可視化的方法，借此可以保障全球網絡連接的可用性。
綜合事務。也叫“由外至內的測試”，通過Global Service Monitoring運行，可從全球用戶的視角檢測運行狀況。
客戶用量。在用量方面我們會度量自己的“流量入口”、轉化漏斗、參與情況，以及首要客戶。
KPI指標。這些是遙測系統通過計算匯總的指標，借此可判斷服務的商業健康度。
追蹤
最重要的一點，我們必須避免將任何事情當成是理所當然，每個人都接受“線上文化”的理念。換句話說，服務狀態永遠被我們放在第一位。如果線上遇到了問題，那么所有人必須優先加以處理，問題的檢測和補救是此時的頭等要務。我們的所有走廊里都安裝了實時儀表板，服務運轉好壞所有人都一目了然。
所有活動網站問題(LSI)?都會記錄到VSTS研發云中，進而用于分析根源并每周審查。圖14展示了LSI的一個范例。
圖14：生產服務遇到的每個事件，包括補救根源問題的相關細節均會通過LSI進行追蹤。
當警報響起
DevOps的一個常見問題是：“誰帶著傳呼機？”在我們這里，成員遍布世界各地的服務交付?(SD)團隊永遠是24x7保障的第一道防線。如果需要將問題上報至開發團隊，他們會按照功能小組所定義的指定負責人(DRI)?的工作時間安排進行上報。我們對服務層面的預期為，DRI能在5分鐘（工作時間）或15分鐘（下班時間）里接手。
我們對“補救”的看法也很重要。我們的補救不是切換一個虛擬機那么簡單，而是要修復造成問題的根本原因。這種做法有點類似于豐田在工廠里安置的報警拉繩?(Andon cord)，如果在流水線上發現殘次品，任何工人都里可以拉繩報警。[i]我們希望從來源位置修復代碼或配置問題，通過完善測試和發布流程預防相同問題再次發生。所有線上問題響應的度量指標都是以分鐘為單位來衡量的。
這方面我們取得了一個巨大的成果，通過足夠精確的警報機制，可以在無需人工介入的情況下自動聯系DRI。為此我們建立了一個消除噪音和冗余警報，建立智能邊界的運行狀況模型，用它判斷真正需要采取措施的時機，該模型如圖15所示。借此我們在2015年2月將警報精確度提高了40倍，所有P0和P1警報都能自動上報給負責人。
圖15：這個運行狀況模型可以自動消除重復的警報，并判斷問題根源可能在哪個功能領域中。
從用戶的體驗中學習
盡管為工作制造了不少困難，但我們在工程中的方方面面都在逐漸更貼近用戶體驗。例如計算出99.9%的服務級別協議?(SLA)所采用的方法就是一個很好的例子。
SLA本身并不是我們的目標。我們的目標是100%的滿意度。這意味著我們需要執著于可能只占0.001%的異常情況。因為異常情況往往隱藏在平均情況中，為了讓SLA的計算更嚴謹，我們陸續開發了三代算法。這三代算法的具體情況如圖16所示。最初我們使用了由外至內的監視（下圖中虛線所示）用來追蹤服務器的可用性。第二代算法主要關注相對所執行命令的總數，執行緩慢或失敗的命令的相對數量，借此找出更普遍的異常情況所對應的問題（下圖黃線和藍線）。隨著服務繼續完善，“分母”已經排除了大部分不符合要求的客戶所對應的情況。目前我們采取的計算方法是計算用戶所遇到的服務不可用的分鐘數在總使用分鐘數中所占的比重，用黑線代表。
圖16：這個LSI圖對比了三種計算SLA的方法。由外至內的監視沒發現任何問題，追蹤命令執行結果的方法顯示有一小時運行緩慢，而真實用戶的監視發現經歷了三個小時的響應延遲。
從上述四小時的統計可見，第一個（虛線）SLA顯示沒有任何問題。第二個（黑線）顯示問題持續一小時，第三個顯示性能低下持續三小時。實際上我們并不“需要”如此嚴格的度量，但還是這么做了。只為打造更優秀的服務。
安全性
作為例行安全實踐的一部分，我們需要提供有保障的數據隱私、數據保護、服務可用性，以及服務安全性。過去，對于本地部署的軟件，為了構建縱深防御機制預防安全問題，我們付諸了巨大的努力。很明顯，現在依然需要這樣做，此外我們還開始假設服務已經被攻陷，并考慮該如何檢測這樣的入侵行為。[ii]
除了使用SU0進行金絲雀部署，我們還可以通過這個數據中心進行安全演練，這么做的目的與消防演練類似，是為了進一步加固VSTS研發云服務。通過這樣的彈性擴展單元進行模擬攻擊，無需擔心可能會對付費客戶的服務造成任何影響。
新的開發模式
以往只開發本地部署的軟件時，我們會通過對工程系統和流程進行優化實現最小化的平均故障間隔時間。換句話說，我們會將軟件發布給客戶，如果隨后發現有錯誤需要糾正，修復成本是極為昂貴的，因此我們會盡可能提前采取一切措施發現可能存在的問題，盡量避免需要發布新的軟件版本。
DevOps徹底改變了這種做法。如果能通過“無痛”的重新部署將修復成本降至最低，那么此時的目標將截然不同。周期時間、發現時間、補救時間，學習時間，所有這一切時間都需要降至最低。
這也催生出多種彈性設計模式。依賴項有可能發生故障，最有可能在流量峰值時期出現。因此服務必須能夠平穩地降級，具備周全的重試策略，例如“斷路開關”就是如此，[iii]而且需要能通過類似混沌猴子?(Chaos monkey)?那樣的實踐進行加固，這種方式是?Netflix?發明的。[iv]
災難恢復計劃至關重要，而我們會在模擬攻擊的時候對這些計劃進行測試。無心之失或重大災難隨時有可能發生，我們需要對此做好準備。
開源
在我們轉型方法的過程中，越來越多地以用戶和貢獻者的身份加入到開源軟件?(OSS)?社區中。OSS工作流程的中的重點在于分享、復用和協作。OSS鼓勵提供可以單獨發布，松耦合的協作服務。
如果針對我們遇到的問題有現成的?OSS?解決方案，我們會直接使用，而不會“重新發明車輪”。如果我們開發的一些東西能夠讓更多人獲益，我們會分享給社區。對于創造出受歡迎組件的工程師，我們會給予獎勵，同時我們也鼓勵公司里的每個人直接利用獲得批準可以使用的組件。任何工程師，都可以為公司里任何產品的改進貢獻自己的力量。與此同時，在內部，我們還會提供企業代碼監管機制，并要求為產品提供更長的支持時間。
學習的平均時間
事件發生后，只有經過調查并從中總結出經驗教訓才算徹底處理完成。我們會使用“5個Why”[v]從不同角度記錄下次該怎樣才能做得更好。如果出現影響到客戶的故障，Brian Harry會以責任高管的身份發布博客文章，解釋具體情況以及從中學到的經驗。這個博客類似一種公共記錄和追責機制，促使我們不斷地精益求精。[vi]
客戶對于這些博客文章的反應讓我們感到吃驚。在介紹過自己是如何把事情搞砸后，客戶對我們表示了感謝。這樣的透明度是一種好事，相比供應商與客戶之間傳統的互動方式，可以塑造出更富有成效的關系。
業務與工程的融合
過去，很難將業務和工程問題放在一起考慮，因為那樣需要花很長時間才能看到相關決策所產生的結果。DevOps改變了這一點。我們希望能在用戶首次與我們互動時就提供出色的用戶體驗，也許用戶只是在網上搜索信息，或者試用產品。我們希望在遙測技術的幫助下，與用戶的每次接觸都能讓用戶感到滿意，我們也會盡可能與主要客戶進行一對一互動，借此更好地了解他們的想法。
例如，我們會將每個客戶的發展歷程看作是一個漏斗，而我們會面臨很多漏斗。這個歷程可能始于某個網頁，通過試用，最終成功使得用戶開始在Azure、本地，或其他地方部署。如果在漏斗的任何一個環節我們對成功率不夠滿意，那么我們會針對改進措施提出假設，對相關變動進行實驗，并度量實驗的結果。我們會將業務實驗與服務其他方面的實驗一起評估，例如活動網站、當前和活躍用戶的月增速等。我們會謹慎地確保可以關注最可行的度量值，而非那些華而不實的度量值。
我們還發現最好能將度量值與定性的客戶反饋放在一起考慮。我們會通過多種方式收集反饋，其中最高級別的接觸是“頂級客戶項目”。我們會通過這些項目讓工程團隊的成員自愿地與某個最重要的客戶建立聯系，大約每月進行一次交流。借助這樣的機會，我們可以更清楚客戶喜歡什么，不喜歡什么，有什么愿望或困惑等，當然具體情況是不能在這里公布的。我們還有一個主要由MVP以及親密客戶組成的內部“圈子”，我們會大約每周一次與他們通過在線會議分享想法。他們會對假設階段的場景發表自己的看法，通常這會以故事板的形式進行，并會在實際執行前很久就開始對優先處理的工作發表意見。此外我們還有uservoice.visualstudio.com?等渠道，供所有人提供建議并投票。
經驗：卓越與否用實踐來證明
隨著接受DevOps，我們需要從七個實踐領域對具體的成長進行評估，我們大家都認為這已經是“新時代的敏捷”。
圖17：在掌握DevOps的過程中，我們試圖通過七個實踐領域進行持續的完善和改進。
敏捷的調度和團隊。這一點與敏捷是相同的，但更輕便。涵蓋多個領域的功能小組從一個通用的產品積壓工作列表中領取任務，通過盡可能少的工作完成整個流程，并在每個沖刺結束后交付可供部署的成果。
技術債的管理。任何技術債都蘊含風險，最終會導致各種計劃外工作，例如可能干擾計劃內交付的線上問題。我們會慎重對待任何類型的技術債，并會通過周密的安排在它們影響到所交付的服務質量前順利解決。（偶爾可能會判斷失誤，例如上文講的VS 2013發布之前遇到的情況，但我們會通過溝通盡可能維持透明度）。
價值流。這意味著按照對客戶的影響決定積壓工作的優先級，專注于為客戶提供價值。原本的敏捷方法中我們經常會談到這一點，但直到現在，通過DevOps遙測機制，我們才可以度量這樣做的成功與否，以及是否需要調整方向。
基于假設的積壓工作。在使用DevOps前，產品負責人會根據有關人員的最佳反饋“美化”積壓工作列表。但現在我們將積壓工作視作一種假設，需要將其轉變為實驗，因此需要收集能夠支持或減少這些假設的數據。我們會根據證據來決定后續的積壓工作，以及到底是堅持進行（更多工作）還是嘗試（其他不同的思路）。
證據和數據。我們對一切進行了監控和數據收集，不僅僅是為了了解運行狀況、可用性、性能，以及有關服務質量的其他指標，這也是為了更好地理解使用情況，并收集與積壓工作的假設有關的證據。例如，我們會對有關用戶體驗的改動進行實驗，衡量對漏斗轉化率的影響。我們會對不同用戶群的使用情況數據進行對比，例如工作日和周末使用情況，借此假設出每種情況下可以繼續改善體驗的方法。
生產為先的心態。只有服務質量始終卓越，才能得到可靠的數據。我們會不斷追蹤線上網站的狀態，對造成各種問題的根源進行補救，主動發現性能方面的異常，并判斷造成這種情況的原因。
為云做好準備。只有對架構進行持續完善，重構為更獨立、相互分離的多個服務，并借助公有云靈活的基礎架構，才能提供24x7x365不間斷運行的服務。如果需要更多容量，可以從云（我們使用了Azure）中獲得。我們開發的每個新功能都首先以云端為主，隨后才會被納入本地運行的產品，僅有少數有意為之的例外情況。于此同時，我們可以確信自己的產品經過了大范圍的加固，并能通過客戶的堅持使用獲得持續不斷的反饋。
參考：
1.?相關詳情回顧請參閱：http://blogs.msdn.com/b/bharry/archive/2013/11/25/a-rough-patch.aspx
2.?具體范例可參閱?Gartner ALM Magic Quadrant
3.?Ries, Eric (2011), The Lean Startup.
4.?Liker, Jeffrey (2003), The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer
5.?參閱：http://aka.ms/redblueteam
6.?https://msdn.microsoft.com/en-us/library/dn589784.aspx
7.?http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html?以及http://blog.smarx.com/posts/wazmonkey-chaos-monkey-for-windows-azure
8.?http://en.wikipedia.org/wiki/5_Whys
9.?示例：https://social.msdn.microsoft.com/Search/en-US?query=outage&beta=0&rn=Brian+Harry%26%2339%3bs+blog&rq=site:blogs.msdn.com/b/bharry/&ac=4
原文：https://mp.weixin.qq.com/s/avcAo1XtY71H_ItJNhL6EQ
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的大规模开发团队如何实现DevOps转型？ 来自微软全球开发平台工程团队的实践经验的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ABP前端使用阿里云angular2 U
- 下一篇： kubernetes实践之运行aspne