被变更伤害的码农，是如何成功挽回的？

作为一个合格的码农，我们每时每刻都在为开发新功能、修复Bug、提升系统性能挥洒汗水。变更发布是产品迭代的必经之路，但是变化总伴随着风险，互联网公司轰动一时发生的大故障，往往跟变更有关。一半以上的故障是由变更引入的，毫无疑问，减少变更引入的故障能够显著提升服务的稳定性。

减少变更引入故障的基本方法是规范开发流程、提升开发质量、加强QA测试环节，从而避免将有问题的版本发布到线上，防患于未然。但是，由于线上环境与测试环境往往存在差异，一些变更在测试环境中工作正常，但是在线上环境会暴露出故障。这些变更成为了薛定谔的猫，只有在上线后才能揭晓是否存在故障。

因此，在发布过程中对服务健康情况进行跟踪检查、及早发现变更引入的故障成为发布过程不可或缺的环节，这样才能避免系统卷入重大故障的血案中。本文将介绍百度是如何对变更发布进行分级、检查来控制变更故障影响范围的。

在百度，我们采用分级发布机制来发布变更到线上环境。分级发布将变更发布过程拆分成多个阶段，每个阶段只将变更应用到部分机器上，并在相邻的两个阶段之间对服务的健康情况进行检查。如果发现服务的健康度显著下降，则可以中止甚至回滚变更。在这个过程当中，大部分故障都能够在最后一个阶段之前被发现，因此故障通常只影响已经应用了变更的部分机器，从而有效地控制了故障的影响范围。

分级发布拆分的阶段越多，越能够在变更全面应用之前发现问题。但是，阶段的数量也并非越多越好，因为每个阶段都需要花费一定的时间来应用变更和检查健康度，阶段的数量大必然导致发布的时间变长，从而降低发布的效率。图1给出了百度内部分级发布的最佳实践方案。

方案包含5个阶段，依次为沙盒环境、单机房少量机器、单机房全量机器、其他所有机房少量机器、以及其他所有机房全量机器。这种划分方法平衡了故障风险和变更发布效率，在每个阶段制定了对应的故障止损预案，在实践中取得了很好的效果。

（编辑：ASP站长网）