本文内容选自2021中国DevOps社区峰会 · 深圳站,武丁老师分享的《DevOps一体化平台落地及研发效能度量实践》文字实录和视频回放。

图片

分享嘉宾:武丁

平安银行 资金同业研发团队DevOps专家,多年银行金融市场方向研发经验,涉及DevOps平台设计开发与推广、不同类型项目团队的敏捷DevOps转型、研发效能度量平台的设计开发与推广等方向。
视频回放:

图片

以下是演讲文字实录:
谢谢大家!我来抛砖引玉,先做一下自我介绍,武丁,大家可以查一下这个名字,很有意思。近几年主要是在做一些DevOps推广,还有一些研发效能度量平台的一些设计、研发和推广工作。今天在开讲之前,因为这个时间点大家可能有些困,我先讲一下我之前几份工作的工作经历,和DevOps相关的,让大家尤其是00后的小伙伴了解一下这个发展历史。

过往经历

大概10年前我有幸参与了一个公司,是在一家外资银行,主要这个项目面向的是一个做前台交易的产品量化,就是说定价模型、风险评估等相关的一些开发工作。这个平台面向前台交易员,还有他的需求很急,可能每天都要发一个版本。我们就做了一套简单的程序集成也就是现在CI概念的工具,基于它我们可以实现每个量化工程师或者计算机专家开发自己的分支快速自动校验,同时因为它是一个大的仓库或者为很多外部服务使用的核心库,不同模块和不同分支之间的合并我们需要做到快速集成、自动化集成和把一些有问题的分支自动剔除出去。这里面就涉及到工具和自动化测试等等。这个东西做完以后当时还是比较自豪的,有一些亮点,接下来我们就想推广给整个大部门的其他团队,但是发现困难重重,因为不同产品线、不同其他项目团队他们的场景完全不一样,五花八门,我们的兼容性确实差。这是第一次经历。
大概是四五年前又是一家外资银行,他开始做DevOps敏捷转型,DevOps转型当时好在有业界的很多非常成熟优秀的工具,比如说大家耳熟能详的流水线,还有我们后续的嘉宾会讲到的JFrog的Artifactory。我们基于这两者做了一些更加灵活的改动,就是为了适配不同的场景和不同业务开发团队的需求,比如我们基于流水线可以把很多共享库做得非常灵活和可配置化,各应用开发团队可以自己像组装乐高积木一样拼接他的流水线,这个非常灵活。同时我也稍微帮后面的嘉宾介绍一下Artifactory,通过它我们可以有一些元数据的管理和流水线的打通,我们的制品可以有一个升级,从开发到集成测试到用户验收测试环节最终到生产环节的一个升级过程。但是还有一个问题,我们的流水线非常灵活,但是我们面向的很多开发团队对这些东西的理解程度是不一致的,我们逐渐的会发现流水线各自配置得五花八门,甚至千奇百怪。
接下来在近两年我在平安银行,正好又赶上了我们整个大概可能是500人规模的研发团队,CTO非常重视这方面的转型,他开始了敏捷转型DevOps转型。恰好又是天时地利人和,我们赶上了平安银行整个架构平台组推广自己的DevOps,也就是开发运维一体化平台叫Starlink。今天我不会过多介绍Starlink,但是我会给大家介绍我们作为一个大的业务开发团队,是怎样通过借助这个大的平台帮助我们高效实现DevOps的转型。同时我们自己又做了一些什么样的研发项目的度量工作,去帮助我们持续的改进。

结合DevOps平台实现高效转型

前面铺垫确实有点多,可能大家这个时间点需要一下这些东西。首先我今天会讲怎样结合DevOps平台做转型,其实这个图应该放在标题的最前面,它其实是一个中心思想,当然也是参考了很多业界的大咖或者朋友的建议和思想。首先最左边自上而下的推广支持,可能不同的企业比如说互联网公司或者传统行业的公司企业文化风格稍微不一样,但是我觉得在金融科技行业我们的推广我认为自上而下的一定效果是最好的,因为我们尤其是比较大的团队,即使再优秀的团队也会存在某个项目组每天可能忙于奔波于各种交付和累计的需求,他们陷入了一个怪圈,就是很忙,但是又没有时间去改进。那自上而下有一个好处,老板拍下来了,你们要动动心思要不要做这个事。
我们的高效转型涉及到三个方面,就是这三个菱形块:第一是工具平台,工具平台有什么好处?这个任务老板拍了下来我们团队怎么做,它是有门槛的。所以说这个平台如果做得好,能够真正的实现端到端,使用门槛降低,我们可以快速的迈出第一步,其实也是关键的一步,我们对接了平台,可以实现简单的持续集成和部署,有一些很好的工具,我们不用去了解细节,直接使用就可以。
有了这个工具平台,第二个方面就是规范的标准或者说最佳实践等等一系列,我们怎么融合到这个工具平台里,我们在使用这个平台的过程中怎么去自然而然的把这些做得优而更优。
第三方面其实是最关键的,是能力文化的建设,说白了就是每个人的思维方式或者认知。我们这个方面的提升会影响到其他方面,比如说工具平台我们的使用是否能用得好、用得明白,我们的规范标准是否能够有更多的引入。但是这三方面的工作中我们起步阶段可能还好,但逐渐随着我们团队或者项目的DevOps成熟度的提升,再往后是越来越难的,我们需要通过中间的环节叫度量去通过数据告诉我们,我们应该往哪里去改进,也就是说通过它作为一个驱动我们持续改进的驱动力。
接下来是我们转型前或使用DevOps前的一些痛点,大家可能都比较有共鸣。但我要强调一点的是,我们接入这个平台,无论是我们自己在一个大企业里有自研的平台,还是我们购买了业界比较优秀的产品,我们在对接的过程中也是自己一个革旧迎新的过程。
因为时间有限,我不会把平安银行的Starlink平台展开讲,主要是讲三点比较重要的地方。第一点是它可以实现端到端的自动化,也就是说从我们的需求开始,到研发、到测试、到发布、到后续的运营等等,整个全流程打通了以后,我们的很多工作才能在这个基础上去继续展开。第二点是固化合规需求或者说最佳实践,因为尤其在银行业强监管是一方面,这是我们必须最重视的,还有我们的内部也是为了满足监管要求,我们内部有很多的稽核审查,这方面有一些无论是流程上或者是一些规范性的要求上,我们之前可能都是大家去宣导、去注意、人为去检查,但事实上我们融入到工具里自然而然就会做到一个好的效果。第三点可能大家一上来看有点不明白为什么会提到这里,就是细粒度的流程管控,大家可能知道我们用一个工具平台,我们提交代码自动编译、打包、部署测试就完了,什么叫细粒度的管控呢?其实就是说整个过程中从工具侧每个小的状态、每个事件我们其实都需要一保存下来、二可提供数据源给到业务开发团队,为什么呢?这是我后续要讲的一个研发效能度量息息相关的,后续可以跟大家再强调着重讲一下。
有了这个工具平台,比如说我们现在开始铺开做转型了怎么做?面对一个500人的团队,非常有趣的现象,在座的可能有很多敏捷教练、敏捷相关的专家或者大家也在经历敏捷转型等等,我们有一些新的概念点给大家宣导,500人开一个大会讲完之后效果往往可能是没有的。所以我们一般的经验是这样的,我们需要结合少部分人的力量,可能大家回到各自工作岗位或者研发团队的团体里的时候,在座的各位其实就是我们需要团队的力量,在座的各位是对DevOps有兴趣的,在这些方面愿意积极去尝试改进的人。我们就要建立一个所谓DevOps行会,这个行会直白说我们团队有很多项目组,每个项目组派出1到2个人,可能就是在座的各位,对DevOps很有热情,也希望改进我们的工作和研发效能。集合起这一方面的人,我们无论是对接工具平台还是说我们推广最佳实践,这个过程中才能起到以点带面,不同团队走的速度不一样,走在前面的团队可以把踩过坑的经验告诉后面的团队,这是我们的实践经验和建议。
说回我们要入驻这个平台,我总结了四个阶段,都是理论上的。但确实上我们这一年半以来的实践经验。第一步是工具适配,为什么不是一上来就用这个平台?因为工具适配的很多工作在后面发现是阻碍的,比如说我们自己的项目或者代码没办法就是祖传代码,可能在座各位都见过,我们要接入平台要多多少少做一些工作,我们要了解一些这个平台设计的工具,我们没必要了解细节,但要了解它大概是做什么的。我们的配置是否应用分离,数据库脚本是否要做一些关键的优化,应对我们后续要集成的自动化校验等等一系列的工作,这时可以并行去做的。第二步是入驻平台,如果这个平台做得丰富,不是一上来就实现端到端的自动化构建,我们可以根据自己当前的痛点去选择性的,我们先做快速的高频次的CI集成,还是说为了优化我们测试以后部署的流程,我们持续部署,基于这个选择我们去接入平台,接入平台以后其实很多人就觉得好像就做完了,但其实是刚开始,在这个过程中接下来我们真正要做的是,我们在这个平台要做很多东西,比如说引入各种各样的工具、比如说静态代码的扫描能否前置,我们有没有单元措施,我们的流水线颗粒度是怎样的、触发机制是怎样的,我们的流水线是扔在那里不管还是有一台机器能把它快速修复。第四个阶段是真正应该最终达到最好的效果,我们和平台开发团队一起作为业务研发团队,一起合作,我们作为主要的用户能够给出高质量的合理的需求,是基于我们对DevOps的认知和工具平台以及在第一线开发遇到真正的痛点结合起来做一个反推,或者说我们在平台外做一些自己所需要的补充的工具。分为这四个阶段,这里先做一个简单的总结,这其实也是我们的实际经验中总结出来的几个点。

规范化研发流程与工具平台的深度融合

规范化流程与工具的融合。这个页面大家可以看到整个研发流程有几个比较关键的节点,比如说我们公司内部对一些关键节点是有定义的,或者说我有交付流程、我有一套理论是需要各个研发团队遵守的,有时候监管也会去看你们所宣扬的宣传的你们在遵守一套规范是否真的在落地执行,这些点都需要在我们的平台里去融合,如果大家是开发人员可能会离得有点远,但是这是银行业务必须重视的,这里我就不过多介绍了,大概就是几个点。
接下来要说的是基于这几个点我们额外的也就是各自团队要提升的怎样把质量内建做好,通过平台,我们的质量内建做好有很多方面,这里简单列了几点。比如说我们是否有代码评审,我们是否对版本夹代有检查,我们的代码静态扫描、代码的复杂性、重复度或者技术是否有安全检查、数据库脚本自动校验,是否能满足这些工具的要求是第一阶段,我们用好了、用到什么程度是随着我们DevOps成熟度的提升而不断提升的,也就是说这些质量门禁是多元化的,我们是可选的,一步一步想升级打怪一样,从青铜到王者,最终实现交付的生态。
这一点可能大家听上去会觉得有点怪,什么叫交付物结构化管理?我们会把交付物和关键数据存下来,除此以外我们可以看到这里显示很多文档,项目文档、需求文档、版本文档等等一系列,我们是做敏捷转型的,为什么做文档?这个概念我们稍微澄清一下,我们在银行业有监管要求,很多文档时要求有的,但是文档一定是我们自己手写word的吗?不是的,我们有自动化、我们有全自动化等等一体化平台,很多地方的文档是可以自动生成的,可以自动追踪的,这是一方面。然后我们整个平台有很多的不同工具,可能数据和相关文档记录都是分散的,我们需要把它统一的管理起来,有可能一开始我们的初衷是大家在银行业年底可能要为了应对监管审查,我们必须要把这一年或者半年所投产发布的版本做一些梳理,这些版本有哪些是做了什么,有一些关键的文档都要整理好。之前可能都是手工的,这个非常痛苦,而且可能有偏差。如果这套工具落地使用一年以后,年底自动导出,这是一个效果。第二点,我们后续基于这个结构化的文档也好或者是交付物也好做一些分析,我们看看一个大的团队做了哪些需求,是不是有重复的,周期发布规律是什么,一系列,可能是将来的工作,但无论怎样我们要把它做一个结构化的管理,满足现有现在的需求。
以上几个例子是我们在所谓的融合监管要求和规范化的流程在这个平台里所做的工作,这个平台再优秀也是逐步去完善的,涉及到我们和平台研发团队的沟通及磨合。除此之外,我们的这些交付物的文档管理做好了以后,我们是否能和研发效能度量连接起来,这是下一个话题,我今天讲得比较多的是研发效能度量。

自动化精细化研发效能度量

有幸今天上午主会场第一位路宁老师是讲研发效能度量,他的很多观点我都深有感触。先问一下大家一个问题,我们现在行业内研发效能度量最重要的四大指标不知道有没有同学记得是哪四个指标,上午路宁老师有提到。很多同学都说了,前置代码提交多久能上线、部署频次、部署失败率、我生产缺陷失败以后修复的周期,这四个是关键的结果性指标,比如说我们这个指标出来以后发现我们团队这四个指标数据不好,然后我们怎么改进?我们需要大量的过程指标或者是一些数据支撑起来我们去分析,这是不能拍脑袋去想的,我们需要精细化的度量去发现我们在整个交付周期中哪些有瓶颈、哪些有问题、哪些可以引导我们去注意我们的一些行为。
我接下来又要问一些问题,看大家有没有一些共鸣,就是关于我们究竟要度量什么?比如我们在做敏捷转型,燃尽图看上去挺好看的,但是你是把任务卡片挪出去了还是真正完成了,这些细节是我们需要看的。如果团队大的话,敏捷有部落,一个部落有很多小队,怎么从部落的层面看迭代的运行情况,还有小队的情况,如果我们的度量足够精细,我们是否能从数据上关键到敏捷团队的行为或者人员结构是否满足敏捷的理念,这些都是有数据支撑我们可以去做的。再往后想,比如说我们的需求,开发团队抱怨需求总变更,支撑的数据说明,我们的需求变更的频次是怎样的,需求发生了变更又是在我们整个交付周期的什么节点,是前置的位置还是后面快上线了,这些数据我们都有了以后会给我们带来一些帮助,甚至能和业务方、产品方带来一些沟通,让他们明白我们的痛点真正在哪里。这是需求侧。
再举一个例子,我们的缺陷密度是怎么分布的,什么叫密度,缺陷可以说我一个月有多少缺陷,密度是我们有多少人吗?还是说我们整个研发周期,比如说我们有故事点,是和这个去做对比吗?我们是和测试缺陷相关的。再比如说我们的整个交付周期,上午路宁老师说了这个交付周期其实是看命的,但是实际上他又提到了一点,这个交付周期我们是可以发现异常点的,我们的交付周期的统计又可以细分到是需求提出到上线、还是需求确定到上线、或者是研发完成到上线,这些都是有细分周期的,这些数据我们都可以拿出来分析看。也就是说,我们做研发效能度量要拿出看股票K线图的兴趣来,我们的数据也一样可以按照那个方式去做,只不过我们需要把控。
再往后说,我们的开发人员提交的代码,开发A提交了1000行代码,开发B提交了2行代码,1000行代码的改动就一定是大改动吗?我们一定要触发大的代码评审吗?不是。所以我们需要再往下看,这个改动的代码真正的复杂度是什么样的,业界有一个代码当量的改革,我们也正在探索,当然是在做一个简单的探索。再有,一个开发或者一个代码仓库,某一块的代码你们知不知道哪一块的代码是改了又改、错了又改、不停的在改,可能叫代码波动率,我们是不是要了解代码仓库哪里需要做优化了、哪里出问题了,为什么我们总改,看着很忙,但是总有问题。这一系列的问题基本上还有很多很多,这就是我们为什么要做精细化研发效能度量的前提。
在最近一段时间内我们自己设计和开发了一套研发效能度量平台,我总结了有四个点是我们必须要做的。
第一点是精细化,我刚才提到了,如果这个指标或者数据不够精细是很忙帮助我们去发现真正的问题细节点的。
接下来说右上角自动化,研发效能度量的工作如果是人工做,那人力成本是相当可观甚至可怕的,而且是很容易出错的,所以我们要自动化。自动化又提到了我们的整个工具平台,它是否有对外暴露数据的能力以及我们怎样把这个数据整合起来,怎样做可视化、怎样做BI分析,这些工作是要做的。在接下来是左下角高准确性,这是整个研发效能度量最难的工作,为什么呢?因为我们花了很大力气把一堆收据收集起来给到研发团队,根据数据分析可能你们哪里有问题,比如说你们开发周期就是慢,为什么呢?他们说正是因为我们的任务卡片隔了几个月忘关了,这个数据完全是真的,我们的度量工作就没有任何意义。
高准确性怎么来呢?就提到了我一开始介绍DevOps一体化平台讲到细粒度的管控,我们的整个研发流程是串起来的,都是工具自动化的,每个状态我们要做细。比如说代码提交触发了某种场景的编译打包,移交到测试环节,这个卡片是要自动翻转到测试端的,确保我们拿着的数据采点是准确的,这是我们强调高准确性的意义,否则前面的工具都是白做的。
最后一点是可定制化,我们做了这么多指标和图表,为什么要可定制化?上午路宁老师提到了我们的指标可能有几百个、图表有几百个,一上来给到不同的开发团队,他们会陷入迷茫的。或者说我们搞一堆图标、指标做一个大屏放在那里,真的会有人仔细看吗?不是的,我们不能把研发效能度量做成一个虚荣性的工作,而是要去真正帮助开发团队发现问题、去持续提升。我们怎么是定制化有两个层面:一个层面是不同角色的人要看到不同的视图、指标、图表,CTO要看全局,大项目组的领导要看哪些,敏捷团队的敏捷教练想关注什么,我作为一个开发人员我自己想关注什么,这个是可定制化的。第二种是我们每个团队根据自身的场景或者所处的阶段,我们更关注哪些,我们定制自己的看板和指标。
说了这么多,这个工具怎么做,就是我们平台设计和开发需要考虑的点。
先给大家放这么几个图,但是这几个图只是简单的图表,然后有一些可以看到黄黄绿绿的指标。因为一些原因走内部的流程把视图真的要拿出来给大家分享可能是需要一些时间的,我们的平台无非又印证了上午路宁老师说的,没想到这么契合。其实真的很简单,我们把数据从各工具平台抓取出来是元数据,是数仓。我们根据这些元数据整理出数据集市的概念或者做数据分析出来,让这些数据可以直观的方便各开发人员或者研发负责人去定制化做自己的图表和指标。基于图形我们现在链接非常成熟的BI分析工具,很多都是开源的,也做得很好,我们做一些简单的改造,契合我们自己的需求,这个平台其实就搭起来了。可能最主要的工作往往是我们要定义指标,这些指标又关联哪些数据,这些数据很细粒度的话我们能否采集到,这是我们需要做的主要工作。
具体这个平台设计开发有兴趣的小伙伴可以线下我们再继续交流,但是我刚才说了这些度量平台和度量的工作,其实我们运行下来会发现几个坑。比如说我们度量出来的指标大部分是过程指标或者有些是结果指标,有的领导和负责人第一反应是我要把这个和所有员工的KPI关联起来,谁交付的卡片慢了,谁提交的代码少了,我要把这个和他的绩效挂钩,他想要什么数据就变成了什么样子,大家都会去做应对。好,你让我每天提交的代码非常多,我原来就用一个注解写完了,我要再写一遍,代码每天都提交,这是没有任何意义的。研发效能度量不是要和KPI挂钩,而是不能挂钩。这是第一个误区。
第二个误区,即使我自己的开发研发过程中要做一些度量,我们应该注意哪些或者说我们怎样才能看懂这些图表,这需要我们前面说的以行会的方式大家多交流沟通,或者大家整体理念认知的提升。比如说我们举个例子,还有几分钟时间,比如说左边第二个图,这个图是一个累计流量图,其实很简单,比如说什么样的卡片,我们用了一段时间之后,不同颜色代表不同状态,你是在需求分析、还是在开发、还是在测试、还是在部署,这个周期时间长了,我一个项目可以看到一个累计的情况,这里面是有很多门道的,可以让我们相对宏观甚至钻到某一个时间段看交付瓶颈在哪里,这是一种场景。
还有比如说右边第二个图,它可以是代码波动率的图,一段时间内哪些代码频繁改动,有了改动波动率高就有问题吗?也不一定,我们必须要了解它的场景,然后去结合实际情况,这个代码我们是不是正在做重构,让我们去做下一步的判断。也就是说,我们要用好这个图表才能达到真正的效用,我们要往正常上引导。
还有我们把大量的图表都用起来以后,就是避免给人为刷数提供空间,而是把精力用在真正提高研发效能或者的工作上。
时间有限,我就先分析这么多,关于研发效能度量其实话题还是很多,欢迎大家后续再沟通。谢谢大家!

Q&A环节

观众1:我想问一下,你刚才讲到自上而下我想了解一下这个平台一开始做研发效能度量的驱动力和背景是什么?
武丁:我稍微解释一下,平安银行其实很大,人也有很多,我们是属于其中一个大的研发部门,是做金融市场和同业等方面的研发工作,大概是四五百人,这个团队的CTO来了以后要做一个转型,他希望通过可量化的一些东西或者数据来帮助团队去提高,这个推广也同样是自上而下的。但是这个过程中大家推广的时候使用的人一定要明白这个东西是为了什么,不要走偏方向。
观众2:我也是在做研发效能度量的,刚才提到一个有共鸣的地方,度量数据非常精细,但是会被应用到绩效考核,会对度量整个指标体系造成比较大的冲击,怎样保护和维护好这个环节?
武丁:这个非常重要。第一,首先要和主导这个工作的或者尽量高层级的领导要做沟通,我们一定不能与绩效考核和绩效指标挂钩。假如实在没办法,一定要和绩效挂钩怎么办?我们就可能需要把工作再做细一些,就是说我们的很多指标能否有机的结合起来做成一个围栏指标,也就是说他为了某一个指标的好看导致另一个指标变差,造成数据造假甚至数据的虚荣。还有一种是说我们怎么去让老板明白和KPI挂钩一定会出问题,大家一定会走偏。

Category新闻动态

©2022 中国DevOps社区版权所有;本站内容许可 CC 4.0

关注社区: