事件管理Skill：把 SRE 事件响应方法论装进 AI 助手
- 它是什么：一个以 Google SRE 原则为基础的事件管理指导型技能，覆盖检测、分类、声明、缓解、沟通、复盘全流程。
- 它解决什么：团队没有统一的事件分级、没有值班和升级规则、事后复盘变成"追责大会"、MTTR 长期降不下来。
- 怎么用：安装后在对话中直接描述你的团队规模与故障场景，技能会输出分级标准、角色分工、值班轮换、运行手册、复盘模板等结构化方案。
- 和工具的区别：PagerDuty、Opsgenie、incident.io 是"承载流程的平台"，本技能是"设计流程的顾问"，两者互补而非替代。
- 适合谁：SRE/运维团队、技术负责人、值班经理、正在搭建或重构事件响应体系的研发组织。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 事件管理Skill |
| 英文名 | managing-incidents |
| 技能ID | 13406 |
它解决什么问题
很多团队并不缺监控和告警，缺的是"告警响了之后怎么办"的统一答案。谁来判断严重程度？谁负责对外发声？什么时候该回滚、什么时候该查根因？事故结束后复盘该产出什么？这些问题如果每次都靠临场发挥，结果就是响应延迟、信息混乱、复盘流于形式。本技能把这些隐性经验固化成一套可复用的方法论：严重性分类、事件角色、值班管理、响应工作流、通信协议、运行手册、无责事后分析、指标与持续改进，全部给出明确口径。
一键安装的思路与步骤
AI 技能的安装通常遵循"找到技能 → 安装到客户端 → 验证生效"三步，本技能同样适用：
- 确认前提：你的 AI 客户端或编程助手需要支持"技能（Skill）"机制，即允许加载外部技能包并在对话中被调用。具体支持范围以官方说明为准。
- 定位技能：在技能市场或技能库中搜索英文名
managing-incidents，或直接使用技能ID13406精确查找。安装入口、安装命令与是否需要授权，以官方说明为准。 - 完成安装：按平台指引将技能添加到你的工作区或本地技能目录，安装后通常无需额外配置即可在会话中调用。
- 验证是否生效：安装完成后，向助手提一个明显的"事件管理"问题，例如"我们有 5 人的运维团队，帮我设计 SEV0 到 SEV3 的分级标准和 1 周一轮的值班表"。如果回答中出现分级定义、事件指挥官（IC）、通信负责人等结构化内容，说明技能已正常工作；如果只是泛泛而谈，建议检查技能是否被正确启用。
该技能的主要功能和特点
- 四级严重性分类（SEV0–SEV3）：从"服务完全中断、支付停机"到"外观问题"，每级都给出影响描述、响应时效和典型示例，并配套一棵可逐步判断的严重性决策树。
- 明确的角色分工：定义事件指挥官（IC）、通信负责人、主题专家（SME）、记录员四类角色，并说明按严重性如何配人——SEV2/SEV3 单人响应，SEV1 配 IC 与 SME，SEV0 配齐四个角色。
- 值班轮换设计：提供"主+备"、跟随太阳（跨时区三班）、分层升级三种轮换模型，并给出 1 周轮换时长、30 分钟交接仪式、每晚上限 2–3 次通知等具体约束。
- 端到端响应工作流：从检测、分类、声明、调查、缓解、解决、监控到关闭，再到 48 小时内的事后分析，形成闭环。
- 通信协议：内部事件频道命名规范（如
#incident-日期-主题）、战室启用条件、对外状态页四阶段（调查中、已识别、监控中、已解决），以及客户邮件与合规通知（如数据泄露 72 小时内）的时机。 - 运行手册（Runbook）标准结构：触发条件、严重性、先决条件、可复制粘贴的步骤、验证方式、回滚方案、负责人、最后更新日期，八要素齐全。
- 无责事后分析流程：强调"假设良好意图、关注系统而非个人"，给出 48 小时内复盘、5 个为什么分析、行动项分配与跟进的完整流程。
- 指标与反模式清单：MTTA、MTTR、MTBF、事件频率、行动项完成率五大指标及目标值，并列出"延迟声明"“跳过复盘”“责备文化”“警报疲劳”"IC 亲自调试"等需要避免的反模式。
- 配套资源：包含严重性交互式分类脚本、运行手册示例、复盘模板、通信模板、值班交接模板与工具集成示例脚本。
和普通工具比强在哪：监控工具告诉你"出事了"，工单系统告诉你"有人认领了"，但都不会告诉你"现在该由谁指挥、多久更新一次状态、复盘该问哪五个问题"。本技能输出的正是这套"决策规则"，且以对话方式按需生成，不需要你先读完整本 SRE 书籍。
如何使用该技能？
第 1 步：把团队现状说清楚
不要只问"怎么做事件管理"，而要把约束条件交代完整。示例输入：
“我们是一个 6 人的后端团队，负责一个支付类 API，目前没有值班制度，出了事故都在一个群里临时喊人。帮我设计一套最小可用的事件响应流程。”
第 2 步：拿到分级与角色方案
技能会据此输出严重性分级表、角色配置和响应时效。输出通常包含：SEV0 需立即 24/7 通知并触达管理层；SEV1 工作时间通知、非工作时间升级并指定 IC；SEV2 走邮件或即时通讯告警、次工作日响应；SEV3 进工单队列按冲刺排期。
第 3 步：设计值班与升级政策
继续追问："在 6 人规模下，主备值班怎么排？升级到什么程度算合理？"可期望获得：1 周轮换、主备 5 分钟未确认即转备、30 分钟后无进展即升级、严重性升高时同步升级等规则。
第 4 步：用严重性决策树做判断
遇到真实事故时，可直接描述现象让技能辅助定级，例如：
“首页可以打开，但下单接口错误率约 15%，有部分用户投诉。这算几级？”
按技能的决策逻辑：生产未完全中断，主要功能降级；有变通方法（重试/稍后再试）则为 SEV1，无变通则可能升到 SEV0。也可以使用技能附带的交互式分类脚本（python scripts/classify-severity.py）逐题判断。
第 5 步：编写运行手册
请求："给我一份数据库主从切换的运行手册框架。"输出应包含触发条件、预期严重性、先决条件、编号步骤、验证方法、回滚步骤与负责人，且步骤要求是可复制粘贴的命令而非抽象描述。
第 6 步：事故后做无责复盘
把时间线贴给技能，要求生成复盘文档。典型输出结构：摘要、时间线、根因（用 5 个为什么推导到系统性原因）、影响范围、做得好的与出错的、行动项（含负责人与截止日期）。注意复盘应在 48 小时内完成，且全文避免出现"某某操作失误"这类归因到人的表述。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 事件管理Skill（managing-incidents） | 事件管理方法论顾问 | 分级框架、角色分工、值班设计、运行手册结构、无责复盘流程、指标定义 | 需支持 Skill 机制的 AI 客户端，安装后对话即用；具体门槛以官方说明为准 | 从零搭建流程、重构升级政策、复盘引导、培训新人 | 优势：开箱即得结构化方案，不绑定任何平台，成本低。不足：不承担告警、通知、状态页等实际执行职能 |
| PagerDuty | 企业级事件响应平台 | 告警聚合、复杂升级策略、值班排班、事件编排 | 需采购与配置，按用户订阅计费（官方标价约 19–41 美元/用户/月，以官方为准） | 10 人以上团队、升级策略复杂、预算充足 | 优势：成熟稳定、生态完善。不足：成本较高、配置偏重，方法论仍需自行沉淀 |
| Opsgenie | 告警与值班管理平台 | 灵活路由、值班排班、与 Atlassian 生态深度集成 | 与 Jira/Confluence 同栈时接入顺畅，按用户订阅计费（官方标价约 9–29 美元/用户/月，以官方为准） | 已在使用 Atlassian 产品的团队 | 优势：路由灵活、性价比相对好。不足：不提供方法论指导，流程设计仍靠人 |
| incident.io | 现代化事件响应协作平台 | Slack 原生的事件声明与协作、AI 辅助响应、自动生成复盘 | 以 Slack 为中心的团队接入快 | 5–50 人团队、Slack 深度使用文化 | 优势：协作体验轻快、上手快。不足：强依赖 Slack，脱离该生态价值下降 |
| 自建文档 + 人工培训 | 传统方式 | 用文档库沉淀流程、靠会议宣贯 | 零工具成本，但维护成本高 | 极小团队、临时应急 | 优势：灵活免费。不足：易过期、难检索、无结构化校验，人员流动后知识断层 |
可以看到，平台类工具解决"流程跑在哪里"，本技能解决"流程长什么样"。合理组合是先借助技能把分级、角色、值班、复盘规范设计出来，再落到 PagerDuty、Opsgenie 或 incident.io 上执行。
该技能的典型应用场景与实际体验情况
场景一：初创团队从零建立事件响应
角色是 5–10 人研发团队的负责人，痛点是"出事全靠吼，谁在线谁上"。使用方式是让技能按实施清单分阶段推进：第 1 周定义 SEV0–SEV3 与基础值班轮换、建立事件频道模板；第 2–3 周编写前 5 个高频故障的运行手册、配置状态页、做一次桌面演练；第 4 周起完成首次无责复盘并建立 MTTA/MTTR 看板。实际体验上，这类需求的上手难度低，只要把团队规模和业务类型说清楚，输出即可直接当规范初稿用。需要注意的是，输出只是"纸面流程"，桌面演练和真实事故才会暴露漏洞。
场景二：值班经理设计轮换与升级政策
角色是运维负责人，痛点是值班通知频繁、夜里被打断、主备交接靠口头。使用方式是让技能给出轮换模型对比，并结合"跟随太阳"方案解决跨时区夜班问题、用分层升级（初级值班→高级值班→架构师）过滤无效噪音。体验上，技能给出的"每晚上限 2–3 次通知，超过即升级"这类硬性约束很有操作性。注意事项：约束值要结合团队实际承载力调整，直接照搬容易造成升级过载。
场景三：事故后的无责复盘
角色是技术负责人或 IC，痛点是复盘会开成批斗会，行动项没人跟。使用方式是提供时间线与日志，让技能按固定结构生成复盘文档，并用 5 个为什么把"某人配置写错"追问到"缺少配置变更的校验与灰度机制"这一系统性根因。体验上，结构化模板能明显降低会议跑题概率。注意事项：无责文化无法靠模板自动实现，主持人仍需在会议中主动阻断追责式提问，并把行动项纳入冲刺规划跟踪，否则复盘就是白做。
场景四：优化 MTTR 指标
角色是 SRE 或工程效能负责人，痛点是平均修复时间久居不下。使用方式是让技能围绕 MTTA、MTTR、MTBF、事件频率、行动项完成率五个指标给出目标值（例如 SEV1 确认时间小于 5 分钟、修复时间小于 1 小时），再倒推差距来源——是告警设计不合理、运行手册不可执行，还是缺少自动化。体验上，把"改进"落到具体抓手比泛泛谈"加强监控"有效得多。
该技能能为用户带来的价值
效率提升：把原本需要翻阅 SRE 书籍、搜集多份行业指南、再开会讨论数轮才能产出的流程文档，压缩成几轮对话。分级标准、值班表、运行手册框架、复盘模板可以一次成型，按实施清单分四阶段推进，从基础到优化大致覆盖 1 周到 3–6 个月的节奏。
门槛降低：没有专职 SRE 的中小团队也能用上大厂级的实践。事件指挥官、通信负责人这类角色概念，以及"先缓解、后根因"这类判断原则，过去只存在于少数团队的肌肉记忆里，现在能被显式写进流程，新人按图索骥即可上手。
可量化收益：MTTA、MTTR、MTBF、事件频率、行动项完成率五个指标给了明确的观测口径与目标线，例如 SEV1 确认时间小于 5 分钟、修复时间小于 1 小时、关键服务 MTBF 大于 30 天、行动项完成率高于 90%。这些目标让"事件管理做得好不好"从主观感受变成可跟踪的数字。
长期价值：无责文化带来的是信息透明度的提升——人们愿意如实报告问题，系统缺陷才能被看见；行动项闭环机制则让每一次故障都转化为一次预防投入，形成"事件→复盘→行动项→预防→减少事件"的正循环。随着时间推移，团队积累的运行手册库和复盘知识库本身就是组织资产，能显著降低人员流动带来的知识流失风险。
常见问题 FAQ
Q1：这个技能怎么安装？会收费吗？
在支持 Skill 机制的 AI 客户端中，通过技能市场搜索英文名 managing-incidents 或技能ID 13406 找到它，按平台指引添加即可。安装入口、命令与是否需要付费，以官方说明为准；本文不对价格作任何承诺。安装后建议先用一个具体问题（如"帮我设计四级严重性标准"）验证是否生效。
Q2：它和 PagerDuty、Opsgenie 是什么关系，需要二选一吗？
不需要。它们解决的是不同层面的问题：本技能负责"设计流程"，包括分级口径、角色分工、值班规则、复盘模板；平台负责"执行流程"，包括发起告警、通知到人、维护状态页。推荐路径是先用技能把规则设计清楚，再选一个平台承载，避免工具先行却不知道流程该怎么定。
Q3：适合多大规模的团队？三五个人的小团队用得上吗？
用得上，而且小团队更容易快速落地。技能本身给出了按规模伸缩的配人方案：SEV2/SEV3 单人响应即可，SEV1 才需要 IC 加 SME，SEV0 才配齐四类角色。小团队可以先只做三件事——定分级、定值班、写前 3 份运行手册，等团队扩张后再补齐通信协议和指标看板。
Q4：它能不能直接帮我们处理正在发生的线上故障？
不能。它是方法论与文档生成型技能，不接入你的监控系统，也不具备告警、电话通知、状态页发布等执行能力。它的价值在于事前把流程和运行手册准备好、事中辅助判断严重性、事后引导复盘。真正的故障止血仍需要人和平台工具来完成。
Q5：技能里给出的严重性分级和指标目标能直接照搬吗？
建议作为起点而非终点。分级中的示例（如 API 完全下线属 SEV0、15% 错误率属 SEV1）具有较强通用性，但指标目标（如 SEV1 修复时间小于 1 小时）需要结合你的业务形态、技术债状况和团队规模校准。比较稳妥的做法是先按技能建议落地，运行一到两个月后依据实际数据回头调整阈值。