蓝盟IT小贴士,来喽!
作为合格的代码生产者,我们时刻都在努力开发新功能,更正错误并提高系统性能。变更的发布是产品迭代的唯一形式,但是变更总是伴随着风险。互联网公司通常是灾难性的,并且经常引起变化。超过一半的故障是由更改引起的。毫无疑问,减少更改带来的故障可以显着提高服务的稳定性。
减少变更和引入失败的基本方法是标准化开发流程,提高开发质量和加强质量控制测试,防止有问题的版本在线发布并避免问题发生。但是,由于在线环境和测试环境通常不同,因此某些更改在测试环境中效果很好,但是在线环境会暴露故障。这些变化成为Schrödinger的猫,只有在连接后才能发现是否有故障。
因此,至关重要的是在启动过程中监视服务的状态并及早发现由更改引起的故障,这可以防止在发生重大故障的情况下涉及系统。本文将介绍百度如何评估和验证交换版本以控制交换故障影响的范围。
在百度,我们使用分层启动机制将更改发布到在线环境中。分层版本将更改的发布过程分为几个阶段,每个阶段仅将更改应用于机器的一部分,并验证两个相邻阶段之间的服务状态。如果发现服务的运行状况显着下降,则可以取消甚至撤消更改。在此过程中,大多数故障可以在最后阶段之前发现,因此故障通常仅影响已应用更改的某些计算机,从而有效地控制了故障的程度。
版本的层次划分的阶段越多,在完全实施更改之前,它就可以检测到更多的问题。但是,阶段数不是尽可能多,因为每个阶段都需要一定的时间来应用更改并验证状态。大量的阶段将不可避免地导致更长的发布时间,这将降低发布效率。图1显示了百度内部分层发布的最佳实践。