記錄初衷
本人一直在從事企業内DevOps落地實踐的工作，走了不少彎路，也努力在想辦法解決面臨的問題，期間也經曆過不少人和事情，最近突然有想法把經曆過的，不管好的不好的都記錄下來，分享給和我一樣的一線實踐者。
我會通過一個個典型故事或場景來叙述，不談理論，不談技術, 隻談遇到的人和事，我和我的團隊夥伴怎麼解決實踐中遇到的問題。
1）DevOps好像很火，我們也來做個搞吧
“DevOps好像大廠都在搞，聽說能提高效能，我們的項目經常延期，要不我們也搞吧~”可能這是很多企業上司實施DevOps的初衷, 這個初衷本沒有錯，可是真的準備好了嗎？想清楚做什麼了嗎？沒關系，可以請外部專家講下，聽下來感覺就是一大堆工具的組合，不就是開發一個一體化平台嗎？
如果隻是看到了别人的成果，沒有清楚中間付出的艱辛和改進，沒有好的方法論指導，很容易照貓畫虎，内部的改進“走形”！
2） 買了你們的平台，多久能有效果出來？
在企業DevOps實踐初期，對于自研和外部采購還存在一些猶豫，一方面覺得如果自己投入資源研發，周期比較長，自己等不了，是以希望能夠盡快通過成熟的外部工具快速達到自己的期望的目标。于此同時，外部的DevOps平台廠商或者咨詢就會看到機會開始介入，對自己的産品和方案進行推廣。對于外部的咨詢和廠商 ，上司常問的問題就是“我買了你們的平台，多久能出效果？”，或 “你們過去的案例一般需要多久？”，“是不是我們買了你們的平台，團隊可以馬上用了”，諸如此類的問題往往令外部的咨詢和銷售無法回答，因為真正做過落地實踐的人都清楚，不可能給出一個明确的答案。
其實，這種現象也反映了組織内上司沒有真正清楚這個事情到底要怎麼做，他們覺得工具能解決問題。這是對于DevOps的一個誤區。
3）“DevOps”應該從管理層認可開始
DevOps出現之後，大家也許曾經提出或者聽到過一個很關鍵卻又普遍的問題——“DevOps轉型應該從哪裡開始？”
工作中，并非所有人都信任DevOps，通常遇到的第一個難題是得到管理層的認可與支援，因為DevOps的核心含義可能會掀起公司的大變革。
但是即使有管理層支援，如果管理層沒有懂DevOps的帶頭人，往往也會出現“事倍功半”的情況，管理層基于得到結果，忽視了這是一次變革，不是某一個團隊就可以進行的。
4）通過工具平台接入率來衡量改進效果?
在上司的支援下，企業開始打造自研效能平台，但是怎麼推廣呢？往往會陷入一個誤區，就是開發了，大家接入使用就好了，接入使用效能自然就提高了。可是真的這麼簡單粗暴嗎？
接入率能說明什麼呢？接入好壞效果怎麼評價？什麼算接入？建立一條流水線，跑通了整個流程就算接入了，就能提高效能了？
企業為了推廣自己的平台，讓團隊接入本來無可厚非，可是方法錯了，如果為了團隊的KPI， 團隊自然會投入人力接入，可能團隊自己沒有認識到這個事情的價值，隻是因為上司需要我們這麼做。可以接入完了，團隊繼續按照自己過去的搞法玩，竹籃打水一場空。
5）找出問題比空喊口号更有用！-價值流分析
“你覺得你們團隊能給團隊帶來哪些效能提升？”有次和上層開會，上司的這個靈魂拷問讓我記憶猶新，說實在的，作為深谙DevOps理論和實踐的一線實踐者竟然不知如何回答。下來請教了很多行業内大咖，“找出問題就基本成功一半了”，這是一個專家的回答。突然我意識到，這不是就剛開始來找團隊做的“價值流分析”嗎，找到問題所在，走着走着迷失了方向~
雖然各家企業DevOps落地方案各不相同，但是有一個基本的共識就是到底要解決什麼問題，隻有真的弄清楚問題，才能想辦法解決。
在實施初期，我們一般會選擇比較有代表性的項目，進行調研和分析。我們會從需求管理、開發、代碼管理、建構、測試、部署、釋出這幾個方面進行調研和分析，判斷項目是否适合遷移到DevOps平台，項目研發過程的某些環節是否需要進行改進和完善。
- 需求管理：需求管理工具、使用者故事、任務、疊代等
- 開發：開發語言、開發工具、技術架構、運作環境、元件劃分及依賴關系等
- 代碼管理：代碼及文檔管理工具、代碼庫分支及用途、分支政策、代碼品質檢測工具及品質名額等
- 建構：建構工具、建構過程及建構政策、建構媒體政策、中間媒體及最終媒體管理等
- 測試：用例和Bug管理、自動化測試工具、驗收标準等
- 部署：環境規劃、環境配置、部署方式、依賴的中間件和公共元件等
- 釋出：上線傳遞物、釋出流程、應用及資料備份方式、復原方式等
本階段産出文檔：調研問卷、提升建議和改進方案。
6) 尋找“反抗軍”因為他們真的痛
項目試點是非常重要的環節，也是後續能否進行推廣的重要評判依據。經過前期的項目改進，以及流程規範的普及推廣，試點項目作出适當調整，試點項目的遷移是對之前所有工作的一個重要檢驗。
在試點階段，一方面是要通過試點項目的規範化改造，打造同類項目的流程規範，形成可複制的流水線模式；另一方面看遷移前後給試點項目帶來哪些好的效果，是否符合預期，是否還有需要改進的空間，平台能力是否需要提升等等。項目試點階段産出的文檔和手冊是後續推廣的重要資源。當試點項目的遷移達到預期效果，就可以進行DevOps平台的普及推廣
但往往啟動階段，就會面臨誰是第一個“吃螃蟹”的團隊，這個時候尋找合适的“反抗軍”是至關重要的，因為他們真的“很痛”，受研發效能底下困擾已久，他們迫切需要改變。這個初心比任何的行政指令更有效，這是發自他們内心的！
在和這些團隊一起協作的時候，也需要主要投入産出比，上來不要找一些高大上的，不切實際的最佳實踐。先讓他們看到效果甜頭，他們才願意投入資源進行改造。當然，過程中必要的溝通技巧，和團隊leader的個人關系也要搞好。
7） 平台建設思路
在DevOps實施過程中，工具鍊的打通必然涉及各種工具的整合。除了DevOps平台本身已經內建的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具，比較常見的是對客戶已有工具等內建，如客戶自建的項目管理平台、CMDB平台、自動化測試平台等等。
對于使用者自建工具的整合，首先需要去理清整合的真正目的是什麼，能為使用者帶來哪些價值。比如，對項目管理平台的整合，DevOps平台可以對項目等疊代、需求、任務等資訊進行收集和彙總，最終項目的進度、成本一目了然。再比如，對CMDB的內建，對于CD過程中使用的資源（主機、容器），直接從CMDB拉取資料即可，無需在DevOps平台中重新配置一遍。
這裡建議，對已有工具的整合，整合的是資料，目的是讓資料流轉和彙總起來，而非做功能的整合。
規範化、統一化
項目遷移到DevOps平台，各個項目可以在一個統一的DevOps平台進行CICD，無需各自搭建持續內建平台。通過制定合理的規範，不同的項目遵守一緻的規範，避免了代碼庫、CICD流程的管理混亂和不規範。制定度量名額和規範，對軟體開發成果和開發過程的測量和分析，幫助對軟體開發過程持續進行改進，有效提高軟體傳遞品質和效率。
研發效能提升
可視化和可編排，無需編寫pipeline腳本，一次配置，多次執行。送出或合并代碼出發、定時觸發或手動一鍵執行建構和部署，提高研發人員效率。有效減少系統變更部署上線的時間，快速響應業務變化。
報表展示、可度量
從效率、品質、進度三個次元展示任務、代碼、建構、部署相關資料，結合項目看闆、報表和度量名額，各環節幹系人可以對進度、品質等進行判斷和幹預。
DevOps的建設是難以短期内完成的，需要進行總體規劃，然後分階段實施。無論是工具的整合，還是度量體系的實施，都需要按部就班、循序漸進，逐漸完成建設，最終實作預期目标。
8） 以終為始，确立統一的目标，避免各自為政
上面一點提到了工具的整合，在企業組織内部，工具可能會分布在不同的部門裡，主要涉及到項目管理，需求管理，代碼管理，建構部署，測試等，DevOps效能平台的目标是拉通所有的工具，進行資料的整合。雖然說是工具的整合，其實不如說是工具背後部門間協作方式，和如何建立共同目标。
過去一段時間，筆者經曆過各工具背後的部門間思想沒有統一，大家名義上都在為一個目标服務，但是缺乏有效的統一目标和方案，說白了各自為政，這給後期的平台度量整合帶來很大的麻煩，有可能系統要重新設計，各系統間的資料模型需要花大力氣去适配和調整。
是以，其實在DevOps建設團隊的内部也需要通過虛拟的組織和明确的上司模式來合作，避免資源浪費和沖突。一個明确的建設體系群組織，至關重要，自己都是松散的，怎麼整合資料，怎麼說服研發團隊？
9）規範在哪裡？避免停留在“紙面上”的規範
代碼庫規範：包括分支和标簽命名規範、分支管理規範（管理流程、hotfix流程、分支政策）、代碼送出規範。
以分支開發、主幹釋出為例，管理流程規範中會涉及代碼庫準備、開發內建、驗收測試、釋出環節，每個分支的用途，每個環節中涉及的角色，角色的操作流程都有詳細規範。
CICD流程規範：命名規範：元件、媒體倉庫、建構定義、建構産物别名、釋出定義。流水線規範：開發流水線、使用者驗收測試流水線及復原流水線、釋出流水線及復原流水線、hotfix流水線。
通過制定流水線的規範，形成不同類型項目的CICD流程模版，可以作為組織級規範進行審計。
除了以上規範外，還包括項目管理規範，靈活開發規範，測試管理規範，安全規範，釋出規範，版本号規範等等。有的組織可能之前有了類似的規範，但是大多都停留在“紙面上”，實際落地很難，除非在研發過程有嚴格的卡點稽核，否則團隊很難落地執行。另一方面，規範先行很有必要，否則自研平台的開發就會形成無水之源，無本之木。
規範的建立，需要結合企業實際情況，需要流程制定部門和研發團隊共同制定，并且基于可以落地的方式，而不是空口理論和舉措，離開工具的标準，規範簡直就是“白紙一張”！
10) 基于現狀進行自研平台的開發，避免脫離團隊實際
對于流水線的定義和設計，需要考慮客戶的環境規劃和網絡政策。一般情況下，會設計和定義開發測試流水線、使用者驗收測試流水線、釋出流水線這些正常流水線，對應開發測試環境、使用者驗收環境、生産環境。開發測試流水線經過多次執行，業務系統形成穩定版本，傳遞到使用者驗收測試流水線，通過使用者驗收測試之後，再轉到釋出流水線進行釋出上線；這個過程也設計到代碼分支和标簽的維護。
有的客戶，階段傳遞物是某個版本的工件媒體，并且媒體庫可以多環境共享或者同步，這種情況下需要在開發測試流水線中設計建構環節和部署環節，在使用者驗收流水線和釋出流水線不需要建構環節，因為傳遞媒體像下一個環境同步即可。流水線設計如下：
有的客戶階段傳遞物是代碼，且各個環境有網絡政策限制。這種類型的流水線，不同環境需要根據對應的代碼分支或标簽将媒體建構出來，然後再進行部署。
這裡想強調的是，自研平台的開發不能離開業務研發團隊的實際場景，必須和他們進行溝通交流，如果單靠借鑒業界的通用流程，很可能最後會發現，團隊需要的根本不是這樣的。即不要離開業務場景去開發平台，需要和業務團隊進行緊密的溝通和面談，了解他們的需求，這也需要投入人力去梳理形成方案。如圖所示，通過團隊溝通形成傳遞流水線流程圖，可以清晰的讓雙方達成共識。
11） 工具并不能解決問題, 必須依靠完整的DevOps體系
- 立項：務必擷取高層上司的支援與推動；
- 目标：分階段建設，明确年度目标，不宜貪大求全；
- 組織：結合建設目标和現狀，明确牽頭部門，關注跨部門協同的難點；
- 落地：規則限制，可先研讨、線下驗證，再線上限制、逐漸調整，且不宜初期就設定過于細緻的規約；
- 文化：切勿重系統、輕文化，一定要關注人文關懷，重視組織文化建設，保障一個相對溫和的實踐環境。
- 完整的 DevOps 體系建設，不僅僅是新工具、新規則，更是新文化，而且在文化變革打頭陣的情況下，很可能取得更好、更持久的成果，讓組織具備自我糾偏的能力。
企業的DevOps實踐絕對不是自研一套平台或者買一套商用平台，缺乏規範指引，團隊賦能和教育訓練，名額引導等要素會寸步難行，這真的不是誇張，而是來自一線的真實感受。這也是為什麼DevOps落地如此之難的原因！
工具拉通，以平台為抓手，規範為指導，度量為方向，推進落地
12） 建立虛拟的工程效能改進組織
如圖所示，左邊需要建立虛拟的研發效能組織，包括項目管理，平台研發，營運推廣，規範審計，靈活教練，工程教練等諸多部門和角色，右側對接業務開發團隊，需要建立定期溝通機制，了解團隊平台需求，同時提供最佳實踐的教育訓練和賦能。于此同時，度量名額結合規範一起制定，幫助團隊持續改進。
13） 度量-效能提升永遠繞不開的痛
度量，這是研發效能永恒的話題。抛開度量的業務和技術本身，探讨度量的所見所聞和所思。
企業管理者之是以關注效能提升，目标就是希望能看到度量資料，這是他們的剛需，其實并不是研發團隊的剛需。如果真的把度量資料曝露在上司面前，研發團隊的一舉一動就擺在明面上了，一切以資料說話。這就是度量的兩面性的根源。
那麼在做自研效能平台時候，如何考慮度量的建設呢？我把之前提問專家的回複貼出來。
-
“如果做DevOps自研平台，什麼時候引入度量合适？”
無論是用devops工具平台自動收集度量資料，還是通過手工收集，合理的度量越早引入越好。因為度量資料的收集，需要經曆一個較長的過程，才能看到供改進參考的資料。
-
“可不可以邊做，邊設計名額收單點局部名額資料？”
可以，而且DevOps自研平台，也應該是小步疊代地實作度量資料的收集。不要一上來就設計和實作大批量的度量資料。因為大批量傳遞度量名額，會讓這批度量名額很晚才能傳遞，不利于盡早度量。
-
“如果問題很明顯了，有必要做度量，去暴露問題嗎？感覺既然很明顯了，就先改進解決問題”
問題很明顯了，也有必要做度量。一方面能通過度量資料，讓上司和團隊看到現狀。另一方面，在改進問題期間，收集度量資料所形成的變化趨勢，能讓大家看到改進舉措是否能有所成效。
目前，真正進行内部度量體系的建設，快被搞崩潰了。前期的基礎資料準備相當重要，業務之複雜遠超工程領域，後面再單獨寫文章聊。