嗨，别着急做度量，平台工程需要先从“数据治理”开始做起

最近一直想写一篇关于“数据治理”和“度量相关”的话题，一直太忙，今天静下心来写点自己的体会

先从平台工程说起

DevOps的兴起源于企业有意弥合运维与开发之间的裂隙，但在实施过程中有部分企业简单粗暴地将其理解为“让开发人员去负责运维的工作”，甚至让高级开发人员接管了运维角色，导致了开发渐渐不堪重负。
这一现实引出了DevOps停滞背后的核心矛盾：开发者不想跟基础设施打交道，但企业在发展过程中又需要专人管控自己的基础设施。在此背景下，平台工程应运而生。

平台工程定义为“设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务功能。平台工程师提供的集成产品通常被称为‘内部开发人员平台(IDP)’，涵盖了应用程序整个生命周期的运营需求。”
平台和应用程序之间的界限在哪里？
“如果你可以把服务拿给另一个产品团队，甚至给另一个公司，他们可以马上使用，那么它就属于平台。”

本质依然是“新瓶装旧酒”，是对“DevOps实践”提供“相对可参考性”的学科体系，除了技术以外，提供了如何建设，运营平台，以及建立企业内部开发者关系的新思路。
事实上，DevOps和平台工程并非这种“你死我活”的关系，在某种程度上，平台工程有可能为DevOps带来新生。

内部平台建设最终需要产出数据

“市面上任何一种工具，都不可能与平台一样能够满足企业的全部需求。企业必须花费充足的时间和精力，定制符合自身需求的平台。” 这是Gartner对于企业进行平台工程建设的建议

市面上其实已经涌现了很多类似的平台，比如阿里云效，腾讯Coding之类的，对于中小型团队，在没有资源投入基础设施建设的前提下，且对期望结果不是那么高的情况下，这些平台是合适的。
不过依然有“相当规模”（研发人员300人以上）的企业依然可能会选择建设内部的”研发效能平台“或者是”DevOps一体化平台“，来解决个性化的问题。
企业建设平台最终的目的就是收集到数据，对研发过程数据进行分析，也就是很火的一个名词“效能度量”。

收集数据简单，治理规划数据不易

如下图所示，由于研发效能度量涉及各个阶段，来自不同的工具。

不要过分度量，而来度量而度量

其实一开始，企业也在努力的建设设计流程，可是流程是需要经过“真实考验的”，是不是业务流程是否真的能运转落地，或者切实得到认同？

“没关系，度量下看看？不是说，通过度量来改进吗？“

好像猛地一看，很合理，度量就是为了改进，管理大师都说了没有度量，就没有改进。
可是改进什么呢？哪里有问题呢？为什么要改进？

没关系，有了数据，自然就知道了

看似合理，其实隐藏一个致命的逻辑缺陷, 度量需要成本的，收入产出比如何？
度量指标的设定，需要具有“牵引改进”的重大意义，如果一个指标不能做到“牵引”作用，那么就是个“假”指标。

• 对于问题很明显的，不要一开始就去设计指标去度量它，需要立马去改进，而不是度量它
• 不要一开始搞很多指标，看都看不完，有几个懂的？甚至多了，设计者本身都懵逼了
• 不要上了就设计开发复杂系统去做度量，通过简单的查数据库，生成excel ,或者其他快捷手段（工具内置的能力），先捞一把数据看看再说，数据都是不对的，度量就是扯淡的
• 不要一开始，就想的过于完美，最终你会发现会推倒重来
  

数据治理过程逐步建模

度量的前提一定是“数据治理”和“流程执行”，前者是保证规范性，后者是保证有效性。
企业在一开始建设之初，一定是有些已经使用的系统，这些系统里都会有数据，需要从总体上考虑未来系统的目标和愿景。

• 对于已有数据，需要进行甄别，什么是没有价值的数据，是否一定要保留？意义何在？卸下包袱，也许重新开始呢？
• 不同的工具产生的数据差异很大，想清楚最终业务视角需要看“什么纬度”的数据，什么是“带头大哥”，什么是“牵引点”，谁是主谁是辅
• 排除干扰，对于数据字段，学会做减法
• 流程领域是死的，工具是活的，从领域中去抽象实体

数据治理的过程，伴随着规则的制定，流程的执行，没有谁先谁后之说，根据“已有数据”去分析用户行为和使用习惯，制定“被大部分人接受”的规则和流程，否定掉“少数人的个性化操作”。
最后，收集单纯的数据很简单，但是想得到“对业务有价值的数据”，需要漫长的【收集-整理-调研-分析-设计定义-运行-优化-调整-反馈-再调整】过程。
没有人能一开始全部想清楚，按照“敏捷的思维”，不要过度设计，自己瞎YY, 让用户用实际行动产生数据，引导用户行为，修正数据，这是作为“平台工程”的实践者需要去思考和琢磨的。

热门相关：龙骑战机   黜龙   覆汉   无法隐瞒的本能：偷拍   龙骑战机