fiy

去年我带一个 40 人的研发团队做发布管理制度重构时，发现一个反常识的现象：把发布审批从 5 级砍到 2 级之后，发布事故率没有上升，反而从月均 3.2 次降到了 1.1 次。这件…

发布检查真正失效，往往不是因为团队没有清单，而是因为清单没有改变任何人的决策：测试报告里有未关闭的高风险缺陷，发布群里却仍在问“今晚能不能上”；业务负责人没有确认回退条件，项目经理…

去年冬天，我陪一家六百多人的研发组织做发布复盘。事故本身很小：一个配置项在灰度环境是对的，在全量环境是错的，导致约 7% 的用户在 23 分钟内无法提交表单。但会议室里吵了四十分钟…

去年双十一前，我所在的团队对一个订单履约服务做了第七轮灰度。前六轮都很“顺利”：5% 流量、15% 流量、30% 流量，错误率曲线平得像一条直线。第七轮放开到 60% 的第九分钟，…

发布管理效率低，通常不是因为团队不够努力，而是因为所有发布都被当成同一种事情处理：小功能要走大版本审批，紧急修复没有独立通道，发布完成后又没有统一验证和复盘。围绕《上线实操方法：项…

2023 年，我曾接手一个 60 人研发团队的发布管理诊断：一年 214 次生产发布，其中 37 次没有任何发布记录，11 次发布后无法在 30 分钟内定位到“改了什么、谁改的、能…

回滚怎么做？项目经理制度设计：发布管理从0到1 去年双十一前一周，我陪一家做 B 端 SaaS 的客户做发布演练。他们的发布流程文档写得很漂亮：Jenkins 流水线、灰度发布、蓝…

发布管理发布全流程：项目经理制度设计与一文讲清 发布当天最让项目经理被动的，往往不是代码出了问题，而是直到临近上线才发现：测试版本和生产版本不一致、业务负责人没有确认、回滚方案没人…

发布审批真正拖慢项目的，通常不是审批人太多，而是审批发生在错误的时间、依据不足、责任边界模糊。我的经验是：同一个团队把“所有发布都走同一套审批”改成“按风险分级、按证据放行、按版本…

2024 年我接手过一个 SaaS 团队的发布复盘：过去 12 个月，该团队共发起 137 次生产发布，其中 23 次触发了事后回滚或紧急修复，比例高达 16.8%。更扎心的是，复…