故障生命周期管理
一句话：故障不是”出了再处理”，而是一条检测→响应→缓解→恢复→复盘→改进的流水线——每个环节有标准动作、有角色分工、有 SLA 约束。
故障生命周期全景
graph LR
DETECT[1.检测<br/>告警触发] --> ACK[2.响应<br/>On-Call 确认]
ACK --> TRIAGE[3.分级<br/>确定 SEV 级别]
TRIAGE --> MITIGATE[4.缓解<br/>止血措施]
MITIGATE --> RESOLVE[5.恢复<br/>根因修复]
RESOLVE --> POST[6.复盘<br/>Postmortem]
POST --> IMPROVE[7.改进<br/>Action Items]
IMPROVE --> DETECT
各环节详解
1. 检测（Detection）
| 信号源 | 检测方式 | 延迟 | 覆盖 |
|---|
| 监控告警 | SLO 燃烧率 + 黄金信号 | 1-5 min | 依赖监控覆盖 |
| 用户反馈 | 客服 → 运维通道 | 5-30 min | 兜底手段 |
| 主动探活 | 合成监控（Synthetic） | 1 min | 核心路径 |
| 异常检测 | AIOps 智能检测 | 1-5 min | 补充盲区 |
# 检测 SLA
detection_sla:
SEV1: "< 2 min" # 核心服务必须在 2 分钟内检测到
SEV2: "< 5 min"
SEV3: "< 15 min"
2. 响应（Acknowledge）
告警触发 → 通知 On-Call → On-Call 确认接收
响应 SLA:
SEV1: 5 分钟内 Ack（超过升级到 L2）
SEV2: 15 分钟内 Ack
SEV3: 30 分钟内 Ack（工作时间）
3. 分级（Triage）
| 级别 | 定义 | 响应要求 | 通知范围 |
|---|
| SEV1 | 核心服务不可用 / 数据丢失 | 5 min 内响应，全员介入 | 技术 VP + SRE + 开发 |
| SEV2 | 核心服务降级 / 非核心不可用 | 15 min 内响应 | SRE + 开发负责人 |
| SEV3 | 单实例故障 / 性能下降 | 30 min 内响应（工作时间） | SRE on-call |
| SEV4 | 潜在风险 / 非用户可感知 | 工单跟踪 | 工单系统 |
4. 缓解（Mitigation）
目标：尽快止血，恢复用户可用性——不追求根治
缓解手段（按速度排序）:
1. 回滚（最快，秒级）→ ArgoCD rollback
2. 扩容（分钟级）→ kubectl scale / HPA 触发
3. 流量切换（分钟级）→ DNS / LB 切换
4. 降级（分钟级）→ 关闭非核心功能
5. 限流（秒级）→ 限制入口流量
6. 重启（秒级）→ kubectl rollout restart
5. 恢复（Resolve）
目标：根因修复，确认完全恢复
恢复验证:
├── SLI 恢复正常（成功率 > SLO）
├── 告警自动 resolved
├── 用户体验恢复正常（无投诉）
└── 错误预算消耗停止
6. 复盘（Postmortem）
参考 无指责复盘与故障分析方法论
7. 改进（Improve）
Action Items 闭环:
├── 短期修复 → 1 周内完成
├── 长期改进 → 2-4 周内完成
├── 流程改进 → 1 个月内完成
└── 定期 Review → 每周跟踪进度
故障指挥体系
graph TD
IC[Incident Commander<br/>故障指挥官] --> COMMS[Comms Lead<br/>沟通负责人]
IC --> OPS[Ops Lead<br/>操作负责人]
IC --> DEV[Dev Lead<br/>开发负责人]
COMMS --> USER[用户沟通<br/>状态页更新]
COMMS --> INTERNAL[内部沟通<br/>管理层同步]
OPS --> SRE[SRE<br/>执行操作]
DEV --> DEVS[开发<br/>代码修复]
IC -.->|决策| DECISION[回滚/扩容/降级<br/>决策点]
| 角色 | 职责 | 谁来当 |
|---|
| IC（指挥官） | 统筹决策、不参与具体操作 | 最了解系统的人 |
| Comms | 对内对外沟通、状态页更新 | 不参与技术操作的人 |
| Ops | 执行操作（回滚/扩容/切换） | SRE on-call |
| Dev | 代码修复、根因排查 | 服务负责人 |
关键原则：IC 不做操作，只做决策。操作的人不思考全局，思考全局的人不操作。
故障状态页
故障状态页模板:
[SEV1] api-gateway 部分用户 502
状态: 调查中
开始时间: 2026-08-03 14:22
影响: ~15% 请求失败
当前进展: 已定位到新版本内存泄漏，正在回滚
---
[更新 14:25] 回滚操作已触发
[更新 14:30] 回滚完成，502 错误率下降
[更新 14:35] SLI 恢复正常，故障解决
[更新 14:40] 故障复盘已启动，预计 48h 内完成
故障管理工具
| 工具 | 用途 | 替代方案 |
|---|
| incident.io / FireHydrant | 故障生命周期管理 | 自建工单系统 |
| PagerDuty / 飞书机器人 | 告警通知与值班 | Alertmanager + 企微 |
| StatusPage.io | 用户状态页 | 自建静态页 |
| 语音桥 | SEV1 紧急沟通 | 腾讯会议/飞书语音 |
常见问题 / 坑点
| 问题 | 原因 | 解决方案 |
|---|
| 缓解优先级错（先查根因） | 工程师习惯先查再修 | 缓解优先于根因——先止血 |
| 没有指挥官 | 大家都在操作没人统筹 | 指定 IC，IC 不操作 |
| 复盘太晚 | 等了一周才复盘 | SEV1 48h 内，SEV2 一周内 |
| 状态页不更新 | 忘了或嫌麻烦 | 每 15 分钟更新一次，SEV1 强制 |
| 同类故障反复 | 改进措施没落地 | Action Items 跟踪 + 月度回顾 |
关联知识
状态