深色模式
OnCall 工具对比
摘要：选值班平台本质是选"谁能可靠地把人叫醒，并把过程留下记录"。本文给出四个硬性评估维度、三类方案的对比表，以及用开源组件自建最小值班平台的路径。
适用环境
bash
# 评估前先明确现有告警源（决定集成成本）
grep -rn 'receivers' -A3 /etc/alertmanager/alertmanager.yml | head -20
# 自建方案依赖容器环境
docker --version1
2
3
4
2
3
4
操作步骤
第 1 步：列出必须满足的硬指标
bash
cat > eval-checklist.md <<'EOF'
| 维度 | 硬性要求 |
| --- | --- |
| 告警接入 | 支持 Alertmanager / webhook 通用接入 |
| 排班 | 支持多层级轮值、换班、节假日 |
| 升级 | 支持 N 次未 ACK 自动升级到下一级 |
| 移动端 | 推送 + 电话/短信兜底，可静音策略 |
| 记录 | 每次告警有 ACK 人与时间，可导出 |
EOF1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
第 2 步：三类方案对比
| 方案 | 代表 | 优点 | 代价 |
|---|---|---|---|
| 商业 SaaS | PagerDuty、Opsgenie、VictorOps | 升级链完善、电话落地可靠 | 订阅费用、数据出境 |
| 开源可自托管 | Grafana OnCall、Alertmanager + 自建网关 | 可控、可内网部署 | 需自维护、电话需接第三方 |
| 极简自建 | Alertmanager + 机器人 + 排班脚本 | 成本最低、改造灵活 | 升级/统计需自己实现 |
第 3 步：选型验证——用一条真实告警打通链路
bash
# 向候选平台发一条测试告警，确认：到达 -> 认领 -> 升级 -> 恢复 全流程
curl -sS -X POST "$CANDIDATE_WEBHOOK" \
-H 'Content-Type: application/json' \
-d '{"status":"firing","commonLabels":{"alertname":"EvalTest","severity":"critical","service":"pay"}}'
echo "观察：多久收到通知？认领是否被记录？超时是否升级？"1
2
3
4
5
2
3
4
5
第 4 步：开源自建最小闭环
bash
# Alertmanager(路由) + Grafana OnCall(排班升级) + 机器人(IM 播报)
cat > docker-compose.yml <<'EOF'
services:
alertmanager:
image: prom/alertmanager:latest
ports: ["9093:9093"]
volumes: ["./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro"]
oncall:
image: grafana/oncall:latest
ports: ["8080:8080"]
EOF
docker compose config >/dev/null && echo "配置有效"1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
第 5 步：评估迁移成本
bash
# 统计现有告警规则与 receiver 数量，估算迁移工作量
echo "告警规则数: $(grep -rc 'alert:' /etc/prometheus/rules/*.yml | awk -F: '{s+=$2} END{print s}')"
echo "receiver 数: $(grep -c 'name:' /etc/alertmanager/alertmanager.yml)"1
2
3
2
3
验证
bash
# 1. 端到端测试告警能在 SLA 内到达
date -u '+%F %T' && curl -sS -X POST "$CANDIDATE_WEBHOOK" -d '{"commonLabels":{"alertname":"EvalTest"}}' -H 'Content-Type: application/json'
# 2. 未 ACK 时能升级
grep -c 'escalat' /var/log/oncall/*.log 2>/dev/null || echo "需人工观察升级行为"
# 3. 历史记录可导出用于统计
curl -sS "$CANDIDATE_API/incidents" -H "Authorization: Bearer $TOKEN" | jq 'length'1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
常见坑
只看功能列表不看通知可靠性
演示全绿但推送延迟 10 分钟，等于没有值班系统。选型必须做真实推送延迟测试。
忽略移动端的免打扰冲突
手机系统级免打扰会屏蔽通知。选型要验证"电话/短信兜底"在自己团队的手机上确实响。
排班数据只存在 SaaS 中
一旦服务不可达或停止订阅，排班与历史全部丢失。定期导出排班与事件记录做本地备份。