SRE事故管理：Severity分级与指挥官机制

可视化演示

展示SEV0-SEV3四级严重度分级影响范围、五阶段事故响应流程（检测到复盘）、各级别MTTR与复盘改进项完成率，交互切换理解事故管理核心机制。

Severity分级：分诊台的四色标签

急诊室的故事，永远从分诊台开始。不管推进来的是谁，护士只问两件事——“哪里最疼、影响多大”，然后在病历上贴一张标签：红色危重、黄色紧急、绿色普通。没有人会给所有病人贴同样的标签，因为抢救资源是有限的，必须先救最要命的。事故响应也一样：系统一告警，值班工程师就是那个分诊护士，他必须在一分钟内回答：这个故障影响了多少人、多少业务、多少收入？

在SRE实践中，这个回答被量化为三个维度的评分。第一个是“影响范围”：故障波及多少个服务、多少个可用区，就像车祸撞了几辆车；第二个是“用户感知”：用户能不能登录、能不能下单、页面是不是一直转圈，就像伤者还有没有意识；第三个是“SLO损失”：错误预算消耗速度、金钱损失、启动了多少次熔断。三项评分各自从1到4打分，最终严重度取三者中的最大值，而不是求平均。

$$\displaystyle S = \max(S_{\text{scope}}, \; S_{\text{user}}, \; S_{\text{sla}})$$

1. S 最终严重度：这是事故最终被贴上的等级标签，取值1到4，1最重、4最轻。

$$\displaystyle S$$

2. S_scope 影响范围分：故障影响的用户量、服务数、地域范围越大，分数越高。

$$\displaystyle S_{\text{scope}}$$

3. S_user 用户感知分：用户是否明显感知故障（白屏、超时、报错），感知越强烈分越高。

$$\displaystyle S_{\text{user}}$$

4. S_sla 指标损失分：SLO消耗速度与直接经济损失越大，分数越高。

$$\displaystyle S_{\text{sla}}$$

5. max 取最大值：哪个维度最危重就按哪个定级，防止“平均分”把险情掩盖成一场普通感冒。

$$\displaystyle \max(\cdot)$$

特别要强调的是，Severity不是贴上去就不变的。分诊护士会在抢救过程中反复观察：伤员血压掉了，标签就要从黄色改成红色；系统切走了流量，影响范围缩小，S2也可以降为S3。动态升降级是分诊台的灵魂——标签是给当下服务的，不是给面子用的。

回到急诊室：因为有了分诊台，S1病人不会被排队耽误，S4病人也不会被过度抢救。软件世界里，这套四色标签的意义同样如此——把稀缺的工程师注意力，精准投放到最要命的故障上。

指挥官机制：急诊室总指挥

分诊护士贴上红色标签的那一刻，急诊室总指挥出现了。注意，总指挥不是技术最强的主刀医生，他甚至不用自己上手做心肺复苏，他的任务只有一件：站在白板上方，让所有人的注意力都集中到一个大脑上。为什么需要这样一个人？因为抢救现场最常见的死因，不是没人会抢救，而是七八个专家七嘴八舌、各执一词、互相等对方下令——这在事故管理里叫“乱七八糟的救火”。

用一个数学公式就能看懂这个必要性。假设现场有 n 个人同时参与协调，如果没有总指挥，每个人都要和其他所有人确认“你干什么我干什么”，沟通链路的数量就是两两配对数。队伍越大，链路爆炸式增长，信息还没传到位，黄金抢救时间已经过去。

$$\displaystyle C_2(n) = \frac{n(n-1)}{2}$$

1. n 参与协调人数：事故现场同时行动、需要同步信息的工程师与业务方人数。

$$\displaystyle n$$

2. C_2(n) 两两沟通链路数：无指挥时，n个人彼此确认信息需要建立的交流边数。

$$\displaystyle C_2(n) = \binom{n}{2}$$

3. n(n-1)/2 组合公式：每个人都要和其他 n-1 个人建立联系，但每条链路被算了两遍，所以除以 2。

$$\displaystyle \frac{n(n-1)}{2}$$

Incident Commander 的权力边界需要定义清楚：他有权调动跨团队资源、有权宣布“暂不修复、先切流量”，但无权不听取技术专家的一线判断。他的职责是决策和协调，不是亲自动手改代码。这个角色还有明确的交接与终止机制——每接一次手，都要在白板上写下当前状态、已尝试动作和待办事项，就像急诊交班时护士要把监护仪读数逐项说清楚。

总指挥的价值，不是因为他比所有人都强，而是因为混乱中终于有一个“唯一声音”。急诊室的老主任常说：手术可以失败，指挥不能混乱。这也是事故管理的第一纪律。

响应流程：抢救四步法

分诊结束、指挥官就位，抢救正式开始。急诊室的抢救流程永远是标准化的：先保证呼吸和心跳，再止血，再拍片子确认病因，最后转普通病房观察。顺序不能乱——你要是在伤员大出血时先研究他有没有骨折，人早就没了。事故响应同样有一条固定的“抢救四步法”。

第一步是告警发现：监控系统或用户反馈告诉你“出事了”；第二步是初步分诊：用上一节的三维评分定级别、拉群、叫该叫的人；第三步是缓解止损：先让业务恢复可用——切流量、回滚、降级、熔断，止血永远是第一目标；第四步是恢复确认：验证业务指标回到正常，确认没有次生灾害，然后才谈得上“修复根因”。很多团队在最关键的第三步犯糊涂，总想先找出根因再动手，结果宝贵的十五分钟全耗在“为什么”上。

$$\displaystyle T_{\text{outage}} = T_{\text{detect}} + T_{\text{triage}} + T_{\text{mitigate}} + T_{\text{verify}}$$

1. T_outage 总宕机时长：从用户开始受影响，到业务完全恢复的总时间。

$$\displaystyle T_{\text{outage}}$$

2. T_detect 发现耗时：从故障发生到监控告警触达工程师的时间。依赖报警系统的覆盖率与准确率。

$$\displaystyle T_{\text{detect}}$$

3. T_triage 分诊耗时：从收到告警到完成分级、指挥官接管的时间。分诊卡和预案能把这段压到几分钟内。

$$\displaystyle T_{\text{triage}}$$

4. T_mitigate 缓解耗时：从开始处置到业务止血恢复的时间。这是提升空间最大的一段。

$$\displaystyle T_{\text{mitigate}}$$

5. T_verify 确认耗时：确认指标稳定、无次生故障的观察时间。

$$\displaystyle T_{\text{verify}}$$

这套流程最反直觉的地方在于“缓解”和“修复”是两件事。就像急诊医生先给伤员输血，而不是立刻推进手术室做根因手术。事故管理的第一目标永远是恢复服务，根因分析交给事后的复盘会。记住这个顺序，能救下很多本不该“背锅”的深夜。

抢救四步法之所以有效，是因为它把混乱的“救火”变成了有节奏的“走流程”。急诊室不会因为忙乱而跳过步骤，生产环境同样需要一个不会乱的固定套路。

沟通机制：家属通报板

抢救室外，家属焦急地等着；抢救室内，护士长每隔一段时间就会走出来，对家属说一句统一口径的话：“病人正在抢救，请耐心等待，有进展会第一时间通知您。”注意，护士长不会让每个医生都跑出来跟家属说一句自己的判断，因为医生之间还没对齐口径，家属听到“情况还行”和“情况很危险”就会崩溃。这就是事故沟通机制的雏形：一个出口，统一节奏。

事故响应里的沟通，本质是“信息的大规模并行分发”。如果每个工程师都去回复用户群、客户经理、老板私信，那和没有指挥官时的两两沟通爆炸一模一样。所以SRE标准做法是设立“沟通负责人”（也叫Customer Liaison），他是对外唯一出口，负责向三类人同步信息：外部用户、内部业务方与老板、以及作战室外的其他工程师。

沟通频率不是一成不变的，而是随时间递减。事故刚开始时，信息流动最快，可能每十五分钟就要同步一次；半小时后局势可控，就可以放宽到每小时一次。用一个简单的公式表达：第 k 次通报的间隔时间，是上一次的两倍。这样做既避免轰炸式刷屏，又保证没人被蒙在鼓里。

$$\displaystyle \Delta t_k = \Delta t_0 \times 2^{k}$$

1. Δt_k 第 k 次通报间隔：相邻两次对外状态同步之间的时间长度。

$$\displaystyle \Delta t_k$$

2. Δt_0 初始通报间隔：事故初期信息最不确定时的最短同步周期，比如15分钟。

$$\displaystyle \Delta t_0$$

3. 2^k 逐次翻倍系数：每多通报一次，间隔时间翻一倍，如同潮水退去，无需一直高亢。

$$\displaystyle 2^{k}$$

沟通机制还有一个铁律：所有对外信息必须由沟通负责人统一出口，任何工程师不得在个人社交账号上发布事故细节。就像急诊室里，只有护士长有权对家属开口。为什么要这么严格？因为对外说错一个字，就是一场公关事故——事故还没结束，第二场事故已经开始了。

家属通报板的意义不是“汇报”，而是“稳住”。信息越透明、节奏越可预期，作战室里的人就越能集中精力抢救，作战室外的人就越不会冲进来添乱。

升级路径：呼叫上级医生

急诊室的墙上挂着一张“呼叫值班表”：普通医生搞不定的，呼叫二线；二线搞不定的，呼叫三线主任；三线搞不定的，直接呼叫院长协调全院会诊。这串电话不是打给“更高级别”的，而是打给“更有资源和决策权”的。事故升级机制的逻辑与此一模一样——它不是惩罚，而是救援。

升级的第一个触发器是时间。每个Severity级别都有一个“响应时限”：S1事故必须15分钟内有人接管，S2是30分钟，S3可以放宽到60分钟。如果超过时限还没解决，就必须自动触发升级，就像抢救15分钟后血压还在掉，护士长必须立刻呼叫二线。把这个规则写成分级递增的时间窗口：第 i 个级别的时限，是基础时限乘以2的 i-1 次方。

$$\displaystyle T_{i} = T_0 \times 2^{\,i-1}$$

1. T_i 第 i 级响应时限：第 i 级事故需要在多长时间内完成接管和处置。

$$\displaystyle T_{i}$$

2. T_0 基础时限：最紧急的 S1 事故的响应底线，通常以分钟计。

$$\displaystyle T_0$$

3. 2^(i-1) 倍增因子：级别每升高一级（i增大），时限放宽一倍。

$$\displaystyle 2^{i-1}$$

升级的第二个触发器是影响范围变化。事故刚发生时可能只是某台机器负载高，十分钟后变成整个机房断电——影响范围扩大，就必须立刻升级，不用等时间窗口。此外还有“横向求助”：发现是数据库问题而当前团队不擅长，就直接呼叫DBA专家加入，这相当于大医院呼叫兄弟医院的专家带着设备来支援。还有一种“越级上报”：如果指挥官判断当前层面的资源已经不够，可以跳过中间层直接找VP或CTO，要求更大范围的组织干预。

响铃电话不是认输，是为了不让伤员在普通病房里无声地恶化。SRE的升级路径设计，本质上是给每一次事故配了一条“生命通道”：你永远可以向上求援，永远不该硬扛。

事后复盘：病例复盘会

病人脱离危险不等于故事结束。急诊科每周都会开一次“病例复盘会”：把上周的危重病例从头到尾放一遍录像，从救护车到达、分诊、抢接到转病房，逐个环节打分——不是给医生打分，而是给流程打分。为什么监护仪比预定时间晚响了十秒？为什么血库送血多用了四分钟？这些问题会变成一张改进清单，由专人跟进，下周会议检查闭环情况。这个机制，在SRE里叫“事后复盘”（Postmortem）。

复盘的第一步是重建时间线：把事故发生期间的所有事件按分钟排列，谁在何时做了什么、观测到什么。时间线是复盘的地基，没有它一切讨论都是空谈。第二步是根因分析：用“五个为什么”不断追问，找到系统层面的根本原因和流程层面的助推因素。第三步是产出行动项：每条行动项必须可执行、有负责人、有截止日期。最后也是最重要的，是“无指责文化”——复盘会上禁止问“这是谁的错”，只允许问“下一次怎么避免”。

复盘的闭环效果可以用一个行动项完成率来衡量：在既定周期内按期关闭的行动项，占总行动项的比例。一家成熟的SRE团队，这个比率通常保持在90%以上。如果复盘中发现的改进项无人追踪、无人关闭，那复盘会就沦为了形式主义的追责秀。

$$\displaystyle R_{\text{action}} = \frac{n_{\text{done}}}{n_{\text{total}}} \times 100\%$$

1. R_action 行动项闭环率：衡量复盘产出的改进任务有多少真正落地。

$$\displaystyle R_{\text{action}}$$

2. n_done 已完成行动项数：在约定时间窗口内关闭并验证有效的改进项数量。

$$\displaystyle n_{\text{done}}$$

3. n_total 总行动项数：本次复盘会产出的全部待办改进项数量。

$$\displaystyle n_{\text{total}}$$

4. ×100% 化为百分数：让结果直观呈现为可比的闭环率。

$$\displaystyle \times 100\%$$

失败的经验是贵重的资产，但只有沉淀成行动项才会有价值。就像急诊室不会因为一次成功的抢救就得意忘形——真正让他们越来越强的，是那张永远在更新的改进清单。复盘会不是批斗会，而是整个团队的一次“系统性打补丁”。

角色分工：抢救小队编制

一台大手术的成功，靠的不是一名天才医生，而是一支编制清晰的梯队：主刀、麻醉、巡回护士、器械护士，各管一摊，互相不越界。事故响应同样需要一张明确的“作战编制表”，每个人都知道自己该站着的位置，否则就会出现两个工程师同时改一个配置这种“抢手术刀”的乱象。SRE事故管理的标准角色分工，就是把急诊室的编制搬进作战室。

最常见的编制包括四个角色。第一个是值班工程师（Incident Responder）：相当于急诊值班医生，负责第一时间接警、分诊和初步处置。第二个是指挥官（Incident Commander）：相当于总指挥，只做决策和调度，不碰键盘。第三个是沟通负责人（Communications Lead）：相当于护士长，负责对外同步信息和安抚用户。第四个是业务联络人（Business Liaison）：负责把“技术故障”翻译成“业务影响”，向业务部门和老板说明损失与预期恢复时间。

每个角色都有清晰的职责边界，尤其是“指挥官不碰键盘”这条，是无数惨痛教训换来的纪律。指挥官一旦亲手去改配置，就没有人站在白板前看全局了，整个作战室就会瞬间退回“两两沟通”的混乱状态。在资源有限的小团队里，可以一人身兼两角，但“指挥官”和“动手修”这两个角色在逻辑上必须分离。

一个团队的任务总量是固定的，被多少个活跃角色分摊，决定了每个人的负载。简单来看，平均负载等于总工作项除以当前激活的角色数。但角色不是越多越好——人一多，沟通复杂度又指数上升，指挥官就需要重新收缩编制。

$$\displaystyle L = \frac{W_{\text{total}}}{R_{\text{active}}}$$

1. L 平均任务负载：每个角色的平均任务量，衡量编制是否合理。

$$\displaystyle L$$

2. W_total 总工作项：事故处置中所有需要执行的动作和决策总量。

$$\displaystyle W_{\text{total}}$$

3. R_active 激活角色数：当前实际参与处置的角色数量。

$$\displaystyle R_{\text{active}}$$

急诊室的编制看起来像是官僚主义，但正是这种“官僚主义”保住了无数人的命。每一次事故都是一场不看剧本的即兴演出，而角色分工就是那根让所有人不会撞车的轨道。在急流中，最危险的不是水太大，而是船上的人都在抢着掌舵却没人划桨。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""模拟事故管理中的 Severity 评级与升级判定。""" class SeverityAssessor:    def __init__(self):        self.scope = 1      # 影响范围评分 1-4        self.user = 1       # 用户感知评分 1-4        self.sla = 1        # SLO 损失评分 1-4        self.target = {}    # 各级响应时限表     def assess(self):        """三元评分取最大值，得到最终 Severity。"""        return max(self.scope, self.user, self.sla)     def set_targets(self, targets):        self.target = targets     def need_escalate(self, minutes):        """超过当前等级时限则触发升级。"""        limit = self.target.get(self.assess(), 60)        return minutes > limit     def suggested_action(self):        sev = self.assess()        if sev == 1:            return "S1: 立即拉取指挥官，全团队介入，优先止损"        if sev == 2:            return "S2: 通知二线专家，建立作战群，15分钟内接管"        if sev == 3:            return "S3: 按常规流程处置，记录时间线"        return "S4: 低优先级处理，后续补复盘" def main():    incident = SeverityAssessor()    incident.scope = 4      # 核心交易链路全部受影响    incident.user = 4       # 所有用户无法下单    incident.sla = 3        # SLO 在快速消耗    incident.set_targets({1: 15, 2: 30, 3: 60, 4: 240})     sev = incident.assess()    print("Severity:", sev)    print("建议动作:", incident.suggested_action())     minutes = 35    if incident.need_escalate(minutes):        print("等待时间已超过时限，触发升级流程")    else:        print("当前仍在响应时限窗口内") if __name__ == "__main__":    main()

1. def assess(self):定义了核心的分级函数，取三个维度评分的最大值，对应“分诊台贴标签”的动作。
2. self.scope = 4模拟某次大故障中“核心交易链路全部受影响”的高分输入。
3. limit = self.target.get(self.assess(), 60)根据当前等级查表获取响应时限，超时即触发升级。
4. need_escalate(minutes)判断是否需要升级的核心逻辑，等价于“超过时限呼叫上级医生”。
5. suggested_action()根据Severity给出对应的标准动作建议，让值班工程师按预案执行。

常见误区

面试题