DevOps轉型成功之路 - 五大實踐及轉型具體實施建議

在上一篇文章《DevOps轉型成功之路 - 轉型的意義及五大誤區》中，咱們從鳥飛派和空氣動力學派的類比提及，DevOps的轉型不能照搬其餘組織的實施過程，而是應該深刻理解其背後的原理、原則和實踐。上篇文章重點介紹了DevOps轉型的五個誤區，分別是：放棄現有人員而招聘新的DevOps專家、進行大規模組織結構重組、從新編寫應用並上雲、購買一攬子DevOps工具、給開發生產環境徹底訪問權限。

那麼DevOps轉型的正確姿式應該是怎樣的呢？本文將重點描述DevOps轉型的五大實踐，以及轉型的具體實施建議。

DevOps轉型的五大實踐

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

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

1. 找到最重要的工做

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

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

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

2. 架構的持續演進

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

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

• 是否無需團隊外的某人或其餘團隊受權就能夠進行自身系統大範圍的設計變動？
• 是否無需與團隊外的其餘人員進行細粒度的溝通就能夠完成自身的工做？
• 是否能夠獨立於其餘依賴的服務或產品，按需部署和發佈自身的產品或服務？
• 是否無需依賴複雜的集成測試環境，就能夠按需進行大多數自身系統的測試？
• 是否能夠在平常業務時段，執行無停機的部署？

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

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

• 從交付業務所需的新功能開始（至少在初期是這樣），新功能使用面向服務的設計
• 不要重寫已有的功能，除非可以使它持續簡化
• 經過不斷拆分，更快的進行交付
• 爲可測試性和可部署性進行設計
• 新的架構運行在PaaS平臺上

3. 組織文化的持續演進

組織和文化的變革一樣應用使用持續演進的方式。在組織中有各類各樣的員工，有些人對新方法和新技術很是感興趣，有些人則偏於保守，不肯意嘗試進行改變。 
你不能一刀切地進行整個組織的變革，應該從最贊同DevOps的理念、方法和技術的人羣開始。接受一個新想法，須要跨越鴻溝。咱們先找到認同DevOps原則和實踐的團隊，聚焦在有必定風險承受能力的小組上，快速作出轉型的標杆效果，打好基礎、給人信心。咱們不須要在早期花費大量時間用於轉化保守的人羣，而最重要的是先要把第一槍打響。

實踐二：建立反饋循環

在小批量工做的基礎上，咱們要創建起反饋循環。反饋循環讓咱們可以持續學習，基於學習進行持續改進，這也是敏捷和學習型組織的關鍵原則。

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

實踐三：經過價值流進行跨職能協做

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

另外，這裏還要強調跨職能協做時的質量管控部分。不只僅是自動化測試，還要關注持續測試、持續安全檢查，讓這些活動在平常工做中反覆進行，作到內建質量。

實踐四：創建實驗的組織文化

調查代表，組織文化是能夠被度量的，並且組織文化對IT效能和組織績效都有可度量的影響。咱們使用Westrum模型來度量組織文化。該模型中有三種類型：

• 病態型組織（Pathological）的特徵是存在大量恐懼和威脅。人們一般處於政治因素而隱藏或者壓制信息，甚至爲了讓本身表面上看起來更好而扭曲事實。
• 官僚型組織（Bureaucratic）的特徵是各部門自保。每一個部門都想維護本身的一畝三分地兒，堅持本身的規則，一般會依照本身的章程循序漸進地行事。
• 生機型組織（Generative）專一於自身的使命以及如何達到目標。任何因素都要讓位於高績效，團隊間高度合做、風險共擔、鼓勵聯結。面對失敗時須要嘗試發現系統中的問題根因，而不是尋找替罪羊或相互推諉。

根據統計結果發現，一個高度信任的生機型文化不只對創造一個安全的工做環境很是重要，更是打造高績效組織的基礎。

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

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

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

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

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

Etsy每一年舉辦開發者大會，會發給過去一年中生產環境最大中斷的製造者一件"三隻袖毛衣"做爲獎勵。那麼爲何獎勵是三隻袖毛衣呢？由於Etsy的404頁面中有一張三隻袖毛衣的圖片。

圖中這位身穿毛衣的同窗就是Etsy去年最大故障的製造者Ryn，她把故障的過程記錄在了博客中，包括什麼時候、什麼緣由形成了生產環境中斷。發生故障時，她立刻在Slack上尋求幫助，而後當即獲得了身邊不少人的回覆，而後他們一塊兒一擁而上快速解決了問題。以後，他們開展了免責的過後故障分析會議，並給出了防止再次失敗、優化系統的具體措施。Ryn也所以得到去年的獎勵，由於她促進了組織學習，讓系統的恢復能力變得更強。

案例三. Netflix的Chaos Monkey和Simian army

Netflix的這個工具不斷在生產環境上製造破壞，驗證系統是否具有良好的恢復能力，並幫助工程師構建更加健壯的系統。 

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

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

咱們能夠邀請來自產品、開發、測試、運維、安全等不一樣部門的Leader參加價值流梳理活動，其實最難的部分是讓這些人在同一時間聚在一間會議室中。咱們逐個梳理從需求提出到編碼、測試驗證再到部署、發佈的過程，過程當中會發現你們的認知並不一致，尤爲是對前置時間、等待時間和C/A%（完整且準確比例）的估算。

讓全部人達成對整個價值流的理解和認知很是重要，但更重要的是肯定將來如何改進的具體措施和預期目標。在不一樣的角色對目標達成一致意見的基礎上，按期（如一個月）進行回顧和持續的改進。在改進的過程當中，並非事無鉅細的告訴團隊具體如何開展工做，而是明確目標並讓團隊深度參與、自主思考，經過不斷實驗和學習想辦法達到目標。（這映射了咱們以前提到的誤區一）

DevOps轉型的具體實施建議

在過去五年對高效能企業的研究中，總結出了DevOps轉型的關鍵能力要素，以下圖所示。圖中共有四大領域，分別是軟件開發實踐、精益產品開發、精益管理、變革領導力，這些領域又細化出了20多個能力項。這些能力項的建設能夠做爲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轉型提供一點點光亮，也祝你早日走上DevOps成功之路！

DevOpsDays大會北京站報名通道

2018年5月5日，與大神Jez Humble面對面暢聊DevOps！ 

與大神見面並交流的機會可貴，趕快掃碼報名！