凌晨 3 点，半梦半醒，手里是一条告警，眼前是 200 行刷屏的日志——这时候你不需要一个聪明的 AI，你需要一个结构化的第二大脑：问对分流问题、按概率给三个假设排序、把你从”先重启服务看看”那种冲动里拽回来。下面这套流程是我第一次值班时希望自己有的版本：步骤短、限制硬、修完做一遍沉淀，让一夜的折腾变成下一位 on-call 不用重历的 runbook 条目。
这篇主要解决什么问题
一套从被叫醒到修好的工作流——用 AI 做分流和假设排序，在高压决策点给明确护栏（什么时候叫醒队友、什么时候直接回滚、什么时候停下接受更长的停机以换更安全的修复）。再加一遍事后沉淀，把 AI 的聊天记录转成 runbook 条目。
这篇适合谁看
任何在 on-call 轮值里的工程师，尤其首次值班的人、没有强 runbook 传统的团队。资深 on-call 用 AI 在长事故里压低认知负担。希望团队 page 处理一致化的技术负责人。
什么时候适合用
线上告警，你是响应人，系统处于降级或未知状态。从没见过的新告警——AI 在不熟悉事故的头 10 分钟最有用。一连串告警，需要分辨哪个是根。
什么时候不建议用
告警里已写明修法的 page（“DB 连接池耗尽——跑 X”）。直接照 runbook。安全事故——升级，不要聊。已知维护窗口期间的 page——先查维护计划。明显是”20 分钟前那次发布弄的”——先回滚，AI 后议。
开工前
- 让 AI 在你的 on-call 设置里随手可达。手机、笔记本、终端——你最先抓到那个。3 点钟的摩擦能毁掉这套流程。
- 准备好粘贴缓冲区。你会反复粘告警、日志、指标快照。整套流程都靠你给 AI 够用的上下文。
- 大致知道你的服务拓扑。AI 调不了你描述不了的东西。“鉴权服务连 Redis 和用户数据库”这种粗略骨架就够起步。
- 预先承诺冷静协议。在线上敲任何命令之前，深呼吸，把你要做的事告诉 AI。这 5 秒能挡掉大多数”手抖”事故。
具体步骤
- 分流。把告警文本和最相关的前 50 行日志贴进 AI。问：“根据这条告警和这些日志，列 3 个最可能的根因按概率排，每个给一条具体诊断检查。先不要给修复。”
# 典型 Linux 服务的快速取日志 journalctl -u myservice --since "10 min ago" | tail -200 # 或 k8s kubectl logs deployment/myservice --tail=200 --since=10m - 检查最近变更。在顺假设树往下钻之前，先问：“最近一小时有发布或配置变更吗？“有，多半就回滚。停、回滚、观察。AI 在这一步的作用是提醒你这是最便宜的检查。
- 按概率跑假设检查。把结果回报给 AI。“检查 1（Redis 内存）通过——用了 30%。检查 2（慢查询）确认——
orders上的SELECT跑 15 秒。“AI 的上下文随真数据增长，不靠猜。 - 写操作前的冷静协议。在线上做任何破坏性动作前——
kubectl delete、DROP、kill、重启——把完整命令贴进 AI 问：“我要在生产跑这条。可能出什么问题？如果它让事情更糟，怎么恢复？“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 分钟内查过最近发布 / 配置变更。多数 page 都追回到”某个东西变了”。
- 恢复以指标回基线为准，不以”告警消失”为准——告警可能短暂消除但原因不对。
- 在你定的时间 / 范围阈值内升级。“一个人扛”是 30 分钟事故变成 3 小时事故的方式。
怎么把这流程沉淀下来
- page 解决后让 AI 把对话总结成 runbook 条目。“把我们的对话转成 runbook 一节：症状、按顺序的诊断步骤、修复、回滚。说人话。“修一修贴进团队 runbook。
- 分流 prompt 存成可在 10 秒内粘出来的片段。3 点的摩擦是大敌。
- 维护一份个人”先查这几个”清单——你这个服务的 top 3-5 假设。AI 是通用的；你的服务有具体的反复出现原因。几轮之后你的清单胜过 AI 的通用排序。
- 下次团队例会评：哪些 page AI 有用，哪些没用？AI 对陌生告警最有用，对已有 runbook 的重复告警最没用。
建议的操作流程
page → 粘告警 + 日志 → AI 给 3 个排序假设 → 查最近发布 → 跑假设检查 1 → 回报 → 确认原因 → 任何破坏性命令前先冷静 prompt → 应用修复或回滚 → 用指标确认 → 把聊天沉淀成 runbook 条目。典型 page 在流程到位时 15-30 分钟从告警到解决。
容易踩的坑
- 只贴告警不贴日志。AI 分不了流。
- 跳过”最近发布”检查。多数 page 是最近一小时上的什么东西引起的。
- 没确认根因就让 AI 提修复。“调大内存上限”对一个错的原因是个好建议。
- 不跑冷静 prompt 就敲破坏性命令。成本 5 秒，收益偶尔挡掉第二个事故。
- 因为”应该先理解 bug”而拒绝回滚。事故中先恢复服务，理解放后面。
- 该叫队友不叫。轮值制度的意义就是一个人不要独自做难事故的第 3 小时。
- 不把聊天沉淀成 runbook 条目。同样的告警还会响；下一位 on-call 配得上你的笔记。
FAQ
- AI 给的假设全错怎么办？: 给反证再问。“不是内存（已查），不是最近发布（已查）。重排。“AI 在反证下收敛比在含糊正向 prompt 下快得多。
- AI 能直接读我的日志 / 指标吗？: agentic 设置（带 MCP 的 Claude Code 之类）能接日志搜索和看板。有用，但确认 AI 在读真实数据不是幻觉。高代价的决断手工粘数据。
- 能让 AI 在线上直接动手吗？: 不能。AI 建议，你动手。建议和动手之间的 5 秒停顿就是用来挡坏主意的。
- 太累想不清怎么办？: 叫队友。AI 是思考辅助，不是替代清醒的人。
- 怎么避免被 AI 带进兔子洞？: 一开始就定 15 分钟计时。15 分钟还在降级且没确认原因，回滚，后续再查。
- 事后复盘呢？: 用事故复盘工作流。on-call 聊天是复盘最好的输入之一——留着。