面试 · 系统串联题

这一档凌驾于 1-5 类题型之上，单独成档。
1-5 类是"知识点的切片"——概念解释型考"是什么"、对比辨析型考"和谁的区别"、原理追问型考"为什么这么设计"、场景排查型考"怎么定位"、方案设计型考"怎么落地"。每题只考一个面。
锚点题（Anchor Question）是"一题炸开成知识树"：考官抛一个高频、高杠杆的主问题，然后顺着你的回答一路往下追问，横跨 SLO（Ch3-4）、可观测与告警（Ch7-8）、事件响应（Ch9-11）、可靠性设计（Ch12-14）、韧性验证（Ch15）多个阶段。一道锚点题答透 = 证明你能把 Ch2-16 串成一条线，而不是背了一堆孤立名词。
为什么单独成档：面试的区分度几乎全在这几道题上。初级候选人答"是什么"，高级候选人答"完整链路 + 边界 + 踩坑"。考官用锚点题在 3-5 分钟内就能判断你有没有真正扛过线上。
怎么用这份文档：
先把每题的「参考答题骨架」讲成一条主线，主动埋钩子（点到而不展开的术语），把考官的追问引到你准备好的深水区。
「考官追问链」按 现象 → 机制 → 边界 → 治理 四段递进，预判考官下一刀砍哪，提前想好。
「踩坑 / 加分点」是真做过才知道的细节——这是把"背过"和"扛过"区分开的地方，一句就能加分。
每题末尾标注它会调用 1-5 类中的哪些具体题，方便回头补细节。

锚点题 1：线上服务 P99 延迟突然翻倍，从收到告警到止血到复盘，完整链路你怎么走？#

为什么是锚点题 这是 SRE 的**"总题"**——几乎每场面试必问，且能一路串到底。它同时考「可观测（黄金信号 / trace）+ SLO 判断（要不要 page）+ 事件响应（止血优先级）+ 可靠性设计（级联 / 降级）+ 复盘文化」。考官从这一题就能看出你是"会看监控"还是"扛过线上"。区分度极高：新人只会说"看日志找报错"，老手会讲"先判影响面、先止血再定根因、复盘闭环"。

会串出的知识点地图

确认层（可观测）：四个黄金信号（延迟 / 流量 / 错误 / 饱和度，Ch7）、白盒 vs 黑盒、"慢"和"错"要分开、成功请求延迟 vs 失败请求延迟要分开统计
判断层（SLO）：这个延迟有没有烧错误预算（Ch3-4）、延迟 SLO、要不要 page（症状告警 vs 原因告警，Ch8）
定位层（可观测深水）：Trace（Tempo/Jaeger）、exemplar 从指标跳 trace、找最耗时 span、是否级联 / 依赖劣化 / 容量瓶颈
止血层（事件响应 + 设计）：mitigate first / diagnose later、回滚 / 切流 / 扩容 / 降级 / 限流的选择与顺序（Ch10、Ch12、Ch14）
复盘层（文化）：无指责 Postmortem、时间线（TTD/TTM/TTR）、行动项闭环（Ch11）

考官追问链

【现象·确认】 "你怎么先确认这不是误报、确实影响用户了？先看什么？" → 打开黄金信号 dashboard：P99 是不是真升了、从什么时间点开始；错误率有没有同步升（分辨"慢"还是"错"）；流量有没有突增（流量涨也会拉高延迟）；饱和度（CPU throttle / 连接池 / 队列）。同时看黑盒拨测确认是不是用户真感知。
【机制·SLO 判断】 "延迟翻倍就一定要 page 吗？怎么决定严重级别？" → 看是否影响延迟 SLO、错误预算燃烧率。如果 P99 翻倍但仍在 SLO 阈值内且不烧预算 → 降级为 ticket，不半夜叫人。告警要基于症状（用户受影响）而非原因（某台 CPU 高）。这一步决定后面所有动作的紧迫度。
【机制·定位】 "怎么定位到底是哪一跳慢？会不会是级联？" → 从指标的 exemplar 跳到具体慢请求的 trace，找耗时最长的 span：DB 慢（慢查询 / 缺索引 / 连接池满）？下游 RPC 慢（去看下游 dashboard，可能是级联源头）？自身慢（GC pause / CPU throttle / 冷缓存）？关联最近变更（发布 / 配置 / 容量 / 基础设施轮换）——80% 的突发问题跟最近一次变更有关。
【边界·止血】 "定位要时间，用户还在等，你先做什么？回滚还是扩容？" → 先止血，不等根因。判断标准：如果时间上强关联最近发布 → 回滚是最快最稳的止血（秒级恢复）；如果是流量 / 容量 → 扩容 + 限流；如果是某个下游拖垮 → 降级熔断该依赖，保住核心链路。止血手段按"恢复速度 + 副作用"排序：回滚 > 切流 > 降级/限流 > 扩容（扩容有冷启动延迟，见锚点题 5）。
【治理·复盘】 "止血完就结束了？" → 写无指责 Postmortem：时间线（何时发生 / 何时发现 TTD / 何时止血 TTM / 何时恢复 TTR）、根因 + 促成因素（往往不止一个）、SLO/错误预算影响。产出带 owner 和 deadline 的行动项并跟踪到关闭：补监控、补 runbook、补压测、补告警、修掉根因。目标是"同一个坑不踩第二次"。

参考答题骨架 "我把它拆成五步，一条时间线走下来： ① 确认——黄金信号看是慢还是错、影响面多大、从哪个时间点开始； ② 定级——对照延迟 SLO 和燃烧率决定 page 还是 ticket，避免过度响应也避免漏报； ③ 止血——先止血再定根因，强关联发布就回滚，容量问题就限流+扩容，下游拖垮就降级熔断； ④ 定位——止血的同时用 trace + exemplar 钉死是哪一跳，关联最近变更； ⑤ 复盘——无指责 postmortem，时间线 + 根因 + 可闭环的行动项。核心两条原则：从广到窄用证据说话，不在表层打转；止血永远优先于定根因。"

踩坑 / 加分点

P99 翻倍的高频根因清单（能一口气报出来就是老手）：GC pause、连接池耗尽、慢查询 / 缺索引、下游依赖劣化、跨 AZ 流量、K8s CPU limit 被 throttle、冷缓存 / 缓存击穿、N+1 查询、日志同步刷盘、noisy neighbor。
百分位不能跨实例平均——把各 pod 的 P99 再求平均是错的（P99 不可加和），要在原始直方图上重算分位数；直方图 bucket 设得太粗会导致 P99 算不准。
成功请求和失败请求的延迟要分开看：超时的请求要么很快失败（拉低）、要么卡到超时才返回（拉高），混在一起看不出真相。
回滚陷阱：DB schema 变更通常不可直接回滚（要靠向前兼容 / 双写 / 扩展-收缩迁移）；回滚重启可能导致冷缓存 → 缓存击穿 → 二次雪崩。
rate() 窗口太短会抖，太长会滞后；报警看长窗口、定位看短窗口。
加分金句："止血用的证据和定根因用的证据是两套——止血只需要知道'和什么变更相关'，不需要知道'为什么'。"
（细节回补：场景排查型第 1、2 题；概念解释型「四个黄金信号」；原理追问型「症状 vs 原因告警」）

锚点题 2：给一个新上线的核心服务，从 0 设计一套 SLO + 告警体系，怎么做？#

为什么是锚点题 高杠杆——SLO 是 SRE 全部工程的地基，错误预算、告警、容量、发布决策全挂在它上面。高频——几乎所有中高级 SRE 岗必问。区分度在于"燃烧率告警为什么不是简单阈值"这一层：能讲清多窗口多燃烧率的人，一定是真配过 SLO 告警的。

会串出的知识点地图

SLI 选型（Ch3）：选哪几个、怎么埋点、good/total 口径、SLI 的 4 大类（可用性 / 延迟 / 质量 / 新鲜度）
SLO 制定（Ch3）：为何非 100%（工程经济学）、参考历史数据、和业务协商、时间窗口（滚动 28/30 天）
SLA 关系（Ch3）：SLO 严于 SLA、SLA 带赔付
错误预算（Ch4）：SLO → 预算换算（99.9%→月 43.2 分钟）、预算政策
告警工程（Ch8）：多窗口多燃烧率、症状 vs 原因、告警可执行性、告警疲劳
落地：Recording Rules、Dashboard（当前值 + 预算剩余 + 燃烧率趋势）

考官追问链

【现象·选 SLI】 "第一步你选哪几个 SLI？凭什么？" → 从用户视角选，2-3 个就够：可用性（成功请求/总请求）、延迟（P99 ≤ 某阈值）、必要时加核心业务成功率（如"下单最终成功率"）。选"用户能感知的"，不选"机器指标"。埋点在离用户最近的一侧（如网关/LB），避免只测到自己内部。
【机制·定 SLO】 "SLO 定多少？为什么不是 100%？" → 先看历史 3 个月实际达标水平作基线，再和业务协商定一个"比现状略高、够用但不过度"的目标（如 99.9%）。100% 不可行：成本每加一个九指数增长、用户感知不出、且没有错误预算就没有发布自由（Ch3 原理）。SLO 严于 SLA，留出缓冲。
【机制·错误预算 → 告警】 "有了 SLO 怎么变成告警？为什么不直接对错误率设个阈值？" → SLO 反推错误预算（99.9% 月度 = 43.2 分钟不可用 = 0.1% 请求可失败）。简单阈值的两个致命问题：阈值高 → 慢速烧预算的持续小故障永远不告警；阈值低 → 抖动反复触发、告警疲劳。所以用**燃烧率（burn rate）**告警——按"多快在烧预算"来分级。

【机制·多窗口多燃烧率】 "燃烧率具体怎么配？14.4、6、1 这些数怎么来的？" → 燃烧率 = 预算消耗比例 / 时间窗占 SLO 周期比例。用 Google SRE Workbook 的推荐组合（下表）。双窗口的意义：长窗口保证"显著性"（不是一个抖动尖峰就报），短窗口保证"恢复后快速停止告警"（reset）。

严重级	长窗口	短窗口	燃烧率	若持续将消耗	多久烧光预算
Page（P0）	1 小时	5 分钟	14.4x	1 小时烧 2%	~2 天
Page（P1）	6 小时	30 分钟	6x	6 小时烧 5%	~5 天
Ticket（P2）	3 天	6 小时	1x	3 天烧 10%	30 天（正好用完）

（验算：14.4 = 0.02 ÷ (1h/720h)；6 = 0.05 ÷ (6h/720h)；1 = 0.10 ÷ (72h/720h)，SLO 周期取 30 天）

【治理·告警质量】 "怎么保证这些告警不变成噪音？" → 三条铁律：告警症状不告警原因（page 用户受影响的现象，CPU 高之类降为 ticket / dashboard 做前瞻）；每条 page 必须可执行（有明确 runbook，否则删掉或降级）；定期复盘告警的信噪比，把"响了但不用做任何事"的告警砍掉。

参考答题骨架 "分四步： ① 选 SLI——站在用户视角选 2-3 个（可用性 + 延迟 +（可选）核心业务成功率），埋点埋在离用户最近处； ② 定 SLO——看历史基线 + 和业务协商，定一个不过度的目标，解释清为什么不是 100%； ③ 反推错误预算 + 配燃烧率告警——不用简单阈值，用多窗口多燃烧率（14.4x/6x/1x → 2%/5%/10%），长窗口保显著性、短窗口保快速 reset； ④ 保证告警质量——症状告警、可执行、定期治理信噪比。落地物：Recording Rules（预聚合 5m/1h/6h/3d）+ Dashboard（当前可用性 + 预算剩余 Gauge + 燃烧率趋势）+ 错误预算政策文档。"

踩坑 / 加分点

good/total 口径必须全篇一致：通常 good = 2xx+3xx；5xx / 429 限流 / 499 客户端断连 / 504 超时算失败；纯客户端 4xx（400/404）算不算失败要显式约定（常见做法是从分子分母同时剔除，避免用户输错参数污染 SLO）。
别用可用性掩盖延迟：请求都返回 200 但慢到用户放弃，可用性 SLO 全绿也是坏——必须有独立的延迟 SLO。
只配长窗口 → 故障恢复后还在 page（长窗口滞后）；只配短窗口 → 抖动误报。双窗口 + for 时长缺一不可。
SLO 长期 100% 达标反而是坏信号——说明目标定低了、或团队不敢发布，应提高目标或加大功能投入（Ch3）。
加分金句："SLO 不是技术指标，是产品和 SRE 之间的合约——它决定了什么时候可以放手发布、什么时候必须停下来修稳定性。"
（细节回补：方案设计型第 1 题；原理追问型「SLO 为何非 100%」；概念解释型 SLI/SLO/SLA）

锚点题 3：这个月错误预算已经烧完了，产品经理坚持要上一个重要功能，你怎么办？#

为什么是锚点题 这是软硬结合的杀手题——考的不只是技术，是"错误预算政策"这个 SRE 制度设计，以及你在利益冲突里怎么用数据而不是情绪谈判。极高区分度：新人要么"硬刚不让上"、要么"老好人放行"，成熟 SRE 会讲"预算政策是事先约定的规则、冻结的是功能不是修复、有例外流程、强上就降风险"。几乎是 SRE 文化的试金石。

会串出的知识点地图

错误预算政策（Ch4）：预算用尽 = 冻结新功能发布，这是事先和管理层签好的规则，不是临场博弈
冻结的边界：冻的是 feature launch，不冻紧急修复 / 安全补丁 / 降低风险的变更
例外与豁免：谁有权豁免（通常是 SLO owner / 上级）、豁免要留记录
数据驱动谈判（Ch4）：错误预算的意义就是把"立场之争"变成"数据裁判"
强上如何降风险（Ch14）：金丝雀 / 渐进式发布 + 快速回滚 + feature flag
根因：预算为什么烧光了？是不是发布质量问题 / SLO 定太高

考官追问链

【现象·亮政策】 "你第一反应是什么？直接拒绝吗？" → 不情绪化拒绝，也不无原则放行。先亮出事先约定的错误预算政策："我们年初和管理层一起签过——预算烧完就冻结新功能发布，直到预算恢复。这不是我 SRE 拦你，是我们共同定的规则在生效。" 把冲突从"人对人"转成"人对规则"。
【机制·澄清冻结边界】 "那这个功能是不是就一定上不了？" → 澄清冻结的边界：冻结的是'增加风险的新功能发布'，不冻结'降低风险的变更'——紧急修复、安全补丁、以及能改善可靠性的改动照常走。先判断这个功能属于哪类。
【边界·例外流程】 "如果 PM 说这个功能是季度 OKR 必须上呢？" → 走例外豁免流程：错误预算政策本身应包含 exception 机制——由 SLO owner 或更高一级 stakeholder 评估业务价值 vs 可靠性风险后书面批准，并明确豁免的代价（比如同意后下个周期要优先还稳定性债）。豁免留记录，不搞私下放行。
【边界·强上降风险】 "老板拍板必须上，你拦不住了，怎么把风险降到最低？" → 用工程手段兜底：金丝雀 / 渐进式发布（1% → 10% → 100%，每档观察 SLI）、feature flag（出问题秒级关闭，无需回滚部署）、准备好快速回滚（并演练过）、加密监控和临时更严的燃烧率告警。把"要不要上"的政治问题，转成"怎么上得最安全"的工程问题。
【治理·刨根】 "这事过去之后你会做什么？" → 复盘预算为什么会烧光：是发布质量差（那要卡质量门禁 / 加测试）、还是 SLO 定得过高不现实（那要和业务重新校准 SLO）、还是有个长期未修的可靠性债。预算烧光是症状不是原因，不解决根因下个月照样烧光。

参考答题骨架 "我不会情绪化对抗，走四步： ① 亮规则——错误预算政策是年初和管理层一起签的，冻结是规则在生效，不是我个人在拦； ② 划边界——冻结的是增加风险的新功能，紧急修复 / 安全补丁 / 可靠性改进不冻； ③ 走例外——真有高优先级业务，走书面豁免流程，由 SLO owner 评估并明确代价； ④ 降风险——若最终决定强上，用金丝雀 + feature flag + 快速回滚把风险压到最低。事后一定要刨根：预算烧光是症状，复盘是发布质量、SLO 校准还是可靠性债的问题。"

踩坑 / 加分点

最容易翻车的回答是"我坚决不让上"——这显得 SRE 是发布的绊脚石。正确姿势是"我是来帮你安全地上，不是来拦你"。
错误预算政策必须事先签、有管理层背书——如果临到烧光才拿出来，就是空文，PM 完全可以不认。这一条能体现你懂"制度要前置"。
feature flag 优于回滚：flag 关闭是秒级、无部署、可按用户灰度；回滚要重新走部署、可能碰上不可回滚的 schema 变更。
豁免不是"批了就完"——要记账：这次透支下次要还（下周期优先还稳定性债），否则豁免会变成常态、预算政策形同虚设。
加分金句："错误预算把 SRE 和研发从对立变成同一战壕——预算充足时我巴不得你多发布快迭代，预算是我们共同的资源，不是我的 KPI。"
（细节回补：原理追问型「错误预算如何平衡速度与稳定」；概念解释型「错误预算」；方案设计型「渐进式发布」）

锚点题 4：一个服务开始过载 / 雪崩，会怎么一步步演变？你怎么把它止住？#

为什么是锚点题 高杠杆——级联故障（cascading failure）是分布式系统最凶险也最经典的失效模式，考它能一次性炸开"重试放大 / 队列耗尽 / 正反馈 / 亚稳态 / 熔断限流降级 / load shedding / 容量水位"一整棵树。高频——大厂几乎必问。区分度在"为什么加机器救不了"和"先丢负载而不是先扩容"这两个反直觉点上——答得出，一定踩过坑。

会串出的知识点地图

雪崩演变机制（Ch12）：过载 → 延迟升 → 客户端超时 → 重试 → 负载更高（重试放大正反馈）；线程池 / 连接池 / 队列耗尽；一台挂了负载转移到其余台 → 多米诺
亚稳态失效（metastable failure）：触发因素消失后系统仍卡在坏状态出不来，必须主动打断正反馈才能恢复
为什么加机器救不了：冷缓存 / JIT 未预热、对后端的连接风暴、根因在下游时新机器只是加更多压力
止血手段（Ch12）：先丢负载 load shedding（边缘按优先级 429/503）、优雅降级（关非核心功能）、熔断（快速失败保护下游）、限流（保护自己）
重试治理：指数退避 + jitter（防惊群）、重试预算（cap 在请求量的百分比）、禁止多层重试（乘法放大）
容量水位（Ch13）：留 headroom、健康检查抖动防护

考官追问链

【现象·演变】 "从一点小抖动到全面雪崩，中间发生了什么？" → 描述正反馈链：某台负载略高 → 处理变慢 → 客户端超时 → 客户端重试（负载凭空翻倍到三倍）→ 更慢 → 线程池 / 连接池 / 请求队列被占满 → 该台彻底不响应 → 健康检查判死 → 流量转移到其余台 → 其余台被同样压垮（多米诺）→ 全挂。
【机制·亚稳态】 "把触发它的那波流量撤掉，系统会自己恢复吗？" → 通常不会——这是亚稳态失效。重试和队列积压形成的正反馈已经自我维持，即使原始触发消失，系统仍卡在"忙着处理重试和超时"的坏状态里出不来。必须主动打断循环（丢负载 / 清队列 / 重启）才能跳回稳态。这是雪崩最反直觉的点。
【边界·加机器为什么没用】 "第一反应扩容加机器，行不行？" → 往往救不了甚至更糟：新起的实例冷缓存 / JIT 未预热，命中率低反而更慢；一批新实例同时对后端 DB / 缓存建连 = 连接风暴，把后端也打挂；如果根因在某个下游依赖，新机器只是往那个瓶颈灌更多流量。扩容是慢药，雪崩要快药。
【边界·正确止血顺序】 "那正确的止血顺序是什么？" → 先丢负载再谈其他：① Load shedding——在边缘 / 网关按请求优先级（criticality）主动拒绝一部分（返 429/503），保住系统能处理的那部分；② 优雅降级——关掉非核心功能（推荐、个性化），只保核心链路；③ 熔断——对劣化的下游快速失败，别让线程都堵在等它；④ 循环打断、状态恢复后，再逐步扩容 + 预热，把降级的功能慢慢放开。
【治理·根治重试与容量】 "以后怎么防止它再发生？" → 重试治理：指数退避 + jitter（防止所有客户端同时重试的惊群）、重试预算（重试量不超过正常请求的 ~10%）、禁止多层重试（每层重试 3 次、三层叠加 = 27 倍放大）；熔断 + 限流常态挂着；容量留 headroom、健康检查加防抖（避免一抖动就摘节点加剧转移）；用混沌工程注入过载演练（Ch15）。

参考答题骨架 "我分演变和止血两段讲：演变——过载→变慢→客户端超时→重试放大（正反馈）→线程池/队列耗尽→单点死→负载转移→多米诺全挂；关键是这是亚稳态，撤掉触发也不会自愈。止血——反直觉的两条：加机器救不了（冷缓存 + 连接风暴 + 灌爆下游），要先丢负载不是先扩容。顺序是 load shedding → 降级 → 熔断，先打断正反馈、稳住系统，再扩容预热恢复。根治——退避+jitter+重试预算、禁多层重试、常态熔断限流、容量留水位、混沌演练。"

踩坑 / 加分点

"加机器救不了"是这题的最大加分点——能主动说出冷缓存 + 连接风暴，考官立刻知道你真扛过雪崩。
重试是多层乘法放大：客户端重 3 次 × 网关重 3 次 × 服务间重 3 次 = 27 倍。只在最外层或最靠近用户的一层重试，内部层禁止重试。
jitter 不能省：没有 jitter 的指数退避会让所有客户端在同一时刻集体重试，形成新一波惊群（thundering herd），等于没退避。
健康检查抖动的坑：探针太敏感 → 服务稍慢就被判死摘掉 → 负载转移到其余台加剧过载 → 更多台被判死 → 全摘。就绪/存活探针的阈值和超时要留余量。
重启是双刃剑：重启能清掉坏状态跳回稳态，但重启后冷缓存可能又触发一轮雪崩——要配合 load shedding 慢启动。
load shedding 要按优先级：给请求打 criticality 标签（关键交易 vs 后台批量），过载时先丢低优先级，而不是无差别拒绝。
加分金句："雪崩的本质是正反馈循环——所以止血的第一性原理是'打断循环'，而不是'增加供给'；供给增加只会喂养循环。"
（细节回补：概念解释型「熔断/限流/降级」；原理追问型「重试为什么要退避」；场景排查型过载类题）

锚点题 5：怎么设计一次能扛住大促的容量规划 + 自动扩缩？#

为什么是锚点题 高频——电商 / 面向 C 端的岗必问；高杠杆——串起"需求预测 → 压测找拐点 → 资源水位 → HPA/扩缩冷启动 → 降级预案 → 与 SLO 关系"一整条容量工程链。区分度在"HPA 追不上突增怎么办（冷启动 / 预扩）"和"容量和 SLO 的关系"上——这两点分开纸上谈兵和真扛过大促。

会串出的知识点地图

需求预测（Ch13）：历史峰值 × 增长系数 + 营销活动量、有机增长 vs 计划事件
压测找拐点（Ch13）：找 utilization→latency 曲线的"膝盖点/拐点"，容量要留在拐点左侧
资源水位线：目标利用率、N+2 冗余（扛 AZ 故障）、给扩容反应时间留 headroom
HPA / 自动扩缩：基于 CPU / 自定义指标（QPS / 队列长度）、冷启动问题（镜像拉取 + 预热 + 建连）、预扩 / 定时扩容（scheduled / KEDA）
节点层扩容：Cluster Autoscaler 分钟级慢、需 overprovisioning（pause pod 占坑）
降级预案（Ch12、Ch14）：关非核心、加大缓存 TTL、写操作异步化、静态兜底页
与 SLO 的关系（Ch3-4）：容量按"峰值下仍满足 SLO"来定，overprovisioning 成本 vs 烧预算风险的权衡

考官追问链

【现象·预测】 "第一步怎么估到底要准备多少容量？" → 需求预测：以历史同类活动峰值为基线 × 业务给的增长系数（如去年双十一 QPS × 3），叠加有机增长；区分"有机增长（可渐进扩）"和"计划事件（尖峰、要预扩）"。预测要落到每个服务的 QPS / 每个资源的用量，不是拍脑袋一个总数。
【机制·压测找拐点】 "有了目标 QPS，怎么知道单实例能扛多少、要几台？" → 压测找拐点：逐步加压，画 utilization / QPS → 延迟曲线，找延迟开始非线性上翘的膝盖点（knee）——那就是单实例安全上限。容量要让峰值落在拐点左侧留余量，绝不贴着拐点跑（贴着跑一抖动就过拐点雪崩）。
【边界·冷启动追不上】 "大促零点流量瞬间上来，HPA 来得及扩吗？" → 来不及，这是最大的坑。HPA 感知负载 → 决策 → 起 pod → 拉镜像 + JIT 预热 + 建连接池 + 缓存预热，整个链路几十秒到几分钟；节点不够还要等 Cluster Autoscaler 加节点（分钟级）。而大促是秒级尖峰。所以不能靠 HPA 被动追，要预扩（pre-scale）：定时扩容（scheduled / KEDA）在活动前把容量提前拉满、提前预热缓存和连接、提前用 overprovisioning（pause pod 占坑）备好节点。
【边界·降级预案】 "万一预测不准、真超了准备的容量呢？" → 兜底靠降级预案（提前写好、演练过）：关非核心功能（推荐 / 评论 / 个性化）、加大缓存 TTL 挡读、写操作异步化削峰、极端时上静态兜底页 + load shedding 按优先级丢量（接锚点题 4）。宁可降级也不雪崩。
【治理·与 SLO 挂钩】 "容量到底该留多少 headroom？留多了浪费钱，留少了出事。" → 用 SLO + 错误预算来定：容量目标是"在预测峰值下仍满足 SLO"。留多少 headroom 是成本 vs 风险的经济决策——overprovisioning 烧钱，容量不足则烧错误预算。通常留出"扛住单 AZ 故障（N+2）+ 扩容反应时间"的余量。活动后复盘实际峰值 vs 预测，校准下次系数。

参考答题骨架 "五步一条链： ① 预测——历史峰值 × 增长系数 + 活动量，落到每服务 QPS； ② 压测找拐点——找延迟上翘的膝盖点定单实例上限，峰值留在拐点左侧； ③ 预扩而非被动扩——大促是秒级尖峰，HPA 有冷启动追不上，必须定时预扩 + 预热缓存/连接 + overprovisioning 占节点； ④ 降级预案兜底——预测不准就关非核心 / 加缓存 / 异步写 / load shedding，宁降级不雪崩； ⑤ 和 SLO 挂钩——headroom 是成本 vs 烧预算的经济权衡，目标是峰值下仍达 SLO，事后校准系数。"

踩坑 / 加分点

HPA 冷启动是最大的坑：新 pod 从"起来"到"能干活"差着预热、建连、拉镜像的时间；大促必须提前预扩，不能指望活动开始后 HPA 自动追。
HPA 基于 CPU 对 IO 密集 / 高并发等待型服务无效——这类要基于自定义指标（QPS、队列长度、并发连接数）扩，用 KEDA 更合适。
节点层扩容比 pod 慢一个量级：Cluster Autoscaler 要申请 + 启动节点（分钟级），大促要么提前扩好节点、要么用 pause pod overprovisioning 预留可被驱逐的"占坑"资源。
缓存预热常被忘：预扩了 pod 但缓存是冷的 → 大量请求穿透到 DB → DB 被打挂（接雪崩题）。要活动前主动灌缓存。
降级预案必须提前演练：临场才发现降级开关有 bug / 依赖没解耦，等于没有。用混沌工程验证（Ch15）。
压测环境要贴近生产：数据量、缓存状态、下游依赖都要仿真，否则测出的拐点是假的。
加分金句："扩缩容不是越自动越好——面对可预测的尖峰，预扩（确定性）比自动扩（追赶式）更可靠；HPA 是给不可预测的日常波动兜底的，不是给大促零点用的。"
（细节回补：方案设计型容量规划题；概念解释型「四个黄金信号-饱和度」；场景排查型容量类题）

锚点题 6：一次线上重大故障，IC / OL / CL 这些角色具体怎么分工协作？#

为什么是锚点题 高频——中高级 / Team Lead 岗必问，考的是"事件管理制度"而非纯技术。高区分度：没经历过大故障的人只会说"大家一起上排查"，经历过的人知道混乱的根源恰恰是没人指挥、所有人同时改系统。这题验证你懂不懂事件指挥体系（Incident Command System，源自消防）。

会串出的知识点地图

事件指挥体系 ICS（Ch10）：从消防应急体系借来的结构化响应
三大角色：IC（Incident Commander 指挥官）、OL（Operations Lead 操作负责人）、CL（Communications Lead 沟通负责人）；长事件加 Planning Lead
角色边界：IC 只协调不动手、OL 是唯一动手改系统的人、CL 对外沟通挡住干扰
SEV 严重等级（Ch10）：分级决定投入多少人、要不要拉 IC
On-call 与交接（Ch9）：长事件轮班交接（follow-the-sun）、心理负荷
收尾：交接给复盘（接锚点题 7）

考官追问链

【现象·为什么要角色】 "故障来了，大家一起上排查不就行了？为什么还要分角色？" → 因为无组织响应的典型失败模式是：所有人挤在一起同时改系统、互相踩、没人纵观全局、管理层来问没人回、两个人做了冲突的操作。ICS 用明确的单一指挥解决"忙而乱"。原则：任何时刻只有一个 IC。
【机制·三角色分工】 "IC、OL、CL 各干什么？" → IC（指挥官）：拥有整个事件、做决策、分派任务、维护实时事件文档、掌握全局——但绝不亲自敲键盘修（一动手就丢了全局视角）。OL（操作负责人）：唯一被授权改动生产系统的人，所有变更经他手，向 IC 报告——避免多人同时改。CL（沟通负责人）：对外——更新 status page、向管理层 / 客服 / 其他团队通报，挡住所有干扰让 OL 专心修。长事件再加 Planning Lead 管交接、跟进后续、长时间作战的后勤。
【边界·什么时候拉起这套】 "什么级别的故障才启动 IC？小问题也搞这一套不是很重？" → 按 SEV 严重等级决定：SEV1（重大、大面积不可用 / 数据风险）必须拉 IC 全套；SEV3 之类小问题 on-call 自己处理即可。原则是宁可早宣布再降级，不要拖到失控——宣布 incident 的成本远低于混乱的成本。
【边界·长事件怎么撑】 "故障持续 10 个小时怎么办，一个 IC 扛不住。" → 显式交接（handoff）：IC / OL 疲劳前正式移交，交接时口头 + 文档同步当前状态、已做操作、假设、下一步（follow-the-sun 跨时区接力）。交接必须显式确认"你现在是 IC 了"，不能含糊——最怕的是"我以为你在盯"的责任真空。
【治理·收尾】 "故障恢复了，IC 的活就结束了吗？" → 不。IC 负责宣布事件关闭、确保有人认领复盘（postmortem）、把实时事件文档 / 时间线交给复盘。事件响应和事后复盘是连着的（接锚点题 7）。

参考答题骨架 "核心是事件指挥体系（ICS），解决'忙而乱'：

IC 拥有事件、做决策、维护时间线、纵观全局，只指挥不动手；
OL 是唯一动手改系统的人，所有变更经他手；
CL 对外沟通、更新 status page、挡住管理层和其他团队的干扰；
长事件加 Planning Lead 管交接和后勤。按 SEV 等级决定启不启动全套；长事件靠显式交接接力；恢复后 IC 负责关闭事件并移交复盘。一句话：这套制度的价值是把'所有人乱上'变成'一个人指挥、一个人动手、一个人对外'。"

踩坑 / 加分点

IC 动手修是头号反模式——IC 一旦扎进某个具体问题就丢了全局，没人协调、没人看别的线索。宁可 IC"什么都不懂具体技术"，只要会协调。
"只有 OL 能改系统"是防灾关键——多人同时改会互相覆盖、无法归因（到底是谁的操作起了效果 / 闯了祸）。所有变更过 OL 一个口子、且记录在事件文档里。
CL 的价值被严重低估：没有 CL，管理层会直接冲进来找工程师问进度、打断修复；有 CL 挡着，OL 才能专心。CL 还负责 status page，避免用户和客服失控。
交接的责任真空最危险：交接不显式确认，就会出现"我以为你在盯着"，结果没人在盯。交接要点名到人、双方确认。
事件文档要实时写（谁在何时做了什么），不是事后补——它既是协调工具，也是复盘时间线的原始素材。
加分金句："IC 管的是人和信息流，不是 bug——最好的 IC 甚至可以不是最懂这个系统的人，因为他的工作是让最懂的人能专心修。"
（细节回补：概念解释型「Incident Command / SEV 等级」；On-call 值班题）

锚点题 7：怎么把一次线上故障，真正变成组织的长期改进？（无指责复盘怎么做）#

为什么是锚点题 高杠杆——它考的是"故障的价值提取"和 SRE 文化的核心：无指责（blameless）。高频——凡是讲究工程文化的团队必问。区分度在于能不能讲清"为什么必须无指责""为什么'人为失误'不是根因""行动项不闭环 = 白复盘"这几个成熟度信号。它是锚点题 1 和 6 的自然收尾。

会串出的知识点地图

无指责文化（Ch11）：对事不对人、假设每个人都在当时的信息下做了自认为对的决定
为什么无指责：指责 → 隐瞒 → 学不到东西；无指责 → 敢暴露真相 → 系统性改进
复盘结构（Ch11）：时间线（TTD/TTM/TTR）、根因 + 促成因素（多因，不是单一根因）、影响（SLO / 用户 / 预算）
"人为失误"不是终点：人能犯错说明系统缺护栏，要问"系统怎么让这个错误变得可能且没被拦住"
行动项闭环（Ch11）：SMART、有 owner + deadline、跟踪到关闭、优先级
触发标准：什么故障必须写复盘
让改进落地：复盘评审、行动项进 backlog 优先排、公开分享、衡量重复故障率

考官追问链

【现象·为什么无指责】 "复盘为什么强调'无指责'？不追责怎么让人长记性？" → 因为追责会杀死真相：一旦复盘变成找替罪羊，工程师就会隐瞒细节、不敢暴露自己的操作、不敢说"我当时没看懂那个告警"——你就永远拿不到真实的时间线，也就学不到东西。无指责的前提假设：每个人都是基于当时掌握的信息、做了他自认为合理的决定。要改的是系统和流程，不是惩罚人。
【机制·复盘结构】 "一份好的复盘长什么样？" → 至少包含：时间线（何时发生 / 何时发现 TTD / 何时止血 TTM / 何时恢复 TTR，暴露检测和响应的短板）、影响（多少用户、烧了多少错误预算、SLO 破没破）、根因与促成因素（往往是多个因素叠加，不是单一根因）、做对了什么 / 哪里运气好、行动项。
【边界·人为失误不是根因】 "复盘写'根因是运维手误敲错了命令'，可以收工吗？" → 不行——'人为失误'是调查的起点不是终点。要继续追："为什么这个手误能造成这么大影响？为什么没有二次确认 / 灰度 / 权限限制 / 自动校验拦住它？为什么这个高危操作还要人手敲？" 人能犯的错，系统就该有护栏。停在"人为失误"是最偷懒也最没价值的复盘。
【边界·行动项质量】 "复盘产出一堆行动项，怎么保证不是写完就烂尾？" → 行动项必须 SMART + 有明确 owner + deadline + 优先级，并进正式 backlog 像需求一样排期跟踪到关闭。区分优先级：P0 = 直接防复发的（最高）、其次是改善检测 / 响应速度的、再次是长期加固。没有 owner 和 deadline 的行动项等于没写。
【治理·让改进真的发生】 "怎么让复盘变成组织能力而不是一份存档文档？" → 几条：定期评审行动项进度（周会过一遍未关闭项，别让它烂）；衡量重复故障率（同类故障再发 = 复盘没起效）；公开分享复盘（别的团队从你的坑里学，别再踩）；明确复盘触发标准（哪些故障必须写——如任何用户可见的中断、数据丢失、SEV1/2、需要人工介入的告警），连 near-miss（差点出事）也值得复盘；营造安全氛围（如"本月最佳复盘"表彰，让人愿意暴露问题）。

参考答题骨架 "核心是无指责复盘 + 行动项闭环： ① 无指责——追责会让人隐瞒真相、学不到东西；前提是假设每个人都在当时信息下做了合理决定，要改的是系统不是人； ② 结构——时间线（TTD/TTM/TTR）+ 影响（SLO/预算）+ 多因根因 + 行动项； ③ 别停在'人为失误'——那是起点不是根因，要问系统为什么没有护栏拦住； ④ 行动项要闭环——SMART + owner + deadline + 进 backlog 跟踪到关闭； ⑤ 变成组织能力——定期评审、衡量重复故障率、公开分享、明确触发标准（含 near-miss）。一句话：复盘的产出不是文档，是'同一个坑不踩第二次'的系统性改进。"

踩坑 / 加分点

"人为失误 / human error"当根因是最大的不成熟信号——它一出现，考官就知道这个团队的复盘停留在甩锅层面。永远再追一层：系统为什么允许这个错误发生且没被拦？
行动项烂尾是复盘的头号杀手：绝大多数团队会开复盘会、写文档，然后行动项无人跟进、下季度同样故障重演。能讲"进 backlog + 周会过进度 + 衡量重复率"的，是真的把复盘做成闭环了。
无指责 ≠ 无责任：无指责是不惩罚"诚实的错误"，但对"隐瞒、明知故犯、绕过流程"仍要问责——分清这条边界很加分。
别只给大故障复盘：near-miss（差点出事但侥幸没爆）和小事件同样藏着系统缺陷，且代价低、最该学。只复盘 SEV1 会漏掉大量廉价的改进机会。
TTD 常常是最大问题：很多故障"发生了很久才被发现"，复盘时容易只盯根因而忽略"为什么这么晚才检测到"——改进检测（补监控 / 补告警）往往比修根因更普适。
复盘要趁热写（24-48 小时内），拖久了时间线细节就丢了；实时事件文档（锚点题 6）是复盘的原始素材。
加分金句："每一次故障都已经付过学费了——无指责复盘就是确保这笔学费不白交，把它变成组织的免疫力。"
（细节回补：概念解释型「无指责 Postmortem」；原理追问型「无指责为何有效」；锚点题 1、6 的收尾）

收尾提醒：这 7 道锚点题不是孤立的——它们本身就串成一条线： 锚点题 1（P99 突发） 是入口的"总题" → 定位时可能发现是 锚点题 4（雪崩） → 止血需要 锚点题 5（容量/扩缩） 的手段 → 处理过程靠 锚点题 6（IC/OL/CL） 的组织 → 收尾是 锚点题 7（复盘）；而这一切都建立在 锚点题 2（SLO/告警） 的地基上，锚点题 3（错误预算冲突） 则是这套体系在组织层面的应用。面试时如果能主动点出"这几道题其实是同一个故事的不同切面"，就是把 SRE 从"知识点"讲成了"体系"——这正是锚点题想验证的最高层能力。