DevOps的五大實踐及轉型具體實施過程

DevOps的五大實踐及轉型具體實施過程，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

那么DevOps轉型的正確姿勢應該是怎樣的呢？

DevOps轉型的五大實踐

實踐一：習慣小批量的方式工作（開發、架構、組織文化的演進）

持久的變革需要以小批量、持續的方式進行，通過反復實驗、根據反饋循環快速學習，找到最正確的實施路徑。這樣需要把大的問題拆成一系列小的問題逐個、漸進式解決，也許這樣沒有Big Bang式的變革令人激動，但這才是讓我們成功的正確姿勢。

1. 找到最重要的工作

最經典的例子就是項目管理，傳統上按半年或一年規劃并申請預算，這驅使我們工作在大型復雜項目上，大量時間花在特性在待辦清單（Backlog）中等待被分析、估算、批準和排優先級等事務性工作上。一份稱為"黑天鵝農場"的白皮書顯示，他們分析了3000個待辦清單中等待開發的不同需求，使用延遲成本（如果不做這個需求，每周損失的成本）的優先級決策方式。

他們發現，在待辦清單中有三個特性，如果不交付這些特性，每個特性每周給組織帶來200萬美金的損失。這幾個特性隱藏在龐大的待辦清單中，但確實極為關鍵的。他們意識到應當停掉手頭所有工作，以最快的速度交付這三個特性。從統計數據上看，這種情況符合冪律分布，如下圖所示。

所以我們的工作就是要在多個項目中間，找到那些真正重要的，這需要更加透明、更加清晰的優先級，以及組織中每個人的協作。

2. 架構的持續演進

很普遍的情況是，很多組織擁有大量的遺留系統，一些軟件或硬件過于老舊，可能廠商已經不再支持了，有些組織的個別系統甚至沒有源代碼（可能在乙方手中或已丟失）。這類組織通常選擇通過長達一兩年的架構再造解決問題，而當進行到一年的時候，他們可能會說，系統復雜度實在太高，我們還需要額外的兩年！我本人就親歷過這樣的超大型項目，最后負責的CTO都換人了，項目還沒做完。

以上描述的場景，關鍵的問題是，大家的關注點常常在架構的技術層面而不是需要達到的結果上。調查數據顯示，如果以下問題的回答都是Yes，那么你更有可能做好持續交付和DevOps，成為高效能IT組織：

• 是否無需團隊外的某人或其他團隊授權就可以進行自身系統大范圍的設計變更？

• 是否無需與團隊外的其他人員進行細粒度的溝通就可以完成自身的工作？

• 是否可以獨立于其他依賴的服務或產品，按需部署和發布自身的產品或服務？

• 是否無需依賴復雜的集成測試環境，就可以按需進行大多數自身系統的測試？

• 是否可以在日常業務時段，執行無停機的部署？

你可以在老舊的遺留系統上實現以上全部這些效果，但也可能在充滿高科技、新技術的情況下，無法達到以上效果的任意一條。所以我們要關注的是架構演進的結果，而不僅僅是使用炫酷的技術。

關于演進式架構的更多內容，以及絞殺者模式的思路，我之前的文章也有介紹，其主要原則如下：

• 從交付業務所需的新功能開始（至少在初期是這樣），新功能使用面向服務的設計

• 不要重寫已有的功能，除非能夠使它持續簡化

• 通過不斷拆分，更快的進行交付

• 為可測試性和可部署性進行設計

• 新的架構運行在PaaS平臺上

實踐二：創建反饋循環

在小批量工作的基礎上，我們要建立起反饋循環。反饋循環讓我們能夠持續學習，基于學習進行持續改進，這也是敏捷和學習型組織的關鍵原則。

持續交付流水線就是反饋循環的具體實現，可以提供多個層次、多個鏈路的反饋信息，并且可以在反饋效率和反饋完整性之間取得平衡。 
以下是去年我與朋友合作的全開源持續交付流水線的設計圖和效果圖，充分體現了流水線的遞次晉級和反饋循環的原則。 
 
全開源流水線只能滿足中小企業的需求，在大型企業中的流水線設計和實現更為復雜，我后面找時間再跟大家單獨介紹。

實踐三：通過價值流進行跨職能協作

需求、開發、測試、信息安全、運維等角色需要在軟件交付價值流中協同工作。價值流圖是促進跨職能協作的關鍵工具。我們可以通過開展價值流梳理的Workshop，識別支撐價值流的各種角色以及角色之間的協作關系。我們不需要文檔化價值流中每一步的細枝末節，而是理解價值是如何傳遞的，各角色是如何協同工作的。

以上模型不僅停留在理論層面，更可以應用在實踐領域。

案例一. Google的災難恢復測試

Google在幾年之前進行過一項研究，如何打造一個優秀的團隊。他們調研了來自180個Google團隊的200位受訪者，觀察了超過250項不同的因素，比如團隊中有人取得博士學位、有性格外向的人，有人著迷于AngularJS等等。但他們最終發現打造高效能IT組織，排在第一位的因素是：心理上的安全感，即可以在團隊中承擔風險而不會感到不安全或者受到傷害。

我們需要構建一個安全的環境，讓失敗是可以接受的，并且作為組織學習的基礎。Google和Amazon都會在線上進行災難恢復測試，確保在發生嚴重故障時，故障恢復策略真正有效，系統仍然可以正常運轉。 
Google有一整個團隊專注于計劃和實施災難恢復測試，甚至有一年模擬外星人侵入硅谷的場景，他們斷開山景城與外界的光纜連接、關閉數據中心并對基礎設施施加真實的影響，但要求團隊必須要維護服務級別目標。他們設計的災難恢復測試，需要由來自很多不同組、平時不在一起工作的工程師相互協作，那么在大規模災難真正來臨的時候，他們已經建立起了很強的工作關系。

案例二. Etsy的"三只袖毛衣"獎勵

Etsy每年舉辦開發者大會，會發給過去一年中生產環境最大中斷的制造者一件"三只袖毛衣"作為獎勵。那么為什么獎勵是三只袖毛衣呢？因為Etsy的404頁面中有一張三只袖毛衣的圖片。

實踐五：持續消除浪費，優化價值流

DevOps需要持續改進，移除浪費，讓價值流動變得更加順暢。我近期輔導了一些團隊使用價值流圖的方式進行流程和問題梳理，發現這的確對組織認知和優化現有軟件交付過程非常有幫助。

DevOps的轉型并不簡單，想要走上成功之路，這里還有幾個Tips：

• 對可度量的業務目標達成一致。制定"跳一跳可以達到"的目標，比如減少10%嚴重缺陷數、提升20%服務可用時長、達到2倍的發布頻率，或者其他混合的結果指標。

• 給團隊資源進行實驗并對學習進行激勵。團隊無法在日常工作照舊的前提下，"加班"進行改進的探索。改進是要有真實工作量投入的，這應當與開發新功能、修復缺陷以同樣的方式進行優先級排序。具體來講，可以使用看板管理WIP，指派專職的團隊全職做改進工作，或者每周給團隊一個特定時間用于做改進工作。

• 與其他團隊溝通，鼓勵協作。很多人經常提及合規、安全、治理等團隊，認為他們是改進的阻礙。但其實如果與這些團隊進行友好的溝通，你可能會發現他們非常期望討論獲得雙贏的具體措施。

• 取得速贏。你需要在一到兩個月做出改進的效果。具體來講有三個關鍵點：首先，通過價值流圖或約束理論，找到一個影響最大的、并且可以快速解決和可被度量效果的問題；其次，限制首次進行改進的范圍，最小化改進工作；然后，與對改進有興趣并有充足容量和能力的團隊合作，取得速贏。

• 分享成功經驗。為了獲得其他人的支持，你需要做好成功經驗的宣傳工作，吸引更多的人加入到改進工作中來。比如有的企業組織內部的DevOpsDays大會，跨部門進行經驗的推廣，這非常有效。另外午餐學習會、內部博客、郵件列表、Slack或HipChat頻道都是獲得參與者最好的渠道。還要對其他嘗試的人提供幫助，就像DevOps教練應該做的工作那樣。

• 持續改進。高效能的組織永遠追求改進的機會。就像豐田管理系統的締造者大野耐一所說的："Kaizen [improvement] opportunities are infinite"，改進的機會是無窮無盡的。百度集團總裁兼COO 陸奇在去年的一次演講中也講過："Engineering Excellence 是一個永無止境的、個人的、團隊的，能力的追求和工具平臺的創新，綜合在一起可以帶給我們帶來的長期的、核心的競爭力"。Relentless pursuit of excellence，這是我們應該堅持的態度。

• DevOps轉型的五大實踐。習慣小批量的工作方式（開發、架構、組織文化的演進）、創建反饋循環（流水線建設）、通過價值流進行跨職能協作、建立實驗的組織文化、持續消除浪費并優化價值流；

• DevOps轉型的具體實施建議。關注DevOps轉型的關鍵能力要素，對可度量的業務目標達成一致、給團隊資源進行實驗并對學習進行激勵、與其他團隊溝通并鼓勵協作、取得速贏、分享成功經驗、持續改進。

看完上述內容，你們掌握DevOps的五大實踐及轉型具體實施過程的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！