當你打開這篇文章的時候，也許你也在為DevOps的落地而苦惱，也許你的組織正在嘗試DevOps轉型，作為一線的實踐者，說說我對這個“落地難”的看法，歡迎交流不同看法～

DevOps是實踐摸索出來的，別人的終究是別人的

如下圖所示，你可能在不同企業研發效能的分享都看到過，各種關于DevOps的書上有會提到DevOps的CALMS 框架（該首字母縮寫詞由《DevOps 手冊》的合著者 Jez Humble 提出，且分別代表文化 (Culture)、自動化 (Automation)、精益 (Lean)、衡量 (Measurement) 和分享 (Sharing)），告訴你通過何種手段，何種步驟來推進DevOps落地實施。

你聽了，感覺說的都很有道理，可是好像沒有解決自己遇到的問題??

• 不同的組織文化不同，領導有的懂技術，有的完全是外行
• 不同的業務不同，互聯網的玩法對傳統企業是不適用的，特別是發布節奏
• 技術債務不同，新的項目可以輕松上路，老的項目只能“負重前行”
• 研發團隊對轉型的態度不同，有的團隊很封閉，有的團隊很開放
• 是否有“專家”角色幫助梳理整個流程
• 有的買的商用平臺工具，有的自研平臺
• 組織規模不同，幾十人，幾百人到上千人的轉型肯定不是一回事

所有這些因素決定了，可以參考，但是沒法照抄。因為DevOps轉型不僅僅是個技術問題，而是一次“組織”的變革之旅。

你可能會遇到的轉型阻礙

提到組織，首先就是人，面對轉型他們大概都是這樣的想法和態度。

• 對于領導，他們會經常問你，效果怎么樣？你需要面對靈魂拷問，如何向不懂“DevOps”的領導解釋做這個實踐的意義。對于領導，他們更關注業務的增長，成本的降低，對于什么最佳實踐，他們是不懂的
• 對于團隊，他們會告訴你我知道有好處，我怎么開始需要投入多少？你能給我提供什么？我很忙，沒看到你們做這個事情的意義！你們提供給我的，不是我最急迫的！
• 對于轉型團隊內部，需要告訴他們怎么配合，可能你和他們不是一個部門，也許你們的目標并不完全一致

以下來自《中國DevOps現狀調查報告（2022）》

**組織缺少具備 DevOps 經驗的專家、組織不清楚 DevOps 的路線圖成為限制組織級 DevOps 轉型的 最大障礙。 **
調查顯示，28.65% 的企業組織缺少具備 DevOps 經驗的專家，導致推進緩慢甚至無從下手；25.47% 的組織不清楚 DevOps 的路線圖以及如何進行轉型，同比增長 5%；25.40% 的企業受限于組織行業的 限制。另有 21.10% 的企業項目團隊工作繁重，沒有時間進行 DevOps 改進。

別人的轉型之路？

普遍的轉型方式如下圖所示，無非就是

• 自上而下，領導強勢要求
• 自下而上，個別團隊試點，經驗推廣
• 引進咨詢機構，或者成立轉型小組

可是現實是

• 大老板或CTO只是提了要求，指派了某位“領導”來負責這個事情，定期聽聽匯報，遇到不懂的領導死活講不清楚
• 自下而上，如果組織規模較小（幾十人規模）還有可能，最多也只能推廣到自己的小部門
• 引入咨詢機構，不是每個組織都有咨詢費，另外轉型是個漫長的過程，最終落地還是組織內部自己落地

到了這里，只能感嘆“理想很美好，現實很骨感”。

面對現實，如何破局？

尋找“反抗軍”，找到你的目標用戶

在《獨角獸項目》這本書中，主角來到一個“陌生的雜亂無序，連一周都沒有產出成功構建的組織”，通過在和“各個角色”接觸過程中，發現了“反抗軍”，他們和主角一樣希望解決當前的困境。建議去看看，你可能有種似曾相識的感覺。

如何找到目標用戶

一般來說轉型初期，你可能會遇到以下這四種角色

• 擁護者：這就是你要找的“反抗軍”，但是初期他們不會自己站出來，需要你“快速”甄別出來
• 徘徊者：認可帶來的收益，但是對投入比較擔心，你需要展示真實的“案例”和收益給他看
• 旁觀者：對轉型不是很關注，也不反對，屬于人云亦云型，跟隨者
• 反對者：你的改進可能對他影響很大，觸及他的利益，或者他曾經受過“折騰”，對轉型喪失信心產生抵觸心理

對于前面兩類角色，是你主要爭取合作的對象，特別是擁護者，要能切實解決他們的問題，贏得信任。對于后面兩類角色，轉型初期，他們絕不是你的“目標用戶”，他們往往在整個組織里的地位比較重要，業務壓力也是最大的，你必須保持足夠耐心。
每個團隊的leader的風格和經歷也很重要，如果曾經在高效的組織工作過，他們帶領的團隊也可能是你合作的目標，但是他們的要求會很高，這個也可能是個小小的“阻礙”。

識別改進點，解決關鍵問題

尋找目標用戶的過程，其實也是識別他們痛點的過程，你需要幫助他們找到問題，剛開始他們是不清楚到底哪里病了，只是知道痛而已。通常有以下幾種方式引導識別問題

價值流分析

DevOps的理論基礎就是“精益思想”，所以通過精益價值流分析是比較普遍的做法，但是這種更適合“工作坊”，另外需要團隊理解什么是“精益”，什么是價值流，這種評估方式適合有一定經驗的專家教練引導。

能力評價體系

這種通過行業標準的方式，對照參考，尋找差距，制定改進計劃，更多適用于企業評級，比較正式。

團隊訪談

上面兩種方式都是比較高大上，偏正式的套路，需要一定的組織能力和引導能力，如果你已經參與上述活動，恭喜你，已經有專家在指導你們做改進了。
這里提供一個更“省錢”，更容易執行的方式，出去跑“客戶”，和研發團隊“促膝長談”，引導他們說出自己的問題（注意，引導交談方式，別被研發團隊帶偏了，你要引導他們到你的思路上）

• 你們現在的痛點是什么？
• 我這里有這樣一個能力或方案，你們看行不行？這樣可以幫助你們xxxxx
• 你的問題可能另外一個方式更合適，也能幫助你解決

找出共性問題，建立改進清單

引導說出共性問題

通過前期的團隊訪談或者工作坊，你需要梳理出來“普遍”的共性問題（PS: 砍掉那些稀奇古怪的個性化需求），并且告訴團隊問題解決后能帶來的收益，繪制一個宏偉的藍圖，畫個大餅～
在人力有限情況下，盡可能把大家拉到一個“同性問題”上，最好還是性價比高的問題（PS: 投資少，見效果，快速取得客戶信任），對于“底子”差的組織，更是如此。

評估團隊，制定不同策略

不同的團隊情況不同，底子也不同，痛點不同，建立團隊的檔案。如果有可能，制定明確的標準和要求，也許會事半功倍
注意：團隊可能比較關心獲得這些收益需要哪些投入，這個可能你需要提前準備好應對的方案和各種輔導材料準備，避免用戶流失。

共同制定改進清單，跟蹤評價

你需要和團隊的代表（這里最好是固定的研發效能愛好者，也許他會讓改進事半功倍）共同制定改進清單，剛開始定一個“小目標”，周期別太長了，不要超過一個月。
目標感-進展感-協作感
記住這三個關鍵詞，如果沒有清晰的目標，雙方感覺不到進展，溝通完后沒有任何協作，或者單方的努力，都可能導致改進失敗。作為教練，你需要保持這個警惕，與團隊要有互動，時刻保持“關心”。
小時候，你改掉一個壞毛病，不還要老師父母在屁股后面整天說，同理，你要時刻向團隊灌輸最佳實踐，保持和他們的互動。

平臺工程團隊及時響應用戶需求

一般在你的背后，應該有個平臺工程團隊建設與之配套的效能提升有關的基礎設施（代碼倉庫，制品庫，流水線，代碼掃描，自動化測試等）。

他們需要針對目標用戶的需求和問題，做出快速反應。除了自助服務開發，教育和協作也成為挑戰。平臺工程師發現，他們花越來越多的時間培訓應用程序開發人員，讓他們了解最佳實踐和如何最好地使用平臺。應用程序開發人員還發現他們依賴于其他應用程序開發人員團隊，并期望平臺工程團隊為他們提供與不同團隊高效協作的工具。

保持曝光率，不斷洗腦

組織改進的過程是個長期而艱難的過程，不要指望某個工具，某次培訓宣講，就能達到預期效果。為了讓你的用戶知道“你們”和你們的“平臺”，需要提高曝光率，你要當作一個“產品”在運營，你要和你的用戶建立聯系，收集他們的需求，聽取他們的心聲，但是如果他們連你的工具有什么功能都不知道，能夠帶給他們的收益都不清楚，你的“產品功能”再牛逼，也是沒有任何價值的。

• 定期通過組織內部渠道（論壇，郵件，公眾號）等打廣告
• 定期組織關于平臺功能和DevOps實踐的培訓分享
• 建立用戶行為分析體系，你需要知道推出的哪個功能用戶喜歡，活躍度高
• 定期發布優秀實踐案例

團結一切可以團結的力量

DevOps貫穿整個研發過程，所以會涉及到不同的部門，特別是“部門墻”很嚴重的組織。有人會說，DevOps不就是要推翻“部門墻”的嗎？那個是理想狀態，現實不會和書上說的那樣。
一般來說，你可能需要打交道的會涉及項目管理部門，企業IT部門，技術中臺部門，安全部門等組織級公共部門，這是另外一波你要合作的對象。
特別是，項目管理部門（PMO），組織的流程規范都是通過他們發出的，但是往往他們并不具備相應的能力，你們需要合作。當然，怎么合作也是有講究的，往往他們并不懂技術，更多你要做解釋，尋求理解支持。

定期匯報，展示成果

做了這么多，你需要去匯報了，要去面對領導的“靈魂拷問”，效果怎么樣？這也是比較頭痛的問題，難在哪里呢？

• 特別是傳統企業，甚至可能都不是IT企業，領導不懂技術，更別提DevOps了
• 你講最佳實踐，講技術方案，講敏捷如何好，DevOps如何好，都沒用，效果呢？

這里其實就是值得討論的一個問題，什么是效果？
很明顯，你需要告訴他效能提高多少？那什么是效能？如何定義效能？是否能提供數據？什么數據？領導是否認可這些數據，構建頻率/時長/前置時間等等，是否他們明白背后的意識呢？
留個思考題，歡迎討論～

轉型過程避坑指南

開始要想清楚

• 組織解決什么問題，也許一開始是會想不清楚，那么聘請外部專家是個合適的選擇
• 引入什么工具，什么是合適的工具，能花錢買的千萬別自己開發，能開發的也不要一股腦都是商用，工具是助力的，不是添堵的
• 轉型組織的構成有那些人，是否合適，要能各展所長
• 要做長遠規劃，一年目標，三年目標，五年目標

切記“大躍進”

不要急于匆忙上馬，不要以為買個工具或平臺，就可以全面使用接入了，這個要衡量下是否真的能解決問題。往往這是“自上而下”往下推，由領導發號施令產生的，他們急于看到效果，往往不了解什么是DevOps.
這樣做的后果是，團隊不再信任改進，抱怨聲一大堆，最后可能就失敗了。

多走進團隊，多引導

研發團隊是你的用戶，你需要走進他們，了解真實情況，不要以為外面商業的平臺就一定能解決他們的問題，特別是大型組織，他們的需求千奇百怪，往往你需要適應他們，再去改進。而不是上來就說，你們怎么不好，不是最佳實踐，商業平臺必須這么玩，這個真的要看團隊的底子好不好。
組織轉型的過程，其實是改變別人十幾年工作習慣的問題，是需要引導，培訓，指導，提升認知的，讓他們知道什么是好的，什么是不好的。

不要過度迷信成熟度模型

雖然我上面也提到了成熟度模型，但是這個僅僅是個參考。鞋子合不合適還是要看穿鞋的人，“成熟度”只是給你定義了標準的鞋子應該如何生產。對穿慣了布鞋的人來說，他需要的只是輕便合腳，對于穿慣了運動鞋的人來說，他需要的是能夠彈跳好。同理，團隊/組織的基礎目標不同，不能一概而論，也許他只只適合爬個小山丘，沒必要要求他能爬珠穆朗瑪峰，不現實，他要的也許是“減肥”，而不是成為“專業運動員”。
過度迷信成熟度，往往容易走偏，給轉型帶來不利因素。

總結：落地套路關鍵詞

總結下，DevOps落地是以“技術工具”為實現手段，“各種最佳實踐”為賦能指引，“組織級流程規范”為牽引，通過各部門角色的合作，對現有“混亂”狀態進行改造的過程。
人們總說擁抱變化，但是當變化到來時，他們卻拒絕變化，因為已經習慣，即使低效無趣，也不想改變。所以，做了DevOps的實踐者，你需要找到合適的套路去影響他們。

• 贏得用戶信任，建立良好的合作關系，甚至是個人關系
• 投資回報率優先，不要試圖強加一些不切實際的最佳實踐和要求給團隊，他們需要“投入少，見效快”。改進是有成本的，尋找收益最大化的方案
• 利益分析，互相吹捧，互相成就
• 提供真實的，一定數量的成功案例
• 保持耐心，循序漸進，接受不完美

參考

• 成熟度模型已死，請你別靠近DevOps
• 成熟度模型罪與罰 - Thoughtworks洞見
• 敏捷流暢度：找到適合需求的敏捷方式_文化 & 方法_Diana Larsen_InfoQ精選文章
• CNCF 平臺白皮書 | 云原生資料庫
• 敏捷流暢之路——敏捷成功的簡要指南

我的博客即將同步至騰訊云開發者社區，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan?invite_code=2oacl07nc9ic0