升级策略指南

本指南涵盖灵王 OPS 中完整的升级工作流程：超时自动升级、多级升级链、将升级策略关联到告警规则，以及调试升级问题。

1. 什么是升级（超时未响应自动升级）

升级是灵王 Ops 在告警在定义的时间窗口内未被确认时，自动通知更多人员或更改通知渠道的机制。

它解决的核心问题： 凌晨 3:00 触发 critical 告警。值班工程师正在睡觉，12 分钟后才看到第一条通知。没有升级，告警会持续触发直到有人手动干预。有了升级，系统会在 5 分钟后自动寻呼副值班，然后在 15 分钟后寻呼团队负责人，确保告警始终得到处理。

工作原理：

告警触发 →（未确认 N 分钟）→ 升级到下一步 → 重复直到最高级别

升级仅对状态为触发中且未确认的告警触发。一旦告警被确认，升级时钟停止，对于该触发事件不再进行进一步的自动升级。

关键概念：

• 升级由时间（超时）触发，而不是告警内容。
• 每个升级步骤定义不同的通知目标（排班、团队或渠道）。
• 每个步骤有自己独立的超时时间，从到达上一步时开始计时。
• 告警一旦被确认或解决，升级立即停止。

2. 升级级别（Level 1 → Level 2 → Level 3）

升级策略被构建为线性级别链。每个级别代表通知紧急程度和范围的升级。

critical 告警的示例时间线：

00:00  告警触发 → Level 1 已通知（主要值班通过 SMS + Slack）
05:00  未确认 → 自动升级到 Level 2（副值班）
15:00  未确认 → 自动升级到 Level 3（团队负责人）
30:00  未确认 → 升级到 Level 4（工程经理）

级别顺序执行。系统不会跳过 Level 2 直接从 Level 1 到 Level 3，除非在 Level 2 配置了零分钟超时（见第5节）。

3. 创建升级策略

升级策略在左侧导航的告警 → 升级策略下管理。

字段

创建新策略

1. 进入告警 → 升级策略。
2. 点击新建升级策略。
3. 填写上述字段。
4. 点击创建。您将进入升级策略详情页，您可以在其中添加步骤。

4. 添加步骤（步骤：在 N 分钟后通知排班/团队/渠道）

创建升级策略后，您需要添加一个或多个升级步骤来定义发生什么以及何时发生。

步骤字段

通知类型

通过 UI 添加步骤

1. 打开升级策略详情页。
2. 点击添加步骤。
3. 选择通知类型。
4. 选择通知目标。
5. 输入之后（分钟）值。
6. 点击保存步骤。

示例：三步链

步骤 1：通知排班 "支付团队值班"   0 分钟后
步骤 2：通知团队 "platform-leads"    5 分钟后
步骤 3：通知渠道 "#incident-pager"    10 分钟后

这意味着：告警触发 → 立即通知主要值班。如果 5 分钟内未确认 → 通知团队负责人。如果再过 10 分钟仍未确认 → 呼叫事件渠道。

步骤排序

步骤按顺序执行。步骤 3 不能在步骤 2 之前触发。步骤 N+1 的超时时钟在上一步骤超时到期且未收到确认时开始。

5. 升级规则（超时、重试次数）

超时（之后 N 分钟）

每个步骤有可配置的超时。该值表示到达上一步后等待多少分钟再进入下一步。

超时值的一般规则：

重试次数

如果通知未能到达目标（例如，排班没有活跃的值班，或者渠道不可用），系统可以在进入下一步之前重复通知。

重试次数为 2 意味着：通知 → 等待超时 → 再次通知 → 等待超时 → 升级到下一步。

交接和转移

当步骤通知排班（值班轮换）时，系统呼叫此刻当前值班的人。如果在排班轮换发生后发生下一步升级，则新的值班收到通知。

升级边界

升级在以下情况停止：

• 告警被任何接收者确认。
• 告警被解决（手动或自动）。
• 达到升级策略的最后一步且其超时到期。

6. 将升级关联到告警规则

升级策略仅在明确关联到一个或多个告警规则时生效。没有此关联，告警遵循默认行为（无自动升级）。

如何关联

1. 进入告警 → 告警规则（或特定告警规则详情页）。
2. 找到升级策略字段。
3. 从下拉菜单中选择所需的升级策略。
4. 点击保存。

取消关联

要从规则中移除升级，请在升级策略字段中选择-- 无 --（或等效的空选项）并保存。

按严重级别路由升级

您可以使用标签匹配器基于严重级别标签将不同的升级策略关联到同一告警规则：

这通过创建具有相同告警表达式但不同严重级别标签匹配器和不同升级策略的单独告警规则来配置。

按团队路由升级

当同一告警可能影响多个团队时，您可以使用路由规则将告警导向正确的升级链：

# 将支付服务的告警路由到支付团队升级
{service="payment-service"} → 升级："支付团队升级"

# 将结账服务的告警路由到商务团队升级
{service="checkout-service"} → 升级："商务团队升级"

默认升级

如果没有关联升级策略，告警遵循系统默认：无自动升级，通知发送一次到配置的渠道。

7. 恢复（何时停止升级）

升级是有状态的——它跟踪每个触发事件达到的最高级别，并在告警进入终态或已确认状态时立即停止。

停止升级的条件

按告警状态的恢复行为

触发中 → 已确认： 升级停止。已确认的告警被视为"进行中"。如果再次触发（新评估周期新指纹），它会再次从 Level 1 开始升级。

触发中 → 已解决： 升级停止，告警关闭。不再发生进一步升级。

触发中 →（未确认，到达最后一步）： 升级在最后一步停止。告警保持触发。不再采取自动行动。运维人员必须手动确认或解决。

重新升级

如果告警被确认但根本原因未修复，它可能会再次触发。重新触发的告警（带新指纹或在解决条件清除后重新评估）会再次从 Level 1 开始升级。

升级状态是按触发事件计算的

升级状态绑定到特定的触发事件，而不是告警规则。如果告警 A 触发并升级到 Level 2，然后告警 A 被解决，同一告警规则的新触发将全新从 Level 1 开始。

8. 升级模拟/测试

在依赖升级策略处理 critical 告警之前，务必进行测试。灵王 Ops 提供两种测试方式：手动触发和空运行/模拟。

通过手动告警触发进行测试

1. 进入告警 → 告警规则。
2. 找到具有您要测试的升级策略的规则。
3. 点击规则行 → 操作 → 触发测试告警。
4. 立即触发带有测试标记的合成告警（如 __test_alert__=true 标签），以便识别和清理。
5. 观察告警详情页中的升级时间线，验证每个步骤在预期时间触发。

重要： 测试告警计入告警统计。测试后立即清理。

通过空运行/模拟进行测试（无真实通知）

一些团队运行评估升级策略但不发送真实通知的模拟模式：

1. 进入告警 → 升级策略。
2. 打开您要测试的策略。
3. 点击模拟。
4. 选择要使用的告警（真实的或模拟的）作为输入。
5. 模拟显示将达到哪些步骤以及何时达到，但不发送任何实际通知。

手动步骤推进

如果您不想等待真实超时进行测试：

1. 在每个步骤确认测试告警以确认收到通知。
2. 然后取消确认（某些系统允许）以重置升级时钟。
3. 或者简单地触发多个测试告警并让它们运行整个链。

验证清单

创建或修改升级策略后，验证：

• [ ] 所有通知渠道（Slack、PagerDuty、email）收到测试消息。
• [ ] 排班正确识别当前值班人员。
• [ ] 超时在预期时间精确触发（使用 1 分钟超进行测试）。
• [ ] 确认在正确步骤停止升级。
• [ ] 每个级别通知正确的团队/人员。

9. 常见模式

模式 1：标准值班升级（5分钟 → 15分钟 → 30分钟 → 主管）

critical 服务的最常见模式：

Level 1: 通知 "值班排班：主要"       0 分钟（立即）
Level 2: 通知 "值班排班：备用"     5 分钟（未确认）
Level 3: 通知 "团队负责人"          10 分钟（未确认）
Level 4: 通知 "工程经理"            15 分钟（未确认）

理由：主要值班先处理。沉默 5 分钟后，寻呼副值班。再过 10 分钟（共 15 分钟），通知团队负责人。再过 15 分钟（共 30 分钟），工程经理收到升级。

模式 2：关键基础设施快速升级（2分钟 → 5分钟 → 10分钟）

对于数据库、网络或核心平台服务，停机代价极高：

Level 1: 通知 "值班排班：DBA 团队"      0 分钟
Level 2: 通知 "值班排班：平台团队"      2 分钟
Level 3: 通知 "工程总监"                5 分钟
Level 4: 通知 "工程副总裁"              10 分钟

模式 3：Warning 告警（15分钟 → 30分钟）

较低严重级别告警获得更长的超时：

Level 1: 通知 "值班排班：主要"       0 分钟
Level 2: 通知 "团队负责人"            15 分钟

模式 4：多团队升级（交接）

当告警涉及多个团队时，升级链可以交接责任：

步骤 1: 通知 "值班排班：结账团队"   0 分钟
步骤 2: 通知 "值班排班：支付团队"   10 分钟
步骤 3: 通知 "结账工程经理"          20 分钟

模式 5：渠道升级（广播）

对于需要广泛可见性的重大事件：

Level 1: 通知 "值班排班：主要"         0 分钟
Level 2: 通知渠道 "#oncall-alerts"      5 分钟
Level 3: 通知渠道 "#incident-response"   10 分钟
Level 4: 通知 "CTO"（直接）             20 分钟

模式 6：计划维护窗口（维护期间无升级）

与静默结合使用（见告警.md 第8节）：

1. 维护前，为受影响的告警创建静默规则。
2. 静默阻止升级启动。
3. 维护后，使静默过期或移除——恢复正常升级。

10. 调试升级问题

当升级行为不符合预期时，系统性地检查系统的每一层。

症状：告警触发但 Level 1 无人收到通知

可能原因：

1. 告警规则未关联升级策略。检查规则的升级策略字段。
2. 通知渠道（Slack、PagerDuty）配置错误或禁用。在告警 → 通知渠道验证渠道是否活跃。
3. 告警触发时排班没有活跃的值班。进入值班 → 排班检查排班确认有人被指派。
4. 告警被静默。在告警 → 静默检查活跃匹配。

症状：升级从 Level 1 跳到 Level 3

可能原因：

1. Level 2 超时为 0 分钟。检查每个步骤的之后（分钟）值。
2. Level 2 通知目标没有有效接收人（空团队、损坏的渠道）。系统可能将此视为通知失败。检查重试次数是否设置为 0 且目标可到达。

症状：升级触发但通知未到达

1. 检查告警详情页中的告警时间线。每个升级步骤都记录在那里。
2. 如果时间线显示到达了该步骤但通知未到达，则问题在通知渠道（Slack 机器人不在频道中、PagerDuty 集成密钥被撤销、email 被拒绝等）。
3. 在告警 → 通知渠道检查通知渠道的集成状态。

症状：确认后升级未停止

可能原因：

1. 确认应用于不同的告警（标签相似但指纹不同）。在时间线中确认告警 ID。
2. 告警在确认后重新触发（确认应用于较早的触发事件，但新的触发事件已开始）。检查时间线中的告警指纹。

症状：升级太慢/超时未生效

1. 升级引擎按轮询间隔运行（例如每 30 秒）。5 分钟超时意味着升级可能在 5 分钟标记后最多 30 秒触发。这是设计运作方式。
2. 高系统负载可能延迟升级检查周期。如果持续发生，检查系统健康指标。

诊断步骤

1. 检查告警时间线 — 每个升级步骤、发送的通知、确认和解决都带有时间戳记录。
2. 验证升级策略关联 到正确的告警规则。
3. 确认排班在测试时间有活跃的值班。
4. 独立测试每个通知渠道 通过从告警 → 通知渠道发送测试消息。
5. 检查升级策略的步骤顺序 — 使用 UI 可视化确认步骤顺序正确且超时设置正确。

有用的过滤器

查找受升级问题影响的告警：

# 达到 Level 2 或更高级别的告警
 escalation_level >= 2, status=firing

# 过去一小时内触发且未确认的告警
 status=firing, fire_time > now()-1h, acknowledged=false

获取帮助

如果问题无法通过配置更改解决：

1. 收集告警 ID、告警规则名称、升级策略名称以及事件的大致时间。
2. 从告警详情页导出告警时间线。
3. 检查告警 → 升级策略 → [策略] → 审计日志以获取策略的任何最近更改。

快速参考

有关与升级交互的告警静默和抑制规则的信息，请参见告警管理指南。

有关升级步骤使用的通知渠道的信息，请参见通知配置。