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