ga-curriculum/incident-response-and-postmortems
GitHub: ga-curriculum/incident-response-and-postmortems
一份面向AI/ML运维团队的事件响应与事后总结培训课程，帮助团队建立系统化的故障处理、根因分析与无指责复盘能力。
Stars: 0 | Forks: 0
# 事件响应与事后总结
**课程时长：** 120 分钟
## 模块概述
了解团队如何为事件做准备、做出响应并从中吸取教训。从开发环境过渡到生产环境会引入现实世界中的风险；因此，工程团队必须练习记录根本原因，并设计事后总结以推动系统和流程的改进。
## 课程分解
| 部分 | 主题 | 时长（分钟） |
|---------|---------------------------------------------------|--------------------|
| 1 | 有效事件响应的阶段 | 10 |
| 2 | 事件分析的结构化方法 | 25 |
| 3 | 设计无指责的事后总结与工具上下文 | 25 |
| 4 | 实验：事后总结模拟 | 60 |
**
## 目录
1. 有效事件响应的阶段
2. 事件分析的结构化方法
3. 设计无指责的事后总结
4. 工具上下文：重现故障
5. 实验：事后总结模拟
6. 总结与反思
## 1. 有效事件响应的阶段
**学习目标：** 概述 AI 运维中有效事件响应的各个阶段。
当生产环境中的 AI 系统发生故障时，混乱是最大的敌人。有效的事件响应依赖于一个结构化、可预测的生命周期，该周期能引导团队从恐慌走向问题解决。
在机器学习中，“事件”并不总是服务器崩溃；它可能是一种隐性故障。隐性故障是指基础设施运行正常，但系统未能正确执行其预期功能的任何情况——这包括特征过期、模型版本不匹配、特征编码错误、数据漂移或预测偏差。
### 事件严重级别
当事件发生时，首要决策是划分其严重级别，以确定升级路径和响应时间：
* **P1（优先级 1）：** 完全中断或严重的数据完整性故障。
* **P2（优先级 2）：** 服务严重降级。
* **P3（优先级 3）：** 影响有限或局部问题。
* **P4（优先级 4）：** 监控盲区或存在临时解决方案的轻微 Bug。
### 事件响应的六个阶段
1. **准备：**
在故障发生之前，设置告警、定义待命轮班机制并编写操作手册（用于响应特定故障模式的文档化操作程序集）。
2. **识别：**
检测问题（例如，通过 Grafana 告警检查特定于 AI 的 SLI，如数据新鲜度或模型输入过期），并确认事件的发生。
3. **遏制：**
止血。在 AI 领域，这通常意味着将流量路由到安全的启发式备用模型，以防止进一步的损害。
4. **解决：**
修复问题的根本原因（例如，修复损坏的特征管道）。
5. **恢复：**
部署修复程序，并小心地将主要的 AI 服务恢复至全流量状态。
6. **经验教训（事后总结）：**
以无指责的方式分析事件，以防止再次发生。
``` graph TD %% Define styles classDef prep fill:#e6f7ff,stroke:#1890ff,stroke-width:2px,color:#000; classDef active fill:#fff1f0,stroke:#f5222d,stroke-width:2px,color:#000; classDef recovery fill:#f6ffed,stroke:#52c41a,stroke-width:2px,color:#000; A[1. Preparation
Alerts & Runbooks]:::prep --> B[2. Identification
Anomaly Detected]; B:::active --> C[3. Containment
Activate Fallback Model]; C:::active --> D[4. Remediation
Fix Root Cause]; D:::recovery --> E[5. Recovery
Restore Primary Traffic]; E:::recovery --> F[6. Lessons Learned
Blameless Postmortem]; F -->|Process Improvement| A; ``` ### **实际案例：
失控的定价算法** 假设一家航空公司的动态定价模型突然将国际航班的价格定为 5 美元。 * *识别：*
财务监控仪表板触发警报，提示每个座位的收入大幅下降。
* *遏制：*
事件指挥官立即执行“紧急停止开关”，绕过 ML 模型并应用静态的基准定价规则。
* *解决与恢复：*
工程师进行调查，发现向模型输送数据的特征管道中存在 Bug。他们修复了该管道，恢复流量，并验证定价行为恢复正常。
## 2. 事件分析的结构化方法 **学习目标：** 应用结构化方法来记录和分析事件。 一旦眼前的紧急火情被扑灭，团队必须了解事件发生的*原因*。仅仅处理表面症状（例如，重启崩溃的服务器）而不了解根本原因，注定会导致事件再次发生。专业人员必须利用结构化方法，如**五个为什么**或**石川图（鱼骨图）**，深入挖掘潜在的系统性缺陷。 ### **实际案例：
ML 中的“五个为什么”** 1. *为什么？* 推理服务器内存耗尽并崩溃。 2. *为什么？* 模型的有效载荷大小增加了 400%。 3. *为什么？* 大量新的分类特征批次在没有进行降维的情况下被传递给了模型。 4. *为什么？* 自动化数据预处理管道缺少针对特征向量大小的数据验证检查。 5. *为什么？（根本原因）* 团队在“问题定义与业务理解”阶段没有为传入数据定义基线或约束条件。 ## 3. 设计无指责的事后总结 **学习目标：** 设计能够识别根本原因并提出系统性改进措施的事后总结。 事后总结是一份关于事件的书面记录，包含其影响、为缓解事件采取的行动、根本原因以及为防止事件再次发生而采取的后续行动。至关重要的是，事后总结必须是**无指责**的。应假设所有相关人员都是基于当时掌握的信息，出于最大的善意采取行动的。如果工程师害怕因犯错而受到惩罚，他们将会隐瞒信息。 ### **实际案例：
构建行动项** **一个糟糕的行动项**：
*“告诉 Dave 在更新模型权重时要更加小心。”*（聚焦于指责，依赖于人的记忆）。
**一个良好的行动项**：
*“实施自动化单元测试和 CI/CD 检查，以确保在部署前模型权重与先前版本的偏差不超过 10%。”*（系统性、自动化、无指责）。
## 4. 工具上下文：重现故障 当生产系统发生故障时，如果直接在实时服务器上调查 Bug，会面临引发进一步宕机的风险，因此无法安全地进行。 * **Docker：**
这款容器化工具允许工程师将损坏环境的精确镜像提取到本地。通过在 Docker 中运行系统，您可以安全地重现崩溃、逐步分析日志，并在一个完全隔离、可重现的沙盒环境中测试修复方案。
* **GitHub：**
一旦找到根本原因，GitHub 就可以跟踪修复问题所需的代码变更。GitHub Issues 或 GitHub Wikis 还可以作为事后总结文档的长期协作家园，从而创建一个可搜索的组织学习历史记录。
## 5. 实验：事后总结模拟 **实验目标：** 回顾模拟事件并制定改进计划。学习者将练习识别根本原因、记录经验教训并提出可靠性增强建议。 ## 6. 总结与反思 **反思问题：** 1. “无指责”文化实际上是如何提高 AI 系统的技术可靠性的？ 2. 纵观 ML 工作流的各个阶段，你认为哪个阶段最常成为生产事件中隐藏的根本原因？为什么？
在故障发生之前，设置告警、定义待命轮班机制并编写操作手册（用于响应特定故障模式的文档化操作程序集）。
2. **识别：**
检测问题（例如，通过 Grafana 告警检查特定于 AI 的 SLI，如数据新鲜度或模型输入过期），并确认事件的发生。
3. **遏制：**
止血。在 AI 领域，这通常意味着将流量路由到安全的启发式备用模型，以防止进一步的损害。
4. **解决：**
修复问题的根本原因（例如，修复损坏的特征管道）。
5. **恢复：**
部署修复程序，并小心地将主要的 AI 服务恢复至全流量状态。
6. **经验教训（事后总结）：**
以无指责的方式分析事件，以防止再次发生。
``` graph TD %% Define styles classDef prep fill:#e6f7ff,stroke:#1890ff,stroke-width:2px,color:#000; classDef active fill:#fff1f0,stroke:#f5222d,stroke-width:2px,color:#000; classDef recovery fill:#f6ffed,stroke:#52c41a,stroke-width:2px,color:#000; A[1. Preparation
Alerts & Runbooks]:::prep --> B[2. Identification
Anomaly Detected]; B:::active --> C[3. Containment
Activate Fallback Model]; C:::active --> D[4. Remediation
Fix Root Cause]; D:::recovery --> E[5. Recovery
Restore Primary Traffic]; E:::recovery --> F[6. Lessons Learned
Blameless Postmortem]; F -->|Process Improvement| A; ``` ### **实际案例：
失控的定价算法** 假设一家航空公司的动态定价模型突然将国际航班的价格定为 5 美元。 * *识别：*
财务监控仪表板触发警报，提示每个座位的收入大幅下降。
* *遏制：*
事件指挥官立即执行“紧急停止开关”，绕过 ML 模型并应用静态的基准定价规则。
* *解决与恢复：*
工程师进行调查，发现向模型输送数据的特征管道中存在 Bug。他们修复了该管道，恢复流量，并验证定价行为恢复正常。
## 2. 事件分析的结构化方法 **学习目标：** 应用结构化方法来记录和分析事件。 一旦眼前的紧急火情被扑灭，团队必须了解事件发生的*原因*。仅仅处理表面症状（例如，重启崩溃的服务器）而不了解根本原因，注定会导致事件再次发生。专业人员必须利用结构化方法，如**五个为什么**或**石川图（鱼骨图）**，深入挖掘潜在的系统性缺陷。 ### **实际案例：
ML 中的“五个为什么”** 1. *为什么？* 推理服务器内存耗尽并崩溃。 2. *为什么？* 模型的有效载荷大小增加了 400%。 3. *为什么？* 大量新的分类特征批次在没有进行降维的情况下被传递给了模型。 4. *为什么？* 自动化数据预处理管道缺少针对特征向量大小的数据验证检查。 5. *为什么？（根本原因）* 团队在“问题定义与业务理解”阶段没有为传入数据定义基线或约束条件。 ## 3. 设计无指责的事后总结 **学习目标：** 设计能够识别根本原因并提出系统性改进措施的事后总结。 事后总结是一份关于事件的书面记录，包含其影响、为缓解事件采取的行动、根本原因以及为防止事件再次发生而采取的后续行动。至关重要的是，事后总结必须是**无指责**的。应假设所有相关人员都是基于当时掌握的信息，出于最大的善意采取行动的。如果工程师害怕因犯错而受到惩罚，他们将会隐瞒信息。 ### **实际案例：
构建行动项** **一个糟糕的行动项**：
*“告诉 Dave 在更新模型权重时要更加小心。”*（聚焦于指责，依赖于人的记忆）。
**一个良好的行动项**：
*“实施自动化单元测试和 CI/CD 检查，以确保在部署前模型权重与先前版本的偏差不超过 10%。”*（系统性、自动化、无指责）。
## 4. 工具上下文：重现故障 当生产系统发生故障时，如果直接在实时服务器上调查 Bug，会面临引发进一步宕机的风险，因此无法安全地进行。 * **Docker：**
这款容器化工具允许工程师将损坏环境的精确镜像提取到本地。通过在 Docker 中运行系统，您可以安全地重现崩溃、逐步分析日志，并在一个完全隔离、可重现的沙盒环境中测试修复方案。
* **GitHub：**
一旦找到根本原因，GitHub 就可以跟踪修复问题所需的代码变更。GitHub Issues 或 GitHub Wikis 还可以作为事后总结文档的长期协作家园，从而创建一个可搜索的组织学习历史记录。
## 5. 实验：事后总结模拟 **实验目标：** 回顾模拟事件并制定改进计划。学习者将练习识别根本原因、记录经验教训并提出可靠性增强建议。 ## 6. 总结与反思 **反思问题：** 1. “无指责”文化实际上是如何提高 AI 系统的技术可靠性的？ 2. 纵观 ML 工作流的各个阶段，你认为哪个阶段最常成为生产事件中隐藏的根本原因？为什么？
标签：AI运维, ITIL, IT运维管理, MLOps, SRE, 事件分级, 事后分析, 偏差过滤, 工程实践, 应急响应流程, 故障排除, 故障模拟, 数据漂移, 无指责复盘, 机器学习系统, 根因分析, 模型偏差, 生产环境风险, 系统可靠性工程, 系统改进, 请求拦截, 运维培训, 静默故障