AI代码故障的on-call SOP：首个小时的应对预案

大多数团队会为顺利的 AI 交接做计划。几乎没有人会为失败的交接做计划。

本文为 AI 变更在生产环境失效定义了一份六十分钟 playbook。每个步骤都能塞进一页。团队可以用免费模型 token 和一台免费服务器来演练。

凌晨两点， pager 响了。前一天刚发布了一个功能。diff 大部分是由 AI 助手编写的。

测试通过了。预览看起来也没问题。现在计费任务一直在崩溃。

第一反应是怪模型。这个直觉会浪费时间。真正的失败发生在交接环节。

交接发生在意图在人员之间转移时。prompt 作者知道目标。reviewer 知道 diff。

值班工程师两点时两者都不清楚。AI 记得对话。人类不记得。

把每条 AI 生成的变更都当作一次没有记忆的交接。prompt 文本不等于意图。绿色测试套件不是证明。事故是三者碰撞的结果。

六十分钟时钟

先控制，再调查。前五分钟只有一件事：阻止损害扩大。

回滚发布或关闭功能开关。revert 很无聊。无趣意味着快速。快速才是重点。

# Option A: roll back the deployment
kubectl rollout undo deployment/billing

# Option B: disable the feature at the flag service
curl -X POST https://flags.example.com/api/billing-v2 \
  -H 'Content-Type: application/json' \
  -d '{"enabled": false}'

调试在控制住之后开始。团队经常跳过这个顺序。他们看 diff 的同时，用户正在感受爆炸。

第五分钟到第十五分钟属于证据收集。恐慌在一小时内会抹掉上下文。

捕获 prompt、git range 和测试输出。一条命令构建事故包。

#!/usr/bin/env bash
# incident_snapshot.sh: bundle evidence for an AI-change incident
set -euo pipefail

DIR="incident-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$DIR"

git log --oneline -10 > "$DIR/git_log.txt"
git diff HEAD~1..HEAD > "$DIR/last_diff.patch"
echo "$PROMPT" > "$DIR/prompt.txt"              # paste the original prompt
echo "$MODEL_OUTPUT" > "$DIR/model_output.txt"  # paste the model summary
pytest -q --tb=short > "$DIR/test_output.txt" 2>&1 || true

echo "bundle ready: $DIR"

这个包就是那份从未存在过的交接。它让后来的响应者重建变更。它也暴露了模型摘要中的缺口。

第十五分钟到第四十分钟属于复现。用一个普通模型运行失败的输入。

剥掉脚手架。一个最小化失败用例会塑造修复方案。免费模型 tier 单独就能处理这一步。

不需要预留 GPU。目标是拿到一个小 repro，而不是完整解决方案。

repro 有第二个好处。用全新的眼光重新运行 prompt。值班工程师看到原始模型行为。这个信号通常比任何日志行都有效。

第四十分钟到第六十分钟属于决策。要么修复方案很明显，要么 revert 就这么保留着。

写一段关于失败模式的文字。更新 runbook。下一个值班工程师继承的是一条线索，而不是沉默。

可以粘贴到 wiki 的 runbook

把整个时钟压缩成六行。放到一个名为 AI-Change Incident 的页面上。

# AI-Change Incident
1. Contain. Revert or flag off before reading the diff.
2. Snapshot. Run incident_snapshot.sh.
3. Reproduce. Failing input against a plain model.
4. Decide. Fix now, or keep the revert.
5. Record. One paragraph on the failure mode.
6. Restore. Confirm the state, then hand back.

压缩版比本文更重要。凌晨两点 pager 能读六行。读不了一篇论文。让 wiki 页面成为事实来源。

在 pager 选中你之前演练

playbook 不练习就会腐坏。事故演练通常需要预留基础设施。这个成本让大多数团队根本不去运行它们。

这里的演练几乎零成本。MonkeyCode 是一个开源项目，有免费 tier 用于事故演练。

披露：本文是 MonkeyCode 产品推广的一部分。

目前的免费额度包括一千万模型 token 和一台免费服务器。配额会随产品决策变化。在规划季度计划前核实一下。

免费服务器是演练环境。免费 token 覆盖模型调用。每季度一次演练几乎零成本。这个模式能撑过预算季。

演练需要一个 broken change、一个脚本、一个盲眼响应者。

# drill.sh: arm a staged incident without touching production
git checkout -b drill/billing-ledger
cp broken_billing.py services/billing/           # a known-bad change
git add -A
git commit -m "feat(billing): compact the ledger (drill)"
git push origin drill/billing-ledger
echo "drill armed. pager rotation starts now."

用真实事故命名演练。分配一个从未见过该变更的 pager。把修复方案藏起来。

开始计时。真正跑一遍六行 runbook。然后比较所选路径与预期路径。

第一次演练会暴露丑陋的缺口。这就是演练的意义。第二次演练感觉更平静。第三次会成为习惯。

局限与排除项

这个时钟不是通用的。没有回滚或功能开关的团队需要更长的控制窗口。没有日志的团队无法 snapshot 任何东西。

安全关键系统需要一个有真正权力的人类审批者。没有任何演练能替代那份责任。

告警噪音大的团队需要在零分钟之前增加分诊步骤。时钟在确认真实失败后才开始。

如果每条生成的代码在合并前都经过人工 review，就跳过这个 playbook。那些团队已经把失败提前了。

他们需要的是 review workflow，不是 incident workflow。两种 playbook 互为补充。不能互相替代。

把免费 tier 视为移动靶盘。优惠会变，配额会移。本文的数字反映操作者当前的核查。在把这个演练作为季度惯例之前重新核实。

存续下来的模式

AI 辅助团队在意图与行动之间的边界处失败。模型生成。人类批准。

双方都没有写下对方需要的东西。事故包修复了这个边界。六行 runbook 让它可操作。

季度演练让它固化。在免费 tier 上跑第一次演练。一千万 token 和一台免费服务器足够起步。

你未来的值班自己会感谢那个演练过的团队。