SRE Book Part III 分布式可靠性专题

• 掌握数据中心负载均衡的层次
• 理解区域级故障与容量不对称的处理
• 掌握连接排空与健康检查

数据中心负载均衡在多个数据中心之间调度流量，保障可用性。区域级故障处理：通过健康检查与故障检测（探活、心跳）识别故障数据中心，自动把流量切换到健康区域，避免向故障区域转发。容量不对称：各数据中心容量不同，负载均衡需按容量加权分配流量，避免小容量区域过载、大容量区域闲置；结合流量权重与实时容量调整。连接排空（drain）：机房下线或维护前，优雅停止接收新连接，等待存量连接自然结束（drain），避免强行切断导致业务中断；配合健康检查状态（draining）让 LB 停止调度新流量。核心是"健康检查驱动故障切换、容量加权驱动均衡、排空保证优雅下线"，三者共同维持跨区域可用性。

面试官关注跨区域负载均衡的可用性。回答应体现故障切换、容量加权、连接排空与健康检查的组合。

• 掌握前端负载均衡的选择策略
• 理解按用户体验、区域与健康选择
• 掌握重试放大处理

前端负载均衡在用户与后端服务间分发请求，选择策略综合考虑：用户体验（选择延迟低、响应快的后端）、区域（就近选择本区域后端减少跨区延迟）、健康状态（跳过不健康/过载后端）。常用策略：加权轮询、最少连接、基于延迟/队列深度的选择、一致性哈希（session 保持）。健康状态用健康检查动态更新，剔除故障后端。重试放大处理是重点：后端故障/超时时客户端重试，若后端已被 LB 剔除但重试仍发生，或用无界重试，会放大请求（重试风暴）；需控制重试次数、加指数退避与抖动（jitter）、只在重试时优先选择健康后端、避免全局重试。核心是"选择健康且近的后端，并约束重试避免雪崩"。

面试官关注前端负载均衡与重试治理。回答应体现选择策略、健康检查、以及退避与抖动控制重试放大。

• 掌握容量告警阈值设计
• 理解过早扩容与过载的权衡
• 掌握分级阈值与缓冲

容量告警阈值需在"过早扩容（浪费成本）"与"过载风险（可靠性受损）"间平衡。设计原则：设置分级阈值，而非单一阈值——如 60% 预警、70% 告警、80% 紧急（结合扩容耗时），预留"扩容时间窗"（从告警到扩容生效的时间决定阈值）。考虑突发流量与业务波动：阈值需留缓冲，避免瞬时尖峰触发告警；用趋势而非瞬间值（如持续 N 分钟超阈值）。避免过早扩容：阈值过高导致频繁扩容成本高；避免过载：阈值过低导致来不及扩容。平衡方法：结合"扩容前置时间"设定阈值（扩容耗时越长，阈值越低）、按业务重要性分级、用容量模型（预测峰值）而非只看当前水位。核心是"告警要留出扩容时间，且随扩容速度动态调整"。

面试官关注容量预警的工程权衡。回答应体现分级阈值、扩容前置时间、趋势与缓冲、按业务分级。

• 掌握容量规划工具链的组成
• 理解各工具的角色
• 掌握选型考量

容量规划工具链用于采集、分析、预测容量。Prometheus 负责指标采集与存储（拉取指标、告警规则），Grafana 负责可视化与仪表盘（展示趋势、容量水位），自定义模型负责预测与建模（基于历史数据做线性/时间序列预测、建立容量模型推算 QPS）。选型考量：数据采集——Prometheus 适合云原生、指标采集，需关注指标规模与存储；可视化——Grafana 提供丰富仪表盘与告警，适合监控展示；预测——Prometheus 提供简单预测（如 predict_linear），复杂预测需自定义模型（时序预测、机器学习）。选型原则：小规模用 Prometheus+Grafana 即可，大规模/复杂需求引入自定义模型与专门容量平台；评估指标量、查询复杂度、预测精度需求、成本。核心是"采集、可视化、预测三件套按需组合"。

面试官关注容量工具链选型。回答应体现 Prometheus/Grafana/自定义模型的分工、选型考量与按规模演进。

• 掌握成本监控与异常检测
• 理解成本告警的设置
• 掌握成本异常的分析

成本异常检测用于及时发现成本突变（如资源失控、误扩、账单异常）。方法：指标化——把成本转化为可监控指标（按服务/资源/账户的月度/实时成本、单位成本、成本增长率）；基线对比——与历史基线（同周期、同规模）对比，检测偏离（如环比/同比突变）；阈值与规则——对成本显著上升设阈值告警（如单日成本超预算 X%、异常增长）；智能检测——用统计/机器学习识别异常模式（如季节性之外的成本尖峰）。成本告警设置：按业务/预算分级（研发、生产、部门），设置预算告警（预计超支提醒）、异常告警（成本突增）。分析：定位成本异常的源头（按标签、资源类型、区域下钻），结合资源利用率找浪费。核心是"成本要可观测、有基线、有告警、可下钻"。

面试官关注成本治理的监控化。回答应体现成本指标化、基线对比、阈值/智能告警、下钻定位异常。

• 掌握分布式共识的原理
• 理解 quorum 与 leader 选举
• 掌握状态复制对可靠性的影响

分布式共识用于在多个节点间达成一致，是可靠性的基础。quorum（法定多数）是共识的核心：多数节点（如 3 节点需 2 节点）确认才提交，保证任一时刻至多一个决策集成立，避免脑裂与双主。leader 选举（如 Raft、etcd）通过租约与投票选出单一 leader 负责写操作，保证状态一致；leader 故障时重新选举。状态复制（Raft 日志、状态机）把变更复制到多数节点，多数持久化才提交，保证故障时状态不丢失。对可靠性的影响：quorum 决定容错能力（3 节点容忍 1 故障，5 节点容忍 2），leader 保证写入一致，状态复制保证数据持久。权衡：更高 quorum 更可靠但更慢、更耗资源。核心是"共识保证一致性与故障容忍，是分布式可靠性的基石"。

面试官关注分布式一致性的原理。回答应体现 quorum 容错、leader 选举、状态复制，以及它们对一致性与可靠性的保证。

• 掌握单位经济指标的概念
• 理解 FinOps 与业务方对齐
• 掌握指标落地与优化

单位经济指标（如单位请求成本、单位用户成本）把云成本与业务价值挂钩，比"总成本"更能反映经营效率。FinOps 团队与业务方对齐需：定义单位（单位请求、单位用户、单位交易），把成本分摊到对应业务单元（借助标签、成本归属），计算"单位成本 = 总成本 / 业务量"；与业务方对齐基线（哪类单位成本合理、目标值）。对齐的价值：业务方能理解成本与业务量的关系，据此做资源投入与定价决策；成本优化聚焦"单位成本"而非盲目砍成本。落地：建立单位成本仪表盘、定期与业务方评审、把单位成本纳入业务指标（如单位请求成本下降）。核心是"用单位经济指标把成本与业务价值绑定，让 FinOps 与业务方共同优化而非对立"。

面试官关注成本与业务价值的对齐。回答应体现单位成本的定义、成本分摊、与业务方对齐基线、用单位指标优化。

• 掌握资源标签体系的设计
• 理解成本分摊（chargeback/showback）
• 掌握标签驱动成本治理

资源标签体系是成本分摊的基础：为云资源打标签（环境、业务、团队、成本中心、项目），使成本可按标签归属到具体业务单元。标签体系设计：统一标签规范（键值定义、命名、必填项）、按组织/业务维度分层（环境、团队、业务线、成本中心）、强制标签策略（创建资源必须打标）。成本分摊（chargeback/showback）：showback 是"把成本归集给业务方参考"（不实际扣钱），chargeback 是"实际向业务方计费"；通过标签把资源成本聚合到业务单元，生成分摊账单。标签驱动治理：用标签定位"谁在花钱、钱花在哪"，发现浪费（未打标、闲置、规格过大）；未打标资源成本无法分摊，需治理。核心是"标签体系是成本可观测、可分摊、可治理的前提"。

面试官关注成本分摊的落地。回答应体现标签体系设计、chargeback/showback 的差异、标签驱动成本治理。

• 掌握突发流量预案设计
• 理解快速扩容路径
• 掌握扩容与降级配合

突发流量（大促/热点）需提前设计容量预案。容量评估：基于历史峰值与业务预测估算流量峰值，预留缓冲；预案设计：明确峰值容量、扩容时机、扩容路径、降级与限流策略。快速扩容路径：自动化扩容（弹性伸缩、按需烧镜像、预置模板）、提前准备资源池（预留容量/预置实例）、多区域分载、数据库/缓存扩容预案。扩容时机：设定阈值（如 CPU/队列/延迟触发扩容），提前于峰值启动。配合降级：当扩容来不及或成本过高时，用限流、降级（舍弃非核心功能）、排队、缓存保护核心业务，防止雪崩。预案要演练（压测、全链路演练）验证可执行。核心是"提前评估、快速扩容、主动降级、演练验证"四者结合。

面试官关注突发流量的工程预案。回答应体现容量评估、快速扩容路径、降级限流配合、演练验证。

• 掌握闲置资源识别方法
• 理解回收与降配
• 掌握持续优化机制

闲置资源是成本浪费的常见来源。识别：用监控数据分析资源利用率（CPU/内存/磁盘/网络），识别长期低利用率（如 CPU 持续 <5%）、无流量实例、过剩规格（规格远大于实际需求）、未使用服务/存储快照。回收：对确认闲置的资源下线/释放（停用、删除、清理快照与未用卷），对规格过剩的降配（rightsizing）。持续优化机制：定期扫描（自动化扫描资源利用率，生成报告）、建立规格基线（按负载推荐规格）、预算与告警约束（超预算提醒）、把资源优化纳入团队成本责任。注意事项：回收前确认无依赖、有回滚（保留足够时间观察）。核心是"用数据识别闲置、用降配/回收优化、用机制持续检查"，避免"占有即浪费"。

面试官关注成本优化与资源治理。回答应体现低利用率识别、回收降配、持续扫描与预算机制。

• 掌握容量压测的方法
• 理解过载暴露的路径
• 掌握压测结果与容量规划联动

压测是提前暴露容量不足、避免线上过载的关键手段。方法：分级压测（基准测试、负载测试、峰值压测、破坏性压测），逐步加压观察系统指标（吞吐、延迟、错误率、资源利用率）找到瓶颈点与饱和点。暴露过载：用容量压测模拟业务峰值，观察系统在多少并发/容量下开始过载（延迟飙升、错误率上升、队列堆积），找出"拐点"；结合慢启动、突发流量场景。与容量规划联动：压测结果（最大承载 QPS、资源水位与容量的关系）建立容量模型，推算生产峰值所需资源，据此扩容或预留。压测发现的问题（瓶颈组件、扩容点）作为整改项。核心是"用压测在低成本环境下复现过载，提前定位容量短板并规划"。

面试官关注容量过载的前置暴露。回答应体现分级压测找拐点、过载场景模拟、压测结果与容量规划联动。

• 掌握长尾流量与季节性的特征
• 理解预测偏差的来源
• 掌握处理偏差的方法

容量规划的预测常受长尾流量与季节性波动影响而偏差。长尾流量：少量高价值但频率低的大流量（如突发热点、大客户活动），平均值会低估峰值，需关注峰值/分位数而非均值。季节性波动：按天/周/月/年周期的规律波动（如工作日高峰、节假日、大促），需用季节性分解与同周期对比预测。处理偏差：按分位数（P95/P99）而非均值规划，预留峰值缓冲；用季节性模型（分解趋势+季节+残差）预测；对比历史同周期（去年同月、上周同期）校准；对不可预测的突发事件预留弹性扩容与降级预案。核心是"预测要识别波动模式、用峰值与分位数、留缓冲"，避免"均值规划导致峰值过载"。

面试官关注容量预测的波动性处理。回答应体现长尾取峰值、季节性分解、分位数与缓冲、弹性预案。

• 掌握过载处理机制
• 理解各机制的组合
• 掌握避免延迟雪崩

过载时不控制，排队+重试会引发延迟雪崩。组合机制：排队（有限队列暂存请求，控制并发）、限流（超阈值拒绝请求，保护系统）、优先级（核心请求优先，低优先级先丢）、背压（下游慢时上游主动减速/拒绝，避免无限堆积）、负载 shedding（主动丢弃"非关键/可重试"请求，保护核心）。组合策略：先限流+排队控制进入的量，用优先级区分请求，用背压向调用方传导压力，用负载 shedding 削掉低价值请求。关键是多处配合：限流防超出、排队缓冲、优先级保核心、背压限线程、shedding 降负载。避免延迟雪崩：控制重试、拒绝超时请求、避免队列无限增长（队列满时快速失败）。核心是"把过载化为可控的拒绝与降级，而非全量排队堵死"。

面试官关注过载的工程化处理。回答应体现排队/限流/优先级/背压/shedding 的配合与延迟雪崩的防止。

• 掌握三类实例的特点
• 理解成本与稳定性权衡
• 掌握组合采购策略

三类实例在成本与稳定性上不同：预留实例（Reserved）——预付换取折扣，稳定、适合长期稳定负载；Spot 实例——竞价、成本低但可能被中断，适合无状态、可中断、容错负载；按需实例——随时可用、成本最高、弹性好，适合突发与不可预测负载。权衡与组合：稳定且有规律的负载用预留实例（成本优、稳定）；可中断/容错的工作（批处理、无状态、可重试）用 Spot 实例（大幅降成本）；突发、弹性、无法预测的负载用按需实例（保证可用）。采购策略：按负载画像分类，用预留覆盖基线、Spot 覆盖弹性可中断部分、按需兜底突发。稳定性保障：对 Spot 运行的关键任务做容错（自动重建、检查点）、监控 Spot 中断提示。核心是"按负载稳定性与容忍度匹配实例类型，平衡成本与稳定性"。

面试官关注实例采购的成本与稳定性权衡。回答应体现三类实例特点、按负载画像组合、容错保障。

• 掌握超时设置原则
• 理解重试放大控制
• 掌握抖动（jitter）设计

超时与重试是分布式可靠性的关键，设计不当会放大故障。超时设置：客户端超时应合理（不能过长导致阻塞、过短导致误判），结合服务延迟分布（如 P99）设置；超时应随重试递减（总预算固定）。重试放大控制：无界重试会导致重试风暴（雪崩），需限制重试次数、总重试预算（总时间上限）、只对"可重试"错误重试（幂等、非致命错误）、避免对"已超时/服务 down"立即重试。抖动（jitter）：重试时加随机延迟（jitter），避免所有客户端同时重试造成"惊群/同步重试"，用指数退避+上限+抖动。核心是"超时设预算、重试有界、退避加抖动"，把故障的放大控制在可控范围。

面试官关注超时与重试的工程细节。回答应体现超时设置、有界重试与预算、指数退避与抖动。

• 掌握 Spot 实例中断特性
• 理解中断对容量的影响建模
• 掌握缓冲与容错设计

Spot 实例可被云厂商随时中断（受市场价格与需求影响），中断会产生容量瞬时减少。建模：把 Spot 容量视为"可用概率"而非恒定——统计中断频率、中断比例、中断集中度，建立"可用容量 = 申请量 ×（1 - 中断率）"的模型，考虑中断的突发性（可能集中中断）。缓冲设计：预留冗余容量（按中断率预留缓冲，如 1/(1-中断率)）、跨可用区/区域分散降低同时中断概率、保留按需/预留实例作为兜底（保证核心容量）。容错：对 Spot 工作做检查点/可恢复设计，中断后自动重建；监控中断事件（实例中断通知）提前处理。核心是"把 Spot 不确定容量建模为概率，用缓冲与兜底保证核心容量稳定"。

面试官关注 Spot 中断的容量管理。回答应体现中断概率建模、缓冲预留、跨区分散与兜底容错。

• 掌握容量模型构建
• 理解 QPS 与资源水位推算
• 掌握预测与压测结合

容量模型用于把业务量预测转化为资源需求，推算 QPS 与资源水位。构建：基于业务增长预测（用户增长、转化率、活动计划）估算未来 QPS；用压测数据建立"QPS 与资源消耗"的关系（如每 QPS 的 CPU/内存/连接数），得到单位容量。推算：目标 QPS = 当前 QPS × 增长率 × 峰值系数；资源水位 = 目标 QPS × 单位资源消耗 × 缓冲系数。模型要素：峰值系数（高峰/均值比）、冗余系数（预留 N% 缓冲）、增长系数（预测增长率）。实施：用压测校准单位资源消耗，用业务预测校准增长，定期用实际数据校验模型（预测 vs 实际）。核心是"业务预测×单位容量×缓冲系数=资源需求"，并用数据持续校准。

面试官关注容量模型的工程化。回答应体现业务预测、压测单位容量、QPS 与资源水位推算、模型校准。

• 掌握容量评审的频率
• 理解参与方与职责
• 掌握决策机制

容量评审会是容量规划落地的重要机制。频率：按业务节奏设定（如每月常规评审、大促前专项评审、季度或年度容量规划）；关键节点（发版、活动、业务增长）前加开。参与方：业务方（提供业务预测、活动计划）、研发/运维（提供系统容量与压测数据）、财务/FinOps（成本视角）、容量负责人（主持与决策）。决策机制：评审会输出容量决策（是否扩容、扩容多少、何时扩容、预算分配），明确决策依据（业务预测、容量模型、压测数据）与决策记录；重大决策需多角色确认，形成可执行的 action item。评审会不是"汇报会"而是"决策会"，聚焦"容量是否够、风险是否可控、资源是否合理"。核心是"以数据为决策依据，多角色对齐，形成可执行结论"。

面试官关注容量评审的组织。回答应体现频率设定、参与方分工、数据驱动的决策机制与 action 闭环。

• 掌握假阳性与假阴性
• 理解对负载均衡与容灾切换的影响
• 掌握治理方法

健康检查判定失真会影响负载均衡与容灾切换。假阳性（healthy 判定为 unhealthy）：健康节点被误判不可用，导致流量被移除、负载不均、甚至不必要的切换；假阴性（unhealthy 判定为 healthy）：故障节点未被发现，流量仍发往故障节点，导致请求失败。影响：假阳性引起不必要的切换/震荡（thrash），假阴性导致请求打到坏节点。治理：健康检查设计要合理——探测关键业务接口而非仅端口、设置合理超时与次数（避免瞬时抖动误判）、区分"轻微退化"与"不可用"（熔断/权重）、健康检查与负载均衡联动（用半开状态逐步恢复）。容灾切换用"多指标+多数仲裁"避免单点误判。核心是"健康判定要准确、稳定，避免误切与漏切"。

面试官关注健康检查的可靠性。回答应体现假阳性/假阴性成因、对负载均衡与切换的影响、治理方法。