深色模式
事件分级 Sev
摘要：分级不是给事故"打分"，而是决定投入多少人力与沟通成本。本文给出一套以用户影响为唯一尺度的 Sev1~Sev4 定义、对应 SLA，以及把分级写进告警标签的落地方式。
适用环境
bash
# 分级要能被机器识别，因此需要体现在告警标签中
grep -rn 'severity' /etc/prometheus/rules/*.yml | awk -F'severity: ' '{print $2}' | sort | uniq -c1
2
2
操作步骤
第 1 步：以用户影响定级
| 级别 | 判定标准（满足任一） | 响应 SLA | 沟通要求 |
|---|---|---|---|
| Sev1 | 核心功能全量不可用 / 数据丢失风险 | 5 分钟 ACK，15 分钟止损 | 立即通知 + 状态页 |
| Sev2 | 核心功能部分受损 / 明显降级 | 15 分钟 ACK | 群同步 + 负责人 |
| Sev3 | 非核心功能受损 / 有 workaround | 当班处理 | 群同步 |
| Sev4 | 内部体验问题、无用户影响 | 排期处理 | 工单 |
第 2 步：把分级写进告警规则
yaml
- alert: CheckoutUnavailable
expr: sum(rate(http_requests_total{path="/checkout",code=~"5.."}[5m])) / sum(rate(http_requests_total{path="/checkout"}[5m])) > 0.3
for: 2m
labels:
severity: critical # critical -> Sev1, warning -> Sev2/3, info -> Sev4
sev: "1"
annotations:
summary: '下单接口错误率 > 30%'1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
第 3 步：自动初始化响应动作
bash
# 收到 critical 时自动建事件频道并记录起点时间
cat > sev-open.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
sev=$1; title=$2
start=$(date -u '+%F %T')
mkdir -p incidents/"$(date +%F)"
echo "sev=$sev start=$start title=$title" >> incidents/"$(date +%F)"/timeline.md
echo "已记录 Sev$sev 起点: $start"
EOF
chmod +x sev-open.sh && ./sev-open.sh 1 "下单不可用"1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
第 4 步：允许升级与降级
bash
# 分级可随时间调整，但必须留痕
cat >> incidents/"$(date +%F)"/timeline.md <<EOF
$(date -u '+%F %T') 升级 Sev2 -> Sev1：影响范围扩大到全量用户
EOF1
2
3
4
2
3
4
第 5 步：争议处理规则
分级有分歧时，按就高不就低处理，事后在复盘里校准定义。禁止为了"SLA 好看"压低级别。
验证
bash
# 1. 所有告警规则都带 severity/sev 标签
for f in /etc/prometheus/rules/*.yml; do
grep -L 'severity:' "$f" && echo "$f 缺 severity"
done
# 2. 用 promtool 校验规则语法
promtool check rules /etc/prometheus/rules/*.yml
# 3. 时间线文件已生成
cat incidents/"$(date +%F)"/timeline.md1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
常见坑
按"技术严重度"而非"用户影响"定级
全库 CPU 100% 但用户无感，不该定 Sev1；反之一个小功能页面白屏但用户大量投诉，就是 Sev2。
级别与告警一一对应、无法调整
真实事故中影响会变化。分级必须支持人工升降级并留痕。
用定级结果追责
一旦分级与绩效挂钩，团队会自发压低级别，指标全部失真。分级只用于资源调度，不用于考核。