收益：
- 能够了解事件的生命周期（检测、分类、缓解、解决、事后分析）、MTTD/MTTR 指标以及“先缓解，后调查”的原则
- 能够使用人工智能缩小事件发生时的假设范围，并生成无可指责的事后分析草图，用数据验证每个根本原因
- 能够应用一种不责怪事后分析的语言进行写作，并通过掩盖事件数据来共享事件数据。
每个系统最终都会崩溃。区别在于优秀团队如何为这一不可避免的事件做好准备以及如何学习。事件是中断或威胁中断服务的意外事件：服务崩溃、响应时间飙升、数据丢失。事件管理意味着尽快检测、缓解、解决事件，然后从中吸取教训。这是日夜驱动 DevOps 和 SRE（站点可靠性工程）专业人员的纪律。
衡量事件质量的两个关键指标：MTTD（平均检测时间）和 MTTR（平均恢复时间）。目标是缩小两者。 AI在这里增加了两大价值：快速总结事件发生时的日志和指标以缩小可能的根本原因，并在事件发生后快速起草事后调查报告。但有关事件进程的决定——关闭哪些服务、回滚、对客户说什么——都是你的。
事件的生命周期
- 检测：警报响起或出现客户投诉。越早越好。
- 分诊：有多严重？什么是域名？分配严重性级别 — 通常为 SEV1（最严重的整个系统）到 SEV4（次要）。
- 组建您的响应团队。在重大事件中，事件指挥官负责协调。
- 缓解：首先止血——通常是回滚或覆盖标志。稍后您会找到根本原因。
- 解决：应用永久修复。
- 学习（事后分析）：发生了什么，为什么会发生，我们如何防止它再次发生？
提示：事故发生时最昂贵的错误之一是延迟止血，因为“让我们首先找到确切的根本原因”。规则：先减（恢复/恢复服务），后查询。回滚到已知良好的版本通常是最快的缓解措施。
无负罪感的死后文化
健康团队的支柱是一种无可指责的事后剖析文化：目标不是“谁干的”，而是“什么系统和流程允许这个错误？”是问题。如果人们知道自己会受到惩罚，就会隐藏错误；隐藏的错误重复出现。事后分析不是一份指控报告，而是一份学习文件。
一个好的事后分析包括：总结、影响（有多少用户、多长时间、多少钱）、时间表、根本原因、进展顺利/失败以及行动项目——具体措施，每项都有所有者和日期。
注意：在使用 AI 撰写事后分析时，请务必消除指责性语言（即“X 人犯了错误”）。当向人工智能提供事件数据时，还会屏蔽客户端 ID、内部 IP 和秘密——事后分析通常会广泛共享。
根本原因分析：5 个为什么和人工智能
一个经典的技巧是“5个为什么”：问“为什么？”到一个问题。通过反复询问，你就能从表象中找到真正的根源。 “服务崩溃了。为什么？内存不足。为什么？有泄漏。为什么？库更新......”人工智能很快就会构建这条链并建议可能的分支 - 但你必须用你的数据验证每个“原因”； AI也可以建立一个合理但错误的链条。
严重性表
级别
影响
例子
干预
SEV1
整个系统/关键业务损失
付款完全下降
瞬间，整个队伍，指挥官
SEV2
主要功能障碍
登录失败
快速、随叫随到+支持
SEV3
部分/有限效果
报告延迟
工作时间内
SEV4
小/化妆品
打字错误
普通工作队列
三个迷你箱子
案例 1 — MTTR 从 45 分钟缩短至 8 分钟。支付服务崩溃了。值班工程师将屏蔽日志和最后一次部署信息交给AI，并询问“最近20分钟内最有可能触发的是什么？”他问道。人工智能显示，崩溃是在上次部署的同一分钟开始的。工程师立即回滚了该版本；服务在 8 分钟内返回。然后方便地调查了根本原因（新版本中的连接池错误）。
案例 2——20 分钟内的事后草图。 SEV2之后，团队很累，没有力气写报告；报告常常被推迟数周。这一次，他们向人工智能提供了时间线和事件记录，并制作了一份无犯罪的尸检草图。人工智能为影响、时间表和行动项目创建了一个简洁的框架；该团队用事实填充了它并在 20 分钟内发布了它。教训并没有消失。
案例 3 — 发现了错误的根本原因。在一个案例中，人工智能说“根本原因是数据库过载”，这似乎是合理的。但工程师确认了指标：事件发生时数据库负载正常。真正的原因是外部 DNS 问题。人工智能的最初假设虽然不稳定，但却是错误的。数据验证防止了报告发表时得出错误的结论。
四个可复制模板
1) 事件发生时的快速分诊：
我们正在经历一场生产活动。隐藏的症状：[症状]。上次更改：[上次部署/更改]。给我：(1) 按概率顺序排列的 3 个最可能的根本原因假设，(2) 将在 1 分钟内验证每个假设的命令/指标，(3) 最快的 SAFE 缓解步骤（例如回滚）。严格来说；声明我必须验证每个假设。
2）无辜的尸检草图：
根据下面的事件记录写出一份无可指责的事后草图。部分：摘要、影响（用户/持续时间/成本）、时间线、根本原因、哪些进展顺利、哪些进展糟糕、行动项目（每个项目都有所有者 + 日期字段）。重点关注命名、流程和系统。备注：[蒙面]
3）5个为什么分析：
构建一条“5 个为什么”链，从以下症状开始：[症状]。显示每一步是否有多个可能的分支。在每个“为什么”旁边写下我将查看以验证它的证据（日志/指标）。最后，标记哪些步骤尚未验证。
4）创建可操作的项目：
根据这个根本原因，建议可采取行动的项目，以防止同一事件再次发生。按以下方式对每个项目进行分类：(a) 预防、发现或减少，(b) 估计工作量，(c) 影响。按最高影响/努力比排序。根本原因：[X]
弱提示/强提示
Weak：“服务崩溃了，怎么办？”
结果：没有上下文；人工智能可以提出不适合您情况的一般建议，甚至可以提出明确的根本原因。
Strong：“生产支付服务已经给出了 5xx 5 分钟。最后一次部署是在 6 分钟前。按概率顺序给出 3 个最可能的根本原因假设，告诉将验证每个假设的命令，并建议最快的安全缓解措施。不要具体，说明我需要验证。”
区别：第二个提示给出症状、时间、最后一次变化；它需要假设+验证+还原，并使人工智能不精确。
常见错误
- 在缓解之前寻找确切的根本原因。它可以延迟止血并增加 MTTR。
- 未经验证就发表了人工智能的第一个假设。报告中泄露了流动但虚假的根本原因。
- 指责性的语言。匿名撰写的事后分析会助长隐瞒和重复错误。
- 以行动为导向的报告，没有要点。没有所有者和日期的提案永远不会被实施。
- 共享事件数据而不屏蔽它。事后调查面向广大受众；秘密/个人数据被泄露。
- 没有提前准备回滚路径。如果逆转不切实际，则减慢速度。
总之
事件管理是指快速检测、缓解、解决不可避免的事件并从中学习； MTTD 和 MTTR 是关键指标。黄金法则是“先缓解，后调查”，恢复到已知良好的版本通常是最快的缓解措施。人工智能在总结事件发生时的日志、缩小假设范围以及在事件发生后生成无可指责的事后分析草图方面具有无价的价值，但您有责任用数据验证每个根本原因假设、清除指责语言并掩盖事件数据。
应用任务
考虑一个过去（或虚构）的事件。 （1）让AI利用“现场快速分诊”模板生成假设和验证步骤；注意哪个假设可以被数据证实。 （2）使用“无罪尸检大纲”模板草拟一份报告，并填写事实。 (3) 确定至少两个可操作的项目，并为每个项目指定所有者和日期。
清单
- [ ] 事件发生时，我首先想到的是缓解（回滚/关闭），而将根本原因留到了后来。
- [ ] 我用 log/metric 验证了 AI 的每一个根本原因假设。
- [ ] 我用不责怪事后的语言写的，重点是流程和系统。
- [ ] 我为每个可操作项目分配了一个所有者和一个日期。
- [ ] 我从提供给人工智能的事件数据中掩盖了秘密和个人信息。
- [ ] 我根据影响正确分配了严重性级别。