被变更逼疯的码农，是如何成功自救的？(2)

鉴于人工规则检查存在阈值选择、更新困难的问题，迫切需要有更智能的检查方法。我们对一些引入故障的变更进行分析发现，大部分的故障会导致指标突变，运维工程师往往对发生突变的指标格外关注。同时，我们也发现，在变更场景下，指标突变不一定代表变更引入了故障。

比如，当在流量上涨期间进行变更发布时，流量相关的指标必然会发生突增。再比如，在变更发布过程中伴随着进程重启，像内存、文件句柄等指标可能会因为资源释放而发生突降。因此，智能检查算法由两部分组成：度量指标是否发生突变、对突变是否合理进行判断。若指标在变更发布前后发生了无法解释的突变，则认为指标异常。

指标突变是否合理可以从以下两个角度进行解释：突变是否由时间因素、重启导致。由于时间因素的影响会同时施加在应用变更的机器（实验组）和未应用变更的机器（对照组），可以根据对照组来排除时间因素的影响；进程重启对指标的影响可以通过历史变更来建模。当对照组与历史变更均无法解释指标突变时，则认为指标异常，需要中止变更。智能检查无需人工配置参数，可以自动、智能地识别异常突变的指标。

图4给出了一个具体的例子，每一行代表一个指标，对于每个指标都展示了在某次变更发布前后的波动情况、对照组在对应时间的波动情况以及指标在历史一次正常的变更发布前后的波动情况。

对于指标①，指标在本次变更发布后出现了上涨，但是对照组也出现了类似程度的上涨，因此判断上涨是由时间因素导致，指标变化正常；对于指标②，变更发布后指标出现突降，历史正常变更发布后指标都会发生突降，因此判断突降是由进程重启导致的，指标变化正常；对于指标③，变更发布后发生了突增，而对照组跟历史变更发布后均未发生明显变化，即指标突变无法被对照组、历史变更解释，指标异常，需要中止甚至回滚变更。

以上就是我们使变更发布更加安全高效的方法，智能检查算法是减少故障损失的核心。算法基于历史变更和对照组进行，不需要人工配置参数，具有普适性。希望能够对大家有所帮助，如有任何想法和疑问，欢迎一起交流。

【编辑推荐】

1. 传统数据库不适合现代企业架构了？
2. 炒作还是赌未来？量子技术深陷淘金狂潮
3. 多云架构落地设计和实施方案
4. 程序员未来干什么？做架构还是做管理？
5. 解码技术社区：Github区块链代码库超5万 这个最受关注

（编辑：ASP站长网）