Skip to content
返回维护与 LTS

热修流程

在正常发布节奏外发关键修复 — 快、安全、带复盘。

为什么

热修是发布流程的例外，例外是流程崩溃处 — 无测试、无审查、无回退的仓促修复成比所修漏洞更大的事件。定义的热修流程保速度同时保安全：从发布标签分支（非 main，可能有未发布变更）、写修复 + 回归测试、快速审查（1 审查者、30 分钟 SLA）、带热回退部署、48 小时内排复盘。流程还使热修设计上罕见：若每周热修则发布节奏太慢，修法是加速正常流程非正常化热修。

何时使用

仅 P0 漏洞 — 生产可利用、无变通。绝不功能或非关键 bug。

如何做

1. 从生产发布标签分支（非 main）：git checkout -b hotfix/<漏洞-id> v1.2.2
2. 写最小修复 + 复现漏洞回归测试；提交
3. 快速审查：1 审查者、30 分钟 SLA、安全负责人通知（非正常 2 审查者、24 小时门控）
4. 跑完整测试套件 + e2e；若非漏洞测试失败则修或缩热修范围
5. 作为补丁打标签：v1.2.3；部署 staging、冒烟测、然后生产带旧镜像 :prev 供回退
6. 监控 1 小时；回归则 kubectl rollout undo（即时回退到 :prev）
7. 热修分支合回 main（使修复不丢在下发布）
8. 48 小时内排复盘：什么坏、如何发现、如何防复发
9. 跟踪热修日志：日期、漏洞、修复时间、回退是否工作、复盘链接

示例

# CVE-2024-9999（认证绕过，P0）热修
# 1. 从生产标签分支（非 main）
git checkout -b hotfix/cve-2024-9999 v1.2.2

# 2. 最小修复 + 回归测试
# src/auth.ts：加缺失的 token 验证
# test/auth-bypass.test.ts：
it('拒绝伪造 token (CVE-2024-9999)', () => {
  expect(() => auth(forgedToken)).toThrow('invalid token');
});
git commit -m "fix(security): 认证绕过 [CVE-2024-9999, P0 热修]"

# 3. 快速审查（1 审查者，30 分钟 SLA）
gh pr create --reviewer security-lead --label hotfix
# security-lead 30 分钟内审查

# 4. 打标签 + 带热回退部署
git tag v1.2.3
docker tag registry/app:current registry/app:prev  # 热回退
docker build -t registry/app:v1.2.3 . && docker push registry/app:v1.2.3
kubectl set image deployment/app app=registry/app:v1.2.3
# 监控 1 小时；错误率升则：kubectl rollout undo

# 5. 合回 main + 复盘
git checkout main && git merge hotfix/cve-2024-9999
# 48 小时内排复盘
# 日志：hotfixes/2024-04-15-cve-2024-9999.md

常见问题

  • ⚠从 main 而非发布标签分支 — 热修含未发布变更，补丁发布有意外功能。
  • ⚠省回归测试省时间 — 修复发但未来重构悄悄回退因无物抓。
  • ⚠无复盘 — 热修当部署即结束，但根因（漏洞如何进）永不查。

最佳实践

  • ✓总从生产发布标签分支非 main — 热修须仅含修复非未发布工作。
  • ✓即使热修也要求回归测试 — 测试证修复且防未来重构静默回退。
  • ✓每热修 48 小时内排复盘 — 部署非终点；理解根因防复发。