# 一次发布引发生产故障：变更止血、回滚决策与复盘模板
发布后错误率升高时，团队最容易陷入“继续观察还是回滚”的争论。生产处置的目标不是立即解释根因，而是用最短时间恢复服务并保留证据。
## 一、识别变更相关性
把告警时间与应用发布、配置修改、数据库 DDL、网络策略、证书、依赖升级对应起来。检查错误率、延迟、流量、资源、日志和调用链是否从同一时间点发生变化。
如果变更时间高度吻合，应先按变更故障处理，不要因为少量实例正常就排除发布影响。
## 二、建立现场指挥
指定一名事故指挥统一决策；一人负责操作，一人负责记录时间线，其他人按应用、数据库、网络、平台分工。所有变更通过同一频道报备，避免多人同时修改。
## 三、五分钟止血清单
1. 暂停流水线、自动发布和配置同步。
2. 停止继续放量，保存当前版本、配置和指标截图。
3. 对比新旧版本错误率和 P99 延迟。
4. 若旧版本健康，立即回滚或把流量切回旧版本。
5. 若无法回滚，启用功能开关、限流、降级或旁路故障依赖。
6. 持续确认用户侧是否恢复，而不仅是 Pod 是否 Running。
## 四、何时应该回滚
满足以下任一条件应倾向回滚：核心链路不可用；错误率持续超过阈值；数据正确性存在风险；团队在预定止血时间内无法解释问题；新旧版本对比明确指向变更。
不要因为“已经发布了一半”而继续推进，也不要在事故中临时修补多个版本。
## 五、回滚前必须确认
- 数据库变更是否向后兼容。
- 新版本是否已经写入旧版本无法读取的数据。
- 配置、缓存和消息格式是否兼容。
- 回滚镜像、制品和依赖是否可用。
- 回滚后是否需要重放消息或修复数据。
对不可逆 DDL，应优先使用 expand-and-contract：先增加兼容结构，再迁移数据，最后删除旧结构。
## 六、恢复验证
按登录、查询、写入、支付或下单等核心用例验证；对比错误率、P99、队列、数据库连接和资源利用率；持续观察至少一个完整流量周期。
## 七、无责复盘模板
复盘包括：影响范围、时间线、直接原因、促成因素、为什么测试未发现、为什么监控未提前发现、止血为什么快或慢、哪些防线失效。整改项按“预防、检测、缓解、恢复”分类，并标注负责人、完成时间和验收证据。
长期治理应包括灰度发布、自动回滚阈值、制品不可变、配置版本化、数据库兼容性检查、演练和发布审计。真正成熟的发布体系，不依赖某个资深同事临场救火。