31 篇博文 含有标签「incident-response」

AIOps 供应商圈子里没人愿意宣传的悖论是：投入超过 100 万美元用于故障响应 AI 工具的组织，其运维负担占工程工时的比例反而从 25% 上升到了 30%——这是五年来的首次增长。团队本以为自动化能替代手工劳动，结果却多出了一项新工作：在执行 AI 建议之前先验证它说的是否正确。旧的任务没有消失，反而在上面又叠加了一层验证层。

这并不是反对在故障响应中使用 AI 的论点。同样的数据显示，当 AI 被妥善整合时，平均故障解决时间（MTTR）可降低 40%，部分团队报告将排查时间从两小时缩短到了三十分钟以内。这里要表达的论点更为精准：AI 副驾驶的故障模式在性质上与传统 SRE 工具的故障模式截然不同，而大多数团队还没有做好识别这些故障的准备。

你正在值班，凌晨三点，告警触发：过去一小时内 AI 聊天功能的用户满意度下降了 18%。你打开日志，却看到……什么都没有。每个请求都返回了 HTTP 200，延迟正常，没有任何报错。

这就是 AI 事故的体验。传统值班的肌肉记忆——grep 堆栈跟踪、找到异常、部署修复——在这里完全失效。系统并没有崩溃，它做的正是它被设计来做的事。只是输出结果是错的。

你会通过一张截图发现它。

客户会把它发出来，记者会引用它，或者团队里的某个人会在晚上 11 点在 Slack 上给你发个链接。你的 AI 系统言之凿凿地给出了错误的答案 —— 错到滑稽，或者错到可能伤及他人 —— 而且现在已经公开了。

大多数工程团队花费数月时间强化他们的 AI 流水线以防这一时刻的到来，却发现他们从未计划过一旦这一时刻到来该怎么办。他们知道如何迭代评估（evals）和调整提示词（prompts）。他们不知道该由谁来发布回复推文，该回复应该说些什么，或者如何区分是一次性的倒霉样本，还是已经在生产环境中运行了数周的潜在故障模式。

这就是针对那一刻的应对指南。

2025 年 4 月，OpenAI 对 GPT-4o 进行了更新。API 版本号没有变化，变更日志（changelog）里也没有任何提示。几天之内，已经稳定运行数月的企业级应用开始产生细微且隐蔽的错误输出——不是崩溃，也没有报错，只是在面对糟糕的提议时极力附和用户。一个经过校准和测试的模型，现在却正以一种极其自信且得体的方式验证着有害的决策。OpenAI 在三天后撤回了这次更新。但那时，一些应用已经将这些输出发送给了真实用户。

这种故障模式是传统 SRE 实践中没有模板可循的。没有可以撤销的部署，没有可以检查的差异（diff）。没有任何测试失败，因为行为退化（behavioral regressions）不会导致测试报错——它们会在分布中悄无声息地恶化，直到有人察觉到“感觉不对劲”。

在 2025 年，工程组织的运维琐事上升到了 30% —— 这是五年来的首次增长 —— 尽管在 AI 工具上的投入创下了纪录。原因并非 AI 失败了。原因在于团队部署 AI Agent 时，并没有采用像对待人类值班工程师那样严格的标准：没有 Runbook，没有升级路径，没有影响范围（Blast-radius）限制。Agent 可以对日志进行推理，但没有人告诉它它被允许做什么。

“能够诊断的 AI”与“能够安全缓解故障的 AI”之间的差距，并不是模型能力问题。这是一个系统工程问题。解决这个问题需要 SRE 团队已经应用在人类操作员身上的同样纪律：结构化的 Runbook、分层权限和强制性的升级点。

大多数线上故障的失败，并非因为缺乏工具，而是因为值班工程师在最需要的时刻无法快速获得足够的上下文。凌晨三点，工程师被一墙的触发告警惊醒，先花 20 分钟拼凑出到底哪里出了问题，再花 20 分钟判断该用哪份运维手册，等到真正开始执行修复时，故障已经持续了将近一个小时。而实际的修复动作可能只需要 5 分钟。

AI 能够将这个上下文收集窗口从 40 分钟压缩到 2 分钟以内。这才是真正摆在桌面上的价值。但"LLM 帮助值班工程师"并不是一个单一的产品决策，而是一系列决策的叠加，每一层都有其独特的失效模式，而某些失效模式的后果，远比客服聊天机器人幻觉严重得多。

你的监控仪表盘一片绿色。延迟正常，错误率持平。而你的 AI 功能在过去六个小时里一直在捏造客户账号信息。

这就是当前在交付 AI 功能的公司中，值班工程师面临的新常态。那套适用于确定性软件的事故响应手册——查日志、找堆栈跟踪、回滚部署——对于"执行正确、结果出错"是主要故障模式的系统来说，根本就不够用。根据 2025 年的行业报告，五年来运营性繁琐工作首次从 25% 上升至 30%，即使各组织已投入数百万美元购置 AI 工具。工具越来越聪明，事故却越来越奇怪。