解密蚂蚁研发效能：如何用数据驱动效能提升？

添棋

蚂蚁金服 解决方案架构师

添棋 ，软件研发、工程技术、系统工程专家，聚焦 ICT、金融等领域，擅长大规模、高可靠性、分布式软件的架构、研发模式与工程技术、软件项目管理。现负责蚂蚁金服研发效能解决方案，结合 CI/CD、DevOps、大数据、AI 等相关技术，落地云端研发体系及蚂蚁研发洞察平台。

01

背景：蚂蚁金服研发效能体系

1.业务特点：“快”和“稳”的平衡

蚂蚁的业务兼备金融行业和互联网行业属性。 金融的核心诉求是“稳”，因为一旦出现资金问题就会失去用户信任，所以每次的发布必须是高质量。而互联网的核心诉求又是“快”，1个新特性可能需要1周甚至更早要上线，1 个严重问题甚至要在几小时内完成修复。按照常识来判断，我们知道， “快”和“稳” 这两个指标的同时达到最大化几乎是不可能的，就像开车一样，你想快，猛踩油门，风险就会提升。因此，要解决这个问题就需要系统性的设计，尤其是在软件架构和研发体系上。

2.架构以及研发体系演进

随着蚂蚁架构的演进，研发体系也随之逐步升级，当前，我们的最小交付单元叫做 “应用” ，类似业界的“ 微服务” ，一个应用的每一次交付都具有 “小、独、轻、松” 的特点，即：

• 小： 每次发布的需求颗粒度足够小。

• 独： 应用可独立开发、测试、发布。

• 轻： 应用能轻量级部署、升级。

• 松： 应用之间松耦合，相互影响小。

3.我们做什么

作为蚂蚁研发效能部，我们当前聚集3个领域，分别是：

• DevOps： 提供一站式开放集成持续交付 工具 链，助力蚂蚁DevOps落地。

• DevMind： 研发洞察分析，依托数据和算法，驱动团队和一线研发提效。

• DevServices： 研发服务支撑，帮助一线研发快速解决日常问题。

本次分享的重点是 DevMind ，即 “研发洞察” 的落地实践。

02

What：问题和解决思路

列举一些一线研发和各级 Leader 在日常工作中的常见痛点：

• 一线研发： 经常把时间花在解决编译不过、链路排查这类问题定位上，碰到一个没见过的问题，经常半天的时间就搭进去了。

• 一线TL（Team Leader）： 团队同学每天都很忙，但似乎这周没什么产出，都遇到什么问题了？

• 部门负责人： 业务方反馈我们团队交付慢，到底是什么原因？其他部门的水平又怎么样？

显而易见，这些痛点并不是单纯提升工具链效率就可以解决的，但如果放任不管，就会造成很多时间上的浪费，甚至很多 Leader 会使用各种“管理手段”尝试解决这些问题。归根结底， 这类问题的本质是由于信息不足，研发的信息没有在一线研发和 Leader 之间有效的流动，研发经验没有在一线研发之间很好的继承、复用 ，而这类问题正是我们研发洞察需要尝试解决的，当前的思路是这样的：

• Step1： 收集日常研发活动中所有的过程和结果数据，加工后，依托模型和算法识别问题。

• Step2： 对于团队Leader，提供效能的可视化，并把发现的问题和解决方案推荐给Leader，驱动团队进行改进。

• Step3： 通过数据挖掘和分析，找到一线研发在各个活动中的问题点，并通过用数据赋能现有的 DevOps 工具链，帮助一线研发提效。

下面，按照这 3个步骤 ，依次分享一下我们的思考、方案及落地实践。

03

How：蚂蚁研发效能模型

既然要提效，那么我们首先要回答三个问题：什么是研发效能、蚂蚁研发效能如何评估、如何先找到问题并持续调优。

1、什么是研发效能？

“效能” 这个概念本身有很多解释，比如字面理解就是“效率*能力”或者“做正确的事+正确的做事”。比如《精益软件度量》中总结的“价值、质量、效率、能力”。但是映射到蚂蚁的实际情况，从业务对软件研发团队的“效能”的感知的角度看，我们认为比较契合的还是 Capital one 的这句口号—— “Deliver High Quality Working Software Faster” 。

试想一下，如果把研发团队整体看做是一个“生产工厂”，业务方最关心的就是你的这家工厂，能否持续的满足业务需求，能否持续的做到“有质量的快”，如果能做到，那么在此基础上，可以再看下你的投入，自然是越低越好。

2、蚂蚁研发效能如何评估？

（1）流动效率

结合蚂蚁的业务架构、软件架构和研发组织架构，把蚂蚁的研发过程抽象并“具象化”，我们会得到一个类似管道一样的模型，输入就是原始的“业务需求”，它经过设计&拆解变为“应用需求”（也可叫微服务需求），再经过开发人员编码实现、构建成可运行的软件包，最后发布到线上。

按照精益的定义，我们首先要关心“流动效率”，围绕它定义关键指标。当然，这里隐含着一个难点就是“需求粒度”，不同的需求量，交付的周期肯定是有差别的，而 在软件工程领域目前并没有一个精确的方式可以衡量一个需求的“粒度”，人天、点数、代码行无论是哪一种方法都有它的问题和局限性 。至于蚂蚁的解法，此处篇幅有限就不进行展开了。

（2）资源效率

资源效率指的是各环节的资源利用率和产出情况，它影响了整个“管道”的流速。具体我们又拆分为了2个关键的要素：

• 团队能力： 团队中参与开发的人员的产能主要决定了开发、测试阶段的效率。但是在软件工程领域，人的产能也同样没有通用、科学的度量衡，因此我们就再进一步拆解为人员投入、人员能力、以及工作效率，其中比较容易观察和衡量的就是工作效率，工作效率指研发人员使用每一个研发工具完成必要活动的效率。

• 工程能力： 工程工具也是一个综合性、复杂性的系统工程，持续交付流水线以及测试能力决定了在代码在集成、验证、发布阶段的流动效率（全自动化的前提下），研发各类辅助工具会影响研发人员的产出，而基础设施则决定了整个工具链的底层效率和稳定性。但是好在，这些都是机器的事情，只要持续的拆解，每个过程都是客观的、可以度量的。

按照以上的理解，我们就获得了一个 分层的评估方式：

（1） 价值： 业务目标的达成情况，它和研发效能有一定的相关性，但是不一定存在必然因果关系。

（2） 研发效率： 业务直接感知到的研发团队的交付水平，业务方和研发团队的Leader都需要关注的核心点。

（3） 研发能力： 决定了研发效率的关键因素，是团队Leader提升效率的关键抓手。

3、如何先找到问题并持续调优？

基于上述的评估方式，我们可以构建一套用来评估和诊断的模型体系，帮助蚂蚁的研发效能持续的提升。

此需要强调的是我们的一个基本观点： “模型的本质是对规律的洞察，而上帝不会告诉我们规律，只会展示给我们数据” ，因此，我们虽然基于观察和经验构建了逻辑模型，但是会带入大量的团队数据并结合实际进行验证，最终把它转换成 “基于数据构建的可验证模型” ，只有这样才能确保它是贴近事实的。

03

How：决策辅助

下面分享我们帮助团队提效的实践：

首先，上文中已经明确表明，在理论上并没有统一的、有效的、科学的效能度量方法，但是不代表我们解决不了问题。理论是抽象的、基于逻辑的，它和现实的物理世界之间多少会 存在差距，因此，只要我们从实践出发，聚焦到具体的问题上，总会有各种各样的解决方法。

具体到效能度量这件事情上，我们可以回归最初的目的和价值来思考，“度量”的本质其实是帮助团队达成目标的一整套策略，如果团队对目标有共识，那么自然会尝试把现实情况抽象成“度量指标”，用来牵引和评估目标的达成。基于这个思路，我们制定了 三个层面 的落地策略：

1、自上而下，建共识、定指标： 依托“蚂蚁研发效能模型”产出系统性的指标，在公司高层Leader之间达成一致，确保各级主管对效能理解一致，同时基于蚂蚁的历史数据和各位专家的经验，用统计学的方式建立基线作为参考。

2、自下而上，贴场景、保落地： 一个好的指标一定是能够反映出团队的真实情况，并且能帮助团队解决实际问题。为了做到这一点，我们持续和蚂蚁不同业务线的一线团队开展提效试点，一方面帮助团队解决具体问题，另一方面把积累的数据、规则和方案沉降到了研发洞察平台中。

3、平台支撑，产品化、模型化： 我们研发了一款 “研发洞察” 产品，依托数据和模型能力，实现了指标异动的自动检测、问题自动发现以及解决方案的自动推荐，用来服务蚂蚁所有的团队Leader，下面是我们的产品能力上的逻辑图：

 

我们当前主要落地了四个场景：

（说明：下文中图示均为示意图，不涉及真实数据）

场景一：日常体检

我 们把效能指标的规则沉降到了产品中，让产品能够自动对现状进行报告，并对异常指标进行监控和告警。基于这些规则，团队 Leader 不仅能看到自己团队的现状和标准之间的对比，也可以看 到和公司平均水平或其他团队的对比。

场景二：研发效率诊断

洞察平台会以巡检的方式持续监测团队研发周期的短板，推送给部门负责人，部门负责人收到通知后可直接分解到一线 TL。一线 TL 则会使用深入诊断能力，确认异常的应用、时间、问题原因和具体证据，并能够获得解决的方案以及其他团队的实践案例。（细节可以下载材料，其中有相关的演示）

场景三：质量风险诊断

一般来说，研发过程中每个阶段都有相应指标可以衡量质量，只要通过简单的多维分析和可视化就可以帮助到团队 Leader。但是对于研发洞察来说，还需要更近一步，我们会通过关联分析的算法，尝试找到线上故障和研发过程各个阶段质量活动之间的关系，把影响线上质量的关键因子提示给对应的 Leader，帮助 Leader 把问题消灭在前端。

场景四：能力诊断（工程、团队）

工程能力的评估在 DevOps 领域已经很常见，此处不详细说明了。但是关于团队的能力，当前业界并没有真正能衡量人能力的方法或实践，我们当前的策略是通过人的产出反向关联开发着的研发活动、行为，找到可能的改进点，把数据推送给团队Le ader，让团队 Leader 可以结合客观数据主观的判断是否需进行改进。

比如我们可以通过研发在 IDE 上的键盘敲击序列判断编码的时间和习惯，洞察出一个团队的核心编码时间，那么这个团队Leader就会刻意的再这段时间内保护组内的开发同学不被其他杂事打断。

再比如我们通过研发的日常咨询数据，洞察出一个团队最常问的问题是哪一类，某种工具的使用还是 SDK 的使用，帮助团队的 Leader 判断是否要进行培训或者建立内部知识库来针对性的解决问题。

小结

在决策辅助层面，我们的核心观点是： “不仅仅实现研发数据的可视化，而是要能通过效能领域专家的知识沉淀，直接提供效能洞察结果给非专家型的用户” 。

上图中引用的这篇文章来自于 Evangelos Simoudis 的博客，它完整的展示了我们构建的这个系统的本质——“专家系统”。专家系统的构建思路源于20世纪60年代，它是一个计算机程序系统，其内部含有大量的某个领域专家水平的知识与经验，能够利用人类专家的知识和解决问题的方法来处理该领域问题。

你可能会觉得，它似乎和当下流行的基于机器学习解决问题的思路格格不入，但是它的优势就在于“规则的可解释性”，简而言之，我们的系统不仅要告诉团队Leader问题在哪里，更要有逻辑的阐述为什么有问题以及问题的原因，这是目前机器学习技术不擅长做的事情。

04

How：研发辅助

接下来，继续分享我们使用数据帮助一线研发提效的实践，你会发现，它和上面介绍的“决策辅助”是完全不同的思路，我们的落地策略有两个层面：

1、分析研发大数据，识别低效点： 我们投入了效能领域专家和数据专家，结合基于数据思维的“数据挖掘方法”和基于逻辑思维的“工作流分析法”对蚂蚁一线研发过程进行系统性的分析，找到工具链之外一些由于信息问题造成的低效点。

如图所示，蚂蚁的工具链体系多年演进过来，不论是自动化程度、运行效率还是稳定性基本都已经达到了很高的水平，但是我们发现随着工具效率的逐步提升，依赖人经验和能力的环节正在逐步成为瓶颈，比如失败日志的定位、链路的排查、研发问题的咨询等等，那么如何能降低这部分的时间，让一线研发更多聚焦在编码这样的高价值工作上，就是研发洞察中“研发辅助”要解决的问题。

2、数据赋能研发工具： 针对低效点，我们会思考如何使用数据来升级对应的工具，让工具链更“懂”研发，更好更精准的提供服务，具体有三个步骤：

(1) 构建研发画像：分析人、应用的特点、活动、行为，生成标签。

(2) 用户需求预测：根据当前行为预测，可能遇到了什么问题、需要什么帮助。

(3) 智能推荐/修复：将风险&信息提示给用户，甚至直接帮助用户解决。

下面简单分享四个我们的实践

场景一： 失败日志定位

我们通过研发数据分析发现，同样一个失败日志，有人 1 分钟定位，有人要花 30 分钟，这里面的差异就是人和人经验上的差距。

我们通过聚类发现，所有流水线上的失败日志，大概可以分为 14 个大类 96 个小类，而 90% 以上的失败日志都是有解决方案的，因此我们构建了日志的知识库赋能给了日志平台，实现了精准诊断和解法推荐。

这样一来，当一线研发点击失败日志后，会直接看到失败日志的行号以及如何解决这个错误（如图所示）。 落地至今，平均每天可以命中数以万计的失败日志，并可为其中 94% 的失败推荐方案，为每一个遇到流水线失败的用户每天每人节约 28.5 分钟的时间。

场景二： 链路排查

众所周知，在分布式、微服务架构下，系统的链路调用关系错综复杂。 对于线上运维来讲，由于业务规则比较确定，通常可以用 AIOps 的思路来解决，但是在研发过程中，一线研发在自测试、联调过程中的问题定位，由于面临很大的不确定性，仍然需要在复杂的调用关系中进行人肉排查。

对此，我们 构建了一个研发链路的规则库和知识库，赋能给链路排查工具 ，规则库可以继承上线诊断规则以及线下研发的历史排查规则，知识库则是记录每一个命中问题对应的团队解决经验。 这样一来，当开发同学输入一个问题链路 ID 时，工具会直接锁定问题节点，并将团队已经处理过的经验链接推送过去，大大降低了问题排查时间。

场景三： 代码提交风险提示

很多时候，一线研发会因为担心风险不敢轻易的频繁提交代码，这也是问题常常遗留到后期的原因之一，如果能在每一次提交的时候，把影响性知会到他，那么他会很愿意把问题提前消除掉。

在这个实践中，我们通过分析提交的代码变更判断对线上业务的影响，并根据业务的使用量、调用量、关键程度等数据，判断风险，推送给一线研发，并监控这些风险在发布前的闭环情况。 在实际落地中，我们发现 有超过 50% 的风险在代码入主干之前被消除掉，一线研发通过自动化或者手工验证的方式尽可能的对未覆盖过的代码进行了充分的验证。

场景四： 研发咨询

如图所示，这是一个智能答疑机器人，在每个研发工具的右下角都会有一个入口，当研发过程中遇到问题时，点开，可以看到 “猜你想问” ，这是我们对他当前可能遇到问题进行预测，如果未命中，我们的答疑机器人就会根据开发的提问，进行对应的方案推送。

小结

在这个领域，如果用一个词来描述我们的愿景，那么就是 “AI Dev” ，我们希望依托数据和算法把传统的 ”被动辅助工具“转换为“主动智能工具”，让研发工具链更”懂“研发，为一线研发实时的提供更高效的优质服务。

总结： 智能化之路

最后，大家心中可能还有疑惑， 讲了这么多场景， “研发洞察”似乎无处不在，它做了这么多事情，那么它的“实体”到底是什么，又由哪些关键技术组成呢？

研发洞察其实是一个 “以提效为中心，融合研发全领域知识和模型的智能洞察平台”。

把它展开来，简单看一下它的内部结构：

在系统建设上，平台底层有两项关键技术：

(1) 研发效能统一数据中心：从蚂蚁研发工具的源数据中提取数据，一方面使用“阿里大数据”体系的方法论进行建模形成了分析型数据仓库，另一方面使用数据挖掘技术建立了特征工程，形成了人和应用的研发画像。

(2) 研发领域算法模型：基于人工抽象或机器学习算法构建的“学件”，主要包括一些可解释性规则库、基于机器学习的识别/匹配模型、基于NLP的研发语料模型等等。

在核心能力上，我们对上层提供 3 个中台服务，分别对应了问题的 发现、定位和解决。

在用户场景上，面向团队 Leader，我们提供了一款数据产品“研发洞察”，面向一线研发，我们将中台能力赋能到现有工具链上， 期望 在不改变工具使用习惯的情况下，默默的帮助研发同学提升效率，达到润物细无声的效果。

最后，无论是研发洞察平台本身还是我们要解决的问题域，都是一个复杂的系统工程，是AI、大数据、软件工程、组织行为学、研发工具链等多个领域的综合应用，在理论、技术还是落地实践上都需要持续的探索， 我们也希望更多的领域专家和技术专家能加入我们，一起迎接挑战，打造业界领先的研发体系和实践。

后台回复 “20190421” 即可获得完整ppt~

长按识别二维码关注我们

P.S.

蚂蚁金服研发效能团队招募进行中， 解决方案架构师、技术运营、数据研发专家、技术专家、技术支持专家、 产品专家、测试平台高级开发工程师、代码分析技术专家 等众多岗位持续开放，让我们共同开赴DevMind/ DevOps /DevServices三大战场，助力内部及外部伙伴研发效能的持续提升:rocket::rocket::rocket:

如果你对任何岗位感兴趣，请留下联系方式，或者发简历到： AntLinkE@antfin.com

▼  点击“阅读原文”获取更多职位详情