SRE 的职责与工作方式
SRE 用软件工程方法改善服务可靠性。本文负责岗位实践、错误预算决策和混沌实验。目标岗位需要解释可靠性与交付速度的取舍。
1. 面试核心
先记住这几条，再读正文- 可靠性目标。 SRE 用 SLO 量化可靠性，并用工程改进减少重复运维。卡 · SRE 的核心实践
- 错误预算。 错误预算为给定统计窗口分配可接受的失败额度。卡 · 错误预算策略与消耗速率
- 重复运维工作。 toil 具有重复、可自动化且缺少长期收益等特征。
- 混沌实验。 混沌实验用受控故障检验系统的稳态假设。卡 · 故障注入与混沌工程
- 预算消耗速率。 burn rate 等于实际错误比例除以允许错误比例。卡 · 错误预算策略与消耗速率
2. SRE 的核心实践
| 实践 | 具体工作 |
|---|---|
| 可靠性目标 | 明确用户结果、统计口径、窗口与 SLO |
| 错误预算策略 | 根据预算消耗调整发布和可靠性工作 |
| 减少 toil | 用自动化消除重复操作及人工协调 |
| 监控告警 | 根据业务症状与预算消耗触发响应 |
| 故障响应 | 定义角色、升级路径与恢复方案 |
| 无责复盘 | 找到系统缺口，并验证改进效果 |
| 容量与变更 | 压测、预留容量、灰度和回滚演练 |
Google SRE 将运维性工作控制在总时间的 50% 内。该实践为工程改进保留时间。toil 的判断重点是重复性和长期收益。一次性架构改进与重复手工扩容的性质不同。
SLI 是测量值，SLO 是目标，SLA 是对外约定。SLA 还包含未达标时的处理条款。内部 SLO 可比 SLA 更严格，以预留处置余量。
按 30 天的时间可用率计算，99.9% 对应 43.2 分钟。99.99% 对应 4.32 分钟。请求成功率 SLO 则按请求数分配预算。两种口径应分别计算。
监控实现见 监控与告警。事故处置见 故障响应与排查。容量方法见 容量规划。
3. 相关岗位的区别
| 岗位或方法 | 侧重 |
|---|---|
| 运维 | 部署、配置、资源维护和故障处理 |
| 运维开发 | 用代码建设发布、监控和管理工具 |
| SRE | 围绕可靠性目标组织运行与工程改进 |
| DevOps | 改善开发与运维协作及持续交付 |
| 平台工程 | 提供自助使用的内部开发平台 |
这些职责在不同团队中会重叠。运维岗位也能高度自动化。SRE 的关键是明确可靠性目标与工程投入。面试回答应结合 JD 和自己的项目职责。
4. 故障注入与混沌工程
实验先定义稳态指标，再提出可验证的假设。例如单个缓存节点失效后，核心请求仍满足既定 SLO。
- 选择故障类型和最小实验范围。
- 设置稳态指标、对照组和观测窗口。
- 验证停止开关及恢复步骤。
- 注入故障，并比较实际结果与假设。
- 达到停止条件时恢复，记录设计缺口。
测试环境用于验证实验工具和恢复流程。生产实验用于覆盖真实负载、配置与依赖。实验应从少量实例或流量开始。
流量标记能帮助限定请求级注入。共享线程池、缓存和数据库仍会传递影响。节点级故障也会影响该节点上的其他流量。因此，隔离效果需要独立验证。
熔断统计可按实验流量隔离，以控制波及范围。若实验目标就是验证全局熔断，应保留相应统计路径。排除实验错误会改变验证对象。
写入可使用影子数据或可识别的测试记录。自动停止需观察真实用户指标。停止注入后还要确认积压和重试已经消退。
5. 错误预算策略与消耗速率
预算策略应在事故前由开发与可靠性团队约定。策略包含统计窗口、预算口径和触发动作。预算充足时可按计划发布。预算耗尽时，策略可暂停普通功能变更。
暂停发布仍需保留安全修复与恢复性变更的路径。具体豁免由团队事先约定。预算恢复后，也应检查故障改进项和发布风险。
假设月度请求量为 100 万，成功率目标为 99.9%。允许失败的预算就是 1000 次。若当前错误率为 1%，burn rate 为 10。持续该速率会以目标速率的 10 倍消耗预算。
按稳定请求速率估算，30 天预算约 3 天耗尽。实际消耗还取决于流量变化。告警可同时检查长窗口和短窗口。长窗口确认持续影响，短窗口确认故障仍在发生。
6 · 面试题卡片
本页题目与参考回答
6.1 你怎么理解 SRE？它和传统运维、运维开发、DevOps 有什么区别？
考察重点
- 用工程方法保障可靠性：SLO、错误预算、消除琐事、故障响应、复盘。
- 与传统运维、运维开发、DevOps 的关系，并能结合岗位说明。
参考回答
SRE 用软件工程方法管理服务可靠性。
它用 SLI 衡量用户结果，用 SLO 设定目标。错误预算策略连接发布决策与可靠性投入。
日常实践包括监控、值班、容量、变更和复盘。工程改进用于减少重复操作，并缩短恢复时间。toil 应受到约束，给持续改进留出时间。
运维负责系统运行，运维开发侧重工具建设。SRE 围绕可靠性目标组织这些工作。DevOps 强调开发与运维协作及持续交付。具体岗位边界应结合目标团队的 JD。
6.2 故障注入为什么要在线上做而不只在测试环境做？怎样控制爆炸半径，避免影响正常流量？
考察重点
- 混沌实验的流程：稳态、假设、注入、观察、停止。
- 生产实验的理由；爆炸半径、流量标记、数据隔离、熔断统计隔离与自动停止。
参考回答
生产实验用于检验真实负载与依赖下的容错表现。
测试环境先验证注入工具、停止开关和恢复流程。生产中再从小范围开始。
实验需定义稳态假设、对照组和停止条件。流量标记帮助隔离请求级故障。共享资源仍会把影响传给正常用户。节点级故障需按实例和依赖限制范围。
实验流量可单独统计和熔断。若目标是验证全局熔断，就应覆盖该真实路径。写入需隔离或可识别，停止后还需检查积压。
6.3 99.9% 的请求成功率目标怎样计算预算？预算耗尽后怎样处理？
考察重点：统计口径、发布策略与 burn rate。
相关内容：错误预算策略与消耗速率。
参考回答
100 万次请求对应 1000 次失败预算。
错误率 1% 对应 burn rate 为 10。按稳定请求速率估算，30 天预算约 3 天耗尽。预算耗尽后按约定暂停普通功能变更。安全修复与恢复性变更走事先约定的豁免路径。