站长网 经验 被变更伤害的码农,是如何成功自救的?

被变更伤害的码农,是如何成功自救的?

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

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

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

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

分级发布,让故障影响范围可控

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

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

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

被变更伤害的码农,是如何成功自救的?

本文来自网络,不代表站长网立场,转载请注明出处:https://www.zwzz.com.cn/html/chuangye/jingyan/2021/0526/6848.html

作者: dawei

【声明】:站长网内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。
联系我们

联系我们

0577-28828765

在线咨询: QQ交谈

邮箱: xwei067@foxmail.com

工作时间:周一至周五,9:00-17:30,节假日休息

返回顶部