版權(quán)聲明：本作品采用【知識共享署名-非商業(yè)性使用-禁止演繹 4.0 國際許可協(xié)議】進行許可。

[toc]

前言

自接觸并學(xué)習(xí)DevOps起，到交付DevOps相關(guān)的培訓(xùn)和咨詢服務(wù)至今已差不多一年時間。

最近一段時間正在幫助我們的一個重要客戶實現(xiàn)DevOps轉(zhuǎn)型，在此過程中，每一天都會有新的發(fā)現(xiàn)和新的感悟。

客戶方的負責人開玩笑給我說：“如果我們能成功，固然很好，但是如果不盡如人意，大不了寫本書唄！”

我覺得好有道理！

于是，秉著“到此一游總要留下點什么”以及“寫不了一本書也要寫個冊子”的精益思想，開始把感悟到的東西都記錄下來寫成文章，一方面供自己總結(jié)精進，一方面供他人參考借鑒。

這些文章不會有嚴格的順序，純粹想到了就寫，容日后編撰成冊吧。

你以為你以為的DevOps就是你以為的DevOps嗎？

“您對DevOps一定有誤解……”

我每次我在面對需要做轉(zhuǎn)型的團隊的時候，我都會先問在場的所有人一個問題：“大家所理解的DevOps到底是什么？”

得到的答案五花八門，常見的主要有以下幾種：

• “沒聽說過?！?/li>
• “聽說過但是不了解?！?/li>
• “DevOps就是要做敏捷?！?/li>
• “DevOps是一種套路?！?/li>
• “DevOps就是讓開發(fā)人員（Dev）和運維人員（Ops）一起工作?！?/li>
• “DevOps就是CI/CD?！?/li>
• “DevOps就是做一個平臺，讓我們能夠在上面方便開發(fā)。”
• “DevOps就是一大堆工具做自動化?！?/li>

這些回答，與前些年“敏捷”一詞風風火火的時候，對于大多數(shù)人“敏捷就是Scrum”的理解是何其相像！

其實，這也不能完全怪大家，尤其是DevOps在今天來說，依然處于一場“迷之盛宴”的階段。

DevOps的迷之盛宴

這場“迷之盛宴”中有幾類典型的“教派”在其中“群魔亂舞”：

• 忽悠神教
• 套路神教
• 平臺神教

接下來，讓我們挨個說起。

忽悠神教

“你們這些方面與DevOps的要求相比，還有很大差距……（沒了）”

正如“敏捷”火爆時候的滿大街各種連敏捷實踐都沒做過的所謂“認證敏捷教練”，還有“區(qū)塊鏈”出來以后滿大街套著“區(qū)塊鏈”字眼招搖撞騙的創(chuàng)業(yè)項目。每一次某種概念突然火爆的時候，總是少不了這樣一些人：

• 他們以炒作概念為生，但絕不負責落地。
• 他們喜歡制定種種度量或認證標準斂財，然后到處去做評估賺錢。
• 他們夸夸其談，但是慫于實踐。

這些人干的事情就是：到處“念歪經(jīng)”、“傳歪經(jīng)”，錢到手了立刻拍拍屁股走人。

記得我所接觸的第一個試點團隊，團隊看到我們的第一個反應(yīng)是：“怎么又來了一波搞DevOps的”。在初期的幾次接觸中，明顯能夠感受到團隊對于這一次工作抱有相當?shù)牡钟|和不信任感。

當我拿到“某國際知名咨詢公司（該公司壓根沒啥技術(shù)實踐）”之前針對該團隊的評估報告的時候，我的第一個反應(yīng)就是：“WTF?”

該評估報告本質(zhì)上就是一個基于打分表的問卷調(diào)查，寥寥幾個維度加上不同的標準，做了做問卷調(diào)查和簡單的訪談，就為團隊打了個分，定了個性。然后到了該有改進方案部分，直接粘貼了幾個不知道從哪里找來的廣告般的可視化面板的截圖，然后標注了一個醒目的單詞“Sample”。然后就再也沒有然后了……

團隊告訴我們，大家根據(jù)這份評估結(jié)果，努力的在可視化和自動化方面做了很多嘗試，但是“并沒有感到有太大的變化”。

后來，隨著和團隊幾次深入的交流、對實際代碼和實踐進行分析，我們發(fā)現(xiàn)該團隊的開發(fā)環(huán)節(jié)完全掌控在一個以產(chǎn)品壟斷為基礎(chǔ)的強勢供應(yīng)商手上，產(chǎn)品的封閉程度也非常之高（純Win32圖形化操作，所有的中間數(shù)據(jù)和最終數(shù)據(jù)都被存為了專有格式的二進制文件，合同限制團隊只能得到開發(fā)之后編譯的二進制文件而不是代碼）。如果不能把開發(fā)環(huán)節(jié)控制在自己手上的話，永遠都難以優(yōu)化Dev而只能優(yōu)化Ops，這顯然是不能實現(xiàn)從Dev到Ops順暢的價值流動的。而團隊在其他環(huán)節(jié)上已經(jīng)根據(jù)自身的理解采取了多方面的努力和嘗試，采購了專門針對圖形化應(yīng)用的測試工具編寫了自動化驗收測試，甚至還每人都購買和閱讀了《鳳凰項目》一書。

所以我們的最終評估認為，該團隊已經(jīng)做出了很多努力，受制于現(xiàn)實約束，進一步優(yōu)化的空間十分有限。

以上就是一個我親眼見到的“拍拍屁股就走”的例子，如果按照他們的方式再來一次“忽悠”型的咨詢，還真不知道會對這個團隊造成怎樣的傷害。

套路神教

“我聽不懂，我就只想知道怎么驗收？什么時候能做完？”

我相信有很多人同我一樣會經(jīng)常遇到上面這樣的提問，往往出自于某個具有領(lǐng)導(dǎo)角色的人口中。在他們的心中，DevOps是一種工具性的存在，只要按照說明書操作，就理應(yīng)能夠“實現(xiàn)”。

而從“DevOps三步工作法”來看，DevOps的最終目標之一，是對組織文化進行改造，建立一種相互信任、持續(xù)改進和不斷創(chuàng)新的組織文化^[1]：

第一步：實現(xiàn)開發(fā)到運維工作快速地從左向右流動；

第二步：在從右向左的每個階段中，應(yīng)用持續(xù)、快速的工作反饋機制；

第三步：建立具有創(chuàng)意和高度信任的企業(yè)文化，支持動態(tài)的、嚴格的科學(xué)實驗；

DevOps三步工作法

（我習(xí)慣將以上三步簡稱為：優(yōu)化價值流動；優(yōu)化反饋機制；建立持續(xù)改進的文化）

而既然說到了組織，我們知道每一個組織他們所面對的自身實際、目標和挑戰(zhàn)是不同的，所以這個世界上并不存在“DevOps靈丹妙藥”，每個組織都需要嚴肅認真的對待和分析自身實際，走出滿足自身需要的轉(zhuǎn)型之路。

另一方面，持續(xù)改進告訴的是讓我們變得“更好”，所以并不會出現(xiàn)“做完了”的情況。

但可惜的是，這個行業(yè)里有太多不顧核心問題而急于賺錢的人，他們最擅長的就是提供一套“標準化”的解決方案去迎合這種急功近利的心態(tài)，并建立一種“只要按照這種套路做下去，就能實現(xiàn)DevOps”的迷信。

心急吃不了熱豆腐，天下也沒有免費的午餐。相比“摸著石頭過河”來說，好在我們還有很多行業(yè)標桿可以參考。

平臺神教

“沒有什么DevOps的問題是用一套平臺不能解決的！”

之前參加了大大小小不同的DevOps社區(qū)活動，也去不同類型的企業(yè)做過DevOps方面的培訓(xùn)或交流，最讓我印象深刻的是，幾乎各大企業(yè)都在做自己的DevOps平臺，并且各種服務(wù)商也在大力的推銷自己的產(chǎn)品。

首先，DevOps平臺本身并沒有什么問題，通常將運維融入日常開發(fā)工作的方式有以下三種^[1]：

• 創(chuàng)建共享服務(wù)，提高開發(fā)生產(chǎn)力。
• 將運維工程師融入服務(wù)團隊。
• 為每個服務(wù)團隊分派運維聯(lián)絡(luò)人。

其中“創(chuàng)建共享服務(wù)”指的就是通過創(chuàng)造集中式平臺或者工具鏈的方式，通過自動化的方式降低開發(fā)過程中開發(fā)人員對于基礎(chǔ)設(shè)施的注意力損耗，建立更快速的反饋和響應(yīng)力。

在這種指導(dǎo)思想下，開發(fā)工程師最好能夠在運維工程師的幫助下實現(xiàn)這樣一種理想中的工作狀態(tài)：

1. 隨便找到一臺能夠使用Web瀏覽器的設(shè)備，通過瀏覽器打開云端集成開發(fā)環(huán)境。
2. 使用云端集成開發(fā)環(huán)境針對實例化需求編寫測試代碼并實現(xiàn)。
3. 將編寫完成的代碼提交進本地版本控制的變更集，同時觸發(fā)屬分布式持續(xù)集成和自動化構(gòu)建流水線。
4. 當分布式流水線無誤通過后，觸發(fā)后續(xù)的自動化/手動測試、部署等環(huán)節(jié)并交付上線。
5. 在整個過程中，開發(fā)人員應(yīng)當保持對業(yè)務(wù)實現(xiàn)的高度關(guān)注，而盡可能的不去關(guān)注基礎(chǔ)設(shè)施可能產(chǎn)生的干擾。

然而，這種看似理想的工作狀態(tài)在引入人工智能后將會產(chǎn)生另一個“黑暗的”版本：

1. 在所使用的框架和平臺不斷進步的情況下，開發(fā)人員所編寫的代碼將越來越多的由膠水代碼構(gòu)成。
2. 基于大量的人工智能學(xué)習(xí)和訓(xùn)練，需求分析人員開始使用基于業(yè)務(wù)場景的自動化測試用例生成工具生成測試用例。
3. 人工智能學(xué)習(xí)和抽象更多的膠水代碼案例，根據(jù)測試用例自動生成膠水代碼。
4. 最終只會寫膠水代碼的開發(fā)工程師被人工智能所取代，“碼農(nóng)”終于失業(yè)了。

當然了，“黑暗”是針對“只會寫膠水代碼”的人而言的，如果是一個具有分析、設(shè)計能和駕馭整個端到端交付能力的“高級開發(fā)人員”來說，甭提有多爽快了。

話說回來，既然平臺的前景這么廣闊，哪里有問題呢？

問題恰好就出在了盲目夸大平臺的作用，而忽略了“實現(xiàn)開發(fā)到運維工作快速地從左向右流動”這個地方。

根據(jù)我的觀察，目前絕大多數(shù)的集中式品臺都是由各大公司的運維部門主導(dǎo)開發(fā)完成的，我見過完成度非常高的平臺，也見過完成度比較低的平臺，但是他們都具有一個關(guān)鍵的基礎(chǔ)，就是自動化構(gòu)建和部署流水線（Pipeline），而流水線的一個必要條件就是：要有自動化測試。

那么問題來了：有多少公司的開發(fā)和測試團隊具備良好的自動化測試能力？

對不起，親眼所見，僅就國內(nèi)而言，不多……

上到知名互聯(lián)網(wǎng)企業(yè)，下到中小型傳統(tǒng)IT企業(yè)，先姑且不說測試驅(qū)動開發(fā)，僅是有自動化測試的連過半都沒有。

沒有自動化測試兜底，你告訴我，開發(fā)到運維咋個快速流動嘛！更別談持續(xù)反饋了，要不要用手點的方式表演個快速回歸看看？

所以，這也是我們所見到的大多數(shù)所謂“DevOps平臺”很難落地的原因。至于為啥今天做平臺那么火爆，我個人有個非常不負責任的理解就是：

作為長期被忽視的運維工程師們，好不容易打了一次翻身仗，愈戰(zhàn)愈勇用，加上之前所說的套路化迷思，最后從上到下集體妄圖用工具和平臺一統(tǒng)天下……最終促進人工智能替代膠水代碼工程師的偉大未來。（我就是開個玩笑，別打我！）

說到這里，我就想起了之前評估過的一個團隊，做了大量基礎(chǔ)設(shè)施搭建工作的運維工程師用非常無奈的眼神看著我說的話：

“我們工具都搭好了，可是開發(fā)就是不用……”（因為沒有自動化構(gòu)建也沒有自動化測試）

阻擋平臺落地的因素有很多，自動化測試是我見到的最慘烈的一個。

DevOps到底是什么？

穿過浮躁，回歸本質(zhì)，讓我們來看看：DevOps到底是什么？

其實DevOps思想是建立在軟件行業(yè)經(jīng)過實踐驗證的一系列旨在提升響應(yīng)力的思想和實踐的融合過程之上的（所謂“DevOps大融合”），它們包括且不限于^[1]：

• 精益運動
• 敏捷運動
• Velocity大會運動（最為有名的就是演講“每日10次部署：Dev和Ops在Flicker的協(xié)作”）
• 敏捷基礎(chǔ)設(shè)施運動
• 持續(xù)交付運動
• 豐田套路運動
• 精益創(chuàng)業(yè)運動
• 精益用戶體驗運動
• Rugged Computing運動

所以，DevOps即是一種“融合思想”，里面含有了大量需要長期學(xué)習(xí)、理會、實踐的東西。

而其中最為核心且占主導(dǎo)地位的，在我看來就是“精益思想”和“持續(xù)交付”。我們在DevOps轉(zhuǎn)型過程中能夠看到的絕大多數(shù)問題都基本不超出這兩種思想的范圍（當然他們也是建立在一系列思想和實踐之上的）。換句話說，如果你所遇到的問題在這兩種思想中找不到答案，那你的DevOps實踐水平已經(jīng)相對其他組織來說非常高了。

另一方面，DORA團隊在近4年的研究基礎(chǔ)上，總結(jié)了5類共24項能夠影響和推動軟件交付效能的關(guān)鍵能力，并且繪制了關(guān)系圖，這5類能力為^[2]：

• 持續(xù)交付
  • 對所有生產(chǎn)工件使用版本控制
  • 自動化部署過程
  • 實現(xiàn)持續(xù)集成
  • 使用基于主干的開發(fā)方法
  • 實現(xiàn)自動化測試
  • 管理測試數(shù)據(jù)
  • 將安全性集成到軟件和測試階段
  • 實現(xiàn)持續(xù)交付
• 架構(gòu)
  • 使用松耦合架構(gòu)
  • 構(gòu)建自治團隊
• 產(chǎn)品和流程
  • 收集和實施客戶反饋
  • 通過價值流可視化工作流動
  • 小批量工作
  • 培養(yǎng)和支持團隊實驗
• 精益管理和監(jiān)控
  • 使用輕量級變更審批流程
  • 監(jiān)控應(yīng)用和基礎(chǔ)架構(gòu)以支持業(yè)務(wù)決策
  • 主動檢查系統(tǒng)健康狀況
  • 通過限制在制品改進流程和管理工作
  • 可視化工作以便監(jiān)控質(zhì)量和促進團隊溝通
• 文化
  • 支持生機型文化
  • 鼓勵和支持學(xué)習(xí)
  • 鼓勵和支持團隊間的合作
  • 提供使工作有意義的資源和工具
  • 支持或體現(xiàn)變革型領(lǐng)導(dǎo)力

Overall Research Program

怎么樣？是不是感覺24項關(guān)鍵能力每個拿出來都夠喝一壺的？

你看，DevOps融合了這么多種實踐和思想，還需要鍛煉這么多關(guān)鍵能力，那些希望能夠有個“明確完成時間”的想法是不是顯得很可笑了？

總而言之，DevOps所代表的就是一種追求能夠從組織、文化、技術(shù)角度等多個方向上，利用新的思想和工具，全面提升IT組織響應(yīng)力，同時讓客戶和員工都滿意的價值追求。

當然，如果一定要問我DevOps轉(zhuǎn)型到一個理想狀態(tài)需要多長時間的話，我會說：

“誰知道呢，根據(jù)統(tǒng)計，一個企業(yè)完成精益轉(zhuǎn)型需要5年時間，作為DevOps轉(zhuǎn)型來說，沒個奮戰(zhàn)3-5年的心理準備，還是洗洗睡吧……”

結(jié)語

作為DevOps轉(zhuǎn)型的推動者，在這喧囂浮躁的階段，我們應(yīng)當看清現(xiàn)實，樹立正確的DevOps價值觀，用實踐檢驗真理，我相信喧囂過后，總是會大浪淘沙，去偽存真。

而對于那些正因為各種原因“被轉(zhuǎn)型”的人們，我想說：莫急，不慌，多學(xué)習(xí)。

1. 出自《DevOps Handbook》，文字來自中譯版《DevOps實踐指南》。 ? ? ?

2. 內(nèi)容和圖片出自《Accelerate: The Science of Lean Software and DevOps》。 ?