没有根本原因的事后分析
“五个为什么”事件回顾假设存在一个模型并不具备的确定性原因。本文将介绍如何编写一份真实的 LLM 事后分析报告，它建立在故障率增量和促成因素堆栈之上，而非寻找单一的根本原因。
Agent 的演练日：排演那些无法复现的故障
混沌工程假设故障是可重现的；但 Agent 系统的故障往往通过从不重复的随机路径发生。演练日（Game days）——包括工具故障注入、模型降级演练、上下文污染场景以及升级反馈消防演练——能建立运维人员的肌肉记忆，并暴露重现测试永远无法发现的追踪工具缺陷。
让 Agent 先接警：AI 故障响应的信任阶梯
故障发生的最初 15 分钟通常是机械化的，Agent 可以在你解锁笔记本电脑前就完成这些工作。这套由叙述者、建议者、受控执行者、受限自动修复者组成的四层信任阶梯，配合基于证据的晋升和有范围的降级机制，比在经历一个糟糕的夜晚后彻底禁用自动化要明智得多。
理解债：没人能看懂的凌晨两点系统
AI Agent 交付了人类从未建模过的整洁代码，而账单却会在凌晨两点的故障处理中如期而至。本文将探讨为什么“理解债”是 Agent 时代的核心运维风险，以及如何保持人类理解与系统同步。
那个在你待办事项中悄悄更改的弃用日期
供应商可以在不发布差异对比、不发送通知的情况下直接修改弃用日期。当初将原始日期放入延期池的团队，直到收到支持工单时才发现大事不妙。
你的故障指挥官无法执行的智能体运行手册
大多数智能体运行手册在白天读起来很顺畅，但在凌晨 2:17 运行时却会被阻塞，因为作者拥有值班 SRE 所不具备的访问权限。联邦化、声明式范围、紧急访问端点和演练才是解决之道。
带有延迟预算的紧急开关：你的故障处理从未达到的标准
如果一个 AI 功能的遏制时间超过了其爆炸时间，那么所谓的紧急开关只是纸上谈兵，而非实际可用。测量激活延迟，根据损失率对其进行分层，并将该数值写入运行手册。
那个假设人类会阅读页面的 On-Call 运维手册
当智能体在故障频道发布了一份客气的摘要，而指挥官将其理解为已接手时，升级链条中悄然出现了一个无人定义的转换点。本文将探讨弥补这一差距的模式。
没有模型推理项的故障复盘模板
大多数事件模板都没有留出记录 AI Agent 推理内容的栏位——导致行动项在试图为概率性失效寻找确定性的解决方案，从而使得同一类故障不断重复发生。
没人接线的紧急开关：因为功能从未失效
发布标志会被清理，但紧急开关不会。为什么每个 AI 功能都需要持久的运行时禁用机制、预先确定的备选链，以及一个明确标注了控制杠杆的运行手册。
故障复盘：根本原因竟是一个无人负责的提示词
一次生产事故追溯到了几周前修改的一个系统提示词（Prompt），由于当时没有 PR、没有审核人、也没有负责人。本文探讨了为什么提示词总是能绕过变更管理，以及如何在不降低迭代速度的前提下，将它们重新纳入审核流程。
当 Agent 出错时谁会被呼叫：针对非确定性系统的轮值制度
Agent 的故障难以复现、无法回滚，且在所有的基础设施仪表板上都显示正常。本文将教你如何针对无法单步调试的系统，重写运行手册、警报规则和轮值预期。