在大型Web服务如搜索引擎、社交网络中，运维人员需要频繁地部署软件变更以引入新的特征，解决之前软件版本的程序错误，或提高服务性能。软件变更包括软件升级和配置变更。但是，并非每一次的软件变更都能够达到预期的效果。相反，一些软件变更在部署之后，出现了服务性能下降的情况，进而影响用户体验，甚至导致服务收入下降。国际大型互联网公司均出现过由软件变更导致Web服务受损甚至中断的事例：

Case 1: 2012年10月，Google的一次负载均衡软件升级失败，导致全球Gmail业务受损，且持续时间长达18分钟。

Case 2: 2014年2月，Dropbox对服务器操作系统的例行升级中存在bug，导致Dropbox服务中断了3个小时。

Case 3: 2014年6月，Facebook的一次软件系统的配置变更失误，引起Facebook服务中断31分钟。

Case 4: 2014年11月，Microsoft Azure的一次软件升级导致Azure Storage的服务受损。

… …

因此，在软件变更发生后，快速、准确地评估软件变更的影响，是Web服务运维中亟待解决的重要课题。

通常情况下，运维人员会通过灰度发布的方式部署软件变更。在灰度发布方式下，运维人员首先将软件部署在一个服务器子集上，并持续观察KPI曲线，以确定软件变更的影响。如果该服务器子集上的KPI表现与预期相同，则进一步将软件变更部署到全部服务器上，否则回滚此次软件变更。下图展示的是一次软件变更后发生KPI曲线陡降的例子。由于软件变更关联的KPI曲线数量巨大、类型多样、KPI曲线剧变原因复杂，传统的人工检测和判断KPI曲线剧变以评估软件变更影响的方式，存在易出错、不易扩展、消耗大量人力物力资源的缺点。

因此，我们课题组致力于提出一种自动化地评估软件变更影响的机制。但是，自动化的软件变更影响评估机制，存在如下挑战：

• 同时满足低检测时延和高准确性要求。检测时延指的是一条KPI曲线发生剧变的时间与该剧变被检测到的时间的时间差。由于错误的软件变更会导致用户体验下降和/或收入下降，因此软件变更影响评估机制对KPI曲线剧变的检测时延必须要尽可能短。而较低的检测时延往往导致检测KPI曲线剧变的准确性下降。因此，同时满足低检测时延和高准确性要求，对于自动化的软件变更影响评估是一个巨大的挑战。

• KPI数量巨大。一次软件变更往往关联了数百个甚至数万个Web服务和服务器的KPI曲线。由于在任一KPI曲线上都有可能检测到软件变更的影响，因此，需要检测软件变更关联的所有KPI曲线是否发生剧变，以评估软件变更的影响。同时，在大型互联网公司中，每天会部署大量的软件变更。例如，在我们课题组研究的互联网公司中，每天发生几千次软件变更。这就导致自动化的软件变更影响评估机制需要同时检测百万级的KPI曲线。

• KPI类型多样。KPI曲线的种类非常多，它们的表现形式也是不一样的。如下图所示，有的KPI曲线非常稳定，有的KPI曲线是多变的，有的KPI曲线存在周期性。这就要求自动化的软件变更影响评估机制对各种类型的KPI曲线具有良好的鲁棒性。

  

• KPI曲线剧变可能由其他因素导致。除了软件变更，其他因素包括周期性、网络硬件故障、恶意攻击等也可能导致KPI曲线的剧变。因此，自动化的软件变更影响评估机制需要排除掉由其他因素导致的KPI剧变。

针对上述挑战，我们课题组提出了一种自动化的软件变更影响评估机制——FUNNEL。FUNNEL能够在软件变更发生之后快速、准确地检测大量KPI曲线中的行为变化，并且准确地确定这些行为变化是否由此次软件变更导致。下图是FUNNEL的设计框架。

FUNNEL主要分为三部分：

1. 确定影响集合:  由于运维人员会基于服务层次来命名服务，所以FUNNEL可以自动化地确定影响集合。影响集合指的是可能受影响的服务器、实例和服务的集合。

2. 检测性能变化：FUNNEL使用一种基于奇异谱变换的性能变化检测方法，以准确快速地检测KPI曲线剧变。

3. 排除其他因素导致的KPI曲线剧变：FUNNEL使用分流测试的思想确定这些KPI曲线剧变是否由软件变更导致。

   
   

确定影响集合

不同软件变更的影响范围是不同的。一些软件变更的影响是局部的，而另一些软件变更的影响是全局的。例如，广告服务中的软件升级可能对几乎所有的Web服务产生影响。如果错误的判断影响范围，可能会导致Web服务性能下降后检测时延增大，并产生误报警。

如下图所示，假设广告服务的模块A出现了软件变更。则第一步是从众多的KPI中确定影响集合。广告服务中的模块A被部署在n个服务器上，即服务器1到服务器n，每一个服务器运行了一个进程来部署模块A，即进程1到进程n。另外，模块A与团购服务的模块B和模块C，以及搜索引擎服务的模块D关联。具体的关联关系如下图所示。FUNNEL中将A称为变更服务，B、C、D为关联服务。对于部署在 ( A1， A2， …， Am ) 上的特定的软件变更，( A1， A2， …， Am ) 是测试实例，Am+1， …， An 是对照实例。对照实例是在尚未部署软件变更的服务器上运行的服务 A 的实例。影响集合包括测试实例、变更服务和关联服务。

当软件变更被部署在服务器1到服务器l上具体的软件变更影响集合包括下面几部分：

• 变更服务：模块A。

• 关联服务：模块B、模块C、模块D。

• 测试实例：服务器1到服务器l以及进程1到进程l。

下图展示的是KPI曲线实际的选择过程，从大量的KPI曲线（左侧）中挑选出了8个与实际软件变更相关的KPI曲线（右侧）。

检测性能变化

FUNNEL提出了一种快速、准确的检测 KPI 曲线剧变的方法。对于给定的KPI曲线，能够准确地确定 KPI 曲线剧变是否由软件变更导致的。这一方法所取得的效果，远超那些传统的在变更前后比较平均值、中位数、分布等的方法。

在其它研究领域的性能变化检测中， SST 已被证明是准确和快速的。SST 将训练数据映射到正常子空间中，并找出正常子空间和需要测试的数据之间的差异。SST 的核心思想是发现时刻t 的数据点 x(i) 的前后变化。然而，在正常子空间出现噪声时，SST 时具有较低的准确性， 另外SST 具有较高的计算开销。

为了减轻由突发性流量等原因导致的噪声(例如尖峰)对最终变化得分的影响，FUNNEL通过使用前置矩阵更多信息的方法，提高了SST的鲁棒性。为了提高SST算法的计算效率，FUNNEL使用矩阵压缩和隐式内积计算的方法，降低了SST算法的计算复杂度。这样，改进的SST算法具有检测时延低、计算效率高、鲁棒性高的优点，解决了同时满足低检测时延和高准确性要求、KPI数量巨大、KPI类型多样三个挑战。

如下图所示，FUNNEL从第一步获得的KPI影响集合中发现了4个在软件变更附近发生了剧变的KPI。

排除其他因素导致的KPI曲线剧变

针对两种不同的场景，FUNNEL采用了不同的方式排除其他因素导致的KPI曲线剧变:

• 针对灰度发布中非关联服务的场景

• FUNNEL采用分流测试的思想，对比测试组和对照组。这一对比的原理是，除了软件变更以外的其他因素既会影响测试组，也会影响对照组。测试服务器的KPI曲线构成测试组，而对照服务器的KPI曲线构成对照组。

• FUNNEL使用DiD方法来确定KPI剧变是否由软件变更导致。DiD用以评估在特定时间点实施的干预措施的效果。具体的，DiD 比较测试组与对照组随时间的变化，并将差异归因于软件变更的影响。DiD 基于以下假设:在没有软件变更的情况下，测试组 KPI 曲线的平均测量值与对照组 KPI 曲线的平均测量值之间的差异不会随时间的变化而变化。

• 针对关联服务和非灰度发布的场景

• 因为关联服务中没有对照服务器或对照实例，所以对照组为空。此外，如果运维人员一次性在所有服务器上部署软件变更，而不是以灰度发布的方式部署软件变更，此时对照组也为空。

• 在本场景中，测试组由软件变更前后的 KPI 曲线测量值构成，而对照组由 KPI 曲线的历史测量值构成。如果 Web 服务或服务器的性能变化是由周期性导致的，那么对照组和测试组之间应该没有相对的性能变化。

排除掉由其他因素导致的KPI曲线剧变之后，FUNNEL获得了所有的由软件变更导致的KPI曲线剧变，并发送给运维人员。运维人员据此作出决定，是否应该回滚此次软件变更。

我们回到广告服务的模块软件变更的案例，刚刚第二步获得了4个剧变的KPI曲线，其中第一个和第四个KPI剧变是由周期性导致的，所以将他们过滤掉，最终得到的是由软件变更引起的KPI剧变，即下图第三步得到的两条KPI曲线。

最后，FUNNEL将由软件变更引起的KPI曲线剧变的曲线发送给运维人员，由运维人员来决定是否回滚软件变更。值得注意的是，发现由软件变更导致的KPI曲线剧变后，FUNNEL并没有自动地回滚软件版本。这是因为，回滚软件变更这一操作是有风险的 ，一旦出现误判，损失极大。

本文介绍了一种新型的机制——FUNNEL，用于快速、准确地评估大型Web服务中软件变更的影响。对于每个软件变更，FUNNEL 分析可能受影响的所有服务、进程和服务器，并自动构建影响集合，然后快速、准确地检测影响集合中的 KPI剧变。随后，FUNNEL 使用 DiD 方法确定由软件变更引起的性能变化。

由于长度限制，本文没有介绍FUNNEL的算法细节，特此附上论文链接 FUNNEL。