大数跨境
0
0

[大咖说] 珠联璧合:构建研发一体,打造精准度量体系

[大咖说] 珠联璧合:构建研发一体,打造精准度量体系 众安工程效能
2022-07-14
4
导读:本主题从研发一体化出发讨论众安在研发一体化建设以及精准度量方面的实践经验。众安保险效能产品总监 刘星辰众安保

本主题从研发一体化出发讨论众安在研发一体化建设以及精准度量方面的实践经验。

众安保险效能产品总监 刘星辰

众安保险成立于2013年,服务用户超过5亿,年提供保单超过79亿份,即便在疫情期间总保费逆势上涨16.7%,总规模达到近200亿,位于互联网财险第一名。众安取得业务的快速发展,得益于在数字化方面坚定的投入和沉淀。这意味着,在营销侧、客服侧、运营侧,都会有很多数字化的项目,这就给研发团队带来重大挑战,时间紧、任务重。在不增加人员的情况下,如何保质保量完成任务。除了业务创新外,提高研发管理和交付的效率,已经成为众安技术建设的首要任务。 


从我们企业管理和提效的角度来说,管理诉求从业务OKR到项目目标落地,以及交付项目的过程,包括需求、开发、测试、上线。借助我们的工具和能力,最终达到的目标是研发团队聚焦在业务价值上,把最有限的资源放在最核心的业务价值上,消除浪费,提升整体成效。


研发管理过程中很重要的反馈手段是把度量体系建立起来,但如何建立精准的度量往往存在很多困难。


举个例子,研发人员以任务来跟进工作内容,但是我们以周做统计会发现,大家的任务往往处理时间在5分钟以内,这样的比例持续增高,超过60%,任务状态存在滞后且一次性流转全部流程的情况,由此统计出来的数据必然不准确。


究其原因,开发人员聚焦在编写自己代码,推送代码到流水线上构建,往往会疏于流转任务工作流,造成任务节点就停滞。因此,从这些数据上取出来的埋点一定是失真的,同理在质量侧、发布侧的度量也会面临这样的问题。


我们也一直在思考怎么样通过一体化的体系,做到全流程自动联动埋点,减少人工介入,把我的度量做到精准。


基于这个出发点,我们认为这不仅仅是工具落能解决的问题,一定是伴随着“道、术、器”协同落地。


“道”,意为管理方法论,以敏捷交付的方式向团队导入敏捷实践,基于敏捷实践把我们团队聚焦在最高价值的交付业务需求。 


“术”,意为最佳实践,在团队中梳理出落地最佳实践,结合工具协同落地和推广。基于需求做分层,把多个角色之间的协同流程以最佳实践的方式固化到工具体系中,最终做到端到端一体化的协同和自动化流转。


“器”,是指我们的工具,整个工具体系涉及到从需求的提出,到分析、开发、测试以及最终的上线和安全管控,这是我们整个工具体系的基座。


在众安我们打造了一套技术中台,涉及项目管理域(TEAM)、上线发布域(Ship)、质量测试域(Magic)、运维监控域(Seraph)DevOps域、PaaS管理域以及基础设施,技术中台致力于为各个业务条线以及业务中台各个技术团队提供最核心的业务技术组件。

从敏捷实践角度来说,我们在需求层面聚焦在三层模型,这就是“术”,是一个最佳实践。我们倾向于推需求、用户story和任务的三层管理模型。需求对应业务方的业务需求,story对应业务需求最小可以交付的颗粒度,任务对应每个人要去执行的目标。我们在工具层面自研了项目管理系统TEAM,在这个系统中基于这三层做了最佳实践的模板配置,并在各个团队推广。大家基于这层模型分解任务、跟进任务,包括以看板的方式跟进每天的风险、进度等等,这是我们做敏捷管理最基本的功能。


关于任务类型的自动拆分。我们认为造成数据失真原因是有太多的人工操作,研发人员聚焦于编码工作的同时,通常会在手动流转流程中有遗漏。我们在TEAM中做了自动化的能力,基于某些字段在某个环节自动拆分任务,把它分配给某个人。这是有规则可对应的,我们在产品层面做成了自定义的能力,到这个阶段的时候重复的工作交给系统,让人聚焦在自己的本职工作上。


关于状态联动,拆分以后需求下面会拆任务出来,任务本身是由人流转的,需求状态是不是能自动变更呢?最大程度减少人员的操作,我们在产品层面把这样联动的方式做到了可配置,支持自定义任务到达某个状态的时候,触发需求的状态变更。


关于发布流水线,我们自研了发布管理系统Ship,并实现流水线层面的自定义,不仅包括流水线的自定义,也包含模板的自定义。从流水线的角度来说,通常分为不同的阶段,如代码构建,在这个阶段做静态扫描、单元测试、安全扫描等等,以及持续部署阶段,不同的部署环境都可以自定义。在每个节点上,需要进行的活动,包括部署、接口测试、UI测试,都可以自定义配置,同时可以兼容不同类型的代码库。


在测试方面,我们自研了一整套体系测试工具(Magic质量中台),包括自动化测试(UI、接口)、性能测试、代码质量检查、流量录制回放,支持集成到这个体系当中来。

从适配的场景来讲,不只是有应用发布、SQL发布还有配置发布,这些发布形式会形成制品或镜像,推送到相应的镜像仓库或者是制品库。从这些操作的层面来说全部都是可视化的,以开发者的视角开始做代码推送。


流水线其实是一条抽象的设计,只有抽象出来了才能说他是一条高度可自定义的,并且适配不同的应用场景。从阶段来说我们往往会分为四个阶段:构建阶段、并行测试、串行测试、上线。每个阶段接口测试、UI测试等等,都可以通过配置化的方式将其固化到流程当中来。


关于质量卡点和门禁,我们在产品层面做了一些质量域的自定义,所谓的质量门禁不同的部门不同的应用是可以有不同等级的,我们按照这样的逻辑将质量门禁指标做不同的配置。比如说我们做代码质量扫描的时候,对于A1的应用可能要求他本次发布过程中,严重的问题要清零,如果不清零卡点无法通过。其次对于A2级的应用,即非关键链路的应用,相关指标和问题在不完全修复的情况下可以上线,我们对于这样的应用配置不同的级别。


对于代码覆盖率而言,我们在流水线层面抽象出了一些内置植入的agent,把jacoco agent无感知地启动植入容器,流水线部署的时候在你的环境里面开启自动的远程监听,我们测试完成就会调度远程的agent做远程覆盖率的收集。所以这是我们流水线层面做的一些能力。


我们再来思考一个问题。当流水线从构建到测试环境部署阶段,映射到任务流上也就意味着从开发向测试的提侧。他们之间如果可以自动联动的话,当流水线部署好以后,任务的变更无需人工介入。


基于这个思路,我们抽象出中间层发布单,基于发布单做自定义的能力,实现需求流和发布流自动联动。这些能力目前在我们的产品中已全部实现。


有了这样一个过程,我们再看一个例子,让研发人员专注在发布侧。怎么做到的呢?左侧是典型的需求流,以及从需求拆分出来的任务流,右侧是发布流。如何做到让人员聚焦在发布侧?基于我们抽取出来的发布单,我们将发布单左侧自定义,需要联动需求哪个状态。右侧对接的是发布流的状态,他们之间通过消息或者接口交互,在发布单层面把关联关系建立起来,就可以实现这样的联动,这是我们在产品层面的设想。


从效果来看,作为产品经理,在TEAM上收集需求、并分析和跟进,他所有的操作全部在TEAM侧。对于研发人员他只要认领任务,认领完任务以后接下来所有的工作都在发布侧完成,基于需求拉取分支、关联代码,随后部署环境,全部在Ship上完成。


有了这一整套端到端的工具体系,我们实现的不止是一体化,而且是高度自动化的,能力具备以后才能具有建设精准度量的前提条件。基于这个情况,我们在产品层面提供了图表和数据自定义的能力。首先当我们做到准确的数据埋点以后,各个团队可以按照不同的指标筛选数据来源,这个数据来源本质上是一个自定义的数据筛选器,基于系统提供的渲染视图,打造可视化指标体系。


从落地的角度而言,我们也梳理出了适合于自己已经落地的指标体系,涉及到不同的角色、不同的类型,有项目类、缺陷类、质量类,以及不同的角色在什么阶段需要这些指标,并且在内部的质量委员会和项目管理委员会做拉通。


整个看下来,从敏捷方法论到最佳实践、辅导、推广,以及结合我们具有联动自动化能力的工具体系做协同落地以后,我们将整个研发效能建设至今和我们最初探讨这个话题时候数据的对比,目前平均团队的迭代周期是两周,我们在这个过程当中两周是迭代周期,但是需求是可以随时随地发布的,需求交付周期平均提升20%,发布的前置时间也有明显缩短,幅度达到48%,线上变更次数提升22倍,这也是我们经过整个一体化、自动化落地之后,从我们精准度量方面体现出来的结果。


发布流水线打通自动化测试,提升发布过程中的质量效能,代码覆盖率平均提升35%,故障恢复耗时缩短76%。降本这个点是重要的节流的体现,我们从流水线上把资源环境使用率做了最大化程度的复用,当某次发布环境部署结束或者已上线,从系统层面我们会做自动释放,以及部署的时候会向开发人员推荐最佳配置,最大程度降低资源的浪费,所以我们达到了每年节约两千万的低成本。支撑众安集团近超过2000人的IT团队规模,纳管容器超过7万个,年发布次数超过6万次,并发发布峰值超过500,支撑系统稳定性达到99.99%。   


  感兴趣的朋友可以扫码试用体验产品  





【声明】内容源于网络
0
0
众安工程效能
众安工程效能为客户提供DevOps研发运维一体化平台,包括项目管理、CI/CD、质量测试、监控告警、效能度量等产品,打造业务数字化升级的坚强基石
内容 34
粉丝 0
众安工程效能 众安工程效能为客户提供DevOps研发运维一体化平台,包括项目管理、CI/CD、质量测试、监控告警、效能度量等产品,打造业务数字化升级的坚强基石
总阅读38
粉丝0
内容34