SRE

SRE 的第一性目标最大化 MTBF（减少故障发生） + 最小化 MTTR（加速故障恢复）

一切机制、流程、工具，都是为这个目标服务的手段，而非目的本身。

一、SRE 的本质：稳定性工程，而非运维工具

1. SRE 是什么（原理层）

SRE（Site Reliability Engineering）本质是：

在可控成本下，通过工程化手段，系统性管理“失败必然性”的一门学科

其研究对象不是“系统是否会出故障”，而是：

2. 稳定性 ≠ 可用性 ≠ 运维

概念本质
可用性（Availability）结果指标
稳定性（Reliability）系统属性
SRE达成稳定性的工程路径

SRE 关注的是：系统在长期运行中，面对变化与失败的“整体韧性能力”。

二、稳定性工程的核心模型：故障生命周期状态机

1. 故障是一个“状态迁移过程”

所有故障都遵循同一个时间与认知演进模型：

正常运行  ↓（故障发生）未感知状态 —— MTTI  ↓（被发现）已感知未认知 —— MTTK  ↓（定位根因）已认知未恢复 —— MTTF  ↓（采取措施）已恢复未确认 —— MTTV  ↓（验证完成）稳定运行

2. MT* 指标不是指标集合，而是状态治理目标

阶段核心问题治理目标
MTTI什么时候知道“出事了”缩短感知时间
MTTK是否知道“为什么出事”缩短认知时间
MTTF如何最快恢复业务缩短恢复时间
MTTV是否真的恢复避免假恢复
MTBF多久再出一次事降低发生频率

SRE 的能力建设，本质是对每一个状态迁移进行系统性优化。

三、SRE 能力模型（能力层 → 机制层 → 工具层）

1. 能力层（长期稳定知识）

SRE 的核心能力可以抽象为五类：

  1. **故障预防能力**
  2. **故障发现能力**
  3. **故障认知能力**
  4. **故障恢复能力**
  5. **系统演进能力**

这是不随技术变化的稳定结构。

2. 机制层（组织与工程方法）

能力关键机制
故障预防架构设计、容量评估、持续交付治理
故障发现SLI、监控体系、On-Call
故障认知日志、链路、根因分析流程
故障恢复降级、限流、熔断、应急响应
系统演进故障复盘、混沌工程、改进验收

3. 工具层（可替换实现）

监控、日志、AIOps、链路追踪等 仅是能力的实现方式，不应成为体系核心。

四、稳定性衡量体系：SLI / SLO / 错误预算

1. SLI：用“用户感知”定义稳定性

SLI 选择原则：

  1. 能真实反映“是否稳定”
  2. 与用户体验强相关

VALET 模型（用户视角）

2. SLO：稳定性的目标约束，而非 KPI

SLO 的本质是：

系统“允许失败多少次”的工程化表达

原则：

  1. 核心系统更严格
  2. 直接依赖需一致
  3. 弱依赖必须具备治理能力
  4. 错误预算在链路层面共享

3. 错误预算：稳定性与效率的平衡器

错误预算状态工程策略
预算充足鼓励变更与创新
接近耗尽限制或冻结变更
已耗尽全链路暂停操作

这是 SRE 最重要的治理发明之一。

五、故障治理的组织模型（社会技术系统）

1. 故障发现：不是“报警”，而是“责任触发”

关键不在于：

而在于：

2. On-Call 与 War Room 的本质

On-Call 的目标不是轮班，而是：

确保任何时刻，系统都能迅速形成“最小可决策单元”

War Room 是：

3. 故障处理的优先级原则

  1. **先恢复业务**
  2. 再定位根因
  3. 疑难问题必须升级
  4. 信息必须持续同步

六、故障复盘：从经验总结到系统进化

1. 故障复盘不是“追责”，而是“系统改进”

复盘关注的不是：

而是：

2. 结构化复盘模型（四象限）

维度关注点
系统设计单点、级联、容量
工程实现发布、配置、自动化
流程机制On-Call、授权、沟通
认知组织误判、经验缺失

3. 故障归因的三原则（哲学层）

  1. **健壮性原则**：系统必须自愈
  2. **第三方默认不可靠**
  3. **根因往往不止一个**

七、SRE 体系的演进路径（成熟度模型）

阶段特征
人治运维依赖个人英雄
流程化运维规范 + 人工
工程化 SRESLO + 自动化
韧性系统混沌工程 + 自愈

SRE 不是一次建设完成的，而是组织能力的长期演进。

八、总结：这套体系解决什么问题？

SRE 不是“系统不出问题”，而是“系统出问题时，组织与系统都不会崩溃”。

关联内容（自动生成）