线上出事故时该不该让 AI 上手：哪几步能交给它，哪几步必须人来

数据截至 2026-07。文中只讲机制与分工，不引用任何产品的具体限制数值；各家 AI 工具的区域可用性、配额与报错口径以官方最新说明为准。

这件事绝大多数人一开始就归错因：他们争的是”模型够不够聪明能不能救火”，而事故期真正的约束从来不是智力，是可撤销性和责任归属。 一个动作做完能不能一键退回去、退回去要多久、退不回去谁承担——这三问决定它能不能交出去，跟谁执行得更快没关系。想清楚这一点，分工就不再是玄学：AI 可以大量承担”看和收敛”的工作，因为看错了不留痕；它不该独立承担”改和承诺”的工作，因为改错了要人赔。下面按事故现场真实的推进顺序来讲。

站内另有两篇相邻的文章，分工不同：AI 把能跑的代码改坏了怎么止损 讲的是”事故源头就是 AI 那次改动”时怎么定位和回滚，给 Agent 设人工卡点 讲的是常态开发流程里审批点怎么放。本篇不重复这两件事，只处理一个场景：线上已经在冒烟、你手里有 AI 工具，此刻怎么用它、怎么不用它。

一、先给动作分类，再谈交给谁

进入事故状态后，第一件事不是查日志，是在心里给接下来所有动作贴标签。只有三类。

只读动作。 查日志、看监控曲线、拉配置快照、比对两个版本的差异、探活。这类动作做十遍和做一遍代价一样，做错方向也只是浪费几分钟。它们占了事故期工作量的大头，也正是 AI 最能压缩时间的地方。

可逆写动作。 回滚到上一个已知可用版本、把流量切回旧集群、关掉某个开关、重启一个无状态实例。这类动作有明确的反向操作，且反向操作的代价你事前就知道。它们可以由 AI 协助生成步骤清单，但按下执行的必须是人，而且必须是知道反向操作怎么做的那个人。

不可逆写动作。 改库表结构、批量修数据、删消息队列积压、清缓存里唯一的数据副本、轮换正在被依赖的密钥、对外发公告。这类动作没有反向操作，或者反向代价高到不可接受。它们一律不交出去，连”生成脚本让人一键跑”都要谨慎，因为一键跑最容易跳过阅读。

有了这个分类，很多争论直接消失。有人问”能不能让它自动回滚”，答案取决于你能不能在三十秒内把回滚再撤回来；如果回滚会触发数据格式向下不兼容，那它就不是可逆写，是不可逆写。

先固定现场，这一步必须人做，而且要在开始折腾之前做：

# 记下当前跑的是哪个提交，以及最近的候选回退点
git rev-parse HEAD
git log --oneline -n 10

现场没固定就开始改，是事故拖长的头号原因：改到一半你已经说不清坏状态长什么样，也说不清哪个版本是好的。

二、按现象分因：让 AI 帮你缩小假设空间

事故期最贵的不是执行，是假设太多。你同时怀疑网络、依赖、发布、容量、配置，五条线并行查就等于都没查。这一步的目标是把假设砍到一两条，然后逐条验证。

AI 在这里的用法很具体：把你手上的原始材料丢给它做归纳，而不是让它猜结论。有效的输入是错误日志样本、最近一次发布的改动摘要、监控曲线的关键时间点。有效的输出是”这些日志能分成几类""这几类分别集中在哪个时间窗和哪批实例""哪些改动会影响到出错的那条链路”。它不知道你的线上长什么样，所以它给的因果判断只能当候选清单看，验证要自己动手。

下面这张表是我在事故里实际按行走的判别顺序，从最容易验证的开始：

现象	大概率成因	怎么验证	处置动作
发布后几分钟内全量报错，回滚即恢复	新版本代码或配置问题	对比新旧版本的改动范围与配置差异	先回滚止损，再离线定位
大面积 500，依赖方正常	自身进程异常，如启动失败、连接池耗尽	看实例存活数与进程日志的启动段	摘掉异常实例或整体回滚
集中出现 429	自己网关在限，或对端服务在限	看这个 429 是本方网关吐的还是对端响应带回来的，再对齐请求量抬升的时间点	先降并发、砍非关键调用，确认对端已缓过来再谈带退避的重试
突然大量 401 或 403	凭据失效、权限变更、密钥轮换未同步	用一个最小请求单独试凭据	恢复正确凭据，先别急着再轮换一次
报错含证书链校验失败	自签证书或中间证书缺失，常见于内网代理环境	单独取一次握手信息看证书链	补全信任链，不要用关校验的方式糊过去
大量 ETIMEDOUT 或 ECONNRESET	网络链路、连接被中间设备切断、对端过载	分段测耗时，看是解析慢、握手慢还是首字节慢	按慢在哪一段处置，超时值单独调
只有部分用户或部分地域出错	灰度批次、缓存不一致、某个节点异常	按实例与地域切分错误率	摘掉异常节点或停灰度
错误率缓慢爬升，无发布	资源泄漏、数据量增长触发慢路径	看内存或连接数是否单调上升	先重启争取时间，再定位泄漏点

分段测耗时用这一条就够，它是只读的，可以放心反复跑：

curl -sS -o /dev/null -w 'code=%{http_code} dns=%{time_namelookup} conn=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/healthz

握手和证书链单独看：

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

日志分类这种活可以让 AI 写一次性脚本，人读一遍再跑，这类脚本的价值就是快，写复杂了反而不如手工看：

import collections, re, sys

c = collections.Counter()
for line in sys.stdin:
    m = re.search(r'\s(\d{3})\s', line)
    if m:
        c[m.group(1)] += 1
print(c.most_common(10))

第三方接口报错的细分判别，站内 API 超时与连接中断怎么排 讲得更细，事故期需要判断”是我方还是对端”时可以直接照那套走。

三、交出去的和不交出去的

分工到具体条目，我的边界是这样划的。

适合交给 AI 的，都是收敛类工作。 把几千行日志压成几类现象；把一个发布区间的改动按影响面归类，指出哪些碰到了出错链路；把散在几个人嘴里的时间点整理成一条时间线；根据你口述的处置意图写出一份带前置检查和反向操作的步骤清单，供人过目后执行；写只读的巡检脚本；把技术现象翻译成给业务方看的一段话。这些事的共同点是产物是文字或只读脚本，错了不生效，人能一眼看出不对。

必须人来的，都是变更类和承诺类。 按下回滚、切流量、重启、扩容、改线上配置；任何写数据尤其是删数据；任何涉及权限和密钥的操作；判定”现在开始降级还是继续查”；对外发布口径和恢复时间。这里没有”让它自己执行完、我事后审一眼”的中间态，因为事故期你审不动——注意力已经被现场吃掉，粘过来的脚本你只会扫一眼就回车。清单可以由它写，但执行前逐条读懂、逐条按下，这个动作不能省，也不能并行给别人。

还有一条硬边界：不要把生产数据往外送。 事故期最容易发生的越界是把整段日志、配置文件、堆栈甚至数据库查询结果直接粘进对话框，里面往往带着真实用户标识、内网地址、密钥片段。要粘就先脱敏，或者只贴结构不贴内容。这一节的展开见 AI 编程的数据安全风险。

另外说清楚一件事，免得你在半夜的事故里做无效尝试：一批海外 AI 工具与模型服务，官方对中国大陆有区域限制、不支持直连，把它们放进应急依赖是不现实的。市面上存在第三方中转形态，但我不背书、也不给渠道，事故期把可用性押在这类链路上尤其危险——它挂了你连排查的工具都没了。应急路径要用你平时验证过能稳定连上的那条。

日常就该把这套分工练熟，等出事再想是来不及的，Agent 日常运维怎么做 里那些平时跑的巡检和值守习惯，正好是事故期的底子。

四、什么情况下别再折腾了

工程师在事故里最常犯的错是舍不得。已经查了四十分钟，感觉马上就要摸到了，于是又开一轮。判断该不该继续，不要靠感觉，靠三条硬线。

第一条是时间盒。 进入事故时就定死一个数：到点还没定位就执行回滚或降级，不讨论。这个数由你的业务容忍度决定，不由查得顺不顺决定。到点了还差一点点，那就带着”差一点点”去回滚，定位放到事后离线做——线上不是调试环境。

第二条是回滚点是否还在。 只要你还有一个已知可用的版本、且切回去的代价是明确的，那么”回滚”永远优先于”继续查”。反过来，如果这次发布带了不可逆的数据变更，回滚窗口其实已经关了，那就别再幻想回滚，只能向前修，这时候要立刻改策略：停止一切探索性尝试，转成小步可验证的向前补丁。

第三条是有没有在原地打转。 判定标准是连续两轮尝试没有产出新信息——不是没修好，是没换来任何新的事实。这时候继续同一条路只是重复；换条路的意思包括换观察维度、换验证手段、把人换掉让另一个脑子来看现场。让 AI 再生成一版猜测在这个阶段几乎没用，它拿不到新事实，只会把同一堆材料重新排列一次。

还有一个信号要特别警惕：你开始在生产上做”试一下看看”的动作。试一下就意味着你已经没有假设了，只是在碰运气。此刻正确的动作是止损，不是再试一下。

五、避坑清单

把 AI 的推测当作已验证的结论。 会踩，是因为它给出的因果句式非常笃定，而事故期人的判断力是下降的，笃定的句子最容易被接受。避法很简单：它说的每一条都当假设入队，前面加一句”这条怎么验证”，验证不了就不用它做决策。

在没固定现场之前先动手改。 会踩，是因为改的冲动比记录的冲动强，尤其是你觉得自己已经知道原因的时候。避法是把”记下当前版本和上一个可用版本”做成肌肉记忆，两条命令的事，永远排在第一位。

让工具连着多个环境，然后在生产上敲了本该在测试环境敲的命令。 会踩，是因为终端和上下文都长得一样，事故期没人看提示符。避法是环境隔离要物理化：生产操作只在专门的入口做，让危险的路径必须额外走一步。

用关掉校验的方式绕过证书报错。 会踩，是因为它立刻就让请求通了，看起来像修好了。避法是把这类动作视同”制造第二个事故”：证书链问题正确的解法是补全信任链，绕过去意味着你以后不知道什么时候会被真正的中间人问题咬一口。

看到 429 就加重试。 会踩，是因为重试是最顺手的动作。避法是先看清限流是谁在限：如果是对端在限，无退避的重试会把请求量继续推高，事故被你自己放大。正确顺序是先降并发和砍非关键调用，再谈退避重试。

遇到 401 就再轮换一次密钥。 会踩，是因为轮换像是”把凭据刷新一遍”的无害动作。避法是先用一个最小请求确认当前凭据到底有没有生效路径；在依赖方还没同步的时候再轮换一次，会把一个可恢复的问题变成多方不一致。

把整段生产日志粘给外部服务。 会踩，是因为脱敏要花时间，而你正急。避法是事前准备：常用的脱敏方式提前写成一个小脚本，急的时候一条命令跑完再粘。

恢复之后立刻散会。 会踩，是因为压力一解除，所有人只想睡觉。避法是恢复后先花五分钟把现场证据归档：日志片段、监控截图、时间点、做过的动作，这些东西过一夜就找不全了。

六、复盘阶段：这才是它最划算的地方

事故当中 AI 的价值是有限的，事故之后价值才明显，因为复盘正是典型的”材料多、要收敛、错了不致命”的场景。

先把材料摊平。把归档的日志片段、报警记录、群里的对话、每个人做过的动作丢进去，让它整理出一条按分钟排列的时间线，标出”第一个异常信号出现”和”第一个人开始处置”这两个时刻。这两点之间的差值就是你的发现时延，是复盘里最值钱的一个数字，也是最容易被含糊过去的一个数字。

然后让它做对照阅读。把出问题的那段改动和当时的报警配置一起给它，问一个具体问题：这次的现象，按现有的监控和报警规则，最早可能在什么时候被发现，缺哪一条检测项。它给出的候选检测项你要逐条判断可行性，但作为清单起点比空想强。

再让它出草稿。恢复步骤整理成一份可复用的处置手册草稿，包含前置检查、执行顺序、验证方式和反向操作。草稿一定要人改，因为它写不出你环境里的隐性约束；但从草稿改比从空白页开始快得多，而这份手册往往就是下一次事故里省下的半小时。

有两件事不要交给它。一是定根因，根因判定要落到具体的机制上，需要现场知识和取舍判断，AI 给的常常是听起来通顺的相关性。二是定责，任何形式的”谁的问题”都必须由人来说，让工具生成这种句子只会让复盘变成互相防守，从此再没人愿意说实话。

复盘的行动项也别写成一堆”加强意识”。每一条要能被验证是否做完：加了哪条报警、改了哪个默认超时、哪个操作从手工改成了必须走审批入口。写不出验证方式的行动项，等于没写。

收个尾

把这套东西压成一张自检清单，贴在你自己的值班文档里就够用了：

• 现场固定了吗，当前版本和上一个可用版本都记下来了吗
• 接下来这个动作属于只读、可逆写还是不可逆写，反向操作是什么
• 假设砍到一两条了吗，每条的验证手段是什么
• 时间盒到点了吗，回滚窗口还开着吗，最近两轮有新事实吗
• 粘出去的材料脱敏了吗
• 执行变更的是人吗，这个人知道怎么退回来吗
• 恢复后五分钟内证据归档了吗
• 复盘的行动项每条都能验证完成吗

事故期用 AI 的正确姿势，不是让它替你做决定，是让它替你把材料变薄，好让你有余力去做那几个只能由人做的决定。