升级策略

定义谁被 page、什么顺序、首响应者不确认时何时升级。

为什么

一个 page 了人但无升级路径的告警是赌博 — 若那人在睡、开车或差网络，宕机就无人值守直到他们注意。升级策略把单点故障变链条：page 主，5 分钟无确认 page 副，15 分钟无确认 page 经理。这保证每个 SEV1 在有界时间内到达清醒的人，这是值班的全部意义。无升级则 MTTA（平均确认时间）无界，5 分钟宕机变 45 分钟因为主在洗澡。

何时使用

当你设置第一个值班轮换时。团队规模或地理变化时 revisit。

如何做

1. 定义严重性 → 响应时间 → 升级链
   - SEV1（收入降）：确认 <5m，解决目标 <1h；主 → 副 → 经理 → 总监
   - SEV2（退化）：确认 <30m；主 → 副
   - SEV3（次要）：下一工作日；仅主，无升级

2. 按严重性设确认和解决超时
   - SEV1：page 主；5m 无确认 → page 副；15m 无确认 → page 经理
   - 每次升级含原告警 + 已 page 的人（无"谁在？"困惑）

3. 用 paging 系统（PagerDuty/Opsgenie）非 Slack/DM
   - paging 系统自动处理排班、确认、升级和 follow-the-sun
   - Slack 消息被埋；page 覆盖静音模式并重复直到确认

4. SEV1 含"利益相关者通知"通道
   - 通讯负责人并行 page 做客户通讯（见 comms-protocol）
   - 经理被通知以便必要时为响应者解阻

5. 季度测试升级路径
   - 在 staging 触发测试 SEV1；确认按正确顺序到达正确的人
   - 真实 SEV1 中发现坏升级路径是双重宕机

示例

# PagerDuty 升级策略（terraform）
resource "pagerduty_escalation_policy" "payments_sev1" {
  name = "payments-sev1"
  num_loops = 2  # 重 page 主两次再放弃
  rule {
    escalation_delay_in_minutes = 5
    target { type = "user_reference"; id = pagerduty_user.payments_primary.id }
  }
  rule {
    escalation_delay_in_minutes = 10  # 5 + 10 = 15m 到副
    target { type = "user_reference"; id = pagerduty_user.payments_secondary.id }
  }
  rule {
    escalation_delay_in_minutes = 15  # 15 + 15 = 30m 到经理
    target { type = "user_reference"; id = pagerduty_user.payments_manager.id }
  }
}
# SEV1 告警 → 服务 → 此策略 → 主立即 page
# 主 5m 不确认 → 副 page
# 副 10m 不确认 → 经理 page
# 利益相关者通道：#incidents 并行 Slack 通知通讯负责人

常见问题

⚠经 Slack 或 DM 而非 paging 系统 page — 消息被聊天埋、不覆盖静音、无确认/升级逻辑。
⚠升级链止于主无副 — 主不可达时宕机等到他注意，MTTA 无界。
⚠升级到不能修问题的经理 — 经理角色是解阻非调试；链应先到技术副。
⚠从不测试升级路径 — 用户 ID 笔误或删账户静默坏升级，真实 SEV1 才发现。

最佳实践

✓用专用 paging 系统（PagerDuty/Opsgenie）带确认超时和自动升级 — SEV1 绝不靠 Slack 或 DM。
✓升级链先到技术副再到经理；经理工作是解阻响应者非调试宕机。
✓SEV1 含并行利益相关者通知使客户通讯立即开始，非响应者调试完才做。
✓季度用 staging SEV1 测试升级路径 — 确认每步在配置时间窗到达正确的人。