2020 年 12 月 23 日，阿里巴巴资深技术专家陈鑫（神秀）在“2020 云原生实战峰会”的“互联网 CTO 数创先锋营”（闭门会议）中为现场的数十位互联网公司 CTO 及技术专家分享《数字化时代，如何构建下一代研发协作工具平台》。（本文整理自神秀的现场分享，为方便阅读，内容有删减）
本次分享主要由四部分组成：
1、企业在成长过程中遇到的研发效能困境；
2、研发管理从信息化走向数字化的路径，以及背后的逻辑；
3、云原生和 AI 两项新技术在研发平台上的落地；
4、结合阿里巴巴自身案例，分享如何进行研发管理数字化落地。
**
1 企业成长与研发效能
**
企业研发效能的制约因素
在“互联网 CTO 数创先锋营”（闭门会议）分享中，阿里巴巴资深技术专家陈鑫（神秀）从人员规模增长、软件服务架构、技术演化三方面系统地分析了企业研发效能的制约因素，并从中提炼出三个关键因素：成本、人以及人与人之间的协同损耗，这三个因素构成一个“环”。
（如下图所示）
陈鑫认为成本是不可能无限放大的，所以它是这个“环”中最关键的约束。而因为成本原因，企业往往不能雇佣足够优秀的工程师，甚至需要采用外包团队去完成业务开发，因此人员的技能不足是常态。又因为人员的能力参差不齐，甚至无法满足技术要求的，所以就无法创造出完美的架构和完美的组织设置，这就会出现大量的协同消耗。技术债务是会累积的，协同消耗往往会随着时间不断放大，消耗更多的人力，在固定的成本约束下会导致更少的业务人力投入。这个环就会出现负反馈，也就是越来越差。
那么，如何走出负反馈，进入高速发展呢？通常我们会采用技术去武装人，提升个人能力上限，这是重要破局点。接下来，需要适应当前团队组织和架构现状的协同流程，去降低损耗。需要注意的是这往往只能带来改进，在固有架构和组织模式不变的情况下很难从根本上改变局面。最后，可以使用一些工具去提升工作效率，以前手工做的，现在自动化去做，就能腾出更多时间去聚焦业务价值输出。
三管齐下后就可以有效驱动这个环进入正反馈，团队效率更高，技能提升更快，协同更加顺畅，业务发展好了，又可以投入更多的人力成本。
寻找下一阶段效能突破的路径
从本质出发去思考，以上提到的“研发效率”问题可以拆分为“协作效率”和“单点效率”两方面的问题。解决“协作效率”问题，我们需要去思考如何找到组织瓶颈，做到有的放矢？组织和架构复杂度发展到一定程度后，就会形成盘根错节的协作问题。此时改进的重点其实并不是如何解决，而是找到优化的重点方向，并且能下钻到具体问题进行突破，最后能看到所采取措施的结果。小团队的问题显而易见，而大团队的问题仅靠感性认知判断，往往无法直达本质。
“单点效率”方面很好理解，其突破核心在于新技术和新工具的应用，如何释放新技术带来的效能红利是技术团队始终要去做的事情。
结合以上两个方面，阿里云云效产品的使命就是让企业能具备研发敏捷和组织敏捷的双敏能力。做到这一点的路径就是研发管理数字化转型。
**
2 研发管理从信息化到数字化
**
研发管理的信息化与数字化
先抛出两个问题：什么是研发管理数字化，以及研发管理数字化与信息化的区别。
如下图所示，左边是目前各企业通常的做法，第一部分项目协作，在这个版块主要解决的是多工种的信息流转问题和知识沉淀问题。第二部分是软件开发，开发测试人员会采用各种各样的工具去完成手头的工作，比如编写、评审、联调、测试等等。第三部分是交付运维，需要把编写好的软件顺利的发布到线上给用户使用。
当前有很多工具可以完成这些工作，按照这个流程从上到下，逐步推进即可。但这里面有两个问题：
这些工具都是人参与其中的，人在推进这个流程中起到了关键作用，而工具只是优化了人的一部分工作。
我们更关注过程而不关注这些过程所产生的数据对企业的价值。这些信息成为了一个一个孤岛散落在各处。其实在业务领域做数字化转型时，核心本质问题都大体类似。
陈鑫认为 打破信息孤岛是研发管理数字化的关键，具备以下几个特征：
首先是面向业务价值的，这是企业做所有研发活动的终极目标。
第二是全局透明化，不管是业务还是产品、技术都可以掌握全局信息，这也是打破信息孤岛的直接好处。
第三是加速信息流转，提升协作效率。
第四是度量驱动，可以全局的看到效率瓶颈并有效去解决，避免头痛医头、脚痛医脚。
第五是智能加持，这也是数字化后的一大魅力，人工智能技术辅助甚至代替人去工作，可以从根本上提升效率。
从强调工具流程走向强调价值交付
如下图所示，当研发团队分工开始细化以后，从组织角度来看，更加专业化，资源效率更高，但是从业务价值交付的角度来看，周期非常长，而且中间还伴随着各种等待。
因此可以得出一个结论：局部效率高并不代表我们可以高效的交付业务需求。 我们有很多工具和手段去提升局部效率，这是一个相对收敛的问题，甚至可以通过加班去弥补效率的不足。同样也并不代表可以持续的高效交付，因为从本源上没有办法保障永远用全局最优的组织和架构以及流程去对应，甚至没有机制去发现瓶颈问题。
实现端到端可见的业务价值
陈鑫认为 研发管理数字化首先要做到的就是端到端可见的业务价值。从业务团队到产研团队有以下几个实施路径。首先是建立以业务价值流为视角的协作链路。以往，我们多半是通过项目管理软件解决产研团队的协作问题，以一个产品或者团队为单位组织需求、缺陷、任务等等。在新的体系中需要将业务团队纳入其中，并且拉通业务价值与产品研发需求、任务之间的关系，从而实现端到端透明可视。
在产研侧采用大量自动化工具仍然是基础工作，除此之外，需要将工具产出的数据链接到价值流上，并且尽量沉淀到数据平台。这里可以采用比较简单的评判方法，比如有多少百分比的工作是在线完成的、是否有统一的数据模型去积累数据。
在前面两步完成后，仍然要解决对齐业务、产品、技术团队目标的问题，比如业务诉求的优先级是什么、时间点是什么、其中的各环节瓶颈是什么，并且在过程中实时追踪。各环节负责人可以感知到异常事件和资源瓶颈，第一时间去着手解决，达到高效的目的。
第三步要做到持续高效，一定要基于前面积累的数据去量化分析，此时数据的魅力得到展现，有越多的工作在线，分析就会越准确。哪个团队在积累债务，哪个团队在积累资产，哪个团队是阻塞点，是调整架构还是调整组织分工，这种决策会更加有效率。
基于价值流理念构建产研数字化体系
如下图所示，是构建数字化体系的一个大致框架，在工具侧可以将从需求到交付的过程划分为三段：需求分析阶段、代码开发阶段、交付运维阶段，这三段分别对应以需求为中心、以代码为中心、以及以变更为中心的三个工具平台。
这三个工具平台会将数据沉淀到统一的数据中台之上。而对工具的选型原则就是是否可以构建出完整的价值流生命周期。而这些数据的再次应用，比如需求智能排期、代码智能应用、效能透视等等，会将企业组织管理推进到数字化阶段。
数字化落地的路径和关键要素
在企业要落地研发管理数字化，路径和关键要素是什么？
第一步 以价值流为核心。拉通研发效能各个阶段，打通工具孤岛，进行能力和数据的链接。
第二步 建立研发链路核心数据模型。通常会以产品、需求、代码、应用、制品为核心来构建数据模型。完成这一步后，我们会拥有一个研发数据中台。
第三步 数据驱动。根据价值流各阶段，定义度量指标，洞察出真实的价值交付时间和损耗。可以进一步下钻到各个阶段、团队的细节，对症下药。
第四步是 智能化应用。以研发数据中台为基础，扩展上层数字化应用，比如代码智能推荐、智能监控、无人值守发布、智能测试等能力。充分发挥数据价值，代替人力工作，从根本上提升效率。
研发信息化是解决企业研发效能的基础，有了扎实的基础能力和数据以后，数字化才有可能。
以上内容讲述了陈鑫对研发管理数字化的目标、红利、路径的理解，接下来会针对单点效率问题，讲述云原生和智能化这两个新兴技术如何在工具体系中落地。
**
3 云原生与 AI 在研发平台中的应用
**
云原生对研发效率的本质影响
以云原生技术带来的应用变化举例。如下图所示，左边是传统应用的研发过程，开发者的代码会深度耦合中间件，需要关注服务发现、分库分表、消息处理等多方面。往下也同样需要关注软件部署在哪，需要多少容量，甚至还需要关注操作系统、存储等问题。
在云原生时代则很不一样，中间件核心能力会下沉到云基础设施中，一些常见的限流、降级、鉴权等能力都无需关心，数据库、运行环境等都是动态伸缩的，常见的运维问题也不需要关心。只需要开发好代码，通过软件交付平台自动化的发布到云端就好。软件开发的复杂度其实不会消失，而是换一种方式存在。云原生技术下，这种复杂度会下沉到云基础设施层，通过云去屏蔽这种复杂性。在采纳云原生技术以后大家会发现，中小企业也可以轻松获得以往“互联网大厂”才能拥有的分布式、高可用、自动化能力。
因此陈鑫认为 卸载“offload”是效率提升的关键。回想下，企业落地 DevOps 的关键要素是什么？绝对不是简单地把 Ops 的工作交给 Dev，毕竟运维是一个高风险、专业化的工作。要落地 DevOps，首先要有一套自动化工具和标准化流程去卸载常见的 Ops 工作，比如部署、扩缩容、故障排查等。
再进一步思考，从汇编到高级语言，从物理机到虚拟机，从虚拟机到容器化，基础设施在不断地进行标准化。因为标准化后才能够有足够的人才投入其中去完善，碎片化市场很难做大。成熟的技术才能够做到完全黑盒化，才能放心的去采纳。因此 只有标准化技术才能卸载技术复杂度，而正是因为标准化，才有了数字化可能。在云原生下，我们拥有业界统一的技术标准，比如中间件标准、容器标准等。拥有了规范的数据，我们就有机会去创造出各种智能工具，去代替人力劳动，从根本上去解决效率问题。
通过 IaC 构建 DevOps 人机新界面
如何让研发工具释放云原生技术红利？经过过去一年的探索，陈鑫认为 IaC 是一个非常好的选择。IaC 全称是“Infrastructure as Code”，中文是“基础设施即代码”，指的是用代码定义和变更基础设施。这个概念其实在 2014 年就被提出了，随后也出现了 GitOps，也就是把代码放到代码库中，使用代码库的版本管理能力来完成基础设施变更控制。
IaC 和 GitOps 的模式对比传统 DevOps 工具最大的区别是什么？是 用户关注切面的变化。传统模式需要使用多运维系统、多控制台、熟悉多种交互方式。使用命令式模式操作基础设施变更，此时下层工具只提供原子能力，而人去控制原子能力的执行顺序，以及观测、回滚等等。这就像开一个手动挡的车一样，需要了解如何换挡，转速控制，以及油离配合。而新模式下，可以通过代码去统一定义基础设施，只描述终态。此时有一个高度自动化和智能化的运维系统，可以帮助我们去安全高效的完成变更。就像在开一个有自动驾驶功能的汽车一样，只需要告诉他要去哪。
但很遗憾，目前为止，IaC 模式都只是被少量运维人员用于编排云资源来使用。而广大开发者群体都在老的模式下工作。这项技术的广泛应用不但需要 DevOps 工具平台的升级，而且需要一个高度自动化和智能化的运维系统进行匹配。在过去一年里，阿里巴巴就在建设这个系统。
基于 GitOps 模式的应用平台设计
接下来，陈鑫简要介绍了如何将 GitOps 模式落地到 DevOps 工具中。如下图所示，展示的是云效新一代应用交付平台的架构示意图。
先来解释下什么是应用，应用一般包含多个组成部分，比如一个服务进程、一个数据库、再加一个 Nginx。而且，一个应用可以被部署在多个环境，比如测试、预发、正式环境等。
用过 K8s 的同学应该都知道，本质上 K8s 就是面向终态的 IaC 模式，定义资源都是用一段 YAML 文件来描述。但是 K8s 都是面向资源来设计的，主要服务对象是运维人员，而应用这个概念是为开发人员设计的。所以需要在 K8s 概念之上扩充出这个工具体系。大家可以关注下 kubevela 这个开源项目，这就是阿里 GitOps 方案的开源实现。
接下来，简单介绍下这个应用平台的组成，从上到下，第一层是用户界面层，开发者可以通过界面 UI，或者 cuelang 一种脚本语言来对应用进行编排，其中 cuelang 模式是显性的代码化，而 UI 是帮助用户生成代码。
下面是应用的静态编排，需要描述应用的组成，比如可以是 K8s pod，也可以是函数，或者是虚拟机，或者是多种组合。再下面是环境以及机器组的配置，描述环境资源所在的物理地点。
当我们要执行一次代码发布或者扩缩容，甚至是更复杂的运维变更时，用户会通过 UI 或者代码对应用描述进行变更，App GitOps Engine 会将变更内容通过 Cloud Provider 进行下发到云去执行，最终自动化的完成变更操作。
具体细节可以访问 kubevela 的官网进行了解。
https://kubevela.io/
研发管理数字化的愿景
“讲完云原生的例子，我们再讲下智能化。这是我心中关于研发管理数字化的一个愿景。”陈鑫介绍说。
首先，从协作、编码、测试、交付、应用运维，可以全面使用云化工具一站式完成。先进的工具加上先进的理念可以帮助企业构建透明高效的组织。 当我们不断生产和积累知识后，研发数字化的魅力开始展现。
在未来，智能化研发管理助手将成为承载我们最先进的软件工程技术和能力的化身，它会承担两大职责：
代替人去完成繁琐的工作，比如缺陷排查、故障发现、持续监控、协助沟通等等。
成为软件交付专家，根据每个企业的实际情况，推送最优质的代码，最合适的编程框架，最适合团队的流程改进建议等等。
接着，他简单介绍了阿里巴巴在代码领域数据智能工具落地的方向，比如在代码效率、质量、安全方面，阿里云云效分别开发了代码缺陷预测、敏感信息扫描、智能评审、代码补全、代码库异常行为监测等产品。
**
4 阿里巴巴的工程实践
**
阿里巴巴面临的效能问题
前面介绍了解决协作效率和单点效率的一些思路，接下来看一下阿里巴巴面临的效能问题及解决问题的方法。
阿里巴巴面临的效能问题是什么呢？我们从业务侧和技术侧两方面来看。
从业务侧看，阿里为避免业务团队重复建设，从而导致数据不统一、业务流程混乱等问题，发明了业务中台这个概念。业务中台其实并不完全是通用性逻辑，它是通用逻辑和各个前台业务定制化逻辑的结合体，因此就产生了一些新问题，比如业务中台中的通用逻辑和一些前台业务定制逻辑迭代速度不一致，从而出现部门协同、排期、优先级问题，互相影响效率。有些前台业务还对应多个中台产品，多方协调存在一个巨大的沟通成本。
从技术侧看，阿里在服务化架构下发展多年，虽然在高可用方面顶住了历届双 11 的考验，但也带来巨大的副作用，比如应用运维工作开始变大，调用链路开始变长，而且都是分布式服务问题，排查难度变大。打个比方，大家在淘宝上买一个商品，这个链路会跨越多个 BU，比如淘宝业务、共享业务、支付宝业务等，涉及的团队一线开发者很难讲清楚。不管是完成一个业务需求，还是排查一个问题，都需要大量沟通。现在还面临 PaaS 层上云考验，如何用好众多的云产品是个很大的问题。
阿里一直以来希望通过技术和组织的变化，来做一些解耦，让不同团队掌握自己的业务发展节奏，分开来跑。但是这种解耦并不能完全消除协作的复杂性，架构的复杂性，而是换了一种方式存在。当我们面对这种业务爆炸、应用爆炸、协作研发成本日益增高的情况时，如何去破局是个非常大的挑战。
破局路径上的挑战
解决问题之前，除了刚才的定性分析，还需要更多的定量分析来洞察关键瓶颈。
如下图所示，是目前阿里在用的一个研发阶段度量模型。先粗略的观察目标 BU、团队的效率关键节点，然后再下钻到具体问题，分析是协作还是技术问题，解决什么具体的场景可以打破瓶颈。如果大家对这里指标感兴趣，可以进一步了解。
结合定性、定量和调研分析，可以得出了以下三个关键方向：如何解决中台协作问题、如何解决日益复杂的架构问题、如何进一步释放云原生红利。
面对如此复杂的问题，如果直接去解决单点问题，必然是只见树木不见森林。在这里，给大家介绍阿里最近在解决集团效能问题过程中总结的一套方法 ALPD。
ALPD—新一代的精益产品开发方法
这是阿里云云研发团队结合了精益思想、云思想、以及架构设计思想等多方面构建出来的一套方法体系。
这个图蓝色部分是我们今天关注的重点。其中分为三个部分：全链路数字化的精益协作，解决前面讲的的中台协作问题。第二部分是领域驱动为核心的技术实践，解决日益复杂的架构问题。第三部分是云原生的工程实践，用这套工程实践去进一步释放云原生对每一个业务开发者的红利。
https://developer.aliyun.com/article/771387
云化一站式 DevOps 平台的发展趋势
“好方法的落地永远离不开工具，”陈鑫说：“而我本人的职责就是用工具去承载方法，用工具去链接开发者和云基础设施，为企业研发管理数字化发展做一些事情。”
当前，阿里云云效推出了一系列好用的工具，可以帮助企业快速上云，包括项目管理、知识库、代码平台、自动化流水线、制品管理等等。阿里巴巴集团依靠云效平台，完成了从手工到自动化的转变，从传统运维模式到 DevOps 的转变，从虚拟机到容器化的转变，相信云效的经验和产品可以帮助到大家，让各位不再为研发效率问题发愁。
**
5 总结
**
最后，陈鑫表示：当然，我们现在做的还远远不够，结合我前面对研发数字化路径分析和方法的总结，在这里讲一下，我对未来趋势的一些判断。首先是 ALPD+ 钉钉的云端协作体系，这是解决持续高效交付业务价值的基础。其次是基于场景化的云端编程体系，比如小程序、Serverless 各种新的编程框架日益增多，一招鲜的玩法会逐步被替代。第三是基于 IaC 理念的云原生研发模式，第四是研发数据中台，这是从简单度量指标分析转变为数据洞察决策分析的基础。最后是智能研发的全面落地。
