SRE 的职责与工作方式
几乎每场 SRE 面试都会问“你怎么理解 SRE”。这道题考察的是你是否知道这个岗位用什么方法保障稳定性：用 SLO 量化可靠性目标，用错误预算平衡发布速度与稳定性，用工程手段消除重复劳动，用故障演练和复盘让系统越来越可靠。本文讲 SRE 的核心实践、它与传统运维和 DevOps 的关系，以及故障注入和混沌工程。
1. 面试核心
先记住这几条，再读正文- SRE（Site Reliability Engineering）是用软件工程的方法解决运维问题：把可靠性当作一个可度量、可权衡的工程目标，而不是“越稳越好”。卡 · SRE 的核心实践
- 核心实践：定义 SLI 和 SLO，按错误预算决定发布节奏；把琐事（手工、重复、可自动化的工作）控制在一定比例以内，其余时间做工程改进；建立监控告警、值班与故障响应流程；无责复盘；容量规划和变更管理。
- 与传统运维的区别在于方法：传统运维以人工操作和响应为主，SRE 用代码和自动化管理系统，并且有明确的可靠性目标与开发团队共同承担。DevOps 是打通开发与运维的理念和文化，SRE 可以看作它的一种具体实现方式。
- 故障注入和混沌工程主动在系统中制造故障，验证容错设计是否真的有效。在生产环境做是因为测试环境的流量、配置和依赖与线上不同；前提是控制爆炸半径、设置自动停止条件，并能区分实验流量与真实流量。卡 · 故障注入与混沌工程
2. SRE 的核心实践
| 实践 | 内容 |
|---|---|
| SLI / SLO / SLA | SLI 是衡量服务质量的指标（如成功请求比例），SLO 是对它设定的目标（如 99.9%），SLA 是对外的合同承诺，违反时有赔偿。内部 SLO 应比 SLA 更严格 |
| 错误预算 | 1 − SLO 就是允许失败的额度。预算充足时可以加快发布、做实验；预算耗尽时冻结功能发布，优先修复稳定性问题。它把“要不要发布”从争论变成一条规则 |
| 消除琐事 | 琐事指手工、重复、可自动化、没有长期价值、随业务规模线性增长的工作。Google SRE 的做法是把它控制在工作时间的 50% 以下，其余用于自动化和工程改进 |
| 监控与告警 | 基于 SLO 告警，告警可执行，见监控与告警 |
| 值班与故障响应 | 轮值、升级机制、明确的角色分工，见故障响应 |
| 无责复盘 | 关注系统和流程的缺陷，而不是追究个人，改进项要跟踪到完成 |
| 变更管理 | 大部分故障由变更引起：灰度发布、自动回滚、变更窗口与审批 |
| 容量规划 | 根据增长预测和压测结果提前准备资源，见容量估算 |
可用性目标与允许的停机时间：99.9% 每月约 43 分钟，99.99% 每月约 4.3 分钟。每多一个 9，成本和对变更速度的限制都会显著上升，所以目标要按业务需要定，而不是越高越好。
3. 相关岗位的区别
| 岗位 | 侧重 |
|---|---|
| 传统运维 | 部署、变更、巡检、故障处理，以人工操作和响应为主 |
| 运维开发 | 开发运维平台和工具：发布系统、CMDB、监控平台、自动化脚本 |
| SRE | 对服务的可靠性负责：SLO、容量、架构评审、故障响应与复盘，用工程手段减少人工 |
| DevOps | 一套理念与实践：开发和运维协作、持续集成与交付、基础设施即代码；也常指负责 CI/CD 和平台建设的岗位 |
| 平台工程 | 为开发者建设自助的内部平台，把部署、观测、环境等能力产品化 |
不同公司的叫法和边界差别很大。面试时先说出通用定义，再结合目标公司的岗位描述（偏故障排查与稳定性，还是偏平台开发）说明自己的理解，比背定义更好。
4. 故障注入与混沌工程
混沌工程通过受控的实验验证系统在故障下的表现，流程是：
- 定义稳态：用业务指标描述正常状态，例如下单成功率、P99 延迟。
- 提出假设：例如“一个可用区的 Redis 节点故障时，下单成功率不低于 99.9%”。
- 注入故障：实例宕机、网络延迟或丢包、依赖返回错误、CPU 或磁盘打满、时钟偏移。
- 观察与比较：对比实验组和对照组的稳态指标。
- 自动停止与恢复：指标超过阈值立即停止实验并恢复。
为什么要在生产环境做：测试环境的流量规模和分布、配置、依赖版本、数据量都与生产不同，很多问题只在生产中出现。成熟的做法是先在测试环境验证，再在生产中从很小的范围开始。
控制爆炸半径：
- 范围从小到大：单个实例 → 一小部分流量 → 一个可用区。
- 只对带有实验标记的请求注入故障（例如通过请求头或用户白名单），正常流量不受影响。
- 熔断、限流等保护机制要能区分实验流量，避免实验触发全局熔断；或者把实验流量的统计与真实流量分开。
- 实验产生的写入要隔离，例如写入影子表或打上测试标记，避免污染真实数据。
- 设置自动停止条件和一键恢复，在业务低峰进行，提前通知相关团队。
5 · 面试题卡片
5.1 你怎么理解 SRE？它和传统运维、运维开发、DevOps 有什么区别？
出现公司：美团、网易游戏、携程、百度、腾讯、UCloud、虾皮、共济科技
考察重点
- 用工程方法保障可靠性：SLO、错误预算、消除琐事、故障响应、复盘。
- 与传统运维、运维开发、DevOps 的关系，并能结合岗位说明。
参考回答
SRE 是用软件工程的方法解决运维问题，对服务的可靠性负责。它的出发点是可靠性需要量化和权衡：先定义 SLI，例如成功请求的比例和延迟，再设定 SLO，例如月度 99.9%；1 减去 SLO 就是错误预算，预算充足时可以加快发布，预算耗尽时暂停功能上线、优先修复稳定性问题，这样开发和运维有了共同的决策依据。日常工作包括：建设基于 SLO 的监控告警，值班和故障响应，无责复盘并跟踪改进项，容量规划，变更管理（灰度、回滚），以及把手工、重复的琐事自动化，控制琐事占用的时间，把精力用在工程改进上。
和传统运维的区别在于方法：传统运维以人工操作和事后响应为主，SRE 用代码管理系统、有明确的目标，并且参与架构评审，在设计阶段就考虑可靠性。运维开发侧重开发运维平台和工具。DevOps 是打通开发与运维、持续交付的理念，SRE 是实现这一理念的一种具体方式。不同公司对这些岗位的划分不同，可以结合岗位描述说明自己会在哪些方面投入。
5.2 故障注入为什么要在线上做而不只在测试环境做？怎样控制爆炸半径，避免影响正常流量？
出现公司：小红书、百度
考察重点
- 混沌实验的流程：稳态、假设、注入、观察、停止。
- 生产实验的理由；爆炸半径、流量标记、数据隔离、熔断统计隔离与自动停止。
参考回答
测试环境的流量规模、请求分布、配置、依赖版本和数据量都与线上不同，很多容错问题只在生产中暴露，例如超时配置在真实负载下不合理、降级开关在线上没有生效。所以先在测试环境验证工具和流程，再在生产中从很小的范围开始做实验。
控制爆炸半径的方法：先定义稳态指标和自动停止条件，指标恶化立即停止并恢复；范围从单个实例、少量带标记的流量开始逐步扩大；故障只对带有实验标记的请求生效，标记通过请求头在调用链中传递；实验产生的写入落到影子表或打上测试标记，不污染真实数据；在业务低峰进行，并提前通知相关团队。
熔断的问题要专门处理：如果熔断器按整体错误率统计，实验流量的错误可能触发对所有流量的熔断。可以让熔断器按流量标记分开统计，实验流量单独计数、单独熔断；或者在注入点直接对实验流量返回预期的故障，不计入真实依赖的健康统计。这样既能验证实验流量下的降级逻辑，又不会影响正常请求。