SRE 稳定性工程总览
一句话：SRE 不是”运维升级版”，而是用工程化手段把不确定性管理到可量化——用 SLO 定义”多稳才算稳”，用错误预算决定”能不能发版”，用 MTTR/MTBF 度量”故障恢复能力”，用 RCA 闭环”从故障中学习”。
为什么需要这篇总览
你的 vault 已有大量 SRE 相关碎片，但散落各处：
SLO SLI 错误预算与智能告警 — SLO 体系，但只是稳定性度量的一环K8s 故障排查方法论 — 排查框架，但偏 K8s 操作层02-Issues/ — 6 篇实战故障记录，缺系统性复盘方法论可观测性知识总览 — 监控底座，但没连到故障管理闭环
本篇把这些串成一条线：度量 → 检测 → 响应 → 恢复 → 复盘 → 改进，每一环都有对应的笔记。
稳定性工程全景图
graph TD
subgraph 度量层
SLO[SLO/SLI/错误预算]
MTTR[MTTR/MTBF 度量]
end
subgraph 预防层
CAP[容量规划]
HA[高可用架构]
CHG[变更管理]
CHAOS[混沌工程]
end
subgraph 检测层
MON[监控告警]
ANOM[异常检测]
end
subgraph 响应层
ONCALL[On-Call/值班]
INC[故障生命周期]
RUN[应急预案/Runbook]
end
subgraph 恢复层
RCA[根因定位]
HEAL[故障自愈]
DR[灾备容灾]
end
subgraph 改进层
POST[无指责复盘]
ACT[Action Items 跟踪]
end
SLO --> MON
MTTR --> POST
CAP --> HA
HA --> CHAOS
CHG --> INC
MON --> ONCALL
ANOM --> ONCALL
ONCALL --> INC
INC --> RCA
RCA --> HEAL
INC --> DR
RCA --> POST
POST --> ACT
ACT --> CAP
ACT --> HA
ACT --> CHG
SRE 核心原则（Google SRE 提炼）
三层防御体系
第一层：预防（减少故障发生频率 → 提升 MTBF）
第二层：检测与响应（降低故障影响时间 → 降低 MTTR）
第三层：恢复与改进（从故障中学习 → 持续提升）
关键指标体系
graph LR
subgraph 可靠性指标
MTBF[MTBF<br/>平均故障间隔时间]
MTTR[MTTR<br/>平均恢复时间]
MTTD[MTTD<br/>平均检测时间]
MTTA[MTTA<br/>平均响应时间]
MTTI[MTTI<br/>平均定位时间]
end
MTBF -->|提升| FREQ[降低故障频率]
MTTD -->|缩短| DETECT[更快发现问题]
MTTA -->|缩短| RESP[更快响应]
MTTI -->|缩短| LOCATE[更快定位根因]
MTTR = MTTD + MTTA + MTTI + MTTR_restore
| 指标 | 全称 | 含义 | 优化方向 |
|---|
| MTBF | Mean Time Between Failures | 两次故障之间的平均时间 | 冗余、变更管控、混沌验证 |
| MTTR | Mean Time To Recovery/Repair | 从故障发生到完全恢复的平均时间 | 缩短检测→响应→定位→恢复 |
| MTTD | Mean Time To Detect | 从故障发生到被监控告警发现的时间 | 监控覆盖率、异常检测 |
| MTTA | Mean Time To Acknowledge | 从告警到 On-Call 人员开始响应的时间 | 告警路由、值班机制 |
| MTTI | Mean Time To Identify | 从开始响应到定位根因的时间 | 排查方法论、工具链 |
| MTTR_restore | Mean Time To Restore | 从定位根因到完全恢复的时间 | 自愈、回滚、应急预案 |
核心公式：MTTR = MTTD + MTTA + MTTI + MTTR_restore。优化 MTTR 要分解到每个子环节，不能只看总数字。
与已有知识库的关联
| 已有笔记 | 在稳定性体系中的角色 |
|---|
可观测性知识总览 | 检测层底座——Metrics/Logs/Traces |
SLO SLI 错误预算与智能告警 | 度量层核心——SLO + 燃烧率告警 |
Metrics 与 Prometheus 实战 | 检测层工具——指标采集与查询 |
Grafana 可视化与告警 | 检测层工具——可视化与告警 |
K8s 故障排查方法论 | 定位层方法——K8s 场景的排查框架 |
CI-CD 最佳实践与安全 | 预防层——变更管控 |
Terraform 生产级实践 | 预防层——IaC 基础设施 |
企业级多智能体设计实战 | 改进层——AI 辅助运维 |
kagent 详解 | 恢复层——K8s Agent 框架 |
02-Issues/ 故障记录 | 改进层——实战复盘素材 |
学习路线
- 建立度量体系：SLO/SLI → MTTR/MTBF → 指标看板
- 补齐方法论：RCA → 无指责复盘 → 故障生命周期
- 建设预防能力：变更管理 → 容量规划 → 高可用架构 → 混沌工程
- 建设响应能力：On-Call → 应急预案 → 故障自愈 → 灾备容灾
- AI 赋能：SRE Agent → AIOps → LLM 辅助 RCA
概念速查
| 术语 | 含义 |
|---|
| SRE | Site Reliability Engineering，站点可靠性工程 |
| SLI | Service Level Indicator，服务等级指标（可量化） |
| SLO | Service Level Objective，服务等级目标（SLI 的门槛） |
| SLA | Service Level Agreement，服务等级协议（对外承诺，违反有赔偿） |
| Error Budget | 错误预算 = 1 - SLO，用于平衡可靠性与创新速度 |
| Toil | 琐事——重复的、可自动化的、无长期价值的运维工作 |
| Blameless Postmortem | 无指责复盘——找系统漏洞不找人背锅 |
| Runbook | 操作手册——标准化的故障处理步骤 |
| On-Call | 值班——随时响应告警的轮换机制 |
| RCA | Root Cause Analysis，根因分析 |
| RTO | Recovery Time Objective，恢复时间目标（允许的最大停机时间） |
| RPO | Recovery Point Objective，恢复点目标（允许的最大数据丢失量） |
| Chaos Engineering | 混沌工程——主动注入故障验证系统韧性 |
| Incident | 事件——影响服务正常运行的问题 |
| SEV | Severity，严重程度分级（SEV1 最高） |
参考资源
SRE 知识体系笔记索引
核心方法论
架构与规划
| 笔记 | 核心内容 | 关联JD |
|---|
| 容量规划方法论 | 压测分层，容量模型，趋势预测，HPA | JD-2 |
| 高可用架构设计总览 | RTO/RPO，冗余设计，故障转移，降级容错 | JD-2 |
| 弹性伸缩策略 | HPA/VPA/KEDA/Cluster Autoscaler | JD-2 |
| 变更管理全流程 | 变更分类，评审Checklist，Argo Rollouts，GitOps | JD-3 |
故障管理
工具与韧性
AI 赋能运维
状态