摘要：本文針對“資料牽引改進，工具固化規範”這一思路在業務團隊落地過程中的動作流程進行詳細闡述，并明确了支撐整個流程的關鍵角色定義群組織運作形式。
為實作雲服務開發的過程可信，需要基于資料對各個服務産品部的可信變革動作進行資料采集、進展可視、目标牽引、能力評估，最終用資料反映目标達成。與傳統的“基于資料晾曬驅動業務團隊改進，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) 在滿足資訊安全的前提下充分共享，不得拒絕合理的資料共享需求。
資料如果不流轉，不僅不會産生業務價值，還增加存儲成本；隻有不斷流轉，對業務團隊産生實際價值時，還能得到使用效果的回報，促進資料價值的進一步提升。
原則為：核心資産安全優先，非關鍵資産效率優先。
一類主資料源
二類主資料源
點選關注，第一時間了解華為雲新鮮技術~