2. PagerDuty 平台基础:账户注册、团队创建、服务与集成配置入门

PagerDuty 是值班自动化与事件响应领域的核心平台。本章将引导你完成从零开始搭建 PagerDuty 环境的完整流程,涵盖账户注册、团队结构设计、服务定义以及集成配置。这些操作是后续所有自动化基线核验与故障排查的物理基础。

2.1 账户注册与初始配置

访问 PagerDuty 官网,选择 “Start Free Trial” 进入注册流程。推荐使用企业邮箱注册,以便后续与 SSO(单点登录)或 SCIM(跨域身份管理系统)集成。

步骤 操作内容 关键注意事项
1 填写邮箱、姓名、密码 密码需满足复杂度要求(大小写+数字+特殊字符)
2 验证邮箱 检查垃圾邮件箱,验证链接 24 小时内有效
3 选择账户类型(Team/Professional/Enterprise) 入门建议选择 Team 或 Professional 计划
4 设置子域名(subdomain.pagerduty.com) 子域名全局唯一,建议使用公司缩写
5 完成初始向导(时区、默认通知规则) 时区必须与值班团队所在地一致
SRE 建议: 注册完成后立即启用 多因素认证(MFA)。路径:User Settings → Account → Multi-Factor Authentication。这是防止账户劫持的第一道防线。

2.2 团队创建与用户管理

PagerDuty 中的 Team 是权限与资源隔离的基本单元。每个团队可以拥有独立的服务、调度策略和用户。创建团队时,建议遵循“服务归属”原则:一个团队负责一组逻辑相关的微服务或基础设施组件。

2.2.1 创建团队流程

  1. 导航至 Teams → + New Team。
  2. 输入团队名称(如:core-platform-sre)和描述。
  3. 设置团队权限级别:Global(跨团队可见)或 Restricted(仅团队成员可见)。
  4. 邀请成员:输入邮箱地址,选择角色(Admin / User / Read-only User)。
  5. 点击 Send Invitations。

2.2.2 用户角色对比

角色 权限范围 典型适用场景
Admin 完全管理权限,可修改团队设置、删除服务 SRE 负责人、平台管理员
User 可创建/修改服务、配置集成、参与值班 一线值班工程师、开发人员
Read-only User 仅查看仪表盘、事件、报告,无法修改 技术经理、合规审计人员
常见陷阱: 不要将所有用户都设为 Admin。最小权限原则同样适用于 PagerDuty 平台。建议每个团队只保留 1-2 个 Admin 角色,其余成员使用 User 角色。

2.3 服务与集成配置

在 PagerDuty 中,Service 代表一个需要被监控和告警的逻辑实体(如:一个微服务、一台数据库服务器、一个 Kubernetes 集群)。每个服务必须绑定至少一个 Integration,用于接收外部监控系统(如 Prometheus、Datadog、Zabbix)发来的事件。

2.3.1 创建服务

  1. 进入 Services → Service Directory → + New Service。
  2. 填写服务名称(如:payment-api-prod)和描述。
  3. 选择归属团队(如:core-platform-sre)。
  4. 配置 Escalation Policy(升级策略):定义当一级值班人员未响应时,告警如何升级到二级、三级。
  5. 配置 Notification Rules:设置值班人员的通知渠道(电话、短信、邮件、Push)和延迟时间。
  6. 点击 Create Service。

2.3.2 集成配置(Integration)

集成是 PagerDuty 与外部监控系统的桥梁。创建服务后,进入 Integrations 标签页,点击 + Add Integration。PagerDuty 支持数百种预构建集成,以下为 SRE 场景中最常用的三种:

集成类型 监控系统 事件格式 配置要点
Events API v2 Prometheus / Alertmanager JSON Payload 获取 Integration Key,配置 Alertmanager 的 receivers
Generic Webhook 自定义脚本 / 自研监控 自定义 JSON 验证 Webhook URL,配置 HMAC 签名校验
Email Integration Zabbix / Nagios / 邮件告警 邮件正文 生成唯一邮箱地址,配置邮件过滤规则
核心概念:Integration Key —— 每个集成实例都有一个唯一的 routing_key(Events API v2)或 Webhook URL。这个 Key 是外部系统向 PagerDuty 发送事件的凭证,必须妥善保管,避免泄露。

2.4 事件流与集成架构

下图展示了从监控系统告警触发到 PagerDuty 创建事件的完整数据流。理解这个架构有助于后续排查“告警未到达”或“重复告警”等常见问题。

PagerDuty 事件流与集成架构图 PagerDuty 事件流与集成架构 监控系统 Prometheus / Datadog Alertmanager 告警聚合与路由 PagerDuty 集成层 Events API / Webhook 服务 & 升级策略 Escalation Policy 值班人员 电话 / 短信 / Push 关键集成参数 Integration Key (routing_key) Webhook URL / 邮箱地址

2.5 集成配置实战:Events API v2 示例

Events API v2 是 PagerDuty 推荐的集成方式,支持结构化 JSON 事件,包含 dedup_key(去重键)和 severity(严重级别)。以下是一个使用 curl 发送测试事件的示例:

# 替换 YOUR_INTEGRATION_KEY 为实际值
curl -X POST https://events.pagerduty.com/v2/enqueue \
  -H "Content-Type: application/json" \
  -d '{
    "routing_key": "YOUR_INTEGRATION_KEY",
    "event_action": "trigger",
    "dedup_key": "test-alert-001",
    "payload": {
      "summary": "API 响应时间超过 5s",
      "source": "prometheus-prod-01",
      "severity": "critical",
      "timestamp": "2025-01-15T10:30:00.000Z",
      "custom_details": {
        "service": "payment-api",
        "latency_ms": 5200,
        "threshold": 5000
      }
    }
  }'
验证集成是否成功: 发送测试事件后,前往 PagerDuty 控制台 Services → 对应服务 → Incidents 页面。如果看到一条新的 Incident,说明集成配置正确。如果未出现,检查 Integration Key 是否匹配、网络是否可达、事件格式是否合规。

2.6 基线核验清单

完成上述配置后,建议执行以下基线核验,确保平台基础就绪:

核验项 预期结果 核验方法
账户 MFA 已启用 登录时要求二次验证 退出登录,重新登录验证
团队用户已激活 所有受邀用户状态为 Active Teams → Members 页面查看
服务已关联升级策略 服务详情页显示 Escalation Policy 名称 Services → 服务 → Escalation Policies
集成测试事件成功 Incidents 列表出现测试告警 发送测试事件,检查 Incidents 页面
通知渠道可达 值班人员收到测试通知 手动触发测试 Incident,确认电话/短信/Push 到达
生产环境警告: 在将生产监控系统接入 PagerDuty 之前,务必在沙箱或测试服务中完成集成验证。错误的 Integration Key 或事件格式可能导致生产告警丢失,造成重大故障响应延迟。