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