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 | 完成初始向导(时区、默认通知规则) | 时区必须与值班团队所在地一致 |
2.2 团队创建与用户管理
PagerDuty 中的 Team 是权限与资源隔离的基本单元。每个团队可以拥有独立的服务、调度策略和用户。创建团队时,建议遵循“服务归属”原则:一个团队负责一组逻辑相关的微服务或基础设施组件。
2.2.1 创建团队流程
- 导航至 Teams → + New Team。
- 输入团队名称(如:
core-platform-sre)和描述。 - 设置团队权限级别:Global(跨团队可见)或 Restricted(仅团队成员可见)。
- 邀请成员:输入邮箱地址,选择角色(Admin / User / Read-only User)。
- 点击 Send Invitations。
2.2.2 用户角色对比
| 角色 | 权限范围 | 典型适用场景 |
|---|---|---|
| Admin | 完全管理权限,可修改团队设置、删除服务 | SRE 负责人、平台管理员 |
| User | 可创建/修改服务、配置集成、参与值班 | 一线值班工程师、开发人员 |
| Read-only User | 仅查看仪表盘、事件、报告,无法修改 | 技术经理、合规审计人员 |
2.3 服务与集成配置
在 PagerDuty 中,Service 代表一个需要被监控和告警的逻辑实体(如:一个微服务、一台数据库服务器、一个 Kubernetes 集群)。每个服务必须绑定至少一个 Integration,用于接收外部监控系统(如 Prometheus、Datadog、Zabbix)发来的事件。
2.3.1 创建服务
- 进入 Services → Service Directory → + New Service。
- 填写服务名称(如:
payment-api-prod)和描述。 - 选择归属团队(如:
core-platform-sre)。 - 配置 Escalation Policy(升级策略):定义当一级值班人员未响应时,告警如何升级到二级、三级。
- 配置 Notification Rules:设置值班人员的通知渠道(电话、短信、邮件、Push)和延迟时间。
- 点击 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 / 邮件告警 | 邮件正文 | 生成唯一邮箱地址,配置邮件过滤规则 |
routing_key(Events API v2)或 Webhook URL。这个 Key 是外部系统向 PagerDuty 发送事件的凭证,必须妥善保管,避免泄露。
2.4 事件流与集成架构
下图展示了从监控系统告警触发到 PagerDuty 创建事件的完整数据流。理解这个架构有助于后续排查“告警未到达”或“重复告警”等常见问题。
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
}
}
}'
2.6 基线核验清单
完成上述配置后,建议执行以下基线核验,确保平台基础就绪:
| 核验项 | 预期结果 | 核验方法 |
|---|---|---|
| 账户 MFA 已启用 | 登录时要求二次验证 | 退出登录,重新登录验证 |
| 团队用户已激活 | 所有受邀用户状态为 Active | Teams → Members 页面查看 |
| 服务已关联升级策略 | 服务详情页显示 Escalation Policy 名称 | Services → 服务 → Escalation Policies |
| 集成测试事件成功 | Incidents 列表出现测试告警 | 发送测试事件,检查 Incidents 页面 |
| 通知渠道可达 | 值班人员收到测试通知 | 手动触发测试 Incident,确认电话/短信/Push 到达 |