【华为云技术分享】解析数据治理在过程可信变革中的运作流程

摘要：本文针对“数据牵引改进，工具固化规范”这一思路在业务团队落地过程中的动作流程进行详细阐述，并明确了支撑整个流程的关键角色定义和组织运作形式。

目的

为实现云服务开发的过程可信，需要基于数据对各个服务产品部的可信变革动作进行数据采集、进展可视、目标牵引、能力评估，最终用数据反映目标达成。与传统的“基于数据晾晒驱动业务团队改进，6+1指标度量”的运作方式有本质的区别，我们是基于统一的作业工具上产生的客观数据呈现，识别研发过程中基本的流程断裂点和质量缺失动作，和业务团队达成一致的目标后，把大部分改进动作固话到作业工具中自动化承载，我们称这个思路为“数据牵引改进，工具固化规范”，也就是我们不仅告诉业务团队哪里有问题，同时也要基于我们的作业工具，辅助业务团队一起改进完善。

本文针对“数据牵引改进，工具固化规范”这一思路在业务团队落地过程中的动作流程进行详细阐述，并明确了支撑整个流程的关键角色定义和组织运作形式。

数据牵引改进，是指关注软件交付过程中各种度量数据的收集、统计、分析和反馈，通过可视化的数据客观反映整个研发过程的状态，以全局视角分析系统约束点，并和业务团队达成共识，提炼出客观有效的改进目标；工具固化规范，针对识别出来的Gap点和重点问题进行分析，制定出可以在作业工具承载的模板规范，以及需要工程师行为做出改变的能力要求，并在作业工具上对这些规范要求的落地效果进行检查，用数据度量改进效果。最后，对改进项目进行总结分享，打造学习型组织，不断驱动持续改进和价值交付，牵引研发团队模式和文化的转变。

2020年的研发过程可信围绕CleanCode、构建、开源、E2E追溯四个领域开展，这也是公司要求的可信变革中最基本、最重要、投入产出比最大的四个点。

4.1 整体流程说明

整个运作流程，围绕数据，按照“定义软件工程规范->定义数据分析模型->工具实现数据度量和分析->数据运营发现实际软件工程活动和规范的偏差->工具辅助团队改进->工具固化软件工程规范”这个流程进行实施，并对最终效果进行阶段性总结。随着业务团队能力的提升以及软件工程规范性、开发模式的改变，对最初定义的软件工程规范，会阶段性的进行完善，循环往复、持续优化，最终让业务团队在遵守公司要求的研发过程可信规范的前提下，实现业务成功。

1) 定义软件工程规范：围绕公司可信变革的目标，BU对各个服务产品部的研发模式规范和能力要求，COE制定适合BU现状的软件工程规范；

2) 定义数据模型：COE针对制定的软件工程规范，提炼出核心的、有针对性、可用工具度量的数据模型，并且和各个服务产品部达成一致；

3) 工具实现数据度量和分析：根据这几个数据模型，数据分析工具自动从数据源进行采集、汇总、计算，并把结果呈现在数据看板上；业务团队可以打开汇总数据，根据明细数据进行动作规范自检和改进；

4) 数据运营发现实际软件工程活动和规范的偏差：数据治理小组在实际运营过程中，分析度量指标的数据，识别业务团队实际的软件工程活动和要求规范不一致的Gap点和关键问题；

5) 工具辅助业务团队改进：COE针对分析出来的Gap点和关键问题，制定相应的改进措施，作业工具承载流程规范模板化整改，并针对业务团队的不规范行为，制定适合各个服务产品部的公约要求，促使业务团队人员能力提升；

6) 工具固化软件工程规范：针对业务团队的公约要求，在作业工具上进行check，最终作业工具承载了整个软件工程规范要求，以及融入到作业流程中的规范要求事前检查。

4.2 三层数据分析模型

我们采用了三层数据分析模型，由作业工具自动采集用户研发过程行为明细数据，数据分析工具进行准实时汇总计算呈现总体目标，三层数据系统性的辅助业务团队系统性的识别研发过程中的不规范点和能力短板，让业务团队“知其然，知其所以然”。这三层数据模型是层层深入，迭代完善，下层支撑上层的关系。

第一层：目标、进展、结果数据分析；和公司可信变革目标牵引对齐，结合BU实际情况，形成BU的整体可信要求，并在数据分析看板上呈现各个服务产品部要达成的过程可信目标、每日的改进进展和最终完成情况；例如，对各个服务产品部要求达成CleanCode的目标。
第二层：词法/语法分析数据；COE针对第一层的目标牵引，分解出来的具体实施环节的度量指标，只有这些分解的指标都完成，第一层的目标才达成。这一层数据的目的主要是围绕帮助业务团队分析自己的能力短板在哪里，进行有针对性的改进指；通过打开汇总数据的层层下钻，用明细数据来分析业务团队在DevSecOps软件工程规范流程中关键动作执行的缺失点，并针对性的制定改进规范要求，牵引作业工具或者业务团队补齐该部分缺失动作；例如，CleanCode的过程可信目标达成，可以分解成：静态检查配置合规率、Committer合入保障率、代码仓Clean三个目标，只有这三个目标达成，就可以认为CleanCode总体目标达成。
第三层：语义分析数据：COE打开第二层数据，不仅要看这些关键动过做没做，还要看做的效果怎么样，最终效果体现在业务团队的DevSecOps软件工程规范提升；这一层的数据分析聚焦在防止为了指标而做第二层的数据，而是看业务团队是否在真正参考BU制定的规范牵引的目标，提升业务交付过程中的效能、可信、质量能力，以及最终产生实际的业务效果。通过打开各个团队的明细数据分析审视业务团队执行的关键动作是否符合规范，是否在合适的阶段点执行，执行效果是否有效；并阶段性的总结和提炼经验，形成知识资产固化到作业工具。例如，针对第二层的静态检查配置合规率，可以分解为：静态检查配置有效性和静态检查执行有效性。静态检查配置有效性，包括：检查静态检查工具配置的数量、是否符合BU的配置规范，以及是否在代码合入主干master时进行了配置；静态检查执行有效性，主要看是否每一次MR提交时都执行静态检查、是否发现问题在研发活动的最早阶段，拦截的问题的效果怎么样。只有第三层的动作度量都达成后，才可以说第二层的目标是达成的。

4.3 数据治理过程流程图

为了实现“数据牵引改进，工具固化规范”这个目标，准确、一致、准实时的数据是核心关键，但因为数据采集不完整、业务团队不规范、数据呈现维度不一致等原因，数据的准确性有一个不断提升的过程，因此需要对各个层级展示的数据进行治理。整个数据治理过程中，由“业务团队/作业工具/治理小组/数据分析工具（阿基米德）/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：根据数据改进的效果，以及过程中暴露的问题进行总结后形成经验资产，并持续改进；

4.4 数据流图

过程可信的数据在各个工具系统中采集、流转、汇聚、分析、呈现，整个数据流图如下：

其中，识别出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中包和多个流水线的对应关系数据；一起构成了以“包”为维度的全量伏羲研发过程数据；

5 运作组织

5.1 数据治理运营团队

按照过程可信在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的业务团队落地过程中的重点问题，以及该问题背后的流程、制度缺失，促使最终规范固化在作业工具中。

5.2 例会设置

“数据驱动DevSecOps能力提升例会”为研发领域数据治理相关问题的求助和裁决例会。

会议分为三个阶段：

1）第一阶段，例行议题，形式类似于“体检报告”，用数据反映业务团队的现状和问题；

2）第二阶段，申报议题，形式类似于“专家会诊”，讨论某一个具体数据治理过程中的问题和Top困难求助；

3）第三阶段，灵活安排议题，形式类似于“问题总结”，针对某一类的具体问题，进行集中讨论和归纳总结定义，形成BU的规范流程和章程总结。

6 主数据承载系统

主数据是指具有高业务价值的、可以在企业内跨越多个业务部门被重复使用的数据，是单一、准确、权威的数据来源。和业务型数据、分析型数据相比，主数据主要有以下几个特征：

1）特征一致性：也就是能否保证主数据的关键特征在不同应用、不同系统中的高度一致，直接关系了数据治理成败；

2）识别唯一性：在一个系统、一个平台，甚至一个企业范围内，同一主数据实体要求具有唯一的数据标识，即数据编码；

3）长期有效性：贯穿该业务对象的整个生命周期甚至更长，当该主数据失去其效果时，系统采取的措施通常为软删除，而不是物理删除；

4）业务稳定性：在业务过程中其识别信息和关键特征会被业务过程中产生的数据继承、引用和复制。除非该主数据本身的特征发生变化，否则该主数据不会随着业务的过程中被其他系统修改。

6.1 主数据源识别原则：

a) 如果有多个数据源构成同类型数据的主数据，两种处理策略：

1）选取一个源系统逐步收编其他源系统的数据，变成唯一主数据源

2）如果1）不能实现，由阿基米德系统进行封装后屏蔽多个数据源系统，该类型数据的唯一数据源变成阿基米德，待后续1）实现后，阿基米德该类型主数据源失效。

3）当数据在多个作业系统中进行流转时，判断是否作为主数据源的标准是：数据在该系统有实际的业务动作产生，而不是只承载数据的流转。

b) 如果确定为唯一数据源，其他消费该类型数据的系统不能和数据源产生冲突。

所有数据仅能在数据源产生，其它系统只能读取不能修改。下游发现的数据源质量问题，应当在数据源头进行修正。

c) 主数据使用方不得改变原始数据，但可以进行扩展。

数据消费方不得对获取的数据进行增、删、改，但可以在数据的基础上进行属性扩展。

d) 在满足信息安全的前提下充分共享，不得拒绝合理的数据共享需求。

数据如果不流转，不仅不会产生业务价值，还增加存储成本；只有不断流转，对业务团队产生实际价值时，还能得到使用效果的反馈，促进数据价值的进一步提升。

原则为：核心资产安全优先，非关键资产效率优先。

6.2 一类主数据源

类型	承载系统	接口人
组织架构	Vision
云服务	CSBI
微服务组、微服务	伏羲

6.3 二类主数据源

类型	承载系统	接口人
代码库	阿基米德
主分支（“Master”）	阿基米德
Committer	阿基米德

点击这里→了解更多精彩内容