稳定性建设 -美团代码变更风险可视化系统建设与实践
变更是软件系统进化的推动力，同时也是孕育风险的温床。如果一个系统没有了相应的迭代和变更，那这个系统就会逐渐失去了活性和价值。不过，随着系统进行了变更迭代，软件风险也会慢慢衍生，而规避变更引发的软件风险在质量保障领域是一个较大的挑战。通过对下面典型软件系统架构图分析，我们可提炼出3大类变更维度：
- 基础设施变更：主要包括基础硬件变更、运营商网络变更、云服务容器变更、开发语言变更、操作系统变更以及机房集群的变更，这些基础设施迭代极大提升了系统底层的服务能力，一旦变更引发系统风险，其影响面通常也比较大。
- 系统外部变更：比如用户流量突增、用户需求变化以及相关三方服务及三方组件变更，这些帮助系统不断衍生出新的迭代能力，同时也增加了系统稳定性风险的发生。
- 系统内部变更：比如技术人员迭代、新功能发布以及系统整体架构的升级等，这是驱动系统软件进化的核心变更因子，也是最频繁的变更风险发生地。
在这里，我们先列举了一些比较常见的、因变更风险所引发的典型线上事故：
- 外部变更所引发的线上问题，某地的光缆被挖断导致整个服务有很大的影响。
- 代码变更典型问题，谷歌Gmail系统在发布新功能时产生的副作用而引发的功能上问题。
- 代码变更典型问题，Knight公司在升级一段很老的代码时引发的异常逻辑功能发生。
- 配置变更引发的问题，所引发的“薅羊毛”事件。
- 人员操作变更，研发误操作引发的整个核心数据删除；
可以看到，在实际的工作中，由变更所引发的风险，对业务的冲击非常大。结合美团亿级流量的到家业务形态看，系统变更引发风险可能性进一步放大，变更风险的“蝴蝶效应”更加凸显，某个单点问题都有可能给整个到家核心业务带来极大的影响。
- 第一，从到家业务接入方看，美团内部业务包括外卖、闪购、医药等等，外部有众多的企业客户。
- 第二，系统参与相关方较多，包括C端用户、商家、配送骑手及各个平台。
- 第三，业务基于微服务架构模式，各个业务间调用关系复杂，核心链路非常长。另外，业务强依赖配置，一旦某个环节发生变更问题，相关方都会受到影响。
所以对研发与测试来说，洞察与规避变更引入的质量风险变得至关重要
那么，关于变更风险，质量建设核心做功点在哪里？我们对历史线上问题分析发现，系统内部变更引发故障的占比较高，且变更与代码变更有直接或间接关系。因此，我们开始围绕代码变更这个核心变更因子，构建了质量建设的做功点。
随后，我们思考了两个关键问题：
- 代码变更风险是否可被可视化，提升测试和研发感知能力。
- 围绕代码变更风险，是否能够构建一套质量保障防御体系。
通过分析发现，结合下图的代码特征树，我们就可以更好地感知代码变更的可视化能力。然后通过各叶子节点，将所有相关特征很好地识别，并且做对应的质量防御策略。
