06 SRE 稳定性工程阿里对 SRE 的要求是：以业务视角衡量稳定性、以工程手段根治问题、以组织机制放大效果。一、

面试官关注点：你只是"救火队员"还是稳定性体系的建设者？能不能把模糊的"系统稳定"拆成可度量的 SLO、变更 SOP、容量模型、应急预案？

阿里对 SRE 的要求是：以业务视角衡量稳定性、以工程手段根治问题、以组织机制放大效果。

一、SRE 基础概念（Google SRE 体系）

1.1 SLI / SLO / SLA

概念	含义	例子
SLI（指标）	可量化的指标	请求成功率、P99 延迟
SLO（目标）	对内承诺	月度成功率 99.95%
SLA（协议）	对外承诺 + 赔付	低于 99.9% 赔 10% 月费

SLO 要符合 SMART 原则：具体、可量化、可达成、相关、时限。

1.2 错误预算（Error Budget）

100% - SLO = 允许失败比例
例：SLO 99.9% → 每月允许 43.2 分钟失败
用完预算 → 冻结功能发布，专注稳定性
没用完 → 可以"激进一点"（试新功能、混沌演练）

价值：把稳定性和业务速度用同一把尺子衡量，消除研发/SRE 对立。

1.3 MTTR / MTBF / MTTD / MTTF

MTTD（发现）：告警到值班响应
MTTR（恢复）：发现到恢复
MTBF（故障间隔）：两次故障之间时间
MTTF（失效前时间）：平均无故障时长

阿里故障定级与时间要求：

P0：全站不可用，MTTR < 15 分钟
P1：核心业务受损，MTTR < 30 分钟
P2：非核心功能，MTTR < 2 小时
P3：轻微影响，MTTR < 1 天

二、SLO 体系建设

2.1 SLI 设计原则

用户视角：不是内部组件指标，而是用户感知的服务质量
可量化：明确计数器（如 HTTP 5xx / 总请求）
关键路径：覆盖核心交易链路（下单、支付、搜索）

2.2 常见 SLI 类型

类型	指标	公式
可用性	成功请求率	`2xx+3xx+4xx[排除服务端 4xx] / 总请求`
延迟	P99/P95 延迟	直方图分位数
吞吐	QPS	单位时间请求数
准确性	数据正确率	抽样对比
新鲜度	数据延迟	事件时间 - 处理时间
覆盖率	处理完整率	成功处理 / 应处理

2.3 SLO 多窗口多阈值告警

问题：单一窗口告警要么太敏感（抖动告警）要么太迟钝（真故障被淹没）。

方案：两窗口联动告警

短窗口（5min）消耗速率 × 长窗口（1h）消耗速率 双突破才告警

示例：SLO 99.9%，月度错误预算 43.2min。

短 5min 内消耗 2%，长 1h 内消耗 5% → 烧毁率告警（高优先）
短 30min 内消耗 5%，长 6h 内消耗 10% → 普通告警

2.4 SLO 落地节奏

基线阶段：选 3-5 个核心服务，先用"观察 SLO"（不告警），建立数据
承诺阶段：团队评审后转为"承诺 SLO"
执行阶段：纳入周报、故障复盘、发布控制
文化阶段：错误预算成为研发/SRE 共同语言

三、容量规划

3.1 容量评估维度

业务容量：用户数、订单数、GMV
系统容量：QPS、并发连接、存储量
资源容量：CPU、内存、IO、带宽、连接数

3.2 容量模型

所需实例数 = 峰值 QPS × 安全系数 / 单实例承载 QPS
单实例 QPS 来自压测，安全系数通常 1.5-2

3.3 压测方法

类型	说明	工具
基准压测	单实例极限	wrk、ab、jmeter
全链路压测	生产环境 + 影子库	阿里云 PTS、自建
容量压测	逐步加压找拐点	PTS 阶梯模式
稳定性压测	长时间稳定运行	72 小时持续

阿里大促全链路压测（业界标杆）：

影子表：写入带压测标的请求走影子表，不污染生产
影子中间件：Tair/MQ 影子实例
流量染色：透传 pressure tag 贯穿全链路
压测脱敏：生产数据影子化，去敏感字段

3.4 资源水位线

CPU：日常 < 40%，峰值 < 70%
内存：日常 < 60%，峰值 < 80%
磁盘：< 80%（预留空间给快照/日志）
网络：< 60%

阈值理论依据：

CPU 利用率超 70% 后，排队论下延迟指数级上升（Kingman 公式）
留足 buffer 给突发、故障迁移、滚动更新

四、变更管理

4.1 阿里"三板斧"（变更铁律）

可灰度：新逻辑先上 1%，再 10%，再 100%
可观测：灰度期间盯核心指标，有数据支撑决策
可回滚：任何变更必须有 1 分钟内回滚方案（代码、配置、流量）

变更 = 90% 故障的源头。所有资深运维必背这句话。

4.2 变更类型分级

级别	场景	要求
高危	数据库 DDL、核心中间件配置、跨 AZ 切换	双人审批、变更窗口、回滚演练
常规	应用发布、扩容	单人审批、灰度 + 监控
低危	配置下发、文案修改	流程提交即可

4.3 发布策略

策略	说明	场景
滚动发布	分批替换旧实例	默认
蓝绿发布	两套环境切流量	数据库/中间件大版本
金丝雀	按比例切流	核心业务、C 端
灰度放量	按用户标签、地区	功能开关
影子发布	新老并行跑，新版只看不切	高风险逻辑验证

4.4 变更卡点

大促前封网（大促前 7 天起，只允许 P0 变更）
周五下午 / 节假日前不发版（变更 freeze）
核心服务发布间隔 ≥ 30 分钟（便于观察 + 回滚）

五、应急响应（Incident Management）

5.1 阿里故障响应 SOP

发现（告警/用户反馈）
  → 响应（值班/拉群）
  → 定级（P0-P3）
  → 止血（优先恢复，不追根因）
  → 根因分析
  → 修复 + 复盘
  → 改进落地

5.2 故障战时指挥结构

IC（Incident Commander）总指挥：不动手，只决策
OL（Operations Lead）操作负责人：执行操作
CL（Communication Lead）沟通负责人：对外通报、拉群、协调
PL（Planning Lead）：记录时间线、整理事实

小故障 1 人兼任，P0/P1 必须分离角色，避免一个人既当指挥又动手。

5.3 止血优先级

快速回滚：最近一次变更 rollback
流量切走：跨 AZ/Region 切流
降级/限流：关非核心功能、限流保核心
扩容：资源瓶颈紧急加机器
重启：疑难杂症的最后一根稻草（但要留现场数据）

口诀：先恢复、后复盘；先业务、后技术；先止血、后根因。

5.4 时间线记录模板

T0 (10:23:15) - 监控告警：订单成功率跌至 80%
T0+2m        - 值班响应，确认告警真实
T0+5m        - 拉起作战群，IC 指挥
T0+7m        - 怀疑 10:20 发布，开始回滚
T0+12m       - 回滚完成，成功率恢复至 99%
T0+30m       - 完全恢复，故障关闭
T+1d         - 复盘会议

5.5 战时沟通原则

简洁准确：不用术语黑话，让老板能看懂
周期通报：P0 每 15 分钟一次，P1 每 30 分钟
客观陈述：说现象、措施、预计恢复时间，不说猜测
只一个声音：CL 统一对外，避免信息混乱

六、故障复盘（Postmortem）

6.1 无指责文化（Blameless）

对事不对人，关注系统性原因
个人失误的根因 → 为什么系统允许这种失误发生

6.2 复盘模板

1. 故障摘要（一句话）
2. 影响范围（用户数、金额、时长）
3. 时间线（分钟粒度）
4. 根本原因（5 Whys）
5. 触发条件
6. 发现过程（监控是否及时？）
7. 止血过程（是否有更快方案？）
8. 改进项（Owner + 截止日期）
9. 经验教训

6.3 5 Whys 示例

问：为什么 P0 故障？
答：数据库连接池耗尽。

问：为什么耗尽？
答：慢 SQL 阻塞连接。

问：为什么突然有慢 SQL？
答：新发布的版本移除了索引提示。

问：为什么没有测试发现？
答：测试环境数据量小，执行计划不同。

问：为什么没有预生产压测？
答：发布流程没要求生产数据量压测。

→ 根因：发布流程缺失"生产数据量压测"环节。

6.4 改进项管理

每个改进项必须 SMART（可量化、可完成）
Owner + 截止日期 + 跟踪机制
定期回顾（月会）没完成的改进项，不让其沉没
关键改进项不完成前，该团队禁止上新功能（强约束）

七、混沌工程（Chaos Engineering）

7.1 原则（Principles of Chaos）

定义稳态假设
在生产（或接近生产）环境实验
多样化真实世界事件
持续自动化
最小化爆炸半径

7.2 阿里 ChaosBlade

开源工具，支持：

主机：CPU 打满、内存溢出、磁盘满、网络延迟/丢包
JVM：方法延迟、异常、OOM
中间件：MySQL/Redis 故障
K8s：Pod 杀、节点断网

7.3 实验编排

阶段 1：基础资源级（单机 CPU 满）
阶段 2：单机组件级（MySQL 主节点宕）
阶段 3：AZ 级（一个 AZ 断网）
阶段 4：Region 级（跨域切流演练）

7.4 演练节奏

月度：基础资源、单机故障
季度：AZ 级
半年度：Region 级（跨地域切流）
年度：极端故障（云厂商级演练）

红蓝对抗（Red Team）：蓝队日常运维 + 红队主动搞破坏，训练应急肌肉记忆。

八、高可用架构设计

8.1 高可用的本质：消除单点

所有链路都要问一遍"这个点挂了怎么办"：

DNS → 多权威 NS + 客户端兜底
LB → 跨 AZ LB + 备用 LB
应用 → 多副本 + 多 AZ
DB → 主从 + 半同步 + 备库
缓存 → 集群 + 穿透保护
MQ → 集群 + 持久化
配置中心 → 集群 + 本地 fallback
注册中心 → 集群 + 客户端缓存

8.2 限流、熔断、降级

机制	作用	实现
限流	保护自己不被打爆	令牌桶、漏桶；Sentinel/MSE
熔断	保护下游 + 快速失败	错误率阈值 + 时间窗
降级	保核心去非核心	静态兜底、异步化、读缓存代替查 DB

阿里 Sentinel：开源限流熔断库，阿里双 11 标配，MSE 产品化提供。

8.3 隔离

线程池隔离：Hystrix 风格，每个下游独立线程池
连接池隔离：不同业务独立 DB/Redis 连接池
机器隔离：核心与非核心物理隔离
机房隔离：单元化架构

8.4 超时设置

任何网络调用必须有超时（没有超时 = 永远挂起）
超时时间 < 上游超时（避免上游已经放弃你还在执行）
链路超时预算：总超时 = Σ 各节点超时 + 网络 RTT

九、资深 SRE 的软技能

9.1 向上管理

故障期间用"业务损失"汇报（金额、用户数），不是"服务器挂了"
定期稳定性月报：可量化的改进，不是罗列工作量
争取预算：ROI 计算（一次故障损失 vs 改进成本）

9.2 跨团队协作

发布流程的守门员：温柔但坚定地拒绝不符合三板斧的变更
稳定性文化布道：培训、红蓝对抗、值班轮转
RCA 会议主持：引导技术讨论，避免甩锅

9.3 技术影响力

内网/开源技术分享
建设团队 Runbook / Wiki
招聘 + 梯队建设

十、面试高频问答

Q1：SLO 定 99.9% 和 99.99% 差别有多大？ A：

99.9%：每月 43.2 分钟允许失败
99.99%：每月 4.32 分钟
99.999%：每月 25.9 秒（极高成本，需双活 + 无人值守自愈）
每多一个 9，成本 10 倍级增长（多活、自动化、硬件冗余、人员投入）
定 SLO 要匹配业务价值，不是越高越好

Q2：如何给一个新服务定 SLO？ A：步骤：

看业务价值（C 端交易 vs 内部工具要求不同）
参照友商 / 行业标杆
观察历史数据 1-3 个月，取实际达到水平的 下一档
与业务方评审，纳入 OKR
定期回顾（季度）调整

Q3：错误预算用完了怎么办？ A：

理论上冻结新功能发布，全员专注稳定性
实操：分级处理
- 烧完 50%：告警 + 放慢发布
- 烧完 100%：冻结非紧急变更
- 连续多周超限：架构 review + 组织 review
关键：预算即规则，不是参考，老板要背书

Q4：一次 P0 故障你作为 IC 怎么指挥？ A：STAR 模式讲一个例子：

S（Situation）：XX 业务全量不可用，影响 XX 万用户
T（Task）：作为 IC 需要 15 分钟内止血
A（Action）：
1. 3 分钟内拉齐核心团队（DBA、网络、应用）
2. 分配角色：OL 操作、CL 对外沟通
3. 并行假设：最近变更回滚 + 流量切 backup AZ
4. 持续每 5 分钟对齐进展
R（Result）：12 分钟止血，根因：XXX，后续改进 3 项已全部落地

Q5：压测做全链路要注意什么？ A：

数据隔离：影子表、影子 Redis、影子 MQ 分区
流量染色：TraceId 带 pressure flag 全链路透传
中间件改造：DB/缓存/MQ 客户端识别染色标走影子
外部依赖 Mock：第三方支付、短信 Mock 掉，避免真实扣费
监控隔离：压测数据不污染业务大盘
限流保护：压测异常时自动停止，避免打挂生产

Q6：限流用令牌桶还是漏桶？ A：

令牌桶：允许突发（桶满情况下可瞬间消费）；绝大多数业务首选
漏桶：严格匀速输出，适合绝对不能突发的场景（第三方 API 配额）
Guava RateLimiter 用令牌桶；Nginx limit_req 漏桶

Q7：服务雪崩怎么防？ A：

限流（入口 + 内部）
熔断（调用下游的地方）
降级（非核心降级）
超时（强制，不能省）
隔离（线程池/信号量）
重试策略（指数退避 + 抖动 + 上限，不要无脑重试放大流量）
异步化（削峰填谷，MQ 缓冲）

Q8：怎么判断"该回滚"还是"该前进"？ A：

默认回滚：分钟级内出现指标异常，先回滚再调查
例外：
- 回滚本身有风险（数据不兼容）→ 继续修复 roll forward
- 问题明显且修复极快（1 分钟能改）
文化：SRE 要营造"回滚不丢人"氛围，防止研发死扛

Q9：Runbook 是什么？怎么写？ A：

定义：故障或日常操作的分步可执行文档
格式：
- 适用场景（什么时候用）
- 前置检查（怎么确认是这个问题）
- 操作步骤（命令级）
- 验证步骤
- 回滚方案
- 联系人
要求：任何值班人员照着能操作，不依赖个人经验

Q10：自动化和人工判断怎么平衡？ A：

高频、确定性操作→ 自动化（扩缩容、清日志、重启）
低频、高风险 → 人工 + Runbook（DB 主从切换、跨 AZ 切流）
自愈闭环要有熔断：自动化连续失败 N 次升级到人工，避免"自动化风暴"

十一、阿里稳定性体系速记

三板斧：可灰度、可观测、可回滚
1-5-10：1 分钟发现、5 分钟响应、10 分钟恢复（金融云级目标）
双 11 铁人三项：全链路压测、容量规划、应急演练
BCP（业务连续性计划）：最高可接受中断时长（RTO）+ 最高可接受数据丢失（RPO）
异地多活单元化：RZone（可交易单元）、GZone（全局单元）、CZone（城市同机房）

十二、必读资源

《Site Reliability Engineering》Google SRE 三部曲
《The Site Reliability Workbook》
《混沌工程实战》阿里云
SRE weekly 订阅
阿里 SRE 工程师公开分享（InfoQ、QCon）