最近一直想写一篇关于“「数据治理”和“度量相关”」的话题，一直太忙，今天静下心来写点自己的体会
先从平台工程说起
DevOps的兴起源于企业有意弥合运维与开发之间的裂隙，但在实施过程中有部分企业「简单粗暴地将其理解为“让开发人员去负责运维的工作”」，甚至让高级开发人员接管了运维角色，导致了开发渐渐不堪重负。
这一现实引出了DevOps停滞背后的核心矛盾：开发者不想跟基础设施打交道，但企业在发展过程中又需要专人管控自己的基础设施。在此背景下，平台工程应运而生。
平台工程定义为“设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务功能。平台工程师提供的集成产品通常被称为‘内部开发人员平台(IDP)’，涵盖了应用程序整个生命周期的运营需求。”
平台和应用程序之间的界限在哪里？“如果你可以把服务拿给另一个产品团队，甚至给另一个公司，他们可以马上使用，那么它就属于平台。”
「本质依然是“新瓶装旧酒”，是对“DevOps实践”提供“相对可参考性”的学科体系，除了技术以外，提供了如何建设，运营平台，以及建立企业内部开发者关系的新思路。」
事实上，DevOps和平台工程并非这种“你死我活”的关系，在某种程度上，平台工程有可能为DevOps带来新生。
内部平台建设最终需要产出数据
“市面上任何一种工具，都不可能与平台一样能够满足企业的全部需求。企业必须花费充足的时间和精力，定制符合自身需求的平台。” 这是Gartner对于企业进行平台工程建设的建议
市面上其实已经涌现了很多类似的平台，比如阿里云效，腾讯Coding之类的，对于中小型团队，在没有资源投入基础设施建设的前提下，且对期望结果不是那么高的情况下，这些平台是合适的。
不过依然有“相当规模”（研发人员300人以上）的企业依然可能会选择建设内部的”研发效能平台“或者是”DevOps一体化平台“，来解决个性化的问题。
企业建设平台最终的目的就是收集到数据，对研发过程数据进行分析，也就是很火的一个名词「“效能度量”。」
收集数据简单，治理规划数据不易
如下图所示，由于研发效能度量涉及各个阶段，来自不同的工具。
单纯从工具层面，排除指标定义和计算外，收集数据本身只是个技术问题。不管是对接api，还是对接数据库，BI工具很多。
如果把工具数据，再叠加如下图左边这些因素，才可能让数据变的“有价值”，变得有“说服力”，不是吗？
不要过分度量，而来度量而度量
其实一开始，企业也在努力的建设设计流程，可是流程是需要经过“真实考验的”，是不是业务流程是否真的能运转落地，或者切实得到认同？
“没关系，度量下看看？不是说，通过度量来改进吗？“
好像猛地一看，很合理，度量就是为了改进，管理大师都说了没有度量，就没有改进。可是改进什么呢？哪里有问题呢？为什么要改进？
没关系，有了数据，自然就知道了
「看似合理，其实隐藏一个致命的逻辑缺陷, 度量需要成本的，收入产出比如何？」**度量指标的设定，需要具有“牵引改进”的重大意义，如果一个指标不能做到“牵引”作用，那么就是个“假”指标。**
- 对于问题很明显的，不要一开始就去设计指标去度量它，需要立马去改进，而不是度量它
- 不要一开始搞很多指标，看都看不完，有几个懂的？甚至多了，设计者本身都懵逼了
- 不要上了就设计开发复杂系统去做度量，通过简单的查数据库，生成excel ,或者其他快捷手段（工具内置的能力），先捞一把数据看看再说，数据都是不对的，度量就是扯淡的
- 不要一开始，就想的过于完美，最终你会发现会推倒重来
数据治理过程逐步建模
度量的前提一定是“数据治理”和“流程执行”，前者是保证规范性，后者是保证有效性。企业在一开始建设之初，一定是有些已经使用的系统，这些系统里都会有数据，需要从总体上考虑未来系统的目标和愿景。
- 对于已有数据，需要进行甄别，什么是没有价值的数据，是否一定要保留？意义何在？卸下包袱，也许重新开始呢？
- 不同的工具产生的数据差异很大，想清楚最终业务视角需要看“什么纬度”的数据，什么是“带头大哥”，什么是“牵引点”，谁是主谁是辅
最后，收集单纯的数据很简单，但是想得到“对业务有价值的数据”，需要漫长的【收集-整理-调研-分析-设计定义-运行-优化-调整-反馈-再调整】过程。
「没有人能一开始全部想清楚，按照“敏捷的思维”，不要过度设计，自己瞎YY, 让用户用实际行动产生数据，引导用户行为，修正数据，这是作为“平台工程”的实践者需要去思考和琢磨的。」
本文使用 文章同步助手 同步
