告警升级策略怎么设计：4 步搭好事件升级的兜底方案

你在值班，告警响了，但故障出在你从没碰过的模块——怎么办？升级策略（Escalation Policy）就是为这一刻准备的兜底方案。本文用 4 步把它搭出来。

什么是事件升级与升级策略

事件升级指当前值班人（第一响应人）无法独自解决故障，需要引入更有经验或更对口的同事。

升级策略就是规定"怎么升"的一组规则，回答两类问题：

1. 第一响应人求助时，事件指派给谁？
2. 值班人超时未确认告警，接下来通知谁？比如第一顺位 5 分钟没 Ack，告警自动打给谁？

自动升级 vs 手动升级

• 自动升级：由告警平台按预设规则执行——主值班未确认，自动转备值班，再未确认转负责人。规则一次配置，系统替你盯；
• 手动升级：值班人主动把事件转给特定同事，常见两种路线：按层级（找上级）或按职能（找该模块的负责人）。

成熟的体系是两者混用：自动升级保证"告警永远有人接"，手动升级保证"专业的事交给专业的人"。

第一步：梳理事件的来源清单

事件要么由监控自动创建，要么人工上报。这里聚焦监控自动产生的部分——先搞清楚哪些服务、应用、系统会触发事件，再据此关联升级策略。

举个例子：你监控了网站 SSL 证书，证书过期或失效时监控器会产生事件。证书失效=用户完全打不开网站，严重级别显然是高。把这条记下来，关联到对应的监控器。

对所有能自动创建事件的监控项做同样梳理，最终得到一张表：

刚起步用"高/低"两级就够；要更精细再上 SEV1/SEV2/SEV3 分级（见本系列《严重级别详解》）。

第二步：按严重级别配置升级链

有了清单，就可以为不同级别设计不同强度的升级策略：

高严重级：立即通知主值班；5 分钟未确认自动升级备值班；再 10 分钟未确认升级团队负责人。半夜也照打不误。

低严重级：降低侵略性。工作时间发 IM 通知即可；周末和非工作时间不逐级叫人，攒到工作时间处理，或只记录不升级。

在观测云里，这套逻辑落在监控器 + 告警策略上：不同监控器绑定不同告警策略，策略里定义通知对象、通知方式和升级规则，超时未恢复或未确认即自动转下一级通知对象，无需人工盯梢。 1

升级策略严重依赖你的值班表。还没有值班表的，先看本系列《4 种值班排班模板》。

第三步：定好手动升级的使用规则

自动升级覆盖不了所有情况，手动升级要事先立规矩。最常用的两种：

• 层级升级（Hierarchical）：值班人搞不定 → 升给上级/资深同事 → 再不行继续往上，直到问题解决。适合责任链场景；
• 职能升级（Functional）：不问资历问对口——故障涉及谁负责的模块就转给谁。值班人发现事件超出自己知识范围时，按职能图直接找到模块负责人。

建议把"什么类型的故障找谁"写成值班手册（Runbook）里的一张速查表。好的人工升级路径是缩短 MTTR 的关键手段——值班人不用半夜翻组织架构图猜谁懂支付网关。

第四步：度量、复盘、持续调优

产品、组织、团队都在变，升级策略不是一次定终身，要定期回访团队要反馈。

度量响应表现：值班体系的终极目标通常是达成某个可用性指标（如 SLA 承诺的 99.9%）。MTTA（平均确认时间）、MTTR（平均解决时间）是核心 KPI——先把它们测出来，再试验不同的告警与升级配置，看哪种组合真正压低了这两个数。

度量值班幸福感：工程师的身心状态和 KPI 同等重要。定期 1:1 聊出定性反馈，和 KPI 数据对照着看。有些改动短期提指标、长期耗人心，要警惕这种失衡。

观测云的事件与告警记录天然沉淀了每次触达、确认、恢复的时间线，可直接用于 MTTA/MTTR 的统计与复盘。 1

常见问题（FAQ）

Q：升级几级合适？
一般 2-3 级。主值班 → 备值班 → 团队负责人是标准结构。超过 3 级说明前面的级别没接到告警（检查通知渠道），或事件本身该直接进全员战备流程。

Q：升级间隔设多久？
高严重级 5-10 分钟，低严重级 30 分钟到数小时。间隔太短会让备班和主班同时被打扰，违背升级的初衷。

Q：值班人不敢手动升级，怕显得无能怎么办？
这是文化问题。在复盘会上公开肯定"及时升级"的行为，把"死扛 2 小时才求助"列为反面案例。升级速度是专业度的体现，不是能力缺陷。

Q：自动升级会不会把半夜的小事也升级给负责人？
会——如果严重级别标错了。回到第一步重新审视你的来源清单，把"低级别但配置成电话轰炸"的监控项找出来降级。升级策略的质量 = 严重级别标注的质量。

参考资料

• 观测云监控器与告警策略配置