PagerDuty：事件管理与值班排班

FreeGuideOnline 最新 2026-07-01

什么是 PagerDuty 告警

PagerDuty 是一个事件管理和智能告警平台，能将来自监控工具的信号转化为可操作的“事件”，并通过电话、短信、邮件、移动推送等方式，在合适的时间找到合适的人。它解决的核心问题是：如何在系统出问题时，避免告警石沉大海，让正确的人立即介入。

对于初学者，需要理解几个关键概念：

  • 事件 (Event)：从监控工具发送到 PagerDuty 的一条记录，可能代表主机 CPU 过高、服务不可用等。
  • 告警 (Alert)：当事件符合一定条件（例如来自某个关键服务）时，PagerDuty 会生成告警，触发通知流程。
  • 事件 (Incident)：一个需要响应和解决的重大问题，通常由一个或多个告警合并、去重后产生。Incident 会贯穿“触发 - 确认 - 解决”的完整生命周期。

PagerDuty 能大幅降低告警噪音，避免“告警疲劳”，同时保证高优先级事件不会被遗漏。

快速上手：从零配置一个告警

1. 创建服务 (Service)

服务是告警的组织单元，通常对应真实系统中的一个组件，例如“订单服务”“数据库集群”。

  • 进入 Services → New Service。
  • 填写服务名称和描述。
  • 选择 集成类型 (Integration Type)，例如直接使用 API、Datadog、Prometheus 等。如果暂时没有外部监控，可选择 “Events API V2” 作为通用入口。
  • 点击保存后，系统会生成一个唯一的 集成密钥 (Integration Key)，所有告警源都需要这个密钥来发送事件到该服务。

2. 配置告警路由

每个服务都需要绑定一个 升级策略 (Escalation Policy)，决定告警发生后先通知谁、多久后未响应则升级给下一层。

  • 若还没有现成的升级策略，可在 Escalation Policies 页面新建。
  • 一个升级策略由多个 升级级别 (Level) 组成：
    • 第 1 级：立即通知某人或某待命组，重复通知间隔例如 5 分钟。
    • 第 2 级：如果 15 分钟内无人确认，通知第二层人员。
  • 将创建好的升级策略分配给服务。

3. 发送第一条测试告警

使用 Events API V2 发送一个简单的触发事件，测试链路是否畅通：

curl -X POST "https://events.pagerduty.com/v2/enqueue" \
  -H "Content-Type: application/json" \
  -d '{
    "routing_key": "你的集成密钥",
    "event_action": "trigger",
    "payload": {
      "summary": "测试告警：订单服务延迟过高",
      "severity": "critical",
      "source": "order-service"
    }
  }'

若配置正确，绑定的待命人员将立刻收到通知。此时在 PagerDuty 界面上也会出现一个处于 “triggered” 状态的 Incident。

值班排班与通知策略

为什么需要值班排班

PagerDuty 的核心价值之一是 按排班将告警精准路由至当前值班人，而不是群发消息导致无人认领。排班 (Schedule) 定义了谁在什么时间段轮值。

创建排班

  1. 进入 People → Schedules → New Schedule。
  2. 设定排班名称，例如 “核心团队日间轮值”。
  3. 指定时区（建议统一使用 UTC 或团队所在时区）。
  4. 添加 排班层 (Schedule Layers)：
    • 简单模式：直接拖拽用户到时间线上，或设置 “每天 09:00-17:00 张三，17:00-09:00 李四”。
    • 高级模式：使用 “Restriction” 定义班次的星期与时间窗口，并设置每 1 周或 2 周轮换的用户列表。

保存后，系统会自动计算出任意时间点的值班人，并在通知时引用该排班。

在升级策略中使用排班

将升级策略的通知对象设置为 “Schedule” 而非某个固定用户：

  • 编辑升级策略，在 Level 1 的通知目标选择刚创建的值班排班。
  • 可选地启用 “开启高级通知规则”，例如仅在工作日 09:00-18:00 通知，其他时间暂停。

这样一来，无论团队如何轮岗，PagerDuty 都会准确将告警发给当前在岗的人。

告警生命周期与操作

事件与告警的合并去重

PagerDuty 默认会对相同类型的事件进行智能合并，避免重复通知。你可以通过 告警分组 (Alert Grouping) 策略调整合并行为：

  • 基于时间：在指定时间窗口内收到的相同事件会合并为一个 Incident。
  • 基于内容：根据事件 payload 中的字段自定义合并规则（需要配置 Event Orchestration 或 Global Event Rules）。

良好的合并策略能有效降低告警噪音，例如多条“磁盘使用率过高”的告警合并为一条 Incident，而不是各自成一条。

处理 Incident 的标准流程

每个 Incident 都应经历以下状态转换，以保障问题被闭环处理：

  1. 触发 (Triggered)：Incident 生成，通知已发送。
  2. 确认 (Acknowledged)：值班人看到告警后手动或自动确认，表示“正在处理”。此时通知暂停（除非配置了重复提醒）。
  3. 解决 (Resolved)：问题修复完毕，Incident 关闭。所有相关告警随之标记为已解决。

操作入口包括 Web 界面、移动应用、短信回复、电话按键等。建议团队约定：所有告警必须在 X 分钟内确认，否则自动升级。

自动告警抑制与静默

  • 抑制规则 (Suppression)：当一个高优先级 Incident 触发时，自动抑制低优先级的关联告警。例如“数据库宕机”期间，不再发送“数据库查询慢”的告警。
  • 维护窗口 (Maintenance Windows)：在计划变更期间暂停特定服务的告警，避免人为操作触发大量无效通知。

这些功能可以在服务或集成页面的相应 Tab 下配置。

初学者常见配置误区与最佳实践

误区一：把所有告警设为最高优先级

PagerDuty 中的 severity 字段支持 critical、error、warning、info 四个级别。将所有告警设为 critical 会导致值班人精神紧绷、无法区分真正紧急的问题。应建立明确的优先级定义：

  • critical：影响核心业务，需要立即唤醒值班人。
  • error：部分功能受损，非工作时间可等待下一个工作日。
  • warning/info：仅记录，不触发通知，用于事后分析。

结合 通知规则，可以让 warning 级别的告警仅创建 Incident 而不打电话。

误区二：升级策略设置过于简单

只有一个 Level 且没有超时升级的策略，意味着“如果值班人睡着了或手机静音，告警将石沉大海”。务必至少设置两个 Level，且时间间隔合理：

  • Level 1：值班排班，5 分钟后重复提醒，15 分钟后超时。
  • Level 2：备选人员或技术经理，直接电话呼叫。

误区三：忽略分析反馈

PagerDuty 提供丰富的分析 (Analytics) 功能，包括：

  • 告警频率：哪个时间点告警最多？哪个服务最不稳定？
  • 响应时间：平均确认时间、解决问题的耗时。
  • 团队负载：谁经常在非工作时段处理告警？

定期回顾数据，可以驱动监控告警阈值的优化，减少不必要的打扰。

最佳实践小结

  • 服务拆分要细致：将“购物车服务”和“支付服务”分开，方便不同团队认领。
  • 使用 Runbook 关联：在 Incident 描述或自定义字段中附上处理手册链接，加速故障恢复。
  • 开启智能通知 (Intelligent Alert Grouping)：让平台自动合并流式告警。
  • 测试一切：配置完成后，从外部监控工具发送测试事件，验证通知链路和升级流程是否符合预期。

总结

PagerDuty 告警体系的核心在于 事件路由 + 升级策略 + 值班排班 的三位一体设计。掌握服务的创建、根据业务重要性设置合理的通知规则、并建立起规范的 Incident 处理流程，就可以构建一个健壮且人性化的告警响应机制。初学者可以从模拟一个小服务开始，发送几条测试告警，亲自体验从触发到解决的全流程，再逐步推广到实际生产环境。