版權聲明：本作品采用【知識共享署名-非商業性使用-禁止演繹 4.0 國際許可協議】進行許可。
[toc]
前言
自接觸并學習DevOps起，到交付DevOps相關的培訓和咨詢服務至今已差不多一年時間。
最近一段時間正在幫助我們的一個重要客戶實現DevOps轉型，在此過程中，每一天都會有新的發現和新的感悟。
客戶方的負責人開玩笑給我說：“如果我們能成功，固然很好，但是如果不盡如人意，大不了寫本書唄！”
我覺得好有道理！
于是，秉著“到此一游總要留下點什么”以及“寫不了一本書也要寫個冊子”的精益思想，開始把感悟到的東西都記錄下來寫成文章，一方面供自己總結精進，一方面供他人參考借鑒。
這些文章不會有嚴格的順序，純粹想到了就寫，容日后編撰成冊吧。
你以為你以為的DevOps就是你以為的DevOps嗎？
“您對DevOps一定有誤解……”
我每次我在面對需要做轉型的團隊的時候，我都會先問在場的所有人一個問題：“大家所理解的DevOps到底是什么？”
得到的答案五花八門，常見的主要有以下幾種：
- “沒聽說過。”
- “聽說過但是不了解。”
- “DevOps就是要做敏捷。”
- “DevOps是一種套路。”
- “DevOps就是讓開發人員（Dev）和運維人員（Ops）一起工作。”
- “DevOps就是CI/CD。”
- “DevOps就是做一個平臺，讓我們能夠在上面方便開發。”
- “DevOps就是一大堆工具做自動化。”
這些回答，與前些年“敏捷”一詞風風火火的時候，對于大多數人“敏捷就是Scrum”的理解是何其相像！
其實，這也不能完全怪大家，尤其是DevOps在今天來說，依然處于一場“迷之盛宴”的階段。
DevOps的迷之盛宴
這場“迷之盛宴”中有幾類典型的“教派”在其中“群魔亂舞”：
- 忽悠神教
- 套路神教
- 平臺神教
接下來，讓我們挨個說起。
忽悠神教
“你們這些方面與DevOps的要求相比，還有很大差距……（沒了）”
正如“敏捷”火爆時候的滿大街各種連敏捷實踐都沒做過的所謂“認證敏捷教練”，還有“區塊鏈”出來以后滿大街套著“區塊鏈”字眼招搖撞騙的創業項目。每一次某種概念突然火爆的時候，總是少不了這樣一些人：
- 他們以炒作概念為生，但絕不負責落地。
- 他們喜歡制定種種度量或認證標準斂財，然后到處去做評估賺錢。
- 他們夸夸其談，但是慫于實踐。
這些人干的事情就是：到處“念歪經”、“傳歪經”，錢到手了立刻拍拍屁股走人。
記得我所接觸的第一個試點團隊，團隊看到我們的第一個反應是：“怎么又來了一波搞DevOps的”。在初期的幾次接觸中，明顯能夠感受到團隊對于這一次工作抱有相當的抵觸和不信任感。
當我拿到“某國際知名咨詢公司（該公司壓根沒啥技術實踐）”之前針對該團隊的評估報告的時候，我的第一個反應就是：“WTF?”
該評估報告本質上就是一個基于打分表的問卷調查，寥寥幾個維度加上不同的標準，做了做問卷調查和簡單的訪談，就為團隊打了個分，定了個性。然后到了該有改進方案部分，直接粘貼了幾個不知道從哪里找來的廣告般的可視化面板的截圖，然后標注了一個醒目的單詞“Sample”。然后就再也沒有然后了……
團隊告訴我們，大家根據這份評估結果，努力的在可視化和自動化方面做了很多嘗試，但是“并沒有感到有太大的變化”。
后來，隨著和團隊幾次深入的交流、對實際代碼和實踐進行分析，我們發現該團隊的開發環節完全掌控在一個以產品壟斷為基礎的強勢供應商手上，產品的封閉程度也非常之高（純Win32圖形化操作，所有的中間數據和最終數據都被存為了專有格式的二進制文件，合同限制團隊只能得到開發之后編譯的二進制文件而不是代碼）。如果不能把開發環節控制在自己手上的話，永遠都難以優化Dev而只能優化Ops，這顯然是不能實現從Dev到Ops順暢的價值流動的。而團隊在其他環節上已經根據自身的理解采取了多方面的努力和嘗試，采購了專門針對圖形化應用的測試工具編寫了自動化驗收測試，甚至還每人都購買和閱讀了《鳳凰項目》一書。
所以我們的最終評估認為，該團隊已經做出了很多努力，受制于現實約束，進一步優化的空間十分有限。
以上就是一個我親眼見到的“拍拍屁股就走”的例子，如果按照他們的方式再來一次“忽悠”型的咨詢，還真不知道會對這個團隊造成怎樣的傷害。
套路神教
“我聽不懂，我就只想知道怎么驗收？什么時候能做完？”
我相信有很多人同我一樣會經常遇到上面這樣的提問，往往出自于某個具有領導角色的人口中。在他們的心中，DevOps是一種工具性的存在，只要按照說明書操作，就理應能夠“實現”。
而從“DevOps三步工作法”來看，DevOps的最終目標之一，是對組織文化進行改造，建立一種相互信任、持續改進和不斷創新的組織文化[1]：
第一步：實現開發到運維工作快速地從左向右流動；
第二步：在從右向左的每個階段中，應用持續、快速的工作反饋機制；
第三步：建立具有創意和高度信任的企業文化，支持動態的、嚴格的科學實驗；
（我習慣將以上三步簡稱為：優化價值流動；優化反饋機制；建立持續改進的文化）
而既然說到了組織，我們知道每一個組織他們所面對的自身實際、目標和挑戰是不同的，所以這個世界上并不存在“DevOps靈丹妙藥”，每個組織都需要嚴肅認真的對待和分析自身實際，走出滿足自身需要的轉型之路。
另一方面，持續改進告訴的是讓我們變得“更好”，所以并不會出現“做完了”的情況。
但可惜的是，這個行業里有太多不顧核心問題而急于賺錢的人，他們最擅長的就是提供一套“標準化”的解決方案去迎合這種急功近利的心態，并建立一種“只要按照這種套路做下去，就能實現DevOps”的迷信。
心急吃不了熱豆腐，天下也沒有免費的午餐。相比“摸著石頭過河”來說，好在我們還有很多行業標桿可以參考。
平臺神教
“沒有什么DevOps的問題是用一套平臺不能解決的！”
之前參加了大大小小不同的DevOps社區活動，也去不同類型的企業做過DevOps方面的培訓或交流，最讓我印象深刻的是，幾乎各大企業都在做自己的DevOps平臺，并且各種服務商也在大力的推銷自己的產品。
首先，DevOps平臺本身并沒有什么問題，通常將運維融入日常開發工作的方式有以下三種[1]：
- 創建共享服務，提高開發生產力。
- 將運維工程師融入服務團隊。
- 為每個服務團隊分派運維聯絡人。
其中“創建共享服務”指的就是通過創造集中式平臺或者工具鏈的方式，通過自動化的方式降低開發過程中開發人員對于基礎設施的注意力損耗，建立更快速的反饋和響應力。
在這種指導思想下，開發工程師最好能夠在運維工程師的幫助下實現這樣一種理想中的工作狀態：
- 隨便找到一臺能夠使用Web瀏覽器的設備，通過瀏覽器打開云端集成開發環境。
- 使用云端集成開發環境針對實例化需求編寫測試代碼并實現。
- 將編寫完成的代碼提交進本地版本控制的變更集，同時觸發屬分布式持續集成和自動化構建流水線。
- 當分布式流水線無誤通過后，觸發后續的自動化/手動測試、部署等環節并交付上線。
- 在整個過程中，開發人員應當保持對業務實現的高度關注，而盡可能的不去關注基礎設施可能產生的干擾。
然而，這種看似理想的工作狀態在引入人工智能后將會產生另一個“黑暗的”版本：
- 在所使用的框架和平臺不斷進步的情況下，開發人員所編寫的代碼將越來越多的由膠水代碼構成。
- 基于大量的人工智能學習和訓練，需求分析人員開始使用基于業務場景的自動化測試用例生成工具生成測試用例。
- 人工智能學習和抽象更多的膠水代碼案例，根據測試用例自動生成膠水代碼。
- 最終只會寫膠水代碼的開發工程師被人工智能所取代，“碼農”終于失業了。
當然了，“黑暗”是針對“只會寫膠水代碼”的人而言的，如果是一個具有分析、設計能和駕馭整個端到端交付能力的“高級開發人員”來說，甭提有多爽快了。
話說回來，既然平臺的前景這么廣闊，哪里有問題呢？
問題恰好就出在了盲目夸大平臺的作用，而忽略了“實現開發到運維工作快速地從左向右流動”這個地方。
根據我的觀察，目前絕大多數的集中式品臺都是由各大公司的運維部門主導開發完成的，我見過完成度非常高的平臺，也見過完成度比較低的平臺，但是他們都具有一個關鍵的基礎，就是自動化構建和部署流水線（Pipeline），而流水線的一個必要條件就是：要有自動化測試。
那么問題來了：有多少公司的開發和測試團隊具備良好的自動化測試能力？
對不起，親眼所見，僅就國內而言，不多……
上到知名互聯網企業，下到中小型傳統IT企業，先姑且不說測試驅動開發，僅是有自動化測試的連過半都沒有。
沒有自動化測試兜底，你告訴我，開發到運維咋個快速流動嘛！更別談持續反饋了，要不要用手點的方式表演個快速回歸看看？
所以，這也是我們所見到的大多數所謂“DevOps平臺”很難落地的原因。至于為啥今天做平臺那么火爆，我個人有個非常不負責任的理解就是：
作為長期被忽視的運維工程師們，好不容易打了一次翻身仗，愈戰愈勇用，加上之前所說的套路化迷思，最后從上到下集體妄圖用工具和平臺一統天下……最終促進人工智能替代膠水代碼工程師的偉大未來。（我就是開個玩笑，別打我！）
說到這里，我就想起了之前評估過的一個團隊，做了大量基礎設施搭建工作的運維工程師用非常無奈的眼神看著我說的話：
“我們工具都搭好了，可是開發就是不用……”（因為沒有自動化構建也沒有自動化測試）
阻擋平臺落地的因素有很多，自動化測試是我見到的最慘烈的一個。
DevOps到底是什么？
穿過浮躁，回歸本質，讓我們來看看：DevOps到底是什么？
其實DevOps思想是建立在軟件行業經過實踐驗證的一系列旨在提升響應力的思想和實踐的融合過程之上的（所謂“DevOps大融合”），它們包括且不限于[1]：
- 精益運動
- 敏捷運動
- Velocity大會運動（最為有名的就是演講“每日10次部署：Dev和Ops在Flicker的協作”）
- 敏捷基礎設施運動
- 持續交付運動
- 豐田套路運動
- 精益創業運動
- 精益用戶體驗運動
- Rugged Computing運動
所以，DevOps即是一種“融合思想”，里面含有了大量需要長期學習、理會、實踐的東西。
而其中最為核心且占主導地位的，在我看來就是“精益思想”和“持續交付”。我們在DevOps轉型過程中能夠看到的絕大多數問題都基本不超出這兩種思想的范圍（當然他們也是建立在一系列思想和實踐之上的）。換句話說，如果你所遇到的問題在這兩種思想中找不到答案，那你的DevOps實踐水平已經相對其他組織來說非常高了。
另一方面，DORA團隊在近4年的研究基礎上，總結了5類共24項能夠影響和推動軟件交付效能的關鍵能力，并且繪制了關系圖，這5類能力為[2]：
- 持續交付
- 對所有生產工件使用版本控制
- 自動化部署過程
- 實現持續集成
- 使用基于主干的開發方法
- 實現自動化測試
- 管理測試數據
- 將安全性集成到軟件和測試階段
- 實現持續交付
- 架構
- 使用松耦合架構
- 構建自治團隊
- 產品和流程
- 收集和實施客戶反饋
- 通過價值流可視化工作流動
- 小批量工作
- 培養和支持團隊實驗
- 精益管理和監控
- 使用輕量級變更審批流程
- 監控應用和基礎架構以支持業務決策
- 主動檢查系統健康狀況
- 通過限制在制品改進流程和管理工作
- 可視化工作以便監控質量和促進團隊溝通
- 文化
- 支持生機型文化
- 鼓勵和支持學習
- 鼓勵和支持團隊間的合作
- 提供使工作有意義的資源和工具
- 支持或體現變革型領導力
怎么樣？是不是感覺24項關鍵能力每個拿出來都夠喝一壺的？
你看，DevOps融合了這么多種實踐和思想，還需要鍛煉這么多關鍵能力，那些希望能夠有個“明確完成時間”的想法是不是顯得很可笑了？
總而言之，DevOps所代表的就是一種追求能夠從組織、文化、技術角度等多個方向上，利用新的思想和工具，全面提升IT組織響應力，同時讓客戶和員工都滿意的價值追求。
當然，如果一定要問我DevOps轉型到一個理想狀態需要多長時間的話，我會說：
“誰知道呢，根據統計，一個企業完成精益轉型需要5年時間，作為DevOps轉型來說，沒個奮戰3-5年的心理準備，還是洗洗睡吧……”
結語
作為DevOps轉型的推動者，在這喧囂浮躁的階段，我們應當看清現實，樹立正確的DevOps價值觀，用實踐檢驗真理，我相信喧囂過后，總是會大浪淘沙，去偽存真。
而對于那些正因為各種原因“被轉型”的人們，我想說：莫急，不慌，多學習。
