发布检查

去年 11 月，我帮一家做 SaaS 的客户复盘一次线上故障。故障本身不复杂：一次数据库字段类型变更，导致对账任务在凌晨批量失败，第二天早上 9 点财务发现数据对不上。真正让我意外…

凌晨两点，一次本该十分钟完成的版本上线，因为数据库迁移脚本与线上索引冲突，耗时四十多分钟才回滚。事后复盘时，团队发现发布清单里有“数据库变更已评审”一项，却没有人确认评审的是哪个版…

晚上十点，发布前夜的评审会上，40 多项检查清单一页页过下来，全部打勾。两小时后发布出问题：一个环境配置没有更新，回滚预案没人能说清楚。检查表是齐全的，签字是完整的，结果却是错的。…

发布检查落地方案真正难的地方，不是把检查项从 20 条扩充到 80 条，而是让每一次发布都能回答四个问题：谁负责、凭什么通过、什么情况必须停、出了问题如何恢复。我在一个 126 人…

发布当天最危险的信号，往往不是“还有几个缺陷”，而是所有团队都说“应该没问题”，却没人能指出谁验证了回滚、谁确认了数据迁移、谁有权叫停上线。发布检查管理的核心不是把清单做长，而是把…

发布检查实操方法的关键，不是把检查项从 20 条增加到 80 条，而是让团队在正确的时间，由正确的人，拿着可验证的证据做出“继续发布、延期发布或回滚”的决定。我在参与多个中大型研发…

去年11月，我在一家做SaaS的客户那里旁听他们的发布评审会。47项检查项全部飘绿，会议开了11分钟，主持的项目经理说“那今晚9点发”。9点40分，核心下单链路的5xx率从0.3%…

发布检查落地方案最容易失效的地方，不是检查项不够多，而是每个人都以为“别人已经确认过了”。在一次典型的中大型企业版本发布复盘中，功能代码已经合并、测试报告也已通过，但上线前仍发现权…

发布检查不是在上线前把一张清单逐项勾完，而是要在有限时间内回答三个问题：这次发布到底改变了什么、哪些证据足以证明它可以上线、如果判断错误能否在可接受时间内恢复。很多团队的发布事故并…

去年11月的一个周五，17点42分，一个二十多人的研发团队完成了一次“完美”发布：发布检查单上47项全部打勾，审批流在系统里走了三级签字，发布在预定窗口内结束。19点10分，客服群…