記錄初衷
本人一直在從事企業內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自研平臺，也應該是小步迭代地實現度量資料的收集。不要一上來就設計和實現大批量的度量資料。因為大批量交付度量指標，會讓這批度量指標很晚才能交付，不利於儘早度量。 -
“如果問題很明顯了，有必要做度量，去暴露問題嗎？感覺既然很明顯了，就先改進解決問題”
問題很明顯了，也有必要做度量。一方面能通過度量資料，讓領導和團隊看到現狀。另一方面，在改進問題期間，收集度量資料所形成的變化趨勢，能讓大家看到改進舉措是否能有所成效。
目前，真正進行內部度量體系的建設，快被搞崩潰了。前期的基礎資料準備相當重要，業務之複雜遠超工程領域，後面再單獨寫文章聊。
未完待續
先寫這些，後面遇到更多的坑，再分享出來。