當你開啟這篇文章的時候，也許你也在為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