從0到1打造資料可信的資料產品:解析資料治理在過程可信變革中的運作流程
摘要:本文針對“資料牽引改進,工具固化規範”這一思路在業務團隊落地過程中的動作流程進行詳細闡述,並明確了支撐整個流程的關鍵角色定義和組織運作形式。
目的
為實現雲服務開發的過程可信,需要基於資料對各個服務產品部的可信變革動作進行資料採集、進展可視、目標牽引、能力評估,最終用資料反映目標達成。與傳統的“基於資料晾晒驅動業務團隊改進,6+1指標度量”的運作方式有本質的區別,我們是基於統一的作業工具上產生的客觀資料呈現,識別研發過程中基本的流程斷裂點和質量缺失動作,和業務團隊達成一致的目標後,把大部分改進動作固話到作業工具中自動化承載,我們稱這個思路為“資料牽引改進,工具固化規範”,也就是我們不僅告訴業務團隊哪裡有問題,同時也要基於我們的作業工具,輔助業務團隊一起改進完善。
本文針對“資料牽引改進,工具固化規範”這一思路在業務團隊落地過程中的動作流程進行詳細闡述,並明確了支撐整個流程的關鍵角色定義和組織運作形式。
資料牽引改進,是指關注軟體交付過程中各種度量資料的收集、統計、分析和反饋,通過視覺化的資料客觀反映整個研發過程的狀態,以全域性視角分析系統約束點,並和業務團隊達成共識,提煉出客觀有效的改進目標;工具固化規範,針對識別出來的Gap點和重點問題進行分析,制定出可以在作業工具承載的模板規範,以及需要工程師行為做出改變的能力要求,並在作業工具上對這些規範要求的落地效果進行檢查,用資料度量改進效果。最後,對改進專案進行總結分享,打造學習型組織,不斷驅動持續改進和價值交付,牽引研發團隊模式和文化的轉變。
2020年的研發過程可信圍繞CleanCode、構建、開源、E2E追溯四個領域開展,這也是公司要求的可信變革中最基本、最重要、投入產出比最大的四個點。
整體流程說明
整個運作流程,圍繞資料,按照“定義軟體工程規範->定義資料分析模型->工具實現資料度量和分析->資料運營發現實際軟體工程活動和規範的偏差->工具輔助團隊改進->工具固化軟體工程規範”這個流程進行實施,並對最終效果進行階段性總結。隨著業務團隊能力的提升以及軟體工程規範性、開發模式的改變,對最初定義的軟體工程規範,會階段性的進行完善,迴圈往復、持續優化,最終讓業務團隊在遵守公司要求的研發過程可信規範的前提下,實現業務成功。
1) 定義軟體工程規範:圍繞公司可信變革的目標,BU對各個服務產品部的研發模式規範和能力要求,COE制定適合BU現狀的軟體工程規範;
2) 定義資料模型:COE針對制定的軟體工程規範,提煉出核心的、有針對性、可用工具度量的資料模型,並且和各個服務產品部達成一致;
3) 工具實現資料度量和分析:根據這幾個資料模型,資料分析工具自動從資料來源進行採集、彙總、計算,並把結果呈現在資料看板上;業務團隊可以開啟彙總資料,根據明細資料進行動作規範自檢和改進;
4) 資料運營發現實際軟體工程活動和規範的偏差:資料治理小組在實際運營過程中,分析度量指標的資料,識別業務團隊實際的軟體工程活動和要求規範不一致的Gap點和關鍵問題;
5) 工具輔助業務團隊改進:COE針對分析出來的Gap點和關鍵問題,制定相應的改進措施,作業工具承載流程規範模板化整改,並針對業務團隊的不規範行為,制定適合各個服務產品部的公約要求,促使業務團隊人員能力提升;
6) 工具固化軟體工程規範:針對業務團隊的公約要求,在作業工具上進行check,最終作業工具承載了整個軟體工程規範要求,以及融入到作業流程中的規範要求事前檢查。
三層資料分析模型
我們採用了三層資料分析模型,由作業工具自動採集使用者研發過程行為明細資料,資料分析工具進行準實時彙總計算呈現總體目標,三層資料系統性的輔助業務團隊系統性的識別研發過程中的不規範點和能力短板,讓業務團隊“知其然,知其所以然”。這三層資料模型是層層深入,迭代完善,下層支撐上層的關係。
第一層:目標、進展、結果資料分析;和公司可信變革目標牽引對齊,結合BU實際情況,形成BU的整體可信要求,並在資料分析看板上呈現各個服務產品部要達成的過程可信目標、每日的改進進展和最終完成情況;例如,對各個服務產品部要求達成CleanCode的目標。
第二層:詞法/語法分析資料;COE針對第一層的目標牽引,分解出來的具體實施環節的度量指標,只有這些分解的指標都完成,第一層的目標才達成。這一層資料的目的主要是圍繞幫助業務團隊分析自己的能力短板在哪裡,進行有針對性的改進指;通過開啟彙總資料的層層下鑽,用明細資料來分析業務團隊在DevSecOps軟體工程規範流程中關鍵動作執行的缺失點,並針對性的制定改進規範要求,牽引作業工具或者業務團隊補齊該部分缺失動作;例如,CleanCode的過程可信目標達成,可以分解成:靜態檢查配置合規率、Committer合入保障率、程式碼倉Clean三個目標,只有這三個目標達成,就可以認為CleanCode總體目標達成。
第三層:語義分析資料:COE開啟第二層資料,不僅要看這些關鍵動過做沒做,還要看做的效果怎麼樣,最終效果體現在業務團隊的DevSecOps軟體工程規範提升;這一層的資料分析聚焦在防止為了指標而做第二層的資料,而是看業務團隊是否在真正參考BU制定的規範牽引的目標,提升業務交付過程中的效能、可信、質量能力,以及最終產生實際的業務效果。通過開啟各個團隊的明細資料分析審視業務團隊執行的關鍵動作是否符合規範,是否在合適的階段點執行,執行效果是否有效;並階段性的總結和提煉經驗,形成知識資產固化到作業工具。例如,針對第二層的靜態檢查配置合規率,可以分解為:靜態檢查配置有效性和靜態檢查執行有效性。靜態檢查配置有效性,包括:檢查靜態檢查工具配置的數量、是否符合BU的配置規範,以及是否在程式碼合入主幹master時進行了配置;靜態檢查執行有效性,主要看是否每一次MR提交時都執行靜態檢查、是否發現問題在研發活動的最早階段,攔截的問題的效果怎麼樣。只有第三層的動作度量都達成後,才可以說第二層的目標是達成的。
資料治理過程流程圖
為了實現“資料牽引改進,工具固化規範”這個目標,準確、一致、準實時的資料是核心關鍵,但因為資料採集不完整、業務團隊不規範、資料呈現維度不一致等原因,資料的準確性有一個不斷提升的過程,因此需要對各個層級展示的資料進行治理。整個資料治理過程中,由“業務團隊/作業工具/治理小組/資料分析工具(阿基米德)/COE”五個角色緊密配合,而且以年/半年為目標,不斷總結經驗,迴圈往復、持續優化的過程。
a) COE:和公司可信變革目標牽引對齊,結合BU能力現狀,形成BU的整體可信要求;
b) COE:針對BU的業務現狀,定義出適合BU現狀的軟體工程規範要求;業務團隊:和BU釋出的各個領域的軟體工程規範牽引目標達成一致;
c) COE:針對規範分解出核心的度量指標,並制定度量資料模型;
d) 研發使用者:在使用作業工具進行研發活動;作業工具:承載了BU各個服務產品部在使用過程中沉澱的行為資料;
e) 資料分析(阿基米德):準實時接入作業工具的資料,展示各個服務產品部當前的研發能力現狀;
f) COE:和各個服務產品部達成一致,制定各個服務產品部的年度牽引目標;
g) 資料分析(阿基米德):用資料呈現各個服務產品部的牽引目標和能力現狀,統一資料口徑;呈現月/周/天的明細資料,以及支撐Gap分析和重點問題的資料檢視;
h) COE:根據牽引目標和能力現狀,分析Gap原因和關鍵問題;治理小組:在資料運營過程中,根據資料分析團隊當前的能力現狀是否和資料呈現一致;
i) 研發使用者:可以實時登入資料工具(阿基米德)進行檢視各個層級的明細資料;
j) 治理小組:根據準實時進展資料,分析當前團隊研發過程中的實際問題,並彙總給COE;
k) COE:結合細粒度的分析資料、以及治理小組彙總出來的各個服務產品部的實際問題,制定規範和改進措施,包括作業工具的規範和研發使用者的動作行為公約;
l) 作業工具:承載作業工具上落地的規範要求;治理小組:作為介面人,承接研發工程師的行為規範公約,結合各個服務產品部實際情況來負責落地;
m) 研發使用者:按照規範要求和針對資料的自檢進行研發過程行為規範化;
n) 研發工具:對研發使用者的行為規範是否滿足要求進行自動化檢查;最終目標是讓整個軟體工程規範都固化在工具中進行承載;
o) 資料分析(阿基米德):呈現按照規範改進後的明細資料和彙總目標;研發使用者:自助檢視整改後的明細資料;
p) COE:根據資料改進的效果,以及過程中暴露的問題進行總結後形成經驗資產,並持續改進;
資料流圖
過程可信的資料在各個工具系統中採集、流轉、匯聚、分析、呈現,整個資料流圖如下:
其中,識別出6個重要的全量資料來源:
a) 程式碼庫資料:該資料由伏羲的服務資訊樹上配置的程式碼庫資料,加上阿基米德上人工配置的程式碼庫,構成各個雲服務釋出到生產倉的程式碼全集;
b) Workitem資訊流資料:當前識別vision上的需求、問題、task,加上Gitlab/Codeclub上的issue,構成可識別的Workitem資料全集;
c) SRE現網包資料:包括普羅部署、CCE、CPS、CDK各種型別部署的包資料,構成全量現網包資料;
d) 開源二進位制包資料:開源中心倉資料(java、python、go、nodejs四種)語言,加上公司c/c++的資料構成全量開源二進位制包資料;
e) 研發過程配置資料:阿基米德上配置的committer資料是全量的committer資料;阿基米德上識別出來的主分支是全量的主分支(邏輯“master”)資料;
f) 伏羲研發過程資料:伏羲三個庫,MongoDB的靜態檢查、門禁資料;MySQL中的測試、釋出資料;MySQL中包和多個流水線的對應關係資料;一起構成了以“包”為維度的全量伏羲研發過程資料;
運作組織
資料治理運營團隊
按照過程可信在BU的落地策略,在CleanCode、構建、開源、E2E追溯四個領域設定資料治理運營團隊,由 “資料分析工具(阿基米德)—COE—各個服務產品部介面人組成的治理小組”三個角色組成,以“指標度量為牽引,資料的客觀呈現為落地方式,業務的價值反饋為最終目的”的原則來落地資料治理工作。
COE的職責:
1) 和公司可信變革目標牽引對齊,結合BU能力現狀,形成BU的整體可信要求;定義出適合BU現狀的軟體工程規範要求;針對規範分解出核心的度量指標,並制定度量資料模型;
2) 利用作業工具已經產生的資料,和治理小組一起分析識別資料質量的問題,按照三層資料分析模型,層層開啟,識別業務團隊能力Gap點。
3) 分析典型問題,識別作業流的斷裂點進行補齊,和業務團隊的不規範動作,制定規範和公約要求,逐步改善資料質量。
4) 事後歸納總結,識別出流程缺失,組織缺失,責任缺失等機制行問題,並固化到作業工具中。
治理小組:
1) 結合各個服務產品部的實際情況,承接COE的資料治理規範在各個服務產品部的落地;
2) 識別資料治理動作在各個服務產品部落地過程中的實際問題,和COE一起分析,提出系統性的解決思路,最終固化到作業工具中。
3) 跟蹤過程可信在業務團隊落地的過程中的進展,為業務團隊最終達成可信變革目標負責,為改進過程產生實際的業務價值負責;
資料分析工具(阿基米德):
1) 確保接入的資料準確、實時、一致,用資料實時反映BU各個服務產品部的能力現狀,為COE和治理小組的資料運營提供資料支撐;
2) 系統性的落地COE的方案設計,實現整個BU統一標準的資料看板,能夠清晰的通過資料識別出來業務團隊的能力Gap,牽引業務團隊達成整體改進目標;
3) 按照三層資料模型進行資料展示,層層下鑽,讓業務團隊“知其然,知其所以然”,牽引業務團隊中的每一個人都能自己進行改進;
4) 通過資料分析,識別DevSecOps軟體工程規範在BU的業務團隊落地過程中的重點問題,以及該問題背後的流程、制度缺失,促使最終規範固化在作業工具中。
例會設定
“資料驅動DevSecOps能力提升例會”為研發領域資料治理相關問題的求助和裁決例會。
會議分為三個階段:
1) 第一階段,例行議題,形式類似於“體檢報告”,用資料反映業務團隊的現狀和問題;
2) 第二階段,申報議題,形式類似於“專家會診”,討論某一個具體資料治理過程中的問題和Top困難求助;
3) 第三階段,靈活安排議題,形式類似於“問題總結”,針對某一類的具體問題,進行集中討論和歸納總結定義,形成BU的規範流程和章程總結。
主資料承載系統
主資料是指具有高業務價值的、可以在企業內跨越多個業務部門被重複使用的資料,是單一、準確、權威的資料來源。和業務型資料、分析型資料相比,主資料主要有以下幾個特徵:
1) 特徵一致性:也就是能否保證主資料的關鍵特徵在不同應用、不同系統中的高度一致,直接關係了資料治理成敗;
2) 識別唯一性:在一個系統、一個平臺,甚至一個企業範圍內,同一主資料實體要求具有唯一的資料標識,即資料編碼;
3) 長期有效性:貫穿該業務物件的整個生命週期甚至更長,當該主資料失去其效果時,系統採取的措施通常為軟刪除,而不是物理刪除;
4) 業務穩定性:在業務過程中其識別資訊和關鍵特徵會被業務過程中產生的資料繼承、引用和複製。除非該主資料本身的特徵發生變化,否則該主資料不會隨著業務的過程中被其他系統修改。
主資料來源識別原則:
a) 如果有多個數據源構成同類型資料的主資料,兩種處理策略:
1)選取一個源系統逐步收編其他源系統的資料,變成唯一主資料來源
2)如果1)不能實現,由阿基米德系統進行封裝後遮蔽多個數據源系統,該型別資料的唯一資料來源變成阿基米德,待後續1)實現後,阿基米德該型別主資料來源失效。
3)當資料在多個作業系統中進行流轉時,判斷是否作為主資料來源的標準是:資料在該系統有實際的業務動作產生,而不是隻承載資料的流轉。
b) 如果確定為唯一資料來源,其他消費該型別資料的系統不能和資料來源產生衝突。
所有資料僅能在資料來源產生,其它系統只能讀取不能修改。下游發現的資料來源質量問題,應當在資料來源頭進行修正。
c) 主資料使用方不得改變原始資料,但可以進行擴充套件。
資料消費方不得對獲取的資料進行增、刪、改,但可以在資料的基礎上進行屬性擴充套件。
d) 在滿足資訊保安的前提下充分共享,不得拒絕合理的資料共享需求。
資料如果不流轉,不僅不會產生業務價值,還增加儲存成本;只有不斷流轉,對業務團隊產生實際價值時,還能得到使用效果的反饋,促進資料價值的進一步提升。
原則為:核心資產安全優先,非關鍵資產效率優先。
一類主資料來源
二類主資料來源
點選關注,第一時間瞭解華為雲新鮮技