项目管理

三年前的一个周五傍晚，我参与的一次发布把回滚拖成了四个小时四十七分钟。问题本身并不复杂，一个新上线的计价规则把部分订单的折扣算重了。真正让事情失控的是：没人能确认数据库里那条新增的…

一次发布事故往往不是由某个程序员“漏改了一行代码”单独造成的，而是因为项目组把“代码已经合并”误当成“可以上线”：数据库变更没有回退路径，业务验收只验证了主流程，值班人员不知道谁有…

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

我见过最长的上线计划有47页，包含312个任务项，精确到每15分钟一个检查点。这份计划在上线当晚的第4个小时就彻底失效了，不是因为团队不努力，而是一个没人预料到的第三方支付回调超时…

发布管理发布审批全流程：项目经理最佳实践与一文讲清 发布审批最容易出问题的时刻，往往不是审批人漏点了一个按钮，而是团队把“批准上线”误当成“确认已经准备好”。我建议项目经理把发布审…

2023年我在一家中型软件公司复盘发布事故时发现一个反常识的数据：全年11次P1级生产事故里，有8次的“二次伤害”不是故障本身造成的，而是故障发生后30分钟内没有执行回滚，团队在现…

去年第四季度，我帮一家 600 人规模的 SaaS 公司复盘发布流程。他们的发布审批单做得相当"规范"：12 个字段、5 级审批、9 个必须勾选的检查项。但当我…

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

发布管理真正难的地方，不是把版本号从 V1.3 改成 V1.4，也不是在系统里点击一次“发布”。我在中大型研发团队做版本治理时，见过最典型的事故：功能代码已经通过测试，发布窗口也提…

发布记录做得很长，不等于发布管理做得可靠。一个常见场景是：项目群里已经通知“版本已上线”，但客服不知道哪些用户受影响，运维找不到对应变更单，项目经理也说不清某个缺陷究竟进入了哪个版…