記錄初衷

本人一直在從事企業(yè)內(nèi)DevOps落地實(shí)踐的工作，走了不少?gòu)澛罚才υ谙朕k法解決面臨的問題，期間也經(jīng)歷過不少人和事情，最近突然有想法把經(jīng)歷過的，不管好的不好的都記錄下來，分享給和我一樣的一線實(shí)踐者。
我會(huì)通過一個(gè)個(gè)典型故事或場(chǎng)景來敘述，不談理論，不談技術(shù), 只談?dòng)龅降娜撕褪拢液臀业膱F(tuán)隊(duì)伙伴怎么解決實(shí)踐中遇到的問題。

1）DevOps好像很火，我們也來做個(gè)搞吧

“DevOps好像大廠都在搞，聽說能提高效能，我們的項(xiàng)目經(jīng)常延期，要不我們也搞吧~”可能這是很多企業(yè)領(lǐng)導(dǎo)實(shí)施DevOps的初衷, 這個(gè)初衷本沒有錯(cuò)，可是真的準(zhǔn)備好了嗎？想清楚做什么了嗎？沒關(guān)系，可以請(qǐng)外部專家講下，聽下來感覺就是一大堆工具的組合，不就是開發(fā)一個(gè)一體化平臺(tái)嗎？
如果只是看到了別人的成果，沒有清楚中間付出的艱辛和改進(jìn)，沒有好的方法論指導(dǎo)，很容易照貓畫虎，內(nèi)部的改進(jìn)“走形”！

2） 買了你們的平臺(tái)，多久能有效果出來？

在企業(yè)DevOps實(shí)踐初期，對(duì)于自研和外部采購(gòu)還存在一些猶豫，一方面覺得如果自己投入資源研發(fā)，周期比較長(zhǎng)，自己等不了，所以希望能夠盡快通過成熟的外部工具快速達(dá)到自己的期望的目標(biāo)。于此同時(shí)，外部的DevOps平臺(tái)廠商或者咨詢就會(huì)看到機(jī)會(huì)開始介入，對(duì)自己的產(chǎn)品和方案進(jìn)行推廣。對(duì)于外部的咨詢和廠商 ，領(lǐng)導(dǎo)常問的問題就是“我買了你們的平臺(tái)，多久能出效果？”，或 “你們過去的案例一般需要多久？”，“是不是我們買了你們的平臺(tái)，團(tuán)隊(duì)可以馬上用了”，諸如此類的問題往往令外部的咨詢和銷售無法回答，因?yàn)檎嬲鲞^落地實(shí)踐的人都清楚，不可能給出一個(gè)明確的答案。
其實(shí)，這種現(xiàn)象也反映了組織內(nèi)領(lǐng)導(dǎo)沒有真正清楚這個(gè)事情到底要怎么做，他們覺得工具能解決問題。這是對(duì)于DevOps的一個(gè)誤區(qū)。

3）“DevOps”應(yīng)該從管理層認(rèn)可開始

DevOps出現(xiàn)之后，大家也許曾經(jīng)提出或者聽到過一個(gè)很關(guān)鍵卻又普遍的問題——“DevOps轉(zhuǎn)型應(yīng)該從哪里開始？”
工作中，并非所有人都信任DevOps，通常遇到的第一個(gè)難題是得到管理層的認(rèn)可與支持，因?yàn)镈evOps的核心含義可能會(huì)掀起公司的大變革。
但是即使有管理層支持，如果管理層沒有懂DevOps的帶頭人，往往也會(huì)出現(xiàn)“事倍功半”的情況，管理層基于得到結(jié)果，忽視了這是一次變革，不是某一個(gè)團(tuán)隊(duì)就可以進(jìn)行的。

4）通過工具平臺(tái)接入率來衡量改進(jìn)效果?

在領(lǐng)導(dǎo)的支持下，企業(yè)開始打造自研效能平臺(tái)，但是怎么推廣呢？往往會(huì)陷入一個(gè)誤區(qū)，就是開發(fā)了，大家接入使用就好了，接入使用效能自然就提高了。可是真的這么簡(jiǎn)單粗暴嗎？
接入率能說明什么呢？接入好壞效果怎么評(píng)價(jià)？什么算接入？創(chuàng)建一條流水線，跑通了整個(gè)流程就算接入了，就能提高效能了？
企業(yè)為了推廣自己的平臺(tái)，讓團(tuán)隊(duì)接入本來無可厚非，可是方法錯(cuò)了，如果為了團(tuán)隊(duì)的KPI， 團(tuán)隊(duì)自然會(huì)投入人力接入，可能團(tuán)隊(duì)自己沒有認(rèn)識(shí)到這個(gè)事情的價(jià)值，只是因?yàn)轭I(lǐng)導(dǎo)需要我們這么做。可以接入完了，團(tuán)隊(duì)繼續(xù)按照自己過去的搞法玩，竹籃打水一場(chǎng)空。

5）找出問題比空喊口號(hào)更有用！-價(jià)值流分析

“你覺得你們團(tuán)隊(duì)能給團(tuán)隊(duì)帶來哪些效能提升？”有次和上層開會(huì)，領(lǐng)導(dǎo)的這個(gè)靈魂拷問讓我記憶猶新，說實(shí)在的，作為深諳DevOps理論和實(shí)踐的一線實(shí)踐者竟然不知如何回答。下來請(qǐng)教了很多行業(yè)內(nèi)大咖，“找出問題就基本成功一半了”，這是一個(gè)專家的回答。突然我意識(shí)到，這不是就剛開始來找團(tuán)隊(duì)做的“價(jià)值流分析”嗎，找到問題所在，走著走著迷失了方向~

雖然各家企業(yè)DevOps落地方案各不相同，但是有一個(gè)基本的共識(shí)就是到底要解決什么問題，只有真的弄清楚問題，才能想辦法解決。
在實(shí)施初期，我們一般會(huì)選擇比較有代表性的項(xiàng)目，進(jìn)行調(diào)研和分析。我們會(huì)從需求管理、開發(fā)、代碼管理、構(gòu)建、測(cè)試、部署、發(fā)布這幾個(gè)方面進(jìn)行調(diào)研和分析，判斷項(xiàng)目是否適合遷移到DevOps平臺(tái)，項(xiàng)目研發(fā)過程的某些環(huán)節(jié)是否需要進(jìn)行改進(jìn)和完善。

• 需求管理：需求管理工具、用戶故事、任務(wù)、迭代等
• 開發(fā)：開發(fā)語言、開發(fā)工具、技術(shù)框架、運(yùn)行環(huán)境、組件劃分及依賴關(guān)系等
• 代碼管理：代碼及文檔管理工具、代碼庫(kù)分支及用途、分支策略、代碼質(zhì)量檢測(cè)工具及質(zhì)量指標(biāo)等
• 構(gòu)建：構(gòu)建工具、構(gòu)建過程及構(gòu)建策略、構(gòu)建介質(zhì)策略、中間介質(zhì)及最終介質(zhì)管理等
• 測(cè)試：用例和Bug管理、自動(dòng)化測(cè)試工具、驗(yàn)收標(biāo)準(zhǔn)等
• 部署：環(huán)境規(guī)劃、環(huán)境配置、部署方式、依賴的中間件和公共組件等
• 發(fā)布：上線交付物、發(fā)布流程、應(yīng)用及數(shù)據(jù)備份方式、回滾方式等

本階段產(chǎn)出文檔：調(diào)研問卷、提升建議和改進(jìn)方案。

7） 平臺(tái)建設(shè)思路

在DevOps實(shí)施過程中，工具鏈的打通必然涉及各種工具的整合。除了DevOps平臺(tái)本身已經(jīng)集成的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具，比較常見的是對(duì)客戶已有工具等集成，如客戶自建的項(xiàng)目管理平臺(tái)、CMDB平臺(tái)、自動(dòng)化測(cè)試平臺(tái)等等。
對(duì)于用戶自建工具的整合，首先需要去理清整合的真正目的是什么，能為用戶帶來哪些價(jià)值。比如，對(duì)項(xiàng)目管理平臺(tái)的整合，DevOps平臺(tái)可以對(duì)項(xiàng)目等迭代、需求、任務(wù)等信息進(jìn)行收集和匯總，最終項(xiàng)目的進(jìn)度、成本一目了然。再比如，對(duì)CMDB的集成，對(duì)于CD過程中使用的資源（主機(jī)、容器），直接從CMDB拉取數(shù)據(jù)即可，無需在DevOps平臺(tái)中重新配置一遍。

這里建議，對(duì)已有工具的整合，整合的是數(shù)據(jù)，目的是讓數(shù)據(jù)流轉(zhuǎn)和匯總起來，而非做功能的整合。

規(guī)范化、統(tǒng)一化
項(xiàng)目遷移到DevOps平臺(tái)，各個(gè)項(xiàng)目可以在一個(gè)統(tǒng)一的DevOps平臺(tái)進(jìn)行CICD，無需各自搭建持續(xù)集成平臺(tái)。通過制定合理的規(guī)范，不同的項(xiàng)目遵守一致的規(guī)范，避免了代碼庫(kù)、CICD流程的管理混亂和不規(guī)范。制定度量指標(biāo)和規(guī)范，對(duì)軟件開發(fā)成果和開發(fā)過程的測(cè)量和分析，幫助對(duì)軟件開發(fā)過程持續(xù)進(jìn)行改進(jìn)，有效提高軟件交付質(zhì)量和效率。

研發(fā)效能提升
可視化和可編排，無需編寫pipeline腳本，一次配置，多次執(zhí)行。提交或合并代碼出發(fā)、定時(shí)觸發(fā)或手動(dòng)一鍵執(zhí)行構(gòu)建和部署，提高研發(fā)人員效率。有效減少系統(tǒng)變更部署上線的時(shí)間，快速響應(yīng)業(yè)務(wù)變化。

報(bào)表展示、可度量
從效率、質(zhì)量、進(jìn)度三個(gè)維度展示任務(wù)、代碼、構(gòu)建、部署相關(guān)數(shù)據(jù)，結(jié)合項(xiàng)目看板、報(bào)表和度量指標(biāo)，各環(huán)節(jié)干系人可以對(duì)進(jìn)度、質(zhì)量等進(jìn)行判斷和干預(yù)。
DevOps的建設(shè)是難以短期內(nèi)完成的，需要進(jìn)行總體規(guī)劃，然后分階段實(shí)施。無論是工具的整合，還是度量體系的實(shí)施，都需要按部就班、循序漸進(jìn)，逐步完成建設(shè)，最終實(shí)現(xiàn)預(yù)期目標(biāo)。

8） 以終為始，確立統(tǒng)一的目標(biāo)，避免各自為政

上面一點(diǎn)提到了工具的整合，在企業(yè)組織內(nèi)部，工具可能會(huì)分布在不同的部門里，主要涉及到項(xiàng)目管理，需求管理，代碼管理，構(gòu)建部署，測(cè)試等，DevOps效能平臺(tái)的目標(biāo)是拉通所有的工具，進(jìn)行數(shù)據(jù)的整合。雖然說是工具的整合，其實(shí)不如說是工具背后部門間協(xié)作方式，和如何建立共同目標(biāo)。
過去一段時(shí)間，筆者經(jīng)歷過各工具背后的部門間思想沒有統(tǒng)一，大家名義上都在為一個(gè)目標(biāo)服務(wù)，但是缺乏有效的統(tǒng)一目標(biāo)和方案，說白了各自為政，這給后期的平臺(tái)度量整合帶來很大的麻煩，有可能系統(tǒng)要重新設(shè)計(jì)，各系統(tǒng)間的數(shù)據(jù)模型需要花大力氣去適配和調(diào)整。
所以，其實(shí)在DevOps建設(shè)團(tuán)隊(duì)的內(nèi)部也需要通過虛擬的組織和明確的領(lǐng)導(dǎo)模式來合作，避免資源浪費(fèi)和沖突。一個(gè)明確的建設(shè)體系和組織，至關(guān)重要，自己都是松散的，怎么整合數(shù)據(jù)，怎么說服研發(fā)團(tuán)隊(duì)？

9）規(guī)范在哪里？避免停留在“紙面上”的規(guī)范

代碼庫(kù)規(guī)范：包括分支和標(biāo)簽命名規(guī)范、分支管理規(guī)范（管理流程、hotfix流程、分支策略）、代碼提交規(guī)范。
以分支開發(fā)、主干發(fā)布為例，管理流程規(guī)范中會(huì)涉及代碼庫(kù)準(zhǔn)備、開發(fā)集成、驗(yàn)收測(cè)試、發(fā)布環(huán)節(jié)，每個(gè)分支的用途，每個(gè)環(huán)節(jié)中涉及的角色，角色的操作流程都有詳細(xì)規(guī)范。

CICD流程規(guī)范：命名規(guī)范：組件、介質(zhì)倉(cāng)庫(kù)、構(gòu)建定義、構(gòu)建產(chǎn)物別名、發(fā)布定義。流水線規(guī)范：開發(fā)流水線、用戶驗(yàn)收測(cè)試流水線及回滾流水線、發(fā)布流水線及回滾流水線、hotfix流水線。
通過制定流水線的規(guī)范，形成不同類型項(xiàng)目的CICD流程模版，可以作為組織級(jí)規(guī)范進(jìn)行審計(jì)。

除了以上規(guī)范外，還包括項(xiàng)目管理規(guī)范，敏捷開發(fā)規(guī)范，測(cè)試管理規(guī)范，安全規(guī)范，發(fā)布規(guī)范，版本號(hào)規(guī)范等等。有的組織可能之前有了類似的規(guī)范，但是大多都停留在“紙面上”，實(shí)際落地很難，除非在研發(fā)過程有嚴(yán)格的卡點(diǎn)審核，否則團(tuán)隊(duì)很難落地執(zhí)行。另一方面，規(guī)范先行很有必要，否則自研平臺(tái)的開發(fā)就會(huì)形成無水之源，無本之木。
規(guī)范的建立，需要結(jié)合企業(yè)實(shí)際情況，需要流程制定部門和研發(fā)團(tuán)隊(duì)共同制定，并且基于可以落地的方式，而不是空口理論和舉措，離開工具的標(biāo)準(zhǔn)，規(guī)范簡(jiǎn)直就是“白紙一張”！

10) 基于現(xiàn)狀進(jìn)行自研平臺(tái)的開發(fā)，避免脫離團(tuán)隊(duì)實(shí)際

對(duì)于流水線的定義和設(shè)計(jì)，需要考慮客戶的環(huán)境規(guī)劃和網(wǎng)絡(luò)策略。一般情況下，會(huì)設(shè)計(jì)和定義開發(fā)測(cè)試流水線、用戶驗(yàn)收測(cè)試流水線、發(fā)布流水線這些常規(guī)流水線，對(duì)應(yīng)開發(fā)測(cè)試環(huán)境、用戶驗(yàn)收環(huán)境、生產(chǎn)環(huán)境。開發(fā)測(cè)試流水線經(jīng)過多次執(zhí)行，業(yè)務(wù)系統(tǒng)形成穩(wěn)定版本，交付到用戶驗(yàn)收測(cè)試流水線，通過用戶驗(yàn)收測(cè)試之后，再轉(zhuǎn)到發(fā)布流水線進(jìn)行發(fā)布上線；這個(gè)過程也設(shè)計(jì)到代碼分支和標(biāo)簽的維護(hù)。

有的客戶，階段交付物是某個(gè)版本的工件介質(zhì)，并且介質(zhì)庫(kù)可以多環(huán)境共享或者同步，這種情況下需要在開發(fā)測(cè)試流水線中設(shè)計(jì)構(gòu)建環(huán)節(jié)和部署環(huán)節(jié)，在用戶驗(yàn)收流水線和發(fā)布流水線不需要構(gòu)建環(huán)節(jié)，因?yàn)榻桓督橘|(zhì)像下一個(gè)環(huán)境同步即可。流水線設(shè)計(jì)如下：

有的客戶階段交付物是代碼，且各個(gè)環(huán)境有網(wǎng)絡(luò)策略限制。這種類型的流水線，不同環(huán)境需要根據(jù)對(duì)應(yīng)的代碼分支或標(biāo)簽將介質(zhì)構(gòu)建出來，然后再進(jìn)行部署。

這里想強(qiáng)調(diào)的是，自研平臺(tái)的開發(fā)不能離開業(yè)務(wù)研發(fā)團(tuán)隊(duì)的實(shí)際場(chǎng)景，必須和他們進(jìn)行溝通交流，如果單靠借鑒業(yè)界的通用流程，很可能最后會(huì)發(fā)現(xiàn)，團(tuán)隊(duì)需要的根本不是這樣的。即不要離開業(yè)務(wù)場(chǎng)景去開發(fā)平臺(tái)，需要和業(yè)務(wù)團(tuán)隊(duì)進(jìn)行緊密的溝通和面談，了解他們的需求，這也需要投入人力去梳理形成方案。如圖所示，通過團(tuán)隊(duì)溝通形成交付流水線流程圖，可以清晰的讓雙方達(dá)成共識(shí)。

11） 工具并不能解決問題, 必須依靠完整的DevOps體系

• 立項(xiàng)：務(wù)必獲取高層領(lǐng)導(dǎo)的支持與推動(dòng)；
• 目標(biāo)：分階段建設(shè)，明確年度目標(biāo)，不宜貪大求全；
• 組織：結(jié)合建設(shè)目標(biāo)和現(xiàn)狀，明確牽頭部門，關(guān)注跨部門協(xié)同的難點(diǎn)；
• 落地：規(guī)則約束，可先研討、線下驗(yàn)證，再線上約束、逐步調(diào)整，且不宜初期就設(shè)置過于細(xì)致的規(guī)約；
• 文化：切勿重系統(tǒng)、輕文化，一定要關(guān)注人文關(guān)懷，重視組織文化建設(shè)，保障一個(gè)相對(duì)溫和的實(shí)踐環(huán)境。
• 完整的 DevOps 體系建設(shè)，不僅僅是新工具、新規(guī)則，更是新文化，而且在文化變革打頭陣的情況下，很可能取得更好、更持久的成果，讓組織具備自我糾偏的能力。

企業(yè)的DevOps實(shí)踐絕對(duì)不是自研一套平臺(tái)或者買一套商用平臺(tái)，缺乏規(guī)范指引，團(tuán)隊(duì)賦能和培訓(xùn)，指標(biāo)引導(dǎo)等要素會(huì)寸步難行，這真的不是夸張，而是來自一線的真實(shí)感受。這也是為什么DevOps落地如此之難的原因！

工具拉通，以平臺(tái)為抓手，規(guī)范為指導(dǎo)，度量為方向，推進(jìn)落地

12） 建立虛擬的工程效能改進(jìn)組織

如圖所示，左邊需要建立虛擬的研發(fā)效能組織，包括項(xiàng)目管理，平臺(tái)研發(fā)，運(yùn)營(yíng)推廣，規(guī)范審計(jì)，敏捷教練，工程教練等諸多部門和角色，右側(cè)對(duì)接業(yè)務(wù)開發(fā)團(tuán)隊(duì)，需要建立定期溝通機(jī)制，了解團(tuán)隊(duì)平臺(tái)需求，同時(shí)提供最佳實(shí)踐的培訓(xùn)和賦能。于此同時(shí)，度量指標(biāo)結(jié)合規(guī)范一起制定，幫助團(tuán)隊(duì)持續(xù)改進(jìn)。

13） 度量-效能提升永遠(yuǎn)繞不開的痛

度量，這是研發(fā)效能永恒的話題。拋開度量的業(yè)務(wù)和技術(shù)本身，探討度量的所見所聞和所思。
企業(yè)管理者之所以關(guān)注效能提升，目標(biāo)就是希望能看到度量數(shù)據(jù)，這是他們的剛需，其實(shí)并不是研發(fā)團(tuán)隊(duì)的剛需。如果真的把度量數(shù)據(jù)曝露在領(lǐng)導(dǎo)面前，研發(fā)團(tuán)隊(duì)的一舉一動(dòng)就擺在明面上了，一切以數(shù)據(jù)說話。這就是度量的兩面性的根源。

那么在做自研效能平臺(tái)時(shí)候，如何考慮度量的建設(shè)呢？我把之前提問專家的回復(fù)貼出來。

• “如果做DevOps自研平臺(tái)，什么時(shí)候引入度量合適？”
  無論是用devops工具平臺(tái)自動(dòng)收集度量數(shù)據(jù)，還是通過手工收集，合理的度量越早引入越好。因?yàn)槎攘繑?shù)據(jù)的收集，需要經(jīng)歷一個(gè)較長(zhǎng)的過程，才能看到供改進(jìn)參考的數(shù)據(jù)。

• “可不可以邊做，邊設(shè)計(jì)指標(biāo)收單點(diǎn)局部指標(biāo)數(shù)據(jù)？”
  可以，而且DevOps自研平臺(tái)，也應(yīng)該是小步迭代地實(shí)現(xiàn)度量數(shù)據(jù)的收集。不要一上來就設(shè)計(jì)和實(shí)現(xiàn)大批量的度量數(shù)據(jù)。因?yàn)榇笈拷桓抖攘恐笜?biāo)，會(huì)讓這批度量指標(biāo)很晚才能交付，不利于盡早度量。

• “如果問題很明顯了，有必要做度量，去暴露問題嗎？感覺既然很明顯了，就先改進(jìn)解決問題”
  問題很明顯了，也有必要做度量。一方面能通過度量數(shù)據(jù)，讓領(lǐng)導(dǎo)和團(tuán)隊(duì)看到現(xiàn)狀。另一方面，在改進(jìn)問題期間，收集度量數(shù)據(jù)所形成的變化趨勢(shì)，能讓大家看到改進(jìn)舉措是否能有所成效。

目前，真正進(jìn)行內(nèi)部度量體系的建設(shè)，快被搞崩潰了。前期的基礎(chǔ)數(shù)據(jù)準(zhǔn)備相當(dāng)重要，業(yè)務(wù)之復(fù)雜遠(yuǎn)超工程領(lǐng)域，后面再單獨(dú)寫文章聊。

未完待續(xù)

先寫這些，后面遇到更多的坑，再分享出來。