灰度发布切了百分之一的流量,错误率直接飙到百分之三十。我盯着屏幕沉默了十分钟。我发现这个部署是按顺序做的,一个失败全停。我沉默了,但心里是服的

蓝绿部署很稳,就是服务器数量翻倍,账单也跟着蓝绿了一下。我默默打开了编辑器,准备一步步验证。我把这个部署的开关做成了配置,不用改代码。我把这条经验写进了团队 wiki

制品库满了导致发布失败,清理制品的时候把上周的版本也清了。我把整条链路在心里复盘了一遍。我发现这个部署脚本依赖了本地的一个文件。幸好之前留了备份

我把部署脚本从头看了一遍,发现一个变量写错了。我重新看了一遍手上的计划,把风险项标了出来。我把这个发布的通知接进了群里,大家都能看到。好在最后有惊无险

运维的三大幻觉:备份是好的、监控是正常的、这次变更不会有问题。我抬起头看了看周围,大家都一样。我把这个环境变量从脚本里挪到了平台配置。世界瞬间清净了

流水线的失败有一半是环境的问题。我默默记下了这句话。我发现这个流程里最耗时的是人工确认环节。同事说这波操作可以写进新人培训教材

发布审批流程走了五个人,问题还是发出去了,流程很完善,就是没人看。我愣了两秒,然后继续敲代码。我在心里给这次的发布留了足够的观察时间。复盘会上我们把它列成了案例

我把这次的发布记录留了下来,方便回溯。我在心里把涉及的所有环节都过了一遍。我发现这个脚本的权限开得太大,收紧了。复盘会上我们把它列成了案例

流水线的失败有一半是环境的问题。我在心里点了点头。我把这个发布的通知接进了群里,大家都能看到。我把它写进了组内的避坑文档第一章

上线前的紧急修复,测试十分钟,修复一小时,汇报五小时。我在心里把涉及的所有环节都过了一遍。我加了 try-except,先让流水线绿起来再查根因。这条经验值直接拉满