engineering-emergency-changes

工程紧急变更

紧急评审适用于少数情况：整个变更的速度比常规评审深度更重要。这并不意味着“跳过工程判断”，而是要缩小变更范围、核实紧急情况、优先保证正确性，并安排后续评审。

改编自 Google Engineering Practices Documentation，尤其是“Emergencies”和有关评审速度的指导。来源：https://google.github.io/eng-practices/review/emergencies.html。许可证：CC-BY 3.0。

紧急情况判定

只有当变更范围小且目标明确，并且至少符合以下一项条件时，才将其视为紧急变更：

• 当回滚不是合适方案时，防止重大发布失败。
• 修复严重影响生产用户的错误。
• 解决紧迫的法律或合规问题。
• 修复重大安全漏洞。
• 满足严格的外部截止日期；错过该期限会造成合同、法律、安全、生产用户方面的损害，或明显灾难性的发布后果。

以下情况通常不能单独构成紧急情况：

• 想要提前发布。
• 某项功能耗时很久，作者希望尽快合并。
• 评审者正在睡觉、不在岗或身处其他时区。
• 现在是周五晚上。
• 经理希望今天完成某项软性截止期限的任务。
• 团队想要避开常规评审带来的不适。

大多数截止期限都是软性的。不要为了软性截止期限牺牲代码健康度。

紧急工作流

1. 用一句话说明紧急情况。
2. 判断是否符合紧急情况判定标准。
3. 将变更缩减至最小修复范围。
4. 确认变更能直接解决紧急问题。
5. 优先检查正确性、影响范围、回滚方案和明显的安全问题。
6. 执行当前可用的、最有意义的快速验证。
7. 记录跳过了哪些常规检查以及跳过原因。
8. 只有紧急风险大于代码风险时，才合并或发布。
9. 紧急情况解决后，执行一次常规深度的后续评审。
10. 立即创建清理、测试、文档和事后复盘任务，避免遗漏。

紧急评审检查清单

• 范围：这是解决紧急情况所需的最小变更吗？
• 正确性：它确实修复了生产、安全、法律或发布问题吗？
• 遏制：能否快速回滚或禁用？
• 测试：当前哪项自动或手动检查最能增强信心？
• 可观测性：团队如何确认修复是否有效？
• 副作用：哪些用户、数据、作业、API 或部署可能受到损害？
• 后续跟进：之后必须完成哪些常规评审事项、测试、文档或清理工作？

输出模板

## Emergency Decision
QUALIFIES | DOES_NOT_QUALIFY | NEEDS_MORE_INFO

## Reason
[Concrete reason tied to production user impact, security, legal/compliance, major launch, or hard external deadline.]

## Minimum Safe Change
- ...

## Immediate Verification
- ...

## Release / Rollback Notes
- ...

## Follow-up Required
- Normal-depth review:
- Tests:
- Cleanup:
- Documentation:
- Owner:

常见错误

• 把紧迫性当成紧急情况。
• 扩大热修复范围，把附近的清理工作也纳入其中。
• 跳过所有评审，而不是调整评审重点。
• 忘记在事件解决后执行常规评审。
• 让紧急例外变成团队的常规发布流程。