深色模式
事故定级标准
摘要：定级标准必须让两个不同的人对同一事件得出同一结论。本文给出以"影响用户数 × 功能重要性 × 持续时长"为轴的定级表、判定流程与争议处理规则。
适用环境
bash
# 定级需要可量化数据：影响面与时长
curl -sS --data-urlencode 'query=sum(rate(http_requests_total{code=~"5.."}[5m]))' \
http://127.0.0.1:9090/api/v1/query | jq -r '.data.result[].value[1]'
grep -rn 'severity' /etc/prometheus/rules/*.yml | head -51
2
3
4
2
3
4
操作步骤
第 1 步：三轴定义
bash
cat > severity.md <<'EOF'
| 轴 | 取值 |
| --- | --- |
| 功能重要性 | 核心交易 / 主要功能 / 辅助功能 / 内部 |
| 影响用户比例 | 全量 / 部分(>10%) / 少量(<10%) / 无 |
| 持续时长 | >30min / 5-30min / <5min |
定级规则（从高到低匹配，满足即定级）：
- Sev1：核心交易全量不可用，或有数据丢失风险
- Sev2：核心交易部分受损，或主要功能全量不可用
- Sev3：主要功能部分受损，或辅助功能全量不可用
- Sev4：其余有用户感知的问题
EOF1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
第 2 步：判定流程
bash
cat > classify.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
# 用法: ./classify.sh <功能重要性1-4> <影响比例1-4> <时长1-3>
f=$1; u=$2; d=$3
if [ "$f" -eq 1 ] && [ "$u" -eq 1 ]; then echo "Sev1"
elif [ "$f" -eq 1 ] || { [ "$f" -eq 2 ] && [ "$u" -eq 1 ]; }; then echo "Sev2"
elif [ "$f" -le 3 ] && [ "$u" -le 2 ]; then echo "Sev3"
else echo "Sev4"; fi
EOF
chmod +x classify.sh && ./classify.sh 1 2 21
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
第 3 步：把级别写进告警与工单
yaml
labels:
severity: critical # critical=Sev1, warning=Sev2/3, info=Sev4
sev: "2"1
2
3
2
3
bash
# 工单创建时带级别，便于统计
echo "$(date -u '+%F %T') sev=$(./classify.sh 1 2 2) title=下单部分失败" >> incidents.log1
2
2
第 4 步：允许调整但必须留痕
bash
cat >> incidents.log <<EOF
$(date -u '+%F %T') 调整 sev3->sev2 原因：影响范围扩大至全量用户
EOF1
2
3
2
3
第 5 步：争议处理
bash
cat > dispute.md <<'EOF'
规则：
1. 定级有分歧时，先按就高不就低执行
2. 24 小时内在复盘会上校准定义
3. 定级结果仅用于资源调度，不用于任何个人评价
EOF1
2
3
4
5
6
2
3
4
5
6
验证
bash
# 1. 同一输入得到稳定输出
./classify.sh 1 1 3; ./classify.sh 1 1 3
# 2. 所有事故日志都带级别
grep -c 'sev=' incidents.log
# 3. 无未定级事件
grep -v 'sev=' incidents.log | wc -l1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
常见坑
按技术现象定级（CPU 100%、磁盘满）
技术严重度不等于用户影响。定级唯一尺度是用户能否正常使用。
为了 SLA 好看压低级别
一旦定级与考核挂钩，数据全部失真。定级只决定投入多少人力与沟通成本。
定级后无人升级资源
定了 Sev1 却仍由一个人在排查，等于定级无效。级别必须直接触发对应的人力与沟通动作。