深色模式
OnCall 机制总览
摘要：OnCall 不只是"轮流接电话"，而是一套把告警、责任人、响应时限和复盘串起来的责任闭环。本文从目标与角色切入，给出一套最小可行的值班配置清单，并附上可复制的自检命令，让新人第一天值班就知道该干什么。
适用环境
bash
# 值班机/跳板机建议具备的工具
for c in curl jq date awk ssh; do command -v $c >/dev/null && echo "$c OK" || echo "$c MISSING"; done
# 统一时区，避免排班与告警时间对不上
timedatectl set-timezone Asia/Shanghai
date -u1
2
3
4
5
6
2
3
4
5
6
操作步骤
第 1 步：先定义"值班要交付什么"
值班的交付物只有三个：响应、止损、交接。任何排班设计都要服务这三件事。
- 响应：告警到达后多久被人工确认（ACK）
- 止损：先恢复业务，再查根因
- 交接：无法解决时如何交给下一个人
第 2 步：明确三种角色
| 角色 | 职责 | 是否需全程在线 |
|---|---|---|
| Primary 主值班 | 接收告警、首次响应、止损 | 是 |
| Secondary 备值班 | Primary 超时未响应时接手 | 是 |
| 指挥 IC | 严重事件中做决策与对外沟通 | 事件触发 |
第 3 步：建立值班生命周期
bash
# 一轮值班的标准动作，建议存为 oncall-check.sh
cat > oncall-check.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
echo "== 值班开始自检 =="
echo "时间(UTC): $(date -u '+%F %T')"
echo "1. 告警通道已登录并置顶"
echo "2. 已确认排班表上的 Primary/Secondary"
echo "3. 已打开监控大盘与 Runbook 索引"
echo "4. VPN / 堡垒机 / 生产权限可用"
curl -sS -o /dev/null -w '监控面可达: HTTP %{http_code}\n' "${MONITOR_URL:-http://127.0.0.1:9090}/-/healthy"
EOF
chmod +x oncall-check.sh && ./oncall-check.sh1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
第 4 步：定义响应指标
把"多久算慢"写成数字，否则无法改进：
- 告警触达率：100%
- 首次响应 ACK：≤ 5 分钟
- 严重事件升级：ACK 超时 10 分钟自动升级
第 5 步：为每一次值班留痕
bash
# 值班日志目录，按周归档
mkdir -p oncall-log/$(date +%G-W%V)
cat >> oncall-log/$(date +%G-W%V)/primary.md <<EOF
## $(date -u '+%F %T') 值班开始
- Primary: 我
- 待跟进: 无
EOF1
2
3
4
5
6
7
2
3
4
5
6
7
验证
bash
# 1. 自检脚本可执行且输出时间
./oncall-check.sh
# 2. 日志已落盘
ls -1 oncall-log/$(date +%G-W%V)/
# 3. 模拟告警：确认自己真的会被叫到（非生产时段执行）
curl -sS -X POST "$ALERT_WEBHOOK" -d '{"msgtype":"text","text":{"content":"[演练] OnCall 自检，无需处理"}}'1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
常见坑
只把值班当"接告警"
没有止损手册和升级路径时，值班会变成个人英雄主义。机制的成熟度取决于"最弱的一班"能否按流程处理。
权限到值班时才发现问题
生产权限、VPN、堡垒机没提前验证，事故当晚才发现登不上，白白消耗 MTTR。
用私人手机/私人账号接警
人员离职后告警无人接管。告警通道与接收人必须是团队账号或可继承的配置，禁止写死个人手机号。