监控告警与事故响应
系统跑起来只是第一步——能在故障扩散前发现并快速恢复，才是生产成熟度的真正标志。
告警体系架构
graph TB
subgraph 数据采集
M1[Prometheus 指标]
M2[结构化日志]
M3[分布式追踪]
end
subgraph 告警引擎
RULES[告警规则]
SILENCE[静默规则]
AM[Alertmanager]
end
subgraph 通知渠道
SLACK[Slack/钉钉]
PAGE[PagerDuty]
EMAIL[邮件]
end
subgraph 事故响应
TRIAGE[分级判断]
RUNBOOK[Runbook]
POSTMORTEM[事后复盘]
end
M1 --> RULES
M2 --> RULES
M3 --> RULES
RULES --> SILENCE
SILENCE --> AM
AM --> SLACK
AM --> PAGE
AM --> EMAIL
SLACK --> TRIAGE
PAGE --> TRIAGE
TRIAGE --> RUNBOOK
RUNBOOK --> POSTMORTEM
style TRIAGE fill:#fff3e0,stroke:#f57c00,stroke-width:2px
style POSTMORTEM fill:#c8e6c9,stroke:#388e3c,stroke-width:2px
告警分级标准
| 级别 | 响应时间 | 触发条件示例 | 通知方式 |
|---|---|---|---|
| P0 – 严重 | 5 分钟内 | 服务完全不可用、错误率 > 50% | 电话 + 页面 |
| P1 – 高 | 15 分钟内 | 延迟 P99 > 10 s、错误率 > 5% | IM 即时消息 |
| P2 – 中 | 1 小时内 | Token 用量超预算 20%、缓存命中率骤降 | IM 群组 |
| P3 – 低 | 下个工作日 | 个别接口慢、非关键任务失败 | 邮件汇总 |
关键告警规则示例
# Prometheus 告警规则（prometheus/rules/llm.yml）
groups:
- name: llm_production
rules:
- alert: HighErrorRate
expr: rate(llm_requests_total{status="error"}[5m]) /
rate(llm_requests_total[5m]) > 0.05
for: 2m
labels:
severity: P1
annotations:
summary: "LLM 错误率超过 5%"
runbook: "https://wiki/runbooks/llm-error-rate"
- alert: HighLatencyP99
expr: histogram_quantile(0.99,
rate(llm_request_duration_seconds_bucket[5m])) > 10
for: 5m
labels:
severity: P1
annotations:
summary: "P99 延迟超过 10 秒"
- alert: TokenBudgetAlert
expr: llm_token_cost_usd_total > llm_token_budget_usd * 0.8
labels:
severity: P2
annotations:
summary: "Token 消耗已达预算 80%"
事故响应标准流程
sequenceDiagram
participant A as 告警系统
participant B as 值班工程师
participant C as 事故指挥官
participant D as 团队
A->>B: 触发告警通知
B->>B: 确认 & 评估严重级别
B->>C: P0/P1 升级通知
C->>D: 拉起事故频道
D->>D: 并行排查（日志/追踪/指标）
D->>C: 定位根因
C->>D: 执行修复 Runbook
D->>A: 问题解决，关闭告警
C->>D: 48 小时内完成 Postmortem
实用 Runbook 模板
每条 P0/P1 告警都应对应一个 Runbook，包含以下固定章节：
- 症状描述 — 告警触发时用户/系统的表现
- 影响范围 — 受影响的服务、用户数量估算
- 排查步骤 — 按顺序列出具体命令/查询
- 常见修复方案 — 重启服务、切换模型、回滚版本
- 升级路径 — 15 分钟内无法修复时联系谁
事后复盘（Postmortem）要素
好的 Postmortem 聚焦在"系统性改进"而非"追责"：
- 时间线重建：事件发生 → 首次告警 → 发现 → 修复 → 恢复
- 根本原因分析（5 Whys）
- 影响量化：受影响用户数、收入损失、SLA 扣分
- 改进行动项：每条要有负责人和截止日期
行动清单
- [ ] 为核心指标（错误率、P99 延迟、Token 用量）配置 Prometheus 告警规则
- [ ] 建立 P0–P3 四级分级标准并写入值班手册
- [ ] 为每个 P0/P1 告警配置对应的 Runbook 链接
- [ ] 配置 Alertmanager 告警分组和静默规则，避免告警风暴
- [ ] 建立轮值 On-call 制度，确保 7×24 小时覆盖
- [ ] 每次 P0/P1 事故后 48 小时内完成 Postmortem 并归档
- [ ] 季度回顾 Postmortem 行动项完成情况