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

x33g5p2x  于4个月前 转载在 其他  
字(2.1k)|赞(0)|评价(0)|浏览(130)

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

先从平台工程说起

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

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

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

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

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

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

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

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

本文的目的不是谈如何进行定义效能度量(PS:这又是另外一个很大的话题),而是聊聊数据怎么收,如何正确合理的收集“有价值”的数据?
单纯从工具层面,排除指标定义和计算外,收集数据本身只是个技术问题。不管是对接api,还是对接数据库,BI工具很多。

可是单纯的工具数据,本身很少带“业务属性”,这个其实对于企业最后的决策是没有多大价值的。
如果把工具数据,再叠加如下图左边这些因素,才可能让数据变的“有价值”,变得有“说服力”,不是吗?

**可是,左边的问题,真的容易说清楚吗?很多建设内部平台的企业,左边的问题一开始就是说不清楚的,**如果能说清楚,就不会大费周折的搞这个事情了。似乎陷入了“鸡生蛋,还是蛋生鸡”的怪圈里,无法自拔。

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

其实一开始,企业也在努力的建设设计流程,可是流程是需要经过“真实考验的”,是不是业务流程是否真的能运转落地,或者切实得到认同?
“没关系,度量下看看?不是说,通过度量来改进吗?“

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

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

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

这里给出几点建议

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

数据治理过程逐步建模

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

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

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

相关文章