读书笔记：《SRE：Google运维解密》
目录
一、SRE 的定义
SRE（Site Reliability Engineering，站点可靠性工程）是由软件工程师执行运维工作的学科。其核心是将软件工程原则应用于基础设施和运维问题，通过自动化、监控和工程化方法，使系统具备可扩展性和高可靠性。
SRE 的创始人 Ben Treynor Sloss 将其描述为："当要求软件工程师设计运维团队时发生的事情。"
二、SRE 的七大原则
| 原则 | 内容 |
|---|---|
| 1. 拥抱风险 | 100% 可靠性既不现实也非最优目标。通过错误预算（Error Budget）在可靠性与创新速度之间取得平衡 |
| 2. 服务级别目标 | 建立可量化的可靠性目标（SLO），通过服务级别指标（SLI）进行衡量，区分内部目标（SLO）与外部合同（SLA） |
| 3. 消除琐事 | 识别并自动化那些手动、重复、可自动化的工作（Toil），将工程师精力释放到更有价值的工程研发上 |
| 4. 监控 | 持续测量、分析和改进系统性能，基于四大黄金信号建立监控体系 |
| 5. 自动化 | 将运维工作自动化，减少人工干预，降低人为错误，提升系统效率 |
| 6. 发布工程 | 将发布流程工程化，强调自动化、自服务、速度、密闭构建和标准策略 |
| 7. 简单化 | 系统稳定性与灵活性通过简单化实现。最小 API、模块化、负代码行作为指标 |
三、核心概念体系
3.1 SLI、SLO、SLA
| 概念 | 全称 | 定义 |
|---|---|---|
| SLI | Service Level Indicator | 服务级别指标，用于衡量服务性能的客观指标，如延迟、错误率、吞吐量 |
| SLO | Service Level Objective | 服务级别目标，基于 SLI 设定的内部可靠性目标，如"延迟 < 300ms 的占比达到 99%" |
| SLA | Service Level Agreement | 服务级别协议，与用户签订的正式合同，包含未达标时的补偿条款 |
3.2 错误预算（Error Budget）
错误预算是 SLO 允许范围内的不可靠性额度。例如，99.9% 的可用性目标意味着每年允许 8.76 小时的停机时间，这段时间即为错误预算。
- 只要错误预算未耗尽，团队可以全速推进新功能发布。
- 一旦错误预算耗尽，发布新功能需暂停，优先投入可靠性改进工作。
- 错误预算将可靠性决策从主观判断转化为数据驱动的客观机制。
3.3 琐事（Toil）
琐事是指那些手动、重复、可自动化、且完成后不会使系统状态得到改善的工作。例如：
- 手动收集指标数据
- 重复执行相同的部署步骤
- 手动重启服务
SRE 要求将琐事占比控制在合理范围内，保障工程师至少 50% 的时间用于工程研发工作。
四、监控的四大黄金信号
| 信号 | 说明 |
|---|---|
| 延迟（Latency） | 服务处理请求所需的时间，需区分成功请求与失败请求的延迟 |
| 流量（Traffic） | 系统所承受的负载或需求，如每秒请求数、页面浏览量、交易量 |
| 错误（Errors） | 请求失败的比例，包括显式错误（HTTP 500）、隐式错误（返回错误内容）和策略违规（超时） |
| 饱和度（Saturation） | 服务资源的使用程度，接近 100% 时通常意味着性能下降 |
五、SRE 工作职责金字塔
SRE 的工作按价值层次分为三层：
| 层级 | 内容 | 具体工作 |
|---|---|---|
| 应急响应 | 监控、应急事务处理、事后总结 | on-call 轮值、事故处理、无责复盘 |
| 日常运维 | 变更管理、容量规划与置备、性能与效率 | 发布管理、容量预测、资源优化 |
| 工程研发 | 制定合理的 SLO，在 SLO 安全范围内全速前进 | 自动化工具开发、平台工程、可靠性改进 |
六、发布工程（Release Engineering）
发布工程是 SRE 的子学科，关注软件发布的工程化流程。
核心原则
| 原则 | 说明 |
|---|---|
| 自动化与自服务 | 发布流程应尽可能自动化，工程师可自助完成发布，无需依赖他人 |
| 速度 | 快速、频繁地发布，减少每次发布的变更量，便于测试和故障定位 |
| 密闭构建 | 构建过程应完全独立于构建机器，确保相同源代码在任何机器上构建出完全一致的产物 |
| 标准与策略 | 对部署、源代码变更、新发布和构建配置变更建立安全检查机制 |
七、容量规划与性能
- 容量规划：基于历史数据和业务增长预测，提前规划资源需求，避免服务因资源不足而降级。
- 性能优化：通过监控和 profiling 识别性能瓶颈，持续提升系统效率。
- 连锁故障防护：通过队列管理、流量抛弃、优雅降级、请求截止时间、慢启动等机制防止故障级联扩散。
八、数据完整性
- 数据完整性是手段，数据可用性是目标。
- 交付的是一个恢复系统，而非备份系统。
- 采用纵深防御策略：软删除 → 备份与恢复 → 复制机制 → 早期预警。
- 定期验证恢复策略的有效性。
九、无责事后复盘（Blameless Postmortem）
事故复盘的核心目标是从系统层面分析故障原因，而非追究个人责任。
复盘需回答的问题
- 哪些信号在事前被忽略？
- 哪些工具或流程使错误更容易发生？
- 事故的影响范围和持续时间？
- 解决方法和恢复过程？
- 如何防止类似问题再次发生？
十、SRE 与 DevOps 的关系
SRE 是 DevOps 思想在运维层面的具体实现。两者共享相同的目标（打破开发与运维壁垒、提升交付效率与系统可靠性），但 SRE 提供了更具体的工程实践框架：
- DevOps 是一种文化和运动，强调协作与持续交付。
- SRE 是一种工程学科，通过 SLO、错误预算、自动化等具体机制实现可靠性目标。