凌晨 3 点，半梦半醒，手里一条告警，眼前 200 行日志刷屏——这时候你不需要一个聪明的 AI，你需要一个结构化的第二大脑：问对分流问题、按概率给三个假设排序、把你从”先重启服务看看”那种冲动里拽回来。下面这套流程是我第一次值班时希望自己有的版本：步骤短、限制硬，修完做一遍沉淀，让一夜的折腾变成 runbook 条目，下一位响应人不用重历。
一句话总结
- 把告警加 50-200 行日志贴进 AI，让它给按概率排序的 3 个假设、每个配一条诊断检查——先不要修复。“不要修复”这条约束，正是防你去追一个没确认的原因。
- 头 5 分钟内查最近发布。 多数 page 都追回到”最近一小时上了什么东西”。是的话，答案是回滚，不是继续查。
- 任何破坏性命令前（
kubectl delete、DROP、kill、重启），先跑冷静协议：把完整命令贴进去，问可能出什么问题、怎么恢复。5 秒，常常避免第二个事故。 - 有 agentic 权限的话，官方的 Grafana、PagerDuty、Datadog MCP server 能让 Claude Code 或 Cursor 直接查日志和指标。有用，但要确认它读的是真数据——高代价的决断手工粘。
- AI 建议，你动手。建议和动手之间的停顿就是安全机制。回去睡之前，把解决了的聊天沉淀成 runbook 条目。
AI 什么时候帮得上 page，什么时候帮不上
这套流程最值钱的地方是陌生告警——一个你没见过的事故的头 10 分钟，或者一连串告警里你分不出哪个是根。AI 是个快、不知疲倦、从不慌的分流搭档。
下面这些情况它就是错的工具：
- 告警里已写明修法（“DB 连接池耗尽——跑
X”）。照 runbook 跑。 - 安全事故。升级，不要聊。
- page 出现在已知维护窗口期间。先查计划表。
- 原因明显是”20 分钟前那次发布”。先回滚，后调试。
这和事故管理团队（incident.io、PagerDuty）现在的正统一致：活跃事故期间，缓解优先于根因。先恢复服务，再去理解它。
page 之前：先把 4 件事配好
- 让 AI 在你的 on-call 设置里随手可达——手机、笔记本、终端，你最先抓到那个。3 点钟的摩擦能毁掉整套流程。
- 准备好粘贴缓冲区。 你会不停地粘告警、日志、指标快照。整套流程都靠你给 AI 够用的上下文。
- 大致知道你的服务拓扑。 AI 调不了你描述不了的东西。“鉴权服务连 Redis 和用户数据库”这种粗略骨架就够起步。
- 预先承诺冷静协议。 在线上敲任何命令之前，深呼吸，把你要做的事告诉 AI。这 5 秒能挡掉大多数”手抖”事故。
可选：把 AI 接到你的可观测性栈（MCP）
如果你想让 AI 自己读日志和指标，而不是你来粘，主流可观测性厂商在 2026 年初都发了官方的 Model Context Protocol（MCP）server。截至 2026 年 6 月，它们能接 Claude Code、Cursor 和其他 MCP 客户端：
| MCP server | agent 能做什么 | 配置要点 |
|---|---|---|
| Grafana（官方） | 对 Prometheus 跑 PromQL，对 Loki 跑 LogQL 日志和指标查询，看板、告警、Grafana OnCall、Sift 调查 | 需要 GRAFANA_URL + GRAFANA_SERVICE_ACCOUNT_TOKEN；Grafana 9.0+ |
| PagerDuty（官方，约 2026 年 3 月 GA） | 60+ 工具，含完整事故读写 API、值班表、升级策略 | OAuth 或 API token |
| Datadog（官方） | 监控、指标、日志、链路、事故 | API + app key |
| Splunk（v1.1.0 GA）、Honeycomb（托管） | 搜索、查询、看板 | 厂商 token |
用 Claude Code 几秒就能注册一个：
# 看已经接了哪些
claude mcp list
# 加 Grafana server（凭据放环境变量里）
claude mcp add grafana -- npx -y @grafana/mcp-grafana
# 验证单个 server 有没有响应
claude mcp test grafana两条警告。第一，on-call 的 token 只给只读权限——你可不想 3 点钟的一次幻觉去静默告警，或者 ack 掉你还没分流的事故。第二，永远确认 agent 引用的是一次真查询的真数字，不是凭记忆总结。任何破坏性决断，退回到自己粘数据。
注意 Claude Code 只跑 Anthropic 模型（Opus 4.7 或 Sonnet 4.6，截至 2026 年 6 月都是 1M token 上下文），所以一长段事故聊天不会撑爆窗口。Cursor 如果你愿意，可以让这两个加上 GPT-5.5、Gemini 3.1 Pro 对着同一批 MCP server 跑。
从 page 到修好的循环
- 分流。 把告警文本和最相关的前 50-200 行日志贴进 AI。让它给按概率排序的 3 个假设、每个配一条具体检查，并明确先不要给修复。
# 典型 Linux 服务的快速取日志 journalctl -u myservice --since "10 min ago" | tail -200 # 或 Kubernetes kubectl logs deployment/myservice --tail=200 --since=10m - 检查最近变更。 在顺假设树往下钻之前，先问：“最近一小时有发布或配置变更吗？“有，多半就回滚。停、回滚、观察。AI 在这一步的作用是提醒你这是最便宜的检查——多数 page 都是刚上的东西引起的。
- 按概率跑检查，边跑边把结果回报：“检查 1（Redis 内存）通过——用了 30%。检查 2（慢查询）确认——
orders上的SELECT跑 15 秒。“AI 的上下文随真数据增长，不靠猜。 - 写操作前的冷静协议。 做任何破坏性动作前——
kubectl delete、DROP、kill、重启——把完整命令贴进去问：“我要在生产跑这条。可能出什么问题？如果它让事情更糟，怎么恢复？“5 秒，常常避免第二个事故。 - 决断：继续查还是回滚。 查了 15 分钟仍未明、系统在持续降级，回滚通常是对的。AI 能帮你框这个权衡：“症状是 X，回滚成本是 Y，继续查的成本是 Z。要不要回滚？”
- 应用修复或回滚，然后验证。 跑动作，看系统。等恢复信号——告警消除且指标回基线。指标没回不能宣布解决；告警可能因为错误的原因短暂消除。
- 什么时候叫队友：30 分钟还没找到根因、影响多个服务、要做你从没做过的破坏性动作、累到想不清。AI 可以说”考虑升级”，但拍板是你。
凌晨 3 点用得住的分流 Prompt
On-call 告警。我需要分流。
告警：[粘告警文本]
最近日志（最近 10 分钟）：
[粘 50-200 行]
服务上下文：[1-2 句——这服务干嘛、关键依赖]
最近活动（最近一小时的发布 / 配置变更，已知就写）：
[粘或 "未知"]
产出：
1. 3 个最可能根因按概率排。每个给 *一条* 具体诊断检查（命令、看
哪个指标、搜哪条日志）。先不要写修复。
2. 一句话："如果还没查最近发布，先查。"
3. 一句话："查了超过 15 分钟仍未收敛，考虑回滚最近变更。"
不要软化。不要给我三个"可能也是"的应忽略原因。这 3 个假设必须
是你真实的最佳猜测。宣布解决前的质量检查
- 修复之前跑过诊断检查。凌晨 3 点最常犯的错就是跳去修一个从未确认的假设。
- 每条破坏性命令前都跑过冷静 prompt——无例外，哪怕这条命令你以前敲过。
- 头 5 分钟内查过最近发布和配置变更。
- 恢复以指标回基线为准，不以”告警消失”为准。
- 在你事先定的时间和范围阈值内升级。“一个人扛”是 30 分钟事故变成 3 小时事故的方式。
把这一夜沉淀成 runbook（下次还能赢过 AI）
- 解决后让 AI 把对话总结成 runbook 一节：“把我们的对话转成 runbook 一节：症状、按顺序的诊断步骤、修复、回滚。说人话。“修一修贴进团队 runbook。
- 把分流 prompt 存成可在 10 秒内粘出来的片段。
- 维护一份个人”先查这几个”清单——你这个服务的 top 3-5 反复出现原因。AI 的排序是通用的；几轮之后你的服务专属清单会胜过它。这也正面对付比 MTTR 更重要的指标：重复事故率。一个解得快但同一条 page 反复响的团队，其实没赢。
- 下次团队例会评：哪些 page AI 有用，哪些没用。它对陌生告警最闪光，对已有 runbook 的重复告警帮助不大。
容易踩的坑
- 只贴告警不贴日志。没数据 AI 分不了流。
- 跳过”最近发布”检查。
- 没确认根因就让 AI 提修复。“调大内存上限”对一个错的原因是个好建议。
- 不跑冷静 prompt 就敲破坏性命令。
- 因为”应该先理解 bug”而拒绝回滚。事故中先恢复服务，理解放后面。
- 该叫队友不叫。轮值制度的意义就是一个人不要独自做难事故的第 3 小时。
- 给接了 MCP 的 agent 一个写权限 token，还信它自己去 ack 或解决。
- 不把聊天沉淀成 runbook 条目。
FAQ
- AI 给的假设全错怎么办？ 给反证再问：“不是内存（已查），不是最近发布（已查）。重排。“AI 在反证下收敛，比在含糊正向 prompt 下快得多。
- AI 能直接读我的日志和指标吗？ 能，用官方的 Grafana、PagerDuty、Datadog、Splunk 或 Honeycomb MCP server 接进 Claude Code 或 Cursor。on-call 的 token 保持只读，并确认 agent 引用的是真查询不是记忆。高代价的决断手工粘数据。
- 能让 AI 在线上直接动手吗？ 不能。AI 建议，你动手。建议和动手之间的停顿就是用来挡坏主意的——2026 年的事故响应指南也依然把缓解的扳机放在人手上。
- 太累想不清怎么办？ 叫队友。AI 是思考辅助，不是替代清醒的人。
- 怎么避免被 AI 带进兔子洞？ 一开始就定 15 分钟计时。15 分钟还在降级且没确认原因，回滚，后续再查。
- 事后复盘呢？ 用 AI 事故复盘工作流。on-call 聊天是复盘最好的输入之一——留着。