代码变更风险可视化系统建设与实践

本文整理自美团技术沙龙第77期《美团亿级流量系统的质量风险防控和稳定性治理实践》。文章第一部分介绍了软件系统风险与变更；第二部分介绍了代码变更风险可视化系统的能力建设；第三部分介绍了整个系统在美团内部实践落地的情况；最后是对未来的规划和展望。希望对大家能有所帮助或启发。

1 软件系统风险与变更

变更是软件系统进化的推动力，同时也是孕育风险的温床。如果一个系统没有了相应的迭代和变更，那这个系统就会逐渐失去了活性和价值。不过，随着系统进行了变更迭代，软件风险也会慢慢衍生，而规避变更引发的软件风险在质量保障领域是一个较大的挑战。通过对下面典型软件系统架构图分析，我们可提炼出3大类变更维度：

• 基础设施变更：主要包括基础硬件变更、运营商网络变更、云服务容器变更、开发语言变更、操作系统变更以及机房集群的变更，这些基础设施迭代极大提升了系统底层的服务能力，一旦变更引发系统风险，其影响面通常也比较大。
• 系统外部变更：比如用户流量突增、用户需求变化以及相关三方服务及三方组件变更，这些帮助系统不断衍生出新的迭代能力，同时也增加了系统稳定性风险的发生。
• 系统内部变更：比如技术人员迭代、新功能发布以及系统整体架构的升级等，这是驱动系统软件进化的核心变更因子，也是最频繁的变更风险发生地。

在这里，我们先列举了一些比较常见的、因变更风险所引发的典型线上事故：

• 外部变更所引发的线上问题，某地的光缆被挖断导致整个服务有很大的影响。
• 代码变更典型问题，谷歌Gmail系统在发布新功能时产生的副作用而引发的功能上问题。
• 代码变更典型问题，Knight公司在升级一段很老的代码时引发的异常逻辑功能发生。
• 配置变更引发的问题，所引发的“薅羊毛”事件。
• 人员操作变更，研发误操作引发的整个核心数据删除；

可以看到，在实际的工作中，由变更所引发的风险，对业务的冲击非常大。结合美团亿级流量的到家业务形态看，系统变更引发风险可能性进一步放大，变更风险的“蝴蝶效应”更加凸显，某个单点问题都有可能给整个到家核心业务带来极大的影响。

• 第一，从到家业务接入方看，美团内部业务包括外卖、闪购、医药等等，外部有众多的企业客户。
• 第二，系统参与相关方较多，包括C端用户、商家、配送骑手及各个平台。
• 第三，业务基于微服务架构模式，各个业务间调用关系复杂，核心链路非常长。另外，业务强依赖配置，一旦某个环节发生变更问题，相关方都会受到影响。

所以对研发与测试来说，洞察与规避变更引入的质量风险变得至关重要。

那么，关于变更风险，质量建设核心做功点在哪里？我们对历史线上问题分析发现，系统内部变更引发故障的占比较高，且变更与代码变更有直接或间接关系。因此，我们开始围绕代码变更这个核心变更因子，构建了质量建设的做功点。

随后，我们思考了两个关键问题：

1. 代码变更风险是否可被可视化，提升测试和研发感知能力。
2. 围绕代码变更风险，是否能够构建一套质量保障防御体系。

通过分析发现，结合下图的代码特征树，我们就可以更好地感知代码变更的可视化能力。然后通过各叶子节点，将所有相关特征很好地识别，并且做对应的质量防御策略。

2 代码变更风险可视化（后羿）系统建设

传统测试模式存在两个典型问题：第一，对于研发开发的代码，缺少全面可视化分析能力；第二，对于代码变更所产生的影响范围有多大，实际上更多地依赖研发人员和QA的经验。所以，在这样的传统测试模式的典型问题情况下，我们希望从3个维度做质量保障建设方案：

• 第一阶段是代码变更的感知能力，重点解决对于不同的代码形态和不同的代码工程模式，如何能够最大范围地覆盖到所有的代码变更情况；
• 第二阶段重点做代码特征刻画，将所有变更代码抽离出不同的特征，打上作用标签；
• 第三阶段基于前两个建设能力，构建对应的应用场景生态圈，在不同测试流水线阶段，都能够将代码变更风险的刻画能力嵌入，不断做质量防御。

而代码变更风险的质量保障建设方案最终的落地形态，是打造一个代码可视化分析系统，在到家内部我们将其命名为后羿系统。顾名思义，我们希望该系统能像“后羿射日”一样，在质量风险评估和拦截层面能够做到更加精准，同时提升质量防御能力。该系统架构主要分为四层：

• 第一层是基础组件层。
• 第二层是代码分析层，重点解决对不同的代码形态都能够做到精准的代码变更分析和识别。
• 第三层做特征刻画层，核心解决整个代码的结构化标注和特征化标注。
• 第四层负责构建业务应用层，在不同的场景和环节下，将代码变更可视化能力嵌入到这个环节中，构建一个完备的质量风险拦截能力。

除此之外，我们也会引入智能化手段，赋能整个系统。同时，我们也将核心能力通过开放Open API方式，输出到其他的质量效率相关的工具平台上，赋能美团内部的其他工具平台。

总的来说，对于后羿可视化系统的关键流程，在应用层的透出是通过两个入口进行感知：一是后羿主站；二是工程交付平台。我们通过异步消息感知分析任务和源码下载，获取对应的变更文件、变更方法和变更行号；同时再借助字节码解析能力，解析对应的调用链路变更情况，存储到图数据库里；再对变更代码做特征打标和识别；最后会产生一份可视化分析报告，直接给到对应的QA使用。

当然，在整个建设过程中，我们也遇到了一些技术层面的挑战。

第一个挑战是代码分析技术。在系统建设初期，通过AST单分析能力做代码分析和识别，但存在Lambda表达式识别问题和Java泛型识别问题，在此基础上引入了ASM字节码分析技术解决了前面的问题，但ASM也会有自己的Java反射特性相关问题无法识别。所以我们希望未来引入动态化代码分析技术，来解决反射类问题。

第二个技术难点是海量关系数据存储问题。在建设之初，通过关系型数据库做存储，但随着系统的广泛应用，存储了大量调用链路拓扑关系数据，但它的查询性能非常差。所以在此基础上，我们通过探索引入图数据库的存储方式，解决了在海量数据关系存储数据的查询性能。

第三个技术难点是代码风险特征多样性，像个性化特征跟我们的业务有强相关性，比如资损特征、对应的分页特征和多线程特征。针对这种风险特征，我们之前的开发模式是系统开发者和业务QA深度沟通对应的识别策略，但这样的方式沟通效率和开发周期都比较长。

因此我们做了整体能力改进，通过开发一套组件化开发框架，将整个开发框架开放给各业务线QA，他们可以自己开发定制化开发组件，加载到后羿系统，完成多样性特征的快速识别能力。

3 代码变更风险可视化（后羿）系统实践

接下来，我们重点给大家介绍系统的实践应用落地情况。如下图所示，该图为后羿质量保障应用场景生态全景图。目前后羿系统整体建设了八个核心应用场景：

1. 技术方案层面校准诊断
2. 在Code Review阶段能力的增强
3. 变更影响面评估
4. 接口级的用例推荐
5. 配置变更风险诊断能力
6. 兼容性风险诊断能力
7. 代码特征风险预警
8. 开放Open API能力

首先技术方案缺失项诊断，在项目测试过程中，主要包含以下2个痛点：

1. 研发写技术方案时，标准化程度较低。
2. 中间反馈的问题对于技术方案更新时效性较差，但我们发现技术方案对QA来讲是一个关键性的依赖输入，从而导致QA在写测试用例时，往往会遗漏掉一些关键性的变更信息，比如接口定义变更缺失、配置项定义变更缺失、定时任务变更缺失、异步消息变更缺失以及DB表字段变更缺失，这些信息往往在技术方案里更新不全面。

基于这样的情况，后羿系统通过对代码的识别，能够真正拿到在本次代码层面上，真正变更了哪些信息，再拉取对应的技术方案做解析，再做关键变更信息项的Diff，从而生成一份技术方案的缺失项诊断报告给到对应的QA，QA可以根据此报告做对应的诊断项卡点拦截，同时做测试用例的完善补充。

第二个应用场景是增强版的Code Review评审新模式，传统的Code Review也面临几个痛点问题：

1. 研发在整个Review过程中更多地聚焦在编码规范和架构设计合理性上。
2. 常态化的Code Review模式基于纯文本，它也有几个痛点：第一是无法针对Review的过程做变更方法的上下游快速跳转查看；第二无法做到对变更方法、改动方法的跳转或调用链路的业务逻辑呈现。

基于这样痛点问题，后羿系统打造了基于变更链路场景驱动Code Review新模式，核心解决在Code Review阶段能够更早地感知质量风险。其核心做法是后羿系统在Review一个变更文件时，能够快速提炼出变更文件里对应的变更方法、变更变量以及这些变更方法和变量上都具备哪些风险特征，从而让QA和RD快速抓到变更的重点信息。

在此基础上，我们也提供了变更方法的上下游快速跳转能力，基于Review过程中做变更方法的快速跳转，理解整个业务的上下游关系，同时在跳转过程中，能够将跳转的逻辑点实时绘制成调用拓扑图，感知变更方法之间的业务逻辑关系，更好地从整个链路视角评估本次代码变更的影响情况，很好地解决在Code Review阶段的痛点问题。

第三个应用场景是变更影响范围评估，目前后羿系统构建了六大变更影响范围评估能力：

1. 代码基本属性，比如变更了哪些方法；
2. 能够支持到HTTP、RPC以及JAR包等不同形态代码工程类型；
3. 能够对通用风险特征做识别，比如事物递归兼容性问题；
4. 可以对定制化风险特征做识别，比如权限、算法特征；
5. 可以支持单服务影响，包括方法调用链路，接口特征、消息特征、任务特征等等；
6. 跨端服务的影响面评估，比如一个服务内部的调用链路和在不同的微服务之间的跨端变更点之间的链路影响是什么样子的，都能够做到更精准地影响范围评估能力。

影响面评估示例：

1. 一个变更接口被影响到了，那么它的下游到底是哪些变更方法影响的？我们能够很直观地看到这个变更接口下面有哪些新增的和变更方法所影响到的。
2. 下游所变更的影响方法之间的链路调用拓扑关系是什么样子？我们能够通过链路拓扑图，快速绘制出来对于这个接口下面所有变更方法之间的调用链路。
3. 对应的变更方法对于接口中间所有方法的调用链路详情，我们也能够通过这个能力快速做评估和刻画。
4. 对于一个接口下面所有方法的链路调用关系是什么样子？我们也提供了一个全方法链路的视图分析能力。

第四个应用场景是配置变更的风险诊断，在比较复杂的大型业务上，整个系统对配置往往有强依赖关系，比如典型的灰度配置、降级配置以及内部逻辑相关控制配置项，对于整个系统的影响比较大，但往往QA和研发人员对于配置风险的把控实际上比较缺失，认为代码可能更多的是质量保障的重点，所以由于配置所导致的线上问题比较多，造成的结果比较严重。

基于这样的核心痛点问题，后羿系统重点从三个层面做了关于配置变更风险的核心能力建设：

1. 在配置的变更识别分析层，我们能够很好地对各种类型配置做精准识别：是新增还是变更。
2. 通过后羿影响面评估能力，拿到配置所影响的接口、影响链路以及对应影响的异步消息和定时任务。
3. 有了影响面评估后，我们能够更好地通过测试，将变更场景做到覆盖，由此构建了配置变更测试覆盖度量。因为我们在配置测试过程中对于测试结果的感知能力不强，因此通过基于流量挖掘、流量录制能力构建了实时感知配置测试的覆盖情况。在整个流水线层面，通过关键配置变更卡点能力更好地防御配置变更所引发的一些问题。

下图是我们目前所建设的应用功能页面：

第五个应用场景是服务端兼容性的风险诊断。我们通过对线上问题做汇总分析发现，新老兼容性这类典型问题占比较高，我们尝试通过后羿系统解决，QA能够做简单的兼容性问题识别，比如一个接口的入参返回值有明显的字段新增或类型变化会明确判断出来。

但在兼容性问题分析上，有一类不太明显的变化导致了兼容性问题，比如入参层面有一些约束条件、由可选字段变成了必选字段，这类变化实际上在整个代码定义层面很难感知到；另外一类是变更参数是通过内部间接调用VO类直接组装出来的，实际上对于QA也很难感知内部间接VO类变化的兼容性风险影响。

所以后羿系统基于这样的痛点，构建了反射和序列化，从而快速拿到对应的底层变更VO类所导致的对接口影响能力，给出兼容性接口预警，QA根据这样的分析诊断报告，进一步评估对应的兼容性和上线顺序的合理性安排。

第六个是接口级自动化用例推荐，对于到家的复杂业务，我们沉淀的很多自动化用例怎么用，是全量回归还是选择性筛选，也是比较大的痛点问题。因此后羿系统基于所具备的识别变更方法、分析影响链路以及对应的接口能力，打通和到家智能代码覆盖率平台所具备的历史流量覆盖情况，能够快速拿到变更接口和方法，再借助一体化平台，拿到对应的自动化用例，做精准的自动化用例推荐，从而构建了用例推荐整体解决方案。

第七个典型的应用场景是代码质量风险特征预警，我们在质量建设过程中，往往会遇到一类比较特殊的场景需要验证，比如资损类场景，除了验证功能外，还需要对资损做个性化风险功能场景验证、异常场景验证、特殊分页逻辑、重试场景验证，但这些场景在整个代码过程中，我们往往很难发现这些特征风险，从而忘记验证特殊场景情况。

针对这个问题，后羿系统从两个方面构建了特征风险识别功能：一是系统会自己构建通用风险特征识别策略模型，二是各业务方也会自己打造对应的风险特征识别策略。

如下图所示（最下侧），是目前已经具备和未来将要建设的特征识别能力。有了核心识别能力后，我们再将对应的特征在所要验证过程中相应上下游的依赖平台做工具能力整合，对于不同特征构建出相对应具体测试策略的推荐策略，将这几个能力打通后构建出一套基于代码质量风险特征的体系化质量保障方案。

第八个应用场景的能力是开放Open API的赋能能力，我们希望将后羿系统分析识别的信息，通过开放API的方式透露出去，能够给到对应相关工具平台使用。目前在到家范围内已经将整个能力开放给了接口管理平台、智能代码覆盖率平台、全息系统、异常测试平台、自主工程交付系统以及一体化自动化平台这六个核心的效能工具建设平台。

4 未来规划与展望

结合具体的实践，以及此前总结的经验。未来，我们将从四个方向做未来质量保障建设：

1. 代码分析技术的增强，希望能够通过动态链路分析技术，提升整体的分析准确性。
2. 风险特征识别技术，希望能够基于大语言模型相应能力对风险特征的分析和对应测试策略做推荐。
3. 进一步丰富应用场景生态圈，探索在不同测试环节、不同测试场景下，将后羿能力做更好的整合，赋能到具体的业务质量建设中。
4. 长期来讲，希望将系统的核心能力，通过开源共享方式赋能给相关测试领域。

5 Q & A

Q1：单次分析报告耗时是多久？同一个工程代码的报告间是独立的还是有关联的？

A：目前1-2min可产生分析报告。报告是基于迭代任务维度生成的服务级报告，比如一个项目迭代里有5个工程代码变更，那么这5个工程代码变更关系会作为一个整体分析，体现到报告里。

Q2：链路的拓扑关系是怎么实现的？

A：链路的拓扑关系基于AST技术和ASM技术进行分析，同时，结合线上Mtrace链路关系作为补充。

Q3：微服务多模块之间的服务调用链路可识别出关联性吗？如HTTP接口后续调用多RPC服务接口?

A：微服务多模块之间的服务调用链路可识别出关联性，比如HTTP的下游会调用了哪些RPC接口，目前具备可识别能力。

Q4：底层方法的调用链非常多，这种有推荐策略吗？DB变更是扫描Mapper吗？

A：目前对于调用链路会进行风险特征打标处理，比如：链路包含资损特征、配置特征等，通过特征风险标签能够更好的让用户感知到链路风险等级，为后续测试策略提供关键信息推荐。目前DB变更是通过扫描Mapper进行识别的，基于Mybatis整体DB开发框架做变更扫描。

Q5：关于用例推荐，是推荐单例接口还是会组合成场景接口？

A：目前是推荐单接口用例，比如这个变更接口关联了10个自动化用例，我们会把这10个自动化用例推荐出来。

Q6：分析一个工程大概会花费多长时间？

A：目前要花费1-2min时间。

Q7：实际应用中，主要收益是什么？

A：主要收益是基于八大应用场景落地应用，所有应用场景都会给质量与效率带来价值收益，比如在兼容性问题上已成功拦截多起兼容性质量问题；在配置变更风险评估上， 已成功拦截多起因配置默认值编码错误、线上线下配置不一致问题。

Q8：这套平台是否会对线上服务可用性带来影响？

A：目前这个平台对于线上服务可用性不会造成影响，针对线上环境进行分析时，核心操作是拉取线上对应的部署JAR包，不会对现实服务造成可用性影响。

Q9：这个系统有护城河吗？这个系统收益是什么？对业务有什么帮助吗？在业务上有什么体现吗？

A：说到“护城河”，变更分析底层技术上主要还是基于AST和ASM通用技术，核心是对各种业务代码编写方式的兼容支持、业务场景特征识别精度等维度上有一定的技术挑战。

主要收益集中在变更带来的业务影响范围的风险评估及对质量风险的有效拦截上，目前已成功拦截多起接口影响范围评估不准的Bug、配置变更相关Bug、兼容性Bug等。

在业务帮助上，一是八大应用场景能够给整个质量和效率带来提升；二是可提升对业务理解的效率，比如通过接口下游调用链路可视化能力，可很快理解这个业务链路关系。

Q10：链路拓扑过大，怎么解决，不同服务使用语言不同，字节码技术有啥推荐吗？

A：链路拓扑过大时，可通过链路聚合来归类提升可视化，针对美团是Java技术栈，重点在突破Java识别能力，其他语言服务分析后续会持续关注与解决。

Q11：可以分析出对上下游服务的影响吗？

A：是的。

Q12：分析代码变更，如何识别有效变更和无效变更？

A：比如变更了一段代码，它有可能没有调用方，我们叫做预埋类代码。类似这种代码在测试过程中很难用业务场景进行验证，而且未来上线后很可能会引入潜在风险，目前通过链路变更分析可有效识别此类预埋代码风险。

Q13：系统使用的阶段都是什么？准入阶段还是准出阶段？

A：目前系统在准入和准出阶段都可以使用，没有做严格限制。

Q14：识别出的问题噪音干扰多吗？

A：从噪音干扰层面讲，我们做了很多提升识别率的策略优化，比如HTTP/RPC接口识别率目前已达到98%以上，噪音干扰可做到很好的控制。

6 本文作者

桂来，来自美团到家研发平台。

| 在美团公众号菜单栏对话框回复【2022年货】、【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至[e-mail]申请授权。