{"name":"SRE","id":"运维-SRE","content":"# SRE\n\n> **SRE 的第一性目标**\n> **最大化 MTBF（减少故障发生） + 最小化 MTTR（加速故障恢复）**\n>\n> 一切机制、流程、工具，都是为这个目标服务的手段，而非目的本身。\n\n---\n\n## 一、SRE 的本质：稳定性工程，而非运维工具\n\n### 1. SRE 是什么（原理层）\n\nSRE（Site Reliability Engineering）本质是：\n\n> **在可控成本下，通过工程化手段，系统性管理“失败必然性”的一门学科**\n\n其研究对象不是“系统是否会出故障”，而是：\n\n* 故障**是否可预期**\n* 是否**可快速发现**\n* 是否**可快速认知**\n* 是否**可快速恢复**\n* 是否**不再重复发生**\n\n---\n\n### 2. 稳定性 ≠ 可用性 ≠ 运维\n\n| 概念                | 本质         |\n| ----------------- | ---------- |\n| 可用性（Availability） | 结果指标       |\n| 稳定性（Reliability）  | 系统属性       |\n| SRE               | 达成稳定性的工程路径 |\n\nSRE 关注的是：\n**系统在长期运行中，面对变化与失败的“整体韧性能力”。**\n\n---\n\n## 二、稳定性工程的核心模型：故障生命周期状态机\n\n### 1. 故障是一个“状态迁移过程”\n\n所有故障都遵循同一个**时间与认知演进模型**：\n\n```\n正常运行\n  ↓（故障发生）\n未感知状态 —— MTTI\n  ↓（被发现）\n已感知未认知 —— MTTK\n  ↓（定位根因）\n已认知未恢复 —— MTTF\n  ↓（采取措施）\n已恢复未确认 —— MTTV\n  ↓（验证完成）\n稳定运行\n```\n\n---\n\n### 2. MT* 指标不是指标集合，而是状态治理目标\n\n| 阶段   | 核心问题        | 治理目标   |\n| ---- | ----------- | ------ |\n| MTTI | 什么时候知道“出事了” | 缩短感知时间 |\n| MTTK | 是否知道“为什么出事” | 缩短认知时间 |\n| MTTF | 如何最快恢复业务    | 缩短恢复时间 |\n| MTTV | 是否真的恢复      | 避免假恢复  |\n| MTBF | 多久再出一次事     | 降低发生频率 |\n\n> **SRE 的能力建设，本质是对每一个状态迁移进行系统性优化。**\n\n---\n\n## 三、SRE 能力模型（能力层 → 机制层 → 工具层）\n\n### 1. 能力层（长期稳定知识）\n\nSRE 的核心能力可以抽象为五类：\n\n1. **故障预防能力**\n2. **故障发现能力**\n3. **故障认知能力**\n4. **故障恢复能力**\n5. **系统演进能力**\n\n这是**不随技术变化的稳定结构**。\n\n---\n\n### 2. 机制层（组织与工程方法）\n\n| 能力   | 关键机制             |\n| ---- | ---------------- |\n| 故障预防 | 架构设计、容量评估、持续交付治理 |\n| 故障发现 | SLI、监控体系、On-Call |\n| 故障认知 | 日志、链路、根因分析流程     |\n| 故障恢复 | 降级、限流、熔断、应急响应    |\n| 系统演进 | 故障复盘、混沌工程、改进验收   |\n\n---\n\n### 3. 工具层（可替换实现）\n\n监控、日志、AIOps、链路追踪等 **仅是能力的实现方式**，不应成为体系核心。\n\n---\n\n## 四、稳定性衡量体系：SLI / SLO / 错误预算\n\n### 1. SLI：用“用户感知”定义稳定性\n\nSLI 选择原则：\n\n1. 能真实反映“是否稳定”\n2. 与用户体验强相关\n\n**VALET 模型（用户视角）**\n\n* Volume：系统承诺的容量\n* Availability：是否可用\n* Latency：延迟分位数，而非平均值\n* Errors：错误率\n* Tickets：人工介入频次\n\n---\n\n### 2. SLO：稳定性的目标约束，而非 KPI\n\nSLO 的本质是：\n\n> **系统“允许失败多少次”的工程化表达**\n\n原则：\n\n1. 核心系统更严格\n2. 直接依赖需一致\n3. 弱依赖必须具备治理能力\n4. 错误预算在链路层面共享\n\n---\n\n### 3. 错误预算：稳定性与效率的平衡器\n\n| 错误预算状态 | 工程策略    |\n| ------ | ------- |\n| 预算充足   | 鼓励变更与创新 |\n| 接近耗尽   | 限制或冻结变更 |\n| 已耗尽    | 全链路暂停操作 |\n\n这是 **SRE 最重要的治理发明之一**。\n\n---\n\n## 五、故障治理的组织模型（社会技术系统）\n\n### 1. 故障发现：不是“报警”，而是“责任触发”\n\n关键不在于：\n\n* 有多少监控\n\n而在于：\n\n* **谁被叫醒**\n* **谁有决策权**\n* **谁能调资源**\n\n---\n\n### 2. On-Call 与 War Room 的本质\n\nOn-Call 的目标不是轮班，而是：\n\n> **确保任何时刻，系统都能迅速形成“最小可决策单元”**\n\nWar Room 是：\n\n* 信息收敛中心\n* 决策中心\n* 行动协调中心\n\n---\n\n### 3. 故障处理的优先级原则\n\n1. **先恢复业务**\n2. 再定位根因\n3. 疑难问题必须升级\n4. 信息必须持续同步\n\n---\n\n## 六、故障复盘：从经验总结到系统进化\n\n### 1. 故障复盘不是“追责”，而是“系统改进”\n\n复盘关注的不是：\n\n* 谁犯了错\n\n而是：\n\n* **系统为什么允许这个错误发生**\n\n---\n\n### 2. 结构化复盘模型（四象限）\n\n| 维度   | 关注点           |\n| ---- | ------------- |\n| 系统设计 | 单点、级联、容量      |\n| 工程实现 | 发布、配置、自动化     |\n| 流程机制 | On-Call、授权、沟通 |\n| 认知组织 | 误判、经验缺失       |\n\n---\n\n### 3. 故障归因的三原则（哲学层）\n\n1. **健壮性原则**：系统必须自愈\n2. **第三方默认不可靠**\n3. **根因往往不止一个**\n\n---\n\n## 七、SRE 体系的演进路径（成熟度模型）\n\n| 阶段      | 特征        |\n| ------- | --------- |\n| 人治运维    | 依赖个人英雄    |\n| 流程化运维   | 规范 + 人工   |\n| 工程化 SRE | SLO + 自动化 |\n| 韧性系统    | 混沌工程 + 自愈 |\n\n> **SRE 不是一次建设完成的，而是组织能力的长期演进。**\n\n---\n\n## 八、总结：这套体系解决什么问题？\n\n* 让稳定性 **可设计**\n* 让故障 **可治理**\n* 让经验 **可传承**\n* 让组织 **可持续扩展**\n\n> **SRE 不是“系统不出问题”，\n> 而是“系统出问题时，组织与系统都不会崩溃”。**\n\n## 关联内容（自动生成）\n\n- [/运维/运维.md](/运维/运维.md) SRE是现代运维体系的重要组成部分，两者在理念、方法论、工具和自动化等方面有很强的关联性，运维体系中的SRE、可观测性、自动化等概念在SRE中同样适用\n- [/数据技术/数据运维.md](/数据技术/数据运维.md) SRE的理念和实践方法对于数据运维具有重要的指导意义，特别是在可靠性保障、SLI/SLO设定、错误预算管理、故障响应等方面，SRE为数据运维提供了工程化的解决方案\n- [/软件工程/DevOps.md](/软件工程/DevOps.md) SRE和DevOps都是重视开发和运维协作的文化和实践，通过自动化流程来提高软件交付的效率和可靠性\n- [/软件工程/架构/系统设计/可观测性.md](/软件工程/架构/系统设计/可观测性.md) 可观测性是SRE的重要技术手段，包括日志、指标、链路追踪等，是实现故障快速发现和恢复的基础\n- [/运维/AIOps.md](/运维/AIOps.md) AIOps利用AI和ML技术提升运维的自动化和智能化水平，是SRE自动化体系发展的高级阶段，可以实现更精准的故障预测、更智能的容量规划和更高效的运维决策\n- [/软件工程/安全生产.md](/软件工程/安全生产.md) 安全生产与SRE都关注系统的可靠性、可用性，包含故障响应、系统监控、容量与变更管理等方面的内容\n- [/运维/K8s.md](/运维/K8s.md) Kubernetes作为云原生应用的编排系统，其提供的资源调度、弹性伸缩、健康检查等能力与SRE的自动化理念高度一致\n- [/中间件/消息队列/消息队列.md](/中间件/消息队列/消息队列.md) 消息队列是现代分布式系统的重要组件，在SRE实践中需要关注其可靠性保证、性能优化、监控告警等方面\n- [/数据技术/数据治理.md](/数据技术/数据治理.md) 数据治理与SRE都关注系统的稳定性和可靠性，数据治理中的质量保障与SRE的错误预算管理有相似之处\n- [/运维/持续交付.md](/运维/持续交付.md) 持续交付是SRE的重要实践之一，通过自动化流程降低变更风险，提高交付效率\n","metadata":"tags: ['软件工程', '运维', '性能', '分布式系统']","hasMoreCommit":false,"totalCommits":6,"commitList":[{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2025-12-18T18:38:49+08:00","author":"MY","message":"feat(doc): 重构 SRE 文档内容，增强故障治理与稳定性工程体系描述","hash":"89a5d9fef9f0f7c3b5e6293070b09a3e7bf819c1"},{"date":"2023-04-02T13:46:18+08:00","author":"MY","message":"⚒️知识金字塔","hash":"5227586de5c794724e2571f2abfca0dd0f1fff7f"},{"date":"2022-11-22T16:43:38+08:00","author":"cjiping","message":"✏️SRE","hash":"2c7a073cb4f6265e29b0a5aab35a436daed089c9"},{"date":"2022-11-21T15:25:17+08:00","author":"cjiping","message":"✏️SRE","hash":"b2509e58090d08b05c977baecd7c7c2d294689ac"},{"date":"2022-11-18T16:52:26+08:00","author":"cjiping","message":"➕SRE","hash":"84fd2d323d2322b0a708a97746f1757ede98c134"}],"createTime":"2022-11-18T16:52:26+08:00"}