深色模式
事件状态页
摘要：状态页是"用户不用问就知道发生了什么"的窗口。本文给出组件建模方法、事件更新的四段式写法，以及用容器自托管状态页并验证可访问的步骤。
适用环境
bash
docker --version
command -v docker-compose >/dev/null || echo "使用 docker compose 子命令"
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com1
2
3
2
3
操作步骤
第 1 步：只暴露用户能感知的组件
bash
# 组件粒度 = 用户认知粒度，不是服务拓扑
cat > status-components.md <<'EOF'
| 组件 | 对应服务 | 显示名 |
| --- | --- | --- |
| 网站 | web 前端 | 官网访问 |
| 下单 | order + pay | 下单与支付 |
| API | openapi 网关 | 开放接口 |
EOF1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
不要暴露内部中间件（如 Kafka、Redis），用户无法理解，只会造成困惑。
第 2 步：自托管状态页（示例）
bash
mkdir -p statuspage && cd statuspage
cat > docker-compose.yml <<'EOF'
services:
cachet:
image: cachethq/cachet:latest
ports:
- "8000:8000"
environment:
- APP_ENV=production
- APP_DEBUG=false
- DB_DRIVER=sqlite
volumes:
- cachet-data:/var/www/html/database
volumes:
cachet-data: {}
EOF
docker compose up -d1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
第 3 步：定义四种状态
| 状态 | 含义 | 何时用 |
|---|---|---|
| Operational | 正常 | 默认 |
| Degraded | 降级 | 部分用户受影响但可用 |
| Partial outage | 部分中断 | 明确功能不可用 |
| Major outage | 全面中断 | 核心不可用 |
第 4 步：事件更新四段式
bash
cat > status-update-template.md <<'EOF'
【investigating】我们收到下单失败的报告，正在排查。
【identified】已定位为支付依赖超时，正在处理。
【monitoring】已修复，正在观察 30 分钟。
【resolved】服务已恢复，本次影响时长 XX 分钟。
EOF1
2
3
4
5
6
2
3
4
5
6
第 5 步：把更新动作接到值班流程
bash
# 值班人执行：更新状态页并自动广播
cat > status-update.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
status=$1; body=$2
curl -sS -X POST "${STATUS_API}/incidents" \
-H "Authorization: Bearer ${STATUS_TOKEN}" \
-H 'Content-Type: application/json' \
-d "$(jq -n --arg s "$status" --arg b "$body" '{status:$s, body:$b, visible:1}')"
echo "状态页已更新: $status"
EOF
chmod +x status-update.sh
./status-update.sh investigating "正在排查下单失败问题"1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
验证
bash
# 1. 状态页可访问
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' http://127.0.0.1:8000
# 2. 组件列表返回正常
curl -sS http://127.0.0.1:8000/api/v1/components | jq '.data[].name'
# 3. 更新后能被读到
curl -sS http://127.0.0.1:8000/api/v1/incidents | jq '.data[-1].status'1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
常见坑
状态页常年"全绿"但用户投诉不断
说明组件建模与实际体验脱节。用拨测（黑盒探测）而非内部指标驱动状态页。
只在事故时才想起状态页
账号过期、无人有权限，事故当晚登录不上。每季度做一次"发一条测试事件"的演练。
未经确认就发布根因
对外写"数据库被误删"这类细节会引发二次舆情。对外只说现象与状态，根因留在内部复盘。