事件响应基础：事件分类、响应生命周期、团队角色

说实话，我刚开始做运维那几年，一接到告警电话就头皮发麻。为什么？因为没有体系。不管是小故障还是大灾难，全凭直觉冲上去修。后来经历了几次被审计追着问“你们这次事件定性是什么级别？”“响应流程的每个阶段记录在哪？”才明白——事件响应不是“修好了就行”，它是一套有章法的工程实践。

这节课，我就把我这些年踩过的坑、梳理出的分类逻辑、生命周期模型和团队分工一股脑倒给你。你拿走就能用。

1. 事件分类：先分清楚你面对的是什么

很多人一上来就喊“出大事了！”。其实大部分情况是小问题。我在项目中定过一个原则：分类不准，响应就乱。不同类别的事件，需要的响应速度、升级路径、记录方式完全不同。

我通常按两个维度切：影响范围和紧急程度。组合起来就四类：

类别	影响范围	紧急程度	典型场景
P0 - 严重	核心业务完全中断，影响大量客户	最高，需立即启动	支付网关不可用、数据库主库宕机
P1 - 高	核心功能部分受损，用户体验明显下降	高，需快速响应	登录缓慢、关键API延迟飙升
P2 - 中	非核心功能故障，或影响部分用户	中，可计划修复	报表页面加载超时、旧版客户端报错
P3 - 低	无业务影响，仅内部感知	低，排期处理	日志告警阈值误报、监控图表渲染错位

我当初设计分类表时，还加了一列“是否触发升级流程”。P0自动拉群、呼叫值班主管；P1自动创建事件工单、通知一线负责人；P2/P3走常规缺陷管理。你想想看，如果每个小报错都拉整个SRE团队，大家迟早被吵到神经衰弱。

2. 响应生命周期：从发现到复盘，一个都不能少

事件响应不是“发现→修好→关单”那么简单。我常用的生命周期模型是6阶段法，每一个阶段都有明确动作和产出物。我以前带新人时就反复强调：哪怕你只花30秒处理了一个P3，也要走完这六步。

1. 识别与发现 —— 监控告警、用户反馈、巡检异常……这是源头。我习惯在告警规则上加“告警指纹”，比如“5xx比例触发+异常堆栈关键词”，能快速匹配已知场景。
2. 分类与定级 —— 用上面那套分类表，立刻判定P级。注意：定级可以上调，不能下调（除非有正式审批）。我犯过这错：把P0打成P2，结果两小时后业务全挂，被项目经理追着骂了三天。
3. 初步排查与响应 —— 先止血，再找根因。我最常见的动作是：摘流量、限流、重启、回滚。这个阶段要求速度，不追求完美解。
4. 根因定位与修复 —— 用日志、追踪、指标、事件时间轴拼出全貌。我个人喜欢画一个时间线图，把变更、告警、错误日志的时间戳标出来，异常点往往一目了然。
5. 恢复与验证 —— 确认业务指标回到基线，监控稳定运行至少10分钟（视业务而定）。另外别忘了通知相关方：客户、业务方、管理层。
6. 复盘与改进 —— 写事件报告（Postmortem），不追责，改流程。我建议用“5个为什么”追问到根本原因。

下面这张图把整个生命周期串起来了，你以后挂在工位旁边，每次处理事件都照着走一遍。

3. 团队角色：每个人都知道该干什么

事件响应最怕“一堆人忙成一团，却没人决策”。我经历过一次：数据库主从延迟，四个DBA同时ssh上去看，结果没人通知业务方，也没人做回滚决策。半小时后用户投诉炸了，老板才问“谁在负责？”——这就是角色不清的代价。

我推荐用三角色模型，再大的事件也足够撑起指挥体系：

• 事件指挥（IC） —— 决策者，不碰键盘。负责定优先级、调配资源、对外沟通、宣布恢复。说白了就是“总控”。
• 行动负责人（TL） —— 技术专家，带人动手排查。负责战术执行、信息同步给IC、提出方案建议。
• 通信联络员（COM） —— 信息。负责写事件时间线、在Slack/钉钉群同步进展、回复业务方和管理层。

你可以根据事件规模调整角色人数。P0事件可能需要2-3个TL（网络、应用、数据库各一个），P2事件IC和TL可以是同一个人（但不要跨级操作）。

对了，还有一点：角色不能抢。我在轮值手册里写死了：谁先接警，谁就是初始IC，直到有更高级别的人接手。指挥权转移必须有口头确认+群内at播报。不然你想想看，三个人都在自认为自己是IC，那不乱套？

角色	核心职责	需要的能力	典型输出
事件指挥（IC）	决策、调度、对外公告	全局思维、沟通力、抗压	事件优先级、恢复时间目标
行动负责人（TL）	技术排查、修复执行	系统技术栈精通、调试能力	根因分析报告、热修复方案
通信联络员（COM）	信息同步、时间线记录	文档能力、细心、条理	事件时间线、状态通报

最后说一句：事件响应不是一个人的英雄主义，是流程+角色+分类的组合拳。把这三种基础打扎实了，再遇到大故障，你心里就有底。我自己也是从手忙脚乱走到现在的——每做完一次复盘，把流程修一修，角色调一调，下次就能快几分钟。别小看这几分钟，关键时候就是钱和品牌。