作为一个合格的码农,我们每时每刻都在为开发新功能、修复Bug、提升系统性能挥洒汗水。变更发布是产品迭代的必经之路,但是变化总伴随着风险,互联网公司轰动一时发生的大故障,往往跟变更有关。一半以上的故障是由变更引入的,毫无疑问,减少变更引入的故障能够显著提升服务的稳定性。
减少变更引入故障的基本方法是规范开发流程、提升开发质量、加强QA测试环节,从而避免将有问题的版本发布到线上,防患于未然。但是,由于线上环境与测试环境往往存在差异,一些变更在测试环境中工作正常,但是在线上环境会暴露出故障。这些变更成为了薛定谔的猫,只有在上线后才能揭晓是否存在故障。
因此,在发布过程中对服务健康情况进行跟踪检查、及早发现变更引入的故障成为发布过程不可或缺的环节,这样才能避免系统卷入重大故障的血案中。本文将介绍百度是如何对变更发布进行分级、检查来控制变更故障影响范围的。
分级发布,让故障影响范围可控
在百度,我们采用分级发布机制来发布变更到线上环境。分级发布将变更发布过程拆分成多个阶段,每个阶段只将变更应用到部分机器上,并在相邻的两个阶段之间对服务的健康情况进行检查。如果发现服务的健康度显著下降,则可以中止甚至回滚变更。在这个过程当中,大部分故障都能够在最后一个阶段之前被发现,因此故障通常只影响已经应用了变更的部分机器,从而有效地控制了故障的影响范围。
分级发布拆分的阶段越多,越能够在变更全面应用之前发现问题。但是,阶段的数量也并非越多越好,因为每个阶段都需要花费一定的时间来应用变更和检查健康度,阶段的数量大必然导致发布的时间变长,从而降低发布的效率。图1给出了百度内部分级发布的最佳实践方案。
方案包含5个阶段,依次为沙盒环境、单机房少量机器、单机房全量机器、其他所有机房少量机器、以及其他所有机房全量机器。这种划分方法平衡了故障风险和变更发布效率,在每个阶段制定了对应的故障止损预案,在实践中取得了很好的效果。