記錄初衷

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

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

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

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

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

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

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

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

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

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

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

雖然各家企業(yè)DevOps落地方案各不相同，但是有一個(gè)基本的共識(shí)就是到底要解決什么問(wèn)題，只有真的弄清楚問(wèn)題，才能想辦法解決。

在實(shí)施初期，我們一般會(huì)選擇比較有代表性的項(xiàng)目，進(jìn)行調(diào)研和分析。我們會(huì)從需求管理、開(kāi)發(fā)、代碼管理、構(gòu)建、測(cè)試、部署、發(fā)布這幾個(gè)方面進(jìn)行調(diào)研和分析，判斷項(xiàng)目是否適合遷移到DevOps平臺(tái)，項(xiàng)目研發(fā)過(guò)程的某些環(huán)節(jié)是否需要進(jìn)行改進(jìn)和完善。

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

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

6) 尋找“反抗軍”因?yàn)樗麄冋娴耐?/h2>

項(xiàng)目試點(diǎn)是非常重要的環(huán)節(jié)，也是后續(xù)能否進(jìn)行推廣的重要評(píng)判依據(jù)。經(jīng)過(guò)前期的項(xiàng)目改進(jìn)，以及流程規(guī)范的普及推廣，試點(diǎn)項(xiàng)目作出適當(dāng)調(diào)整，試點(diǎn)項(xiàng)目的遷移是對(duì)之前所有工作的一個(gè)重要檢驗(yàn)。
在試點(diǎn)階段，一方面是要通過(guò)試點(diǎn)項(xiàng)目的規(guī)范化改造，打造同類(lèi)項(xiàng)目的流程規(guī)范，形成可復(fù)制的流水線(xiàn)模式；另一方面看遷移前后給試點(diǎn)項(xiàng)目帶來(lái)哪些好的效果，是否符合預(yù)期，是否還有需要改進(jìn)的空間，平臺(tái)能力是否需要提升等等。項(xiàng)目試點(diǎn)階段產(chǎn)出的文檔和手冊(cè)是后續(xù)推廣的重要資源。當(dāng)試點(diǎn)項(xiàng)目的遷移達(dá)到預(yù)期效果，就可以進(jìn)行DevOps平臺(tái)的普及推廣
但往往啟動(dòng)階段，就會(huì)面臨誰(shuí)是第一個(gè)“吃螃蟹”的團(tuán)隊(duì)，這個(gè)時(shí)候?qū)ふ液线m的“反抗軍”是至關(guān)重要的，因?yàn)樗麄冋娴摹昂芡础保苎邪l(fā)效能底下困擾已久，他們迫切需要改變。這個(gè)初心比任何的行政命令更有效，這是發(fā)自他們內(nèi)心的！
在和這些團(tuán)隊(duì)一起協(xié)作的時(shí)候，也需要主要投入產(chǎn)出比，上來(lái)不要找一些高大上的，不切實(shí)際的最佳實(shí)踐。先讓他們看到效果甜頭，他們才愿意投入資源進(jìn)行改造。當(dāng)然，過(guò)程中必要的溝通技巧，和團(tuán)隊(duì)leader的個(gè)人關(guān)系也要搞好。

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

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

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

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

研發(fā)效能提升
可視化和可編排，無(wú)需編寫(xiě)pipeline腳本，一次配置，多次執(zhí)行。提交或合并代碼出發(fā)、定時(shí)觸發(fā)或手動(dòng)一鍵執(zhí)行構(gòu)建和部署，提高研發(fā)人員效率。有效減少系統(tǒng)變更部署上線(xiàn)的時(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í)施。無(wú)論是工具的整合，還是度量體系的實(shí)施，都需要按部就班、循序漸進(jìn)，逐步完成建設(shè)，最終實(shí)現(xiàn)預(yù)期目標(biāo)。

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

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

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

代碼庫(kù)規(guī)范：包括分支和標(biāo)簽命名規(guī)范、分支管理規(guī)范（管理流程、hotfix流程、分支策略）、代碼提交規(guī)范。
以分支開(kāi)發(fā)、主干發(fā)布為例，管理流程規(guī)范中會(huì)涉及代碼庫(kù)準(zhǔn)備、開(kāi)發(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ā)布定義。流水線(xiàn)規(guī)范：開(kāi)發(fā)流水線(xiàn)、用戶(hù)驗(yàn)收測(cè)試流水線(xiàn)及回滾流水線(xiàn)、發(fā)布流水線(xiàn)及回滾流水線(xiàn)、hotfix流水線(xiàn)。
通過(guò)制定流水線(xiàn)的規(guī)范，形成不同類(lèi)型項(xiàng)目的CICD流程模版，可以作為組織級(jí)規(guī)范進(jìn)行審計(jì)。

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

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

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

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

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

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

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

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

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

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

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

如圖所示，左邊需要建立虛擬的研發(fā)效能組織，包括項(xiàng)目管理，平臺(tái)研發(fā)，運(yùn)營(yíng)推廣，規(guī)范審計(jì)，敏捷教練，工程教練等諸多部門(mén)和角色，右側(cè)對(duì)接業(yè)務(wù)開(kāi)發(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)繞不開(kāi)的痛

度量，這是研發(fā)效能永恒的話(huà)題。拋開(kāi)度量的業(yè)務(wù)和技術(shù)本身，探討度量的所見(jiàn)所聞和所思。
企業(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ù)說(shuō)話(huà)。這就是度量的兩面性的根源。

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

• “如果做DevOps自研平臺(tái)，什么時(shí)候引入度量合適？”
  無(wú)論是用devops工具平臺(tái)自動(dòng)收集度量數(shù)據(jù)，還是通過(guò)手工收集，合理的度量越早引入越好。因?yàn)槎攘繑?shù)據(jù)的收集，需要經(jīng)歷一個(gè)較長(zhǎng)的過(guò)程，才能看到供改進(jìn)參考的數(shù)據(jù)。
• “可不可以邊做，邊設(shè)計(jì)指標(biāo)收單點(diǎn)局部指標(biāo)數(shù)據(jù)？”
  可以，而且DevOps自研平臺(tái)，也應(yīng)該是小步迭代地實(shí)現(xiàn)度量數(shù)據(jù)的收集。不要一上來(lái)就設(shè)計(jì)和實(shí)現(xiàn)大批量的度量數(shù)據(jù)。因?yàn)榇笈拷桓抖攘恐笜?biāo)，會(huì)讓這批度量指標(biāo)很晚才能交付，不利于盡早度量。
• “如果問(wèn)題很明顯了，有必要做度量，去暴露問(wèn)題嗎？感覺(jué)既然很明顯了，就先改進(jìn)解決問(wèn)題”
  問(wèn)題很明顯了，也有必要做度量。一方面能通過(guò)度量數(shù)據(jù)，讓領(lǐng)導(dǎo)和團(tuán)隊(duì)看到現(xiàn)狀。另一方面，在改進(jìn)問(wè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ú)寫(xiě)文章聊。

未完待續(xù)

先寫(xiě)這些，后面遇到更多的坑，再分享出來(lái)。