交付全鏈路數據，蘇寧消費金融在 DevOps 度量設計的思考

做者簡介

顧黃亮，十年研發運維經驗，涵蓋基礎架構、應用架構、數據庫、DevOps，有互聯網，電商，金融從業經歷。
專一於 DevOps 在企業中的應用和落地，致力於企業智慧運維體系的打造。參加多個行業、國家標準的編寫，《開源許可證使用指南（2018）》做者之一，國標《研發運營一體化（DEVOPS）能力成熟度模型》做者之一，《企業IT運維發展白皮書》做者之一，曾供職於航天晨光、上汽集團雲計算中心，現任蘇寧消費金融安全運維部負責人。

隨着 DevOps 的持續火熱，企業的信息化能力的持續增強，以及企業對於IT精益運行的迫切須要，從根本上提高 IT 的生產效率，加速部門、企業的業務創新能力。讓團隊從IT支撐部門，轉向爲IT創新部門。

近兩年來，超過10家頭部金融、互聯網、雲服務提供商等企業經過了《研發運營一體化（DevOps）能力成熟度模型》三級評估，經過這些經典案例，咱們不難看出，DevOps加速了軟件產品的版本交付和部署，實現端到端的持續交付，以流程驅動的方式打通端到端的交付通道。

蘇寧消費金融踐行 DevOps 過程當中，發現交付服務重要組成部分，交付全鏈路數據，還採起斷點的、無序的、度量性較差的傳統方式，缺少配套的全鏈路數據採集、管理、匯聚和輸出，致使項目交付過程當中的管控和交付後的評價缺少科學、客觀的可度量數據和度量體系，進而由流程驅動在積累一段時間後不能快速的推動至流程和數據雙驅動的模式。

創建健全的度量體系的需求在 DevOps 領域具備廣泛性，有助於在更大範圍內快速實現可度量的價值交付，拓展了業界的 DevOps 適用範圍，有助於更好提高組織級的質量和效率。
在正文以前，先談一下IT運維數據的發展歷程和 DevOps 落地的幾種方式，以及各個窗口期運維數據的輸出方式。
根據《企業IT運維發展白皮書》所述，IT運維技術能夠從自動化運維能力、平臺化運維能力、數據化運維能力和智能化運維能力四個層次進行階段性落地嘗試，這四個階段剛好凸顯了運維數據在不一樣階段對運維工具的納管能力、數據的採集、數據的聚合、數據的計算、數據的鏈路構建、數據的輸出、數據的驅動。
從交付的層面來講，價值交付的各個節點大體分爲以下，版本、產品需求、資源、研發、測試、運維、項目投產、項目後評價，僅有兩個角色是貫穿始終的，那就是運維和項目管控，而這兩個角色分別須要解決數據的管理和數據的度量。

DevOps落地的方式大體有四種，以下圖所示，（1）以項目週期數據爲基準的；（2）以資源數據爲基準的；（3）以交付數據爲基準的；（4）以監控數據爲基準的。

在這四種方式中，各窗口期的運維數據輸出方式各不相同，以一、3爲例，度量的手段囊括了資產、資源、版本質量、組織效率、工程環境，以二、4爲例，更多的體如今項目的後評價、成本化覆盤方面。

度量如何作，如何經過度量來進行過程和結果的管控，如何經過度量來優化現有流程，筆者認爲遵循如下幾點步驟。一、歸集度量數據指標；二、度量數據指標拆解；三、肯定度量數據維度；四、構建 DevOps 全鏈路度量體系。

1、歸集度量數據指標

---

在 DevOps 方法論的論述中，構建一個度量指標體系，首先須要根據 DevOps 落地的方式來了解 DevOps 的相關指標都有什麼。
在這以前須要明確一個觀點，任何度量的終極目標都是爲了更好管理和更有針對性的優化，從而使 DevOps 價值最大化。
接下來就以項目生命週期管理流程爲例來歸集全部數據指標，下圖爲蘇寧消費金融以項目生命週期爲基準的流水線，以此爲例。

一、基於項目生命週期管理的終極目標在於交付的價值和投入產出比的最大化。因此體如今數據指標上，最直接的兩個指標就是過程管理和項目後評價，其中過程管理又分爲兩個大類，分別爲工程效率和人員能效。而項目後評價則側重於項目達成和資源投入，具體的在指標分解中體現。

二、任何項目或者產品的上線都會有生命週期，即項目版本肯定到項目上線的一個過程。而這個過程是能夠分紅多個階段的。只要咱們思考清楚如何使每一個階段的又快又好的達成終極目標，咱們就能夠歸集出整個週期內所須要的大部分數據。項目生命週期管理按順序能夠分爲五大階段：

三、產品投產階段是實現產品階段性目標的重要階段，因此咱們要作的工做就是使能調度的資源都進入階段。因此在產品眼中，其實但願產品生命週期是這樣演變的。

四、項目後評價階段是進行成本覆盤的重要階段，是判斷人力資源、軟硬件資源的投入和產品運營後的產出對比，也是判斷項目或產品的成功與否，更是從較高的視野來進行項目和產品優化的重要手段。

2、度量數據指標拆解

---

歸集完所涉及的指標後，會發現指標不少。可是在具體的度量中，可能不一樣階段重點關注的指標不同。例如需求階段關注需求的吞吐量和需求總數，研發階段更關注研發效率和研發質量。因此對於不一樣的交付階段，咱們須要挑選出該階段的核心指標，而後進行拆解，再根據拆解的指標去重點關注。
在度量數據指標拆解以前，說一下流程驅動和數據驅動的區別。流程驅動更相似於ITIL（IT服務流程），分別有問題管理、事件管理、變動管理、業務連續性管理等指標。而數據驅動更關注以結果爲導向的指標，可優化可回溯的特性較爲明顯，即交付價值。
在流程驅動的過程當中，咱們會發現有一個嚴重的問題須要咱們去解決，那就是爲了完成流程驅動，有可能實現的執行手段和目標所達成的願景是相悖的，這也是流程驅動轉變至數據驅動，或者說流程和數據的雙軌驅動的需求。
簡單的總結一下，流程驅動讓你在正確的道路上往前走，而數據驅動是持續的確保你往正確的道路上走。而提高組織級的效率和質量，你須要總體性的優化，當你進行度量指標拆解的時候，你須要關注兩個問題，①爲何須要這個指標；②從這些指標中，你可以得到什麼。

一樣拿蘇寧消費金融項目生命週期爲基準的流水線舉例，進行指標拆解：

項目指標：項目進度、項目工時、項目質量

需求指標：需求總數、各狀態的需求總數、當前的需求完成狀況、各業務方的需求總數、需求吞吐率

版本指標：版本數量、分支數量、倉庫數量、代碼提交數、代碼提交頻率
團隊指標：團隊狀況、人員狀況、任務分解狀況、團隊所管理系統狀況、團隊承接需求狀況、團隊承接任務狀況

資源指標：工程環境數量、系統分配資源狀況、團隊分配資源狀況、人員分配資源狀況、資源可用數據、資源使用數據、資源性能數據

構建指標：構建次數、構建頻率、構建時長、構建成功率
質量指標：壞味道數量、阻塞數量、代碼行數、代碼重複率、代碼問題數、單元測試用例數、單元測試覆蓋率、單元測試執行結果、自動化測試用例數、自動化測試成功率、手動測試用例數、BUG數量、團隊BUG數量、人員BUG數量、BUG修復時長、千行代碼BUG數
環境指標：環境變動時長、環境變動評率、環境不可用時長、工程環境數量
部署指標：部署次數、部署時長、變動時長、部署成功率、整體變動成功率、一次變動成功率

監控指標：監控覆蓋率、監控送達率、監控準確率、線上問題統計、線上問題恢復時長

項目後評價指標：以產品運營核心指標爲準 ，如PV\UV、行爲、轉化率、利潤

3、肯定度量數據維度

---

在肯定度量數據維度以前，介紹下業內兩種經常使用的方式，①數字維度，②類型維度。

軟件是數字化的事物，根據度量維度的不一樣，涵蓋相應的指標類型分別有

1. 可具體的；
2. 可度量的；
3. 可實現的；
4. 現實性的；
5. 有時限的。

而具體的實施有幾種方式，

1. 計數實施，統計度量指標的數量、度量任務的數量、誤差的數量；
2. 測量測算，統計狀態的數據信息，如區間內遞增值和遞減值；

3. 數據分佈，統計數據的分佈狀況，如最大值、最小值、平均值、中位數、百分比；

4. 計時，統計單位時間內的消耗時間和分佈狀況；

按類型維度，可分爲時間維度，如秒、分、時、天、周、月、年；按組織架構，如A團隊、B團隊、C團隊；按渠道，如A渠道、B渠道、C渠道；按系統類型，如公衆號、官網、APP、IOS。
在進行度量數據維度考覈的時候，會有一些難點須要考慮。①度量的難點；②度量的誤區；③度量指標不能動態調整。

1. 度量的難點，主要集中在度量的可視化不夠健全、工做切分的隨意性、敏捷交付過程當中存在多項目的並行；

2. 度量的誤區，主要集中在過渡考覈虛榮性指標，如日均代碼量，局部單元測試覆蓋率，工時統計等等，當虛榮性指標成爲核心度量指標，那就是災難的開始。

3. 度量指標不能動態調整，隨着團隊的效能提高，指標也隨之調整，不然將使團隊的效能停滯不前。

肯定度量指標維度有四個原則，分別是：
①全局指標和局部指標的關係，過渡對局部指標進行優化可能使全局劣勢，所以要提高全局指標的達成率爲目標。
②定量指標和定性指標的關係，儘可能使用量化指標的客觀評價，讓流程驅動儘快延伸至數據驅動。
③團隊指標和我的指標的關係，指標的設定是促進團隊協做，提高組織級的能效和質量，不能因我的指標的關係形成團隊和諧。
④結果指標和過程指標的關係，經過結果指標來評估結果，經過過程指標來優化改進，兩者不是簡單的包含和被包含的關係。

4、構建 DevOps 全鏈路度量體系

---

對於流程和數據雙軌驅動的DevOps，打造和構建全鏈路的度量體系，經過自動化部署流水線有效提升軟件交付的效率，經過質量內建確保軟件交付的質量，經過對過程性數據的持續收集和分析發現交付過程當中存在的瓶頸，經過對軟件產品和用戶的線上數據獲取反饋而且及時做出調整，經過結果性數據去評價團隊的成效。

以DevOps價值服務輸出模型做爲本次文章的結尾。

還不過癮？GOPS 2020 全球運維大會 · 深圳站，更多 DevOps 的精彩議題，請參見大會日程（持續更新中）