嘉宾 | 杨宙   整理 | 秃头小周

出品 | CSDN云原生

2022年5月24日，在云原生系列Meetup·北京站上，bilibili资深开发工程师杨宙做了主题为“效能之上，高效交付”的分享，并对研发效能进行了解读。

研发效能是一个复杂的网状问题，需要树状的思考、线性的回答。随着应用技术的持续发展，对研发效能有了更高的生产要求，随之诞生了众多工具、平台、流程以及自动化、标准化的能力，来帮助提升研发效率。在IT基础架构或企业组织层面，已然形成了一个研发效能层。很多企业的产品业务的快速创新都是需要基于效率之上才能够被实现或运转得更好。

研发效能是团队能够持续为用户交付有效的价值，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）。从最早的敏捷开发、CI/CD工程化流水线，到DevOps、DevSecOps、GitOps、DataOps、AIOps甚至NoOps，从软件生产过程生命周期的不同阶段介入和干预，诞生了各种各样的工具平台来提升和改进组织响应效率。组织协同层面尽可能消灭研发过程间隙、无效等待时间，问题前置处理个体效率层面减少人工事务性操作、工具辅助、智能诊断、决策推荐等。因此，研发效能提升并不等于996.ICU，而是发现效率问题的真正原因，进行度量和改进。

典型的组织生产关系

下图展示的是比较典型的组织生产关系。可以看出存在两方面问题，第一是吞吐率过载，研发人员不足和之前的需求有变化，新增的需求无法被正常分配；第二是需求来源的多样化，不单单只有业务的需求，也有可能是产品的需求或者技术的需求。此外，还能看出在产研侧，如果整体的吞吐量达到瓶颈，就会出现研发供应不上需求的问题，长此以往，一些关键的业务需求无法落地，就会激发矛盾，效能也随之越来越低。当技术需求与业务需求及产品需求在这个场景下长期僵持的话，就需要有一方为主的驱动。

大多场景下业务驱动的生产关系如下图所示，研发人员的时间投入占比，整体为并行的过程。长期支撑业务，会压缩架构设计抽象稳定性等产品化的投入时间占比，由此会产生一些滴水延时效应问题，例如架构腐化、代码腐化、产品腐化、矛盾激化等。此外还有并发冲突的反向效率问题，例如事务的频繁切换、业务周期拉长等。最终依然无法高效实现整个业务价值的交付，无法达到可持续性。

生产关系矛盾是研发效能首要解决的问题，下图是KNAO模型。首先将功能的具备程度跟用户的满意度放在一起来评估，按魅力属性、期望属性、必备属性等进行划分。

需求可以分为5类：

第一类是魅力型需求，是投入少用户满意程度高的需求；

第二类是期望型需求，是产品应当解决什么问题的需求；

第三类是必备型需求，是产品本身具备的需求；

第四类是无差异需求，是感受不是特别明显或者无所谓的需求；

第五类是反向性需求，是用户不喜欢的需求，例如一些广告的智能推荐。

所有的需求分为这5类，结合用户价值满意度，平衡优先级。KNAO模型只能缓解需求被受理问题，并不能彻底解决像研发效能吞吐量的问题，所以吞吐量的问题依然是需要被提升的。

下图是研发效能提升的弹性法，可以看出，我们无法提升整个研发效能的绝对值。当一个效能问题出现时，要尽可能考虑当下局部效能最优解，一点一滴积累，使得最终整体效能接近期待的效能，或者随着业务扩张，人员规模增长，软件规模复杂度不断提高，尽可能减缓研发效能下降的趋势。

黄金三角模型与双流模型

研发效能的关键理念就是黄金三角模型和双流模型。

黄金三角模型分为最佳实践、效能度量、工具平台三个模块。出现效能问题时，可以先度量之后再去探索寻找最佳实践，这些最佳实践需要沉淀在工具跟平台之上，工具平台再反馈进行效能度量，做一些持续化改进。

黄金三角模型有四种理念：

第一是自动化，如果同样的度量，可以持续地去探索追加实践，再沉淀到工具平台里面，形成一个循环，逐步提升整个研发的效能，在此过程尽可能的自动化；

第二是标准化，标准化其实是降低研发过程中一些随机性问题的复杂度，统一的标准可以被统一管理；

第三是覆盖全生命周期，各个阶段都有可能有不同的效能问题；

第四是统一流水线，一站式研发平台，需要去统一整个流水线，提供一个一站式的研发平台，这也是黄金三角研发效能提升的关键理念。

对于双流模型，很多敏捷管理工具跟研发效能工具其实是两个工具，或者可以叫做管理流程和研发流程，很多时候管理者使用敏捷管理工具，研发者使用研发效能工具，开发人员或者测试人员没有及时更新进度到敏捷管理工具上会导致不同步的情况。双流模型可以弥补敏捷管理工具跟研发工具割裂的问题。整个过程中可以减少人工的操作，来保证一致性，进行持续化的提升。

不同阶段的效能工具

下图展示的是每个阶段可使用的工具。

在需求阶段，需要一些敏捷工具。

在设计阶段，除了diagrams.net，目前还没有很好的工具去支撑。设计是一个架构的过程，有很多不确定性。在理论层面，已经有一些方法做辅助手段，比如架构的反模式，通过一些架构的反模式发现架构的债务问题在哪里，技术债务的后期修复成本很高，架构债务的修复成本更高，要在设计阶段，通过反模式进行审查发现并解决。

在开发阶段， Vagrant用于创建和部署虚拟化开发环境，保证环境之间的差异。Codacy是一个代码的审查工具，它可以分析存在的问题，主要包括代码质量、语法规范、功能可用性方面的检查。

在测试阶段，Chaos Mesh做一些混沌工程的故障注入，或者EggPlant提供整个人工智能的协助自动化测试，它可以无缝集成到CI/CD的流程里面去，将整个测试生命周期自动化。

在上线阶段，Argo可以持续集成内容，还有持续部署例如Docker、K8s、Crossplance。

运维阶段的关注点，第一个是监控诊断跟恢复，在运维中很多问题都被遗留到线上，但在线上解决问题的成本很高，所以会有很多工具协助提升效能，例如监控工具Datadog，诊断工具SkyWalking、Pinpoint；第二个是故障的恢复故障治愈，当出现告警事件，可以进行故障治愈的措施，比如重启扩容等。

在不同阶段的过程中，也需要自下而上的持续反馈，像Slack或者GetFeedback协作工具，辅助整个研发不同阶段的效能提升。

一些效能度量指标

研发效能的度量指标最关注三个方面。

第一个是交付效率、交付质量和交付能力。在研发生产流水线的流速率（需求的吞吐量）是最顶层最应该被关注的指标。

第二个是不同阶段消耗时长，例如需求创建时间减去上线完成时间等于需求前置时间。

第三个是产研交付周期，从需求受理到上线过程需要多少时间，开发一个需求总的消耗时间，分为分析设计的时长，开发、测试的时长，部署发布的时长这三方面。与一些活动时间或者等待时间进行换算，可以得到一些关键的指标，例如流速率和流负载。同时，质量在这个过程中不能节省。

交付能力包括方方面面，像响应能力。很多问题在工程化里面是能够被解决的，所以更多是关注在效率和质量两个问题上面的权衡，整个研发效能，涉及组织及组织成员能力的不同，所以这个指标不具备统一性和可参考性，只是方法的过程有参考价值。

综上所述，研发效能是每个组织内部去考虑和发现效率问题，然后进行度量和持续化改进，逐步进行提升的过程。

---

聚焦云原生新技术、新实践，帮助开发者群体赢在开发范式转移的新时代。欢迎关注CSDN云原生微信公众号～