稳定性事故项目口述、容量排障与综合题库

章节定位：本章收口 53 模块，把指标、容量、故障、演练和成本治理放入同一条事故时间线。全部数字均为 E3（演练证据），只用于展示可复算方法，不能冒充生产结果。指标口径回链 01-SLI-SLO错误预算与业务技术成功率，容量模型回链 02-容量排队Little定律与资源模型，恢复边界回链 03-故障模型RPO-RTO与容灾恢复，实验方法回链 04-压测恢复与混沌演练方法，成本与降级回链 05-成本容量治理扩缩容降级与预算。

正式建模源见 reliability-interview-fault-domain.puml。图中把入口、应用、权威数据、异步队列、外部依赖和业务验收拆成独立故障域；任何“恢复”都必须同时通过新增影响停止、历史差异收敛、业务不变量成立和故障余量复验。

1. 从事故信号到业务恢复的十二个口述面

1. 事故开场先冻结用户结果、时间线与证据等级 {#53-06-k01}

稳定性事故的第一句话不应是“某组件挂了”，而应说明谁在什么窗口内没有得到什么结果，以及哪些事实已经证实。事故指挥先冻结版本、流量、受影响租户、首个异常样本和最后正常水位，把指标、日志、链路、业务审计分列为证据，推断单独标注。技术错误回落只能证明当前请求改善；支付未知、库存差异、导出孤儿文件和报警漏送仍要逐项收敛。口径边界详见稳定性信号与迁移路线及技术恢复后的业务验证。

sequenceDiagram
    participant 用户
    participant 指挥
    participant 观测
    participant 审计
    用户->>指挥: 报告结果失败与样本
    指挥->>观测: 冻结窗口、版本和切片
    观测-->>指挥: 返回错误、时延与积压
    指挥->>审计: 核对支付、库存、产物和报警
    alt 证据一致
        审计-->>指挥: 确认影响边界
    else 证据冲突
        审计-->>指挥: 保留未知并扩大取证
    end

数据演绎 1：投诉量与技术错误不能直接互换

十分钟内入口有 120,000 个业务意图，技术失败 1,200 个；业务审计发现 900 个已明确失败、180 个经查单成功、70 个仍未知、50 个缺少关联标识。可确认坏事件至少为 900，待处置对象为 70 + 50 = 120，不能直接把 1,200 / 120,000 = 1% 当最终业务影响。先补齐 50 个对象的关联，再决定最终分子；这也解释了为何事故开场必须同时报告证据缺口。

热门面试题

1. 问题：稳定性事故汇报为什么先讲用户结果？
   • 考点：技术现象与业务影响边界。
   • 回答思路：先界定受损结果，再用技术信号解释。
   • 详细答案：组件异常可能被冗余吸收，组件健康也可能遗漏前端、外部渠道或历史积压。先讲用户结果能固定事故优先级、影响分母和恢复验收，再把错误、时延、队列与资源作为定位证据，避免修好某个进程就过早宣布恢复。
   • 进阶追问：用户结果暂时无法计算怎么办？
   • 进阶回答：明确报告证据覆盖率和未知对象数，采用保守止血并补关联标识，不能用不完整技术分母代替。
2. 问题：时间线中哪些节点必须记录？
   • 考点：事故可追溯性。
   • 回答思路：覆盖出现、检测、决策、动作、技术恢复和业务恢复。
   • 详细答案：至少记录首次异常、首次告警、人工确认、变更冻结、限流或回滚开始、错误回落、积压转降、未知态清零和业务验收完成。每个节点绑定责任人、命令或变更记录，才能拆出检测延迟、决策延迟和执行延迟。
   • 进阶追问：监控时间和业务时间冲突信谁？
   • 进阶回答：保留两套时间及各自语义，按原始事件校时；在未解释时钟或采集延迟前，不强行合成一个时间。
3. 问题：如何避免事故中把推断写成事实？
   • 考点：证据分级与沟通纪律。
   • 回答思路：为每条结论附来源、范围和反证条件。
   • 详细答案：事实必须能定位到指标原始桶、日志样本、链路、账本或工单；相关时间只能形成假设，需通过版本切片、对照组或复现实验验证。对外同步将“已确认影响”“当前假设”“仍待查证”分栏，并在新证据出现时保留修订记录。
   • 进阶追问：根因未明能否先回滚？
   • 进阶回答：可以，若版本相关性强且回滚可逆，应以止损优先，但必须说明这是减险动作而非根因证明。

2. SLI（服务等级指标）、SLO（服务等级目标）与错误预算决定事故门槛 {#53-06-k02}

事故门槛来自预先约定的好事件、坏事件、可评价事件、窗口和正确性红线。SLO（服务等级目标）允许的坏事件数减已发生坏事件得到剩余预算；燃尽速度回答当前异常若持续会多快耗尽预算。预算健康也不能覆盖重复扣款、确认超卖或关键报警漏报等高损失事件。止血后要分别验证短窗口不再高速燃烧、长窗口趋势稳定、未知态没有继续增长。计算规则详见错误预算、多窗口燃尽和预算动作表。

sequenceDiagram
    participant 事件
    participant 指标器
    participant 预算器
    participant 发布门禁
    participant 指挥
    事件->>指标器: 归并业务意图与终态
    指标器->>预算器: 好事件、坏事件、未知态
    预算器->>发布门禁: 剩余预算与燃尽速度
    alt 红线命中或高速燃尽
        发布门禁->>指挥: 冻结放量并启动止血
    else 风险受控
        发布门禁->>指挥: 保持灰度并加强观察
    end

数据演绎 2：预算未耗尽也应停止放量

二十八天有 4,000,000 个可评价事件，SLO（服务等级目标）为 99.95%，允许坏事件 4,000,000 × 0.05% = 2,000 个。此前已用 1,300 个，剩余 700 个；灰度十分钟产生 180 个坏事件，当前流量只占 10%。若线性放大全量，候选损失约 1,800 个，明显超过剩余预算，因此即使当前累计仅 1,480 个也必须停止放量。若其中包含一笔重复扣款，则无需等待比例判断，直接触发正确性红线。

热门面试题

1. 问题：错误预算耗尽是否意味着禁止所有变更？
   • 考点：风险变更与减险变更区分。
   • 回答思路：冻结高不确定发布，保留受控修复通道。
   • 详细答案：预算耗尽说明用户风险已超标，应暂停功能放量和无关变更，但回滚、限流、安全修复、查单补偿仍需执行。每个减险动作要有最小范围、观察窗、回退点和业务验收，不能用“冻结变更”阻止恢复。
   • 进阶追问：修复也可能失败怎么办？
   • 进阶回答：按小批次推进，每批复核坏事件、未知态和不变量，异常立即退回上一稳定检查点。
2. 问题：燃尽速度为什么比单点错误率更适合告警？
   • 考点：目标归一化与持续性。
   • 回答思路：把当前错误率与目标允许错误率比较。
   • 详细答案：相同错误率对不同目标的风险不同，燃尽速度能表达预算消耗倍数；短窗口发现突发，长窗口过滤瞬时噪声。两者结合可减少单点阈值在流量波动下的误报，同时直接连接发布和事故动作。
   • 进阶追问：低流量路径如何处理？
   • 进阶回答：增加最小样本、逐事件红线和合成探测，不用一个偶然百分比驱动自动动作。
3. 问题：为什么预算健康仍可能是严重事故？
   • 考点：聚合比例与高损失事件。
   • 回答思路：说明大分母会稀释稀有正确性故障。
   • 详细答案：重复扣款、负库存和关键报警漏报即使只有一笔，也可能造成不可接受损失，而聚合预算仍显示充足。因此错误预算治理必须叠加领域不变量红线，先保证资金、库存和安全正确，再优化总体可用性。
   • 进阶追问：红线如何防止过度敏感？
   • 进阶回答：要求权威证据确认并定义自动冻结范围，但不能用全局比例抵消已确认的不变量破坏。

3. 容量排障用到达率、服务时间、在途量和瓶颈边界说话 {#53-06-k03}

“CPU（中央处理器）高”只是现象，容量排障要先固定业务对象与单位。Little’s Law（利特尔定律）在守恒窗口内给出在途量约等于到达率乘平均停留时间；停留时间还要拆等待与真实服务。若应用扩容后数据库连接、热点锁或外部渠道限额不变，总能力不会线性增长。现场按入口、队列、线程、连接、数据库、消息和依赖逐层寻找首先出现等待斜率的资源，方法详见Little’s Law（利特尔定律）、利用率拐点与资源分别预算。

sequenceDiagram
    participant 入口
    participant 线程
    participant 连接
    participant 数据库
    participant 依赖
    入口->>线程: 到达率与等待时间
    线程->>连接: 获取数据库连接
    连接->>数据库: 执行业务事务
    数据库->>依赖: 触发必要副作用
    依赖-->>数据库: 返回或超时
    数据库-->>连接: 提交结果
    连接-->>线程: 释放连接
    线程-->>入口: 返回业务结果

数据演绎 3：应用扩容可能把数据库推向崩溃

入口到达率 500 次/秒，平均端到端停留 0.4 秒，在途约 500 × 0.4 = 200。十个实例每个连接池 30，总上限 300；数据库安全会话预算只有 220，还需为管理和补偿保留 20，业务最多 200。若盲目扩到十五个实例，总池上限变成 450，不会增加数据库有效能力，反而放大锁等待与超时重试。正确动作是先把业务总连接限制在 200，切走非关键查询，再验证数据库成功完成率。

热门面试题

1. 问题：Little’s Law（利特尔定律）在事故中怎么用？
   • 考点：守恒窗口与量纲。
   • 回答思路：用到达率和停留时间估算在途，再对照资源槽位。
   • 详细答案：选取到达和完成相对稳定的同一窗口，以业务意图到达率乘平均停留时间估算在途量，用来检查线程、连接或任务槽位是否足够。它不能直接证明瓶颈，也不能在流量快速变化或大量丢弃时机械套用，仍需拆等待位置。
   • 进阶追问：为什么平均值可能误导？
   • 进阶回答：热点和长尾会让少量请求长期占槽，应同时看分位数、分片切片和等待队列。
2. 问题：应用实例越多为什么吞吐可能越低？
   • 考点：共享依赖与争用放大。
   • 回答思路：从总连接、锁、缓存回源和重试解释。
   • 详细答案：实例增加会同步增加线程、连接和回源并发；当数据库、消息分区或外部渠道已到上限，更多请求只会扩大锁竞争、上下文切换与超时重试，正确完成率反而下降。扩容前必须计算共享总量并设置入口并发。
   • 进阶追问：何时可以直接横向扩容？
   • 进阶回答：瓶颈确在无状态实例，依赖余量、预热和流量均衡均已验证时，才小步扩容并观察有效完成量。
3. 问题：怎样定位第一个容量瓶颈？
   • 考点：等待与服务分解。
   • 回答思路：沿请求路径比较水位、等待和完成斜率。
   • 详细答案：从客户端发压或入口到达开始，依次检查网关排队、线程等待、连接获取、数据库执行、锁、消息确认和外部调用；最先出现等待增长且下游完成量不再增长的位置是优先候选。再用限并发或隔离实验验证因果。
   • 进阶追问：链路采样不足怎么办？
   • 进阶回答：用分层计时、连接池等待、慢操作样本和队列水位互证，结论保留不确定性并补观测。

4. 排队与恢复必须看净消化率、最老年龄和恢复斜率 {#53-06-k04}

队列长度是存量，斜率才说明事故是否还在扩大。净消化率等于成功完成率减新到达率；预计清空时间近似为当前积压除净消化率，但前提是任务大小、重试和依赖能力相对稳定。恢复期间若只追求拉取量，可能让数据库、对象存储或支付渠道再次过载。应按优先级、租户和任务成本限并发，观察最老年龄持续下降，并把失败重试与新业务分开。基础公式见消息积压模型和净消化恢复。

sequenceDiagram
    participant 入口
    participant 队列
    participant 工作者
    participant 下游
    participant 指挥
    入口->>队列: 新任务持续到达
    指挥->>工作者: 设置优先级与并发上限
    工作者->>队列: 领取带租约任务
    工作者->>下游: 执行业务副作用
    下游-->>工作者: 返回明确结果
    工作者-->>指挥: 成功完成率与失败率
    指挥->>队列: 核对积压和最老年龄

数据演绎 4：总吞吐看似很高，恢复却可能不动

队列积压 180,000 个任务，新到达 1,500 个/秒，工作者拉取 2,400 个/秒，但其中 500 个失败后重试，真正成功完成只有 1,900 个/秒。净消化率是 1,900 - 1,500 = 400 个/秒，理论清空约 180,000 / 400 = 450 秒。若下游退化使成功完成降到 1,450，即使拉取仍为 2,400，净斜率变成 -50，积压继续增长，必须降并发或隔离失败类型。

热门面试题

1. 问题：为什么恢复速度不能用消费拉取量表示？
   • 考点：处理尝试与成功完成区分。
   • 回答思路：扣除失败、重试和新到达。
   • 详细答案：拉取只说明工作者取到了任务，失败后回队、超时未知和重复执行都没有减少业务存量。恢复能力必须按正确完成量计算，再减去同期新到达；同时看最老年龄，防止只处理新任务制造表面下降。
   • 进阶追问：积压下降就能放量吗？
   • 进阶回答：还要确认下游水位、不变量和失败率稳定，避免通过丢弃或重复副作用换来长度下降。
2. 问题：如何防止恢复流量造成第二次事故？
   • 考点：受控恢复与下游保护。
   • 回答思路：按优先级限并发，小批放量并设置停止条件。
   • 详细答案：先测下游在当前退化状态下的安全完成量，为实时业务预留容量；恢复任务按价值和年龄分队列，每批提升并发后观察连接、锁、限额、失败和业务差异。任何反弹都退回前一档，而不是继续加工作者。
   • 进阶追问：老任务会饿死怎么办？
   • 进阶回答：设置年龄提升与最低保障配额，同时隔离反复失败的毒任务进入人工或专用队列。
3. 问题：预计清空时间为何经常不准？
   • 考点：模型假设与敏感变量。
   • 回答思路：指出任务大小、到达率、失败率和依赖能力会变化。
   • 详细答案：简单公式假设净消化率稳定，但事故中任务成本分布、外部限额和重试比例会变化。应滚动使用最近稳定窗口重算，并给出区间；最老年龄、不同任务类型和下游水位用于判断模型是否失效。
   • 进阶追问：面试时如何表达不确定性？
   • 进阶回答：明确输入假设、给上下界和触发重算条件，不把单点时间当承诺。

5. RPO（恢复点目标）、RTO（恢复时间目标）与故障模型共同定义恢复边界 {#53-06-k05}

RPO（恢复点目标）回答可接受丢失到哪个时间点，RTO（恢复时间目标）回答业务能力多久恢复；二者都要落到业务事实。数据库启动不代表库存流水完整，应用可访问不代表支付未知已查清。故障模型还需覆盖慢依赖、网络分区、逻辑污染、误操作、区域故障和供应商退出，按故障域配置写栅栏、备份、重放、降级与人工清单。详细边界见故障对象与证据、分层恢复目标和切换回切。

sequenceDiagram
    participant 故障域
    participant 指挥
    participant 写栅栏
    participant 恢复域
    participant 校验
    故障域--x指挥: 写入不可用或数据可疑
    指挥->>写栅栏: 冻结旧主与危险写
    指挥->>恢复域: 选择安全位置并重放
    恢复域->>校验: 提交位置、摘要与差异
    alt 数据目标与时间目标均满足
        校验-->>指挥: 允许小流量恢复
    else 任一目标不满足
        校验-->>指挥: 保持隔离并继续补偿
    end

数据演绎 5：RTO（恢复时间目标）达标但 RPO（恢复点目标）可能失败

库存每分钟产生 4,800 条预占流水，异步复制最坏落后 3 分钟，切换耗时 8 分钟。服务在十分钟目标内恢复，RTO（恢复时间目标）表面达标；但候选缺口为 4,800 × 3 = 14,400 条。若库存要求不丢预占事实，就必须从订单日志和消息水位重建并核对释放、扣减，补齐前不能宣布 RPO（恢复点目标）达标。若重放净能力为每分钟 7,200 条且新到达 4,800 条，补齐还需 14,400 / 2,400 = 6 分钟。

热门面试题

1. 问题：RPO（恢复点目标）为零是否等于绝不丢数据？
   • 考点：目标、机制与证明。
   • 回答思路：说明目标需要复制、日志和业务对账共同证明。
   • 详细答案：零目标是业务要求，不是部署标签。同步复制也可能复制逻辑错误，外部副作用还可能在响应丢失后未知。必须定义权威记录、确认点、重放来源和差异验收，演练后才能证明给定故障下接近目标。
   • 进阶追问：支付如何做到接近零？
   • 进阶回答：保留稳定业务键、渠道凭证、不可变分录和查单对账能力，即使响应丢失也能重建终态。
2. 问题：为什么数据库恢复不等于业务恢复？
   • 考点：基础设施与业务不变量。
   • 回答思路：列出应用、队列、外部结果和历史差异。
   • 详细答案：数据库可读写只证明基础能力，事故窗口中的消息、缓存、外部调用和人工动作可能仍不一致。业务恢复要核对库存守恒、账务平衡、任务唯一和报警覆盖，并确认新增请求与历史积压都稳定。
   • 进阶追问：先开放只读是否可行？
   • 进阶回答：可以，前提是展示数据水位与陈旧边界，并禁止用户把旧状态当可执行承诺。
3. 问题：回切为什么也是一次高风险变更？
   • 考点：写入权和数据位置。
   • 回答思路：描述旧域重建、追平、校验与灰度。
   • 详细答案：原故障域恢复后可能数据落后、配置漂移或故障未消除，直接回切会形成第二次中断或双写。应从新主重建旧域，确认位置与摘要一致，冻结写入、设置栅栏，再小流量回切并保留停止条件。
   • 进阶追问：可以长期不回切吗？
   • 进阶回答：可以，但要重新评估容量、成本、依赖和下次故障路径，把临时恢复域正式化。

6. 压测与混沌演练必须证明边界、停止条件和恢复能力 {#53-06-k06}

压测回答给定负载与环境下的性能边界，混沌演练回答故障发生时系统和团队能否守住稳态。两者都要声明版本、数据基数、热点分布、开环或闭环模型、外部副作用隔离、爆炸半径和停止条件。最高吞吐不是唯一结论；排队拐点、正确完成率、错误预算损失、恢复净斜率与业务对账同样重要。方法详见六类压测、混沌合同和结论失效条件。

sequenceDiagram
    participant 方案
    participant 发压器
    participant 系统
    participant 故障注入
    participant 验收器
    方案->>发压器: 下发负载、热点与停止条件
    发压器->>系统: 阶梯增加业务意图
    故障注入->>系统: 注入慢、错、断与实例失效
    系统-->>验收器: 指标、终态与差异清单
    alt 命中停止条件
        验收器-->>发压器: 停止施压并保全证据
    else 稳态仍成立
        验收器-->>方案: 记录边界并进入恢复验证
    end

数据演绎 6：闭环压测会隐藏真实到达压力

300 个并发用户在系统响应 0.2 秒时，忽略思考时间的闭环吞吐约 300 / 0.2 = 1,500 次/秒；系统变慢到 1.0 秒后，闭环吞吐自动降为约 300 次/秒，看板可能误以为入口压力下降。若生产上游按固定 1,200 次/秒开环到达，此时会每秒新增约 900 个等待。压测必须明确模型，并同时观察发送计划、实际发送、系统接收和正确完成，不能用闭环自限流证明生产安全。

热门面试题

1. 问题：压测通过为什么仍要做混沌演练？
   • 考点：性能边界与故障恢复差异。
   • 回答思路：区分正常负载能力和异常状态收敛。
   • 详细答案：压测通常证明稳定环境下的吞吐和时延，不能证明实例失效、依赖超时、重复消息或监控缺样时不变量仍成立。混沌演练验证检测、隔离、降级、查单、回放和团队协同，补足恢复证据。
   • 进阶追问：能在生产做吗？
   • 进阶回答：可以从只读、小租户和单实例开始，但必须有爆炸半径、权限、停止条件和业务责任人。
2. 问题：怎样确定压测停止条件？
   • 考点：实验伦理与风险控制。
   • 回答思路：同时设置技术线和业务红线。
   • 详细答案：技术线包括错误、尾时延、队列斜率、连接与资源水位；业务线包括资金差异、负库存、关键报警遗漏和外部副作用。任一高损失红线命中立即停止，不能为寻找极限继续放大损失。
   • 进阶追问：停止后先做什么？
   • 进阶回答：停止新增压力、固定版本与水位、保留样本，再按预案排空或回滚，避免清场破坏证据。
3. 问题：一次实验结果如何避免被过度外推？
   • 考点：证据范围和重复性。
   • 回答思路：记录环境差异、重复轮次和失效条件。
   • 详细答案：报告需写版本、资源、数据规模、热点、依赖替身、预热、轮次波动和置信范围。结论只适用于这些前提；生产流量、供应商配额或数据分布变化后必须重测，不能把最高点写成长期承诺。
   • 进阶追问：测试环境较小怎么办？
   • 进阶回答：用量纲和瓶颈模型给区间，但将折算标为 E3（演练证据），关键拐点仍需更接近生产的复验。

7. 成本容量、扩缩容与降级要围绕单位正确结果决策 {#53-06-k07}

成本治理不能只看实例单价，应计算每个正确业务结果消耗的计算、存储、网络、第三方配额、观测、值守与补偿成本。扩容前先判断瓶颈能否横向分摊，扩容后核对共享依赖和预热；缩容前排空租约与连接。容量不足时按业务损失设计降级阶梯：支付和库存正确性不可退让，查询新鲜度、普通导出时效和非关键报警展示可以有界退让。细节见故障余量、扩缩容模式和降级恢复顺序。

flowchart TB
    A[发现容量或成本异常] --> B{瓶颈可横向分摊吗}
    B -->|是| C[小步扩容并完成预热]
    B -->|否| D[限制入口与共享依赖并发]
    C --> E{单位正确结果成本下降吗}
    D --> F[按业务损失启用降级阶梯]
    E -->|是| G[保留并复验故障余量]
    E -->|否| H[回收无效容量并重查瓶颈]
    F --> I[按正确性优先顺序恢复]

数据演绎 7：便宜实例可能抬高单位正确结果成本

方案甲每小时资源成本 800 元，可正确完成 2,000,000 个结果，事故与补偿摊销 200 元，单位百万正确结果成本为 (800 + 200) / 2 = 500 元。方案乙把资源降到 600 元，但正确完成降到 1,700,000 个，补偿和值守增至 500 元，单位百万正确结果成本约 (600 + 500) / 1.7 = 647.06 元。账单少 200 元不代表更优；还要确认方案甲的余量和失败成本是否真实可证。

热门面试题

1. 问题：为什么成本治理要使用单位正确结果？
   • 考点：资源单价与业务产出区分。
   • 回答思路：把错误、重试、补偿和值守纳入分子。
   • 详细答案：单看机器费用会鼓励高利用率和减少观测，却可能导致错误、长队列和人工补偿。单位正确结果把真正完成且满足不变量的业务量作为分母，使无效重试和事故成本显性化，才能比较扩容、缓存、异步和降级方案。
   • 进阶追问：正确结果难计价怎么办？
   • 进阶回答：先用稳定业务事件计数并单列不可货币化风险，不为得到总分而虚构价格。
2. 问题：自动扩缩容为什么可能造成抖动？
   • 考点：指标滞后、冷启动与迟滞。
   • 回答思路：说明触发信号晚于真实压力，实例就绪又有延迟。
   • 详细答案：负载升高后队列和资源指标才变化，扩容启动、预热和接流还需时间；压力回落时若立即缩容，下一波又触发扩容。应使用连续窗口、上下不同阈值、冷却期和最小实例，并将队列年龄与正确完成率纳入。
   • 进阶追问：何时用计划扩容？
   • 进阶回答：截单、盘点、结算等时间已知且冷启动较长时，应提前扩容并与响应扩容组合。
3. 问题：降级恢复为什么不能一次全开？
   • 考点：依赖余量与历史积压。
   • 回答思路：从实时流量、恢复流量和缓存预热叠加说明。
   • 详细答案：恢复瞬间既有新请求，又有积压、重试和冷缓存回源，全开会超过下游安全能力。应先恢复身份、账务和库存等正确性基础，再按租户或优先级放开业务，最后恢复报表和历史任务，每档观察反弹。
   • 进阶追问：用户如何感知降级？
   • 进阶回答：展示明确状态、水位和预计处理边界，不把排队或陈旧结果伪装成实时成功。

8. WMS（仓储管理系统）库存事故要从热点锁等待回到账实不变量 {#53-06-k08}

WMS（仓储管理系统）大促事故常以接口超时、热点商品锁等待和预占消息积压出现。止血先冻结受影响仓与商品的高风险放量，明确售罄优于超时未知；查证以订单意图、预占流水、库存版本和仓内出库事实为权威，不能直接改缓存。恢复时隔离热点、限制并发、按唯一业务键补预占或释放，逐批复算“期初加补入减预占减实扣加释放等于期末”。容量回链下单与热点库存，红线回链领域好事件。

sequenceDiagram
    participant 订单
    participant 库存门禁
    participant 权威库存
    participant 预占流水
    participant 仓内系统
    participant 验收
    订单->>库存门禁: 提交仓、商品与意图键
    库存门禁->>权威库存: 条件扣减并检查版本
    权威库存-->>预占流水: 写唯一预占事实
    预占流水->>仓内系统: 下发拣货或出库
    仓内系统-->>验收: 返回实扣、取消或未知
    验收->>权威库存: 复算余额与流水守恒

数据演绎 8：热点库存不能被全局成功率掩盖

全站 500,000 个预占意图中成功 499,200 个，全局结果明确率为 99.84%；但热点商品甲只有 1,000 件，系统确认预占 1,006 件，仓内已拣 998 件，另有 8 件无库存来源。即使全局预算充足，确认超卖 6 件已触发红线。先冻结商品甲，按 1,006 条预占流水与订单、释放、实扣重放；若可安全取消 4 条，剩余 2 条需业务协调，不能直接把缓存改回零后继续销售。

热门面试题

1. 问题：库存事故为什么不能先改缓存数值？
   • 考点：权威事实与派生视图。
   • 回答思路：说明缓存不能解释预占、释放和实扣来源。
   • 详细答案：缓存通常只承担查询或加速，直接改值会掩盖重复预占、漏释放或仓内已出库事实，并可能被后续同步覆盖。应先冻结相关对象，按权威余额和不可变流水重建理论值，修正裁决源后再失效并重建缓存。
   • 进阶追问：权威余额和流水也冲突怎么办？
   • 进阶回答：保持冻结，按订单和仓内凭证核对每条业务身份，不能在来源未定时自动选较大或较小值。
2. 问题：热点锁等待时扩容应用有效吗？
   • 考点：串行裁决瓶颈。
   • 回答思路：区分无状态计算和同键争用。
   • 详细答案：同一仓商品必须在权威点串行裁决，增加应用实例只会带来更多竞争和超时。应对热点限并发、合并查询、缩短事务、拆非关键操作，并用明确售罄保护系统；只有不同键可并行时扩容才有价值。
   • 进阶追问：能把热点商品拆分吗？
   • 进阶回答：可以按真实可独立履约的仓或库存池拆，但不能虚拟分片后允许总量突破物理库存。
3. 问题：库存恢复验收看哪些不变量？
   • 考点：余额、流水与业务终态闭环。
   • 回答思路：从期初、变更、期末和未知清单回答。
   • 详细答案：复算期初、补入、预占、释放、实扣和调整形成的余额等式；同一意图最多一次有效副作用，释放不超过预占，实扣有仓内凭证，所有未知对象有责任人与期限。接口成功率只作为辅助。
   • 进阶追问：差异很小可以带病恢复吗？
   • 进阶回答：只能对已隔离且有人工处置的对象受控恢复，不能让未知差异继续参与自动分配。

9. 支付事故要把超时未知、渠道查单和资金对账串成闭环 {#53-06-k09}

支付超时只说明本地没有及时看到结果，不能猜成失败并重新扣款。止血时冻结高风险渠道或版本，保留原支付意图和幂等键；查证时按渠道交易号核对金额、币种、商户和终态，回调与主动查单都只能推进同一状态机。恢复不仅要看受理错误回落，还要清理最老未知、补齐账务分录并完成渠道、支付单、账务三方对账。指标回链技术与业务分层，供应商故障回链外部依赖退出。

sequenceDiagram
    participant 用户
    participant 支付服务
    participant 渠道
    participant 查单器
    participant 账务
    participant 对账
    用户->>支付服务: 原支付意图键
    支付服务->>渠道: 发起一次渠道交易
    渠道--x支付服务: 响应超时
    支付服务->>查单器: 标记未知并按原键查询
    查单器->>渠道: 查询渠道终态
    渠道-->>查单器: 成功、失败或仍未知
    查单器->>账务: 仅对确认成功生成唯一分录
    账务->>对账: 提交支付单与分录
    对账->>渠道: 核对渠道账单

数据演绎 9：技术恢复后支付事故仍可能继续

事故窗口有 20,000 个支付意图，入口明确失败 300 个、返回成功 19,400 个、超时未知 300 个。回滚后入口错误降至正常，但查单发现未知中 260 个渠道成功、30 个失败、10 个仍未知；成功的 260 个里又有 8 个缺账务分录。业务待处理不是 10 个，而是 10 + 8 = 18 个。只有补齐 8 个唯一分录、对 10 个未知继续查单或人工核验，并确认无重复扣款，才可关闭事故。

热门面试题

1. 问题：支付超时后为什么不能立即重试？
   • 考点：响应不可见与副作用已发生。
   • 回答思路：用原意图查单而非新建交易。
   • 详细答案：请求可能已被渠道成功处理，只是响应丢失；用新业务键重试可能形成第二次扣款。应将本地状态置为未知，保存渠道请求身份，按原键主动查单，回调到达时也通过状态机和唯一约束合并。
   • 进阶追问：渠道不支持幂等怎么办？
   • 进阶回答：本地严格限制并发与重试，使用可查询的商户请求号；无法确认时转人工，不能自动猜测终态。
2. 问题：支付入口成功率恢复后还要查什么？
   • 考点：历史未知与资金正确性。
   • 回答思路：检查最老未知、重复、漏分录和三方差异。
   • 详细答案：入口只代表新增请求，事故窗口中的渠道成功未落账、失败误记成功、重复回调和未知交易仍可能存在。必须按支付意图连接渠道凭证、支付单和账务分录，对差异逐笔处置，并控制退款和出款。
   • 进阶追问：对账要等日终吗？
   • 进阶回答：日终用于全量封账，事故中应先做窗口级准实时差集，尽快限制风险。
3. 问题：支付链路如何设置正确性红线？
   • 考点：高损失低频事件。
   • 回答思路：列出重复扣款、错金额、错币种和分录不平。
   • 详细答案：任一确认的重复扣款、金额或币种不符、借贷不平、退款超过实付都应触发局部冻结；红线按渠道、商户或版本缩小影响，但不能等待全局错误预算耗尽。恢复需有凭证与分录共同证明。
   • 进阶追问：局部冻结会影响可用性怎么办？
   • 进阶回答：明确拒绝和人工引导优于继续产生不可控资金副作用，待证据闭环后再恢复。

10. 异步导出与 Runner（执行器）事故要同时治理资源、租约和产物 {#53-06-k10}

导出与 Runner（执行器）调度不能只看任务状态。大文件可能同时占用 JVM（Java 虚拟机）内存、数据库游标、磁盘和对象存储带宽；工作者重启还可能让旧租约继续提交。止血时暂停超大或低优先级任务，保留任务、尝试代次、分片和产物清单；查证时检查租约栅栏、业务幂等键、对象摘要与下载权限。恢复按任务成本分队列，先验证旧执行者无法覆盖新结果，再用净消化率控制并发。容量回链异步导出资源最小值和Runner（执行器）演练。

sequenceDiagram
    participant 用户
    participant 调度器
    participant 新工作者
    participant 旧工作者
    participant 数据源
    participant 对象存储
    用户->>调度器: 提交导出任务与业务键
    调度器->>新工作者: 发放新代次租约
    新工作者->>数据源: 分页读取冻结条件
    旧工作者->>对象存储: 尝试提交旧代次产物
    对象存储-->>旧工作者: 栅栏拒绝
    新工作者->>对象存储: 提交摘要一致的新产物
    对象存储-->>调度器: 返回可下载结果

数据演绎 10：扩工作者前先看多资源最小值

每个导出任务平均占 256 兆字节内存、2 个数据库连接和 20 兆字节/秒对象带宽。节点可安全给任务的内存是 4,096 兆字节，可并发 16 个；数据库为该节点预算 24 个连接，可并发 12 个；对象带宽预算 160 兆字节/秒，可并发 8 个，因此真实上限是 8。若把工作者从 8 提到 16，带宽先饱和并拉长租约，超时重试反而增加。应保持 8，按文件大小分级并减少单任务带宽或增独立通道。

热门面试题

1. 问题：导出任务完成为何不等于交付成功？
   • 考点：执行状态与用户产物。
   • 回答思路：从行数、摘要、对象、权限和下载回答。
   • 详细答案：任务状态可能在上传前被误置完成，产物还可能为空、漏分片、权限错误或链接过期。业务成功要求冻结查询条件可追溯，分片清单完整，产物回读与摘要通过，正确用户在时限内可下载。
   • 进阶追问：用户没有下载算失败吗？
   • 进阶回答：通常不算，只要结果按时可用且通知规则满足；但应区分链接不可用和用户主动不取。
2. 问题：Runner（执行器）怎样防止旧工作者提交结果？
   • 考点：租约代次与栅栏。
   • 回答思路：每次接管递增代次，副作用端校验。
   • 详细答案：调度器分配租约时生成单调递增代次，续租和提交都携带代次；目标存储只接受当前代次，旧工作者即使网络恢复也被拒绝。仅在调度器内检查不够，最终副作用点必须执行栅栏。
   • 进阶追问：外部存储不支持栅栏怎么办？
   • 进阶回答：使用代次化临时对象，当前租约者原子发布指针；无法保证时将任务转为人工核验或单执行通道。
3. 问题：异步任务积压时如何分级恢复？
   • 考点：任务成本、价值与下游容量。
   • 回答思路：实时关键任务优先，大任务隔离，按净斜率放量。
   • 详细答案：先按租户、时限、文件大小和业务价值分队列，保护支付查单、库存补偿等关键任务，导出大任务进入预约通道。每档限制线程、连接和带宽，观察成功完成率、最老年龄与下游水位。
   • 进阶追问：是否可直接丢弃过期导出？
   • 进阶回答：按产品规则标记明确失败并通知用户，可以不再计算，但必须保留审计，不能静默删除。

11. IoT（物联网）报警风暴必须优先证明关键覆盖与新鲜度 {#53-06-k11}

IoT（物联网）报警风暴的目标不是处理所有重复噪声，而是关键事件不漏、在时限内可见且原始证据可追溯。入口按设备、规则和时间窗去重聚合，关键与普通报警隔离容量；背压只能延迟低价值事件，不能删除关键原始记录。事故中同时看事件到达、去重后报警、关键设备覆盖、最新水位、通知回执和最老年龄。恢复后按权威设备清单补算遗漏，技术吞吐恢复但关键对象未闭环仍属业务未恢复。容量模型见报警峰值。

sequenceDiagram
    participant 设备
    participant 入口
    participant 聚合器
    participant 关键队列
    participant 普通队列
    participant 通知
    participant 验收
    设备->>入口: 上报原始事件
    入口->>聚合器: 按设备、规则和窗口归并
    alt 关键报警
        聚合器->>关键队列: 保留原始证据并优先处理
        关键队列->>通知: 发送并获取回执
    else 普通重复事件
        聚合器->>普通队列: 聚合展示并受控延迟
    end
    通知->>验收: 提交覆盖、新鲜度与回执

数据演绎 11：总吞吐恢复仍可能漏关键报警

80,000 台设备在一分钟各上报 4 条，原始到达率约 80,000 × 4 / 60 = 5,333.33 条/秒。聚合后普通事件降到 1,200 条/秒，关键事件 300 条/秒；关键通道能力只有 250 条/秒，每秒仍净积压 50 条，一分钟累积 3,000 条。即使总处理能力 6,000 条/秒高于原始到达，也可能因优先级配置错误让关键通道滞后。需把至少 50 条/秒余量从普通通道转给关键通道，并按设备清单核对覆盖。

热门面试题

1. 问题：报警去重会不会造成漏报？
   • 考点：报警实例与原始事件分离。
   • 回答思路：聚合展示但保留关键原始证据。
   • 详细答案：若只按文本去重并删除事件会漏报。应以设备、规则版本、严重级别和时间窗生成报警实例，原始事件保留可追溯；关键状态变化即使在窗口内也可升级或重新通知，普通重复只减少展示和通知噪声。
   • 进阶追问：窗口设多长？
   • 进阶回答：由故障变化速度、通知承受力和允许新鲜度校准，并通过回放验证，不能统一固定。
2. 问题：IoT（物联网）风暴时最重要的指标是什么？
   • 考点：关键覆盖而非总吞吐。
   • 回答思路：优先关键设备覆盖、新鲜度和通知回执。
   • 详细答案：总处理量会被普通重复事件抬高，不能证明安全事件被处理。应以权威设备和规则清单计算关键覆盖，跟踪最老关键事件、新鲜度、通知回执和漏报差集，再用队列与资源指标定位原因。
   • 进阶追问：设备本身离线如何计分母？
   • 进阶回答：离线也是业务状态，应按设备责任边界和心跳规则单列，不能直接从分母删除。
3. 问题：风暴恢复后为何要按设备清单验收？
   • 考点：对象覆盖与消息数量差异。
   • 回答思路：相同数量可能集中在少数设备。
   • 详细答案：处理一百万条消息可能全部来自重复设备，而某些关键设备完全没有结果。权威清单能证明每个应覆盖对象是否产生、处理、通知和确认；缺失对象进入补拉、现场核验或人工升级。
   • 进阶追问：历史普通事件是否都要重放？
   • 进阶回答：按合规和业务价值决定，可聚合或归档，但关键原始事件和状态变化必须保留并闭环。

12. 项目事故口述用止血、查证、恢复、验收和复盘形成证据闭环 {#53-06-k12}

高级面试中的事故口述不能只讲“发现问题、重启解决”。建议按背景与不变量、影响与证据、止血、查证、恢复、验收、复盘七段展开，每段给决策理由和失败边界。容量问题要给单位、公式与敏感项；恢复问题要区分技术恢复和业务恢复；项目结果只说可证明的证据等级。最后把根因改进回写到 SLI（服务等级指标）、SLO（服务等级目标）、错误预算、容量模型、演练脚本、降级开关和责任清单，形成学习闭环。总路线回链学习路线与容量持续校准。

sequenceDiagram
    participant 面试官
    participant 候选人
    participant 事故时间线
    participant 容量模型
    participant 业务验收
    participant 复盘门禁
    面试官->>候选人: 请讲一次稳定性事故
    候选人->>事故时间线: 交代背景、不变量、影响与证据
    候选人->>事故时间线: 说明止血和查证顺序
    候选人->>容量模型: 复算瓶颈、余量和恢复斜率
    候选人->>业务验收: 证明差异、未知态和用户结果收敛
    候选人->>复盘门禁: 回写目标、预案、演练与负责人
    复盘门禁-->>面试官: 给出可复验结果和残余风险

数据演绎 12：事故改进必须能量化复验

某次 Runner（执行器）事故检测耗时 12 分钟、决策 8 分钟、恢复执行 20 分钟、业务差异清理 40 分钟，总业务恢复时间 80 分钟。改进后告警覆盖把检测降到 4 分钟，预授权预案把决策降到 3 分钟，自动限流与租约栅栏把执行降到 12 分钟，差异清单自动化把清理降到 15 分钟，演练目标为 4 + 3 + 12 + 15 = 34 分钟。只有下一次同类演练真实达到并且任务唯一性通过，改进项才算关闭。

热门面试题

1. 问题：三分钟事故口述最不能缺什么？
   • 考点：业务影响、决策理由和恢复证明。
   • 回答思路：用七段结构压缩，而非罗列组件。
   • 详细答案：必须说清受损用户结果和不变量、影响范围与证据、首个止血动作及理由、根因如何查证、历史差异如何恢复、用什么业务证据验收、复盘改了哪些门禁并如何复验。数字标明来源和等级。
   • 进阶追问：时间不够先删哪部分？
   • 进阶回答：压缩背景和组件细节，不删止血理由、业务验收与反思；这些最能体现高级工程判断。
2. 问题：没有保留完整生产数据怎样讲事故？
   • 考点：诚实边界与方法表达。
   • 回答思路：区分可证项目事实、待核对数字和演练计算。
   • 详细答案：明确哪些职责和方案有材料支撑，生产规模与收益若无证据就标待核对；可以用 E3（演练证据）展示公式、排障顺序和恢复门槛，但不能把演练值说成真实效果。诚实不会削弱方法深度。
   • 进阶追问：面试官追问具体数字怎么办？
   • 进阶回答：给出记得住且可解释的范围，并说明需回看监控确认；随后展示数字变化如何影响决策。
3. 问题：复盘行动项怎样避免变成口号？
   • 考点：责任、期限和验证闭环。
   • 回答思路：每项绑定失效模式、负责人、门槛和复验。
   • 详细答案：例如不是“加强监控”，而是补齐支付未知态分母、设置最老年龄告警、由支付负责人在指定日期前上线，并用渠道超时演练证明未知在窗口内闭环。未复验的行动项保持开放并披露残余风险。
   • 进阶追问：长期架构改造短期做不了怎么办？
   • 进阶回答：先落地可逆的限流、隔离、清单和人工门禁，记录风险接受人和到期日，再分阶段替换。

综合题使用说明（非知识型）

以下题目用于三至五分钟项目口述训练。每题只给一个完整口述答案，数字继续遵守 E3（演练证据）边界；追问直答必须围绕本题特有的对象、公式或失败路径，不用通用模板替换判断过程。

2. 综合题库

1. 问题：请用一条完整主线说明你如何处理稳定性事故。

   口述答案：我会把事故拆成止血、查证、恢复、验收和复盘五个阶段，但开场先固定用户结果：哪类用户在什么窗口没有拿到明确结果，资金、库存、任务或报警哪条不变量受损。随后冻结版本、入口流量、首个异常样本、最后正常水位和受影响对象清单，把指标、日志、链路、业务审计分别列证，推断不写成根因。止血选择最可逆且能缩小影响的动作，例如回滚异常版本、按仓或渠道限流、暂停无界重试、关闭非关键导出；资金和库存链路宁可明确拒绝，也不继续制造未知副作用。查证沿入口、应用、队列、存储和外部依赖分解等待与错误，并用业务键连接技术尝试和最终终态。恢复时既处理新增请求，也计算历史积压的净消化率，按优先级小批放量，任何差异增长或下游水位反弹都退回前一档。验收不能只看告警变绿，支付要查单与对账，库存要复算余额和流水，任务要验证副作用唯一，报警要核对关键设备覆盖。复盘把检测、决策、执行和差异清理分别计时，行动项绑定负责人、期限、停止条件和下一次演练；未复验前只算风险缓解，不算永久解决。没有生产证据的数字我会标为 E3（演练证据），避免把方法演绎说成线上成绩。沟通上还会维护每半小时更新一次的事实表，明确当前影响、已执行动作、下一决策点和需要业务确认的风险。若证据相互冲突，我宁可保留未知并缩小服务范围，也不会为了给出完整故事提前锁定根因；这种纪律能防止团队围绕错误假设继续放大事故。

   一次具体演练中，入口每分钟新增 600 个未知任务，限流后降到 40 个；我把这个变化只认定为止血证据，仍要求任务账本与外部回执逐笔连接。若十五分钟后未知存量未下降，立即回到隔离状态，不因入口改善扩大流量。

   • 追问 1：根因未明时能否止血？ 直答 1：能，止血依据是影响和可逆性，回滚或限流可以先做，但不能把动作成功当根因证明。

   • 追问 2：谁有权宣布恢复？ 直答 2：技术负责人证明系统稳定，业务责任人确认不变量和受影响清单闭环，两类证据缺一不可。

   • 追问 3：最常见的错误是什么？ 直答 3：看到错误率下降就全量放开，忽略历史未知、积压和补偿流量会制造第二次事故。

   • 详细章节：稳定性口径与信号边界

2. 问题：怎样设计一套能真正驱动事故动作的 SLO（服务等级目标）？

   口述答案：我不会从现成监控图挑一个比例，而是从关键用户结果反推 SLI（服务等级指标）。先定义业务事件身份和责任边界，再写好事件分子、可评价事件分母、事件时间、确认窗口、迟到修正、排除规则、未知态和口径版本。支付可以把“在窗口内取得明确渠道终态且金额、币种与分录守恒”作为正确性好事件；库存则要满足预占唯一、可售量非负和释放闭环。技术错误、尾时延和依赖异常作为诊断指标保留，但不冒充业务结果。SLO（服务等级目标）的目标值由历史分布、外部承诺、失败成本和改进能力共同确定，并给 SLA（服务等级协议）留下内部治理余量。随后把允许坏事件数换算成错误预算，配置短窗口与长窗口燃尽速度：短窗抓突发，长窗判断持续性。动作表要写明预算健康时的灰度范围、持续燃烧时的缩批、预算耗尽后的发布冻结以及修复豁免。重复扣款、负库存、关键报警漏报另设正确性红线，不被大分母稀释。还要监控分母完整度和最老未知；数据源缺样时自动进入保守模式。上线后抽取原始业务记录复算看板，并在产品、研发、运维和业务之间用同一个失败样本走读，确保“成功、拒绝、未知、例外”没有各自解释。目标发布后我会设置复审日期和失效触发器，例如渠道限额、流量结构或确认窗口变化；一旦触发就保留旧版本结果并用新规则并行回算。这样既能审计历史，又不会在事故中通过临时改口径让预算恢复，看板才真正具有发布约束力。

   例如某支付目标窗口允许 2,000 个坏事件，灰度前已消耗 1,500 个；即使当前看板仍达标，新版本在 5% 流量新增 80 个未知，线性上界已越过余量，门禁应停止放量。恢复需证明未知年龄、分母覆盖和资金差异同时回到保护线。

   • 追问 1：SLO（服务等级目标）越高越好吗？ 直答 1：不是，目标要与失败成本和可实现机制匹配；虚高目标既不能驱动动作，也会让预算长期失真。

   • 追问 2：维护窗口可以排除吗？ 直答 2：只有事前约定、用户可知、范围可审计的维护才能按规则处理，事故后临时排除属于修改分母。

   • 追问 3：业务拒绝算好事件吗？ 直答 3：对“给出明确结果”可算可接受，对“交易完成”不能算成功，应拆两个指标。

   • 详细章节：目标、指标与业务成功分层

3. 问题：事故中怎样防止分子分母被重试、取消和未知态污染？

   口述答案：核心原则是按稳定业务意图计数，而不是按技术调用次数计数。支付以支付意图键，库存以租户、仓、商品、订单行和预占意图，导出以任务业务键作为分母身份；回调、主动查询、消费者重投和接口重试只是同一意图的尝试维度。进入责任边界且已持久化的意图才可评价，非法参数等事前无效请求可以按固定规则排除，但等待过慢导致的客户端取消不能在事故后挪出分母。每个意图最终归并为成功、明确失败或未知，未知超过确认窗口按既定目标计坏，同时继续查证，不能先删掉等后续成功再补。事件时间决定用户何时受影响，处理时间说明系统何时看见；迟到回调可以修订最终正确性，却不能抹去时效违约。实现上保留原始事件、业务键、尝试号、规则版本和回算批次，看板同时展示原始意图数、技术尝试数、排除率、未知年龄和迟到修订量。若某次事故技术调用 1,040 次但只有 1,000 个意图，就按 1,000 计算用户成功率，额外 40 次作为重试放大信号。这样分母不会因为系统越不稳定、重试越多而被人为抬高，恢复阶段也能逐笔找到仍未闭环的对象。我还会每日抽样把指标记录与权威账本做双向连接：从账本找是否漏进分母，从指标找是否存在无业务身份的孤儿事件。任何排除规则都配置到期时间和审批人，排除率超过历史区间时自动触发口径审查，避免例外集合无声膨胀。

   我还会抽取事故窗口 200 个样本做双向核对：从支付意图找是否漏进指标，从技术调用找是否没有业务身份。发现 12 次重试被当作新用户事件时，先修回算版本并重算发布结论，旧口径保留审计，不直接覆盖历史。

   • 追问 1：同一订单允许多次支付怎么办？ 直答 1：订单不是唯一分母，使用支付意图身份区分合法多次尝试，并限制同一时刻可生效的意图。

   • 追问 2：未知最终成功要改历史指标吗？ 直答 2：可以修订最终正确性版本，但原确认窗口的时效损失必须保留。

   • 追问 3：排除率突然升高说明什么？ 直答 3：可能是真实流量变化，也可能是度量博弈，应抽样核对取消位置、等待时长和规则版本。

   • 详细章节：好事件、坏事件与可评价事件

4. 问题：错误预算高速燃烧时，你如何决定停止发布还是继续观察？

   口述答案：我先确认告警使用的是业务坏事件而不是单一技术错误，并检查分母完整度。燃尽速度是实际坏事件比例除以 SLO（服务等级目标）允许错误比例；例如目标允许 0.1%，短窗口实际 0.8%，燃尽速度就是 8。短窗口高但长窗口正常，可能是瞬时尖峰，需要看版本、租户、渠道和错误类型切片；短长窗口同时高，说明预算持续被消耗，应立即停止扩大灰度。决策还要结合剩余预算和放大预测：当前只在 5% 流量产生 100 个坏事件，即使累计预算未耗尽，全量线性外推已超过余量，也应停止。正确性红线优先级更高，一笔确认重复扣款或超卖就足以冻结对应风险单元。停止发布不等于停止所有变更，我会保留回滚、限流、查单和修复通道，每项设最小批次、观察窗、回退点和责任人。若观测缺样，自动晋级必须暂停，改用原始日志和业务审计。恢复后先确认短窗回落，再观察长窗不反弹、未知态不增长、历史差异开始下降，才允许从小流量重新进入发布流程。事故复盘还会检查目标是否过松、告警是否过迟，以及动作表是否真的能被值班人员执行。发布系统应把这些规则固化成门禁并记录豁免原因，而不是依赖值班人员临场记忆。对于预测放大，我会同时给线性上界和依赖饱和后的非线性风险；只要两种估算都越过剩余预算，停止放量就是更稳妥的可逆选择。

   处置记录还要保存门禁决定时的预算快照，防止后续迟到事件改变数字后无法解释当时为何停止。若短窗从 8 倍降到 1.2 倍、长窗仍为 3 倍，我会继续冻结，查清历史坏事件和补偿回流，而不是只看短窗转绿。

   • 追问 1：燃尽速度低就一定安全？ 直答 1：不一定，低流量和高损失事件可能被比例掩盖，还要检查样本量和正确性红线。

   • 追问 2：预算耗尽后修复如何审批？ 直答 2：按减险变更走专用门禁，限定范围、双人复核、可回退，并逐批验证业务差异。

   • 追问 3：能否用未来流量预测做决策？ 直答 3：可以，但要给假设和上下界；预测只用于提前减险，不能替代实际业务验收。

   • 详细章节：多窗口燃尽与风险速度

5. 问题：技术成功率已经恢复，为什么你仍可能保持事故状态？

   口述答案：技术成功只证明某一步协议动作完成，无法覆盖事故窗口留下的业务后果。支付入口恢复后可能仍有渠道已扣款但本地未知、成功未记账或重复分录；库存接口恢复后可能有长期预占、重复释放和已确认超卖；导出工作者恢复后可能存在空文件、错权限和孤儿产物；IoT（物联网）消费者吞吐恢复也可能漏掉关键设备。我的恢复标准分三层：第一层是新增影响停止，技术错误、尾时延和队列斜率回到保护线；第二层是历史存量收敛，最老未知下降、积压净消化为正、失败重试受控；第三层是业务不变量通过，渠道凭证与分录守恒、库存余额与流水一致、任务副作用唯一、关键报警覆盖完整。事故指挥会保留受影响对象清单，不因监控绿色就丢弃。每批补偿都使用原业务键，先查询已有结果，避免恢复动作再次制造重复。若有少量对象暂时无法自动闭环，可以在明确隔离、责任人接管和用户告知后恢复其他范围，但这些对象仍属于开放风险。宣布业务恢复时同时报告剩余未知、补偿状态和观察期限，而不是只发一张技术看板截图。这样既避免无限拖延事故，也不把未解决的资金或库存差异藏在“服务正常”之后。为了防止两套状态互相覆盖，我会给技术恢复和业务恢复设置不同负责人、看板和完成时间，并让补偿清单与事故编号关联。事故结束后一周再抽样复查外部账单、库存调整和下载审计，确认没有迟到数据让已关闭差异重新出现。

   例如导出告警恢复后仍有 70 个缺产物、180 个无下载权限；我会暂停这些任务的成功通知，按任务、分片、对象和授权四段修复。只有新增差异为零且历史清单连续两个观察窗下降，才允许关闭业务事故。

   • 追问 1：少量未知能否带着恢复？ 直答 1：可以按风险单元隔离后受控恢复，但未知必须有清单、责任人、期限和禁止自动副作用的保护。

   • 追问 2：告警何时关闭？ 直答 2：技术告警可在信号恢复后关闭，业务事故需等不变量与历史存量达到验收门槛，两者状态分开。

   • 追问 3：补偿成功就算闭环吗？ 直答 3：还要核对补偿没有重复、没有越过外部真实终态，并保留可审计凭证。

   • 详细章节：线上排查与业务恢复验证

6. 问题：指标看起来很好，但数据覆盖不完整时如何处理？

   口述答案：我把指标计算链本身也当作一条需要 SLI（服务等级指标）的服务。先找权威对象清单或业务账本，计算应评价对象数，再比较采集、传输、存储、计算和发布各阶段的覆盖量与水位。假设设备清单有 100,000 台，而指标器只收到 80,000 台，其中 79,920 台处理成功，表面成功率 99.9%，实际覆盖仅 80%，不能宣布全量健康。事故处置上先冻结依赖该指标的自动发布与扩缩容，把缺失范围按租户、分区、客户端版本或事件类型切片；同时使用原始日志、业务审计和合成探测建立临时旁路证据。排查要区分事件未产生、采集丢失、队列积压、分区水位停滞、规则过滤错误和展示查询漏数，每一段记录输入输出计数。恢复后不仅看成功率，还要确认覆盖率、新鲜度、迟到量和规则版本稳定，并对事故窗口回算，判断此前的绿色结论是否需要修订。对于无法补回的历史数据，明确影响边界和不确定性，不用插值伪造精确结果。长期治理包括分母对账、数据质量告警、双路抽样和口径版本审计，让“没有数据”不会被系统解释成“没有失败”。在恢复自动化前，我还会用一小段并行期比较旧指标、新指标和权威抽样，确认新链路没有引入重复或时间窗偏差。历史结论若被回算推翻，需要同步修订事故影响和发布记录，而不是只把当前看板修绿后悄悄结束。

   若权威设备清单 100,000 台而采集只有 80,000 台，我会直接阻断全量健康发布，并定位缺失集中在哪个分区水位。修复后以原始清单回算事故窗口，旧看板若曾误报绿色，需要同步修订影响报告和当时的发布审批。

   • 追问 1：零流量算百分之百成功吗？ 直答 1：不能，零样本应报告无数据，并用合成探测或对象覆盖证明服务是否可用。

   • 追问 2：缺失数据能按失败计吗？ 直答 2：可在保守目标中计坏，但诊断上仍要单列未知，避免混淆真实失败与观测故障。

   • 追问 3：指标链故障要不要单独建目标？ 直答 3：要，至少覆盖完整度、新鲜度和规则版本，否则业务目标失去可信基础。

   • 详细章节：数据质量是指标的前置指标

7. 问题：低流量、高损失链路应该怎样做稳定性治理？

   口述答案：低流量场景不能把样本成功率当成高可靠证明。一周只有八笔结算且全部成功，100% 只描述这八个样本；下一周失败一笔就变成 87.5%，比例极不稳定。对于结算、退款、权限变更和关键设备控制，我会采用逐事件清单、最长无样本时长、合成探测、定期演练和正确性红线组合治理。分母来自权威批次或应执行对象，而不是日志中恰好出现的记录；每笔事件都保留业务身份、计划时间、实际终态和外部凭证。告警不只看比例，还看计划事件是否按时出现、最老未完成、任何资金或权限不变量破坏。SLO（服务等级目标）可以使用更长窗口描述趋势，但事故动作由单笔失败成本驱动，例如一笔错误出款就冻结同类自动执行并启动核验。容量方面也不按平均配置，需确保结算窗口、供应商限额和人工接管能力。恢复时逐笔核对成功、明确失败和未知，不能用后续批次成功冲掉历史损失。向面试官表达时我会说清样本数和证据范围，不宣称“长期百分之百”；真正可信的是每笔可追溯、失败可隔离、恢复可复验，而不是漂亮的小样本比例。为了避免长时间没有真实事件导致能力退化，我会按固定周期跑不产生真实副作用的端到端探测，并演练人工接管、权限和查单脚本。每次真实事件后再核对探测与实际流程差异，更新供应商时限和责任人，保证低频链路不是只在文档中可恢复。

   对每周八笔结算，我会建立八行权威清单，逐笔记录计划时间、渠道凭证、分录和人工接管人；一笔未完成就冻结同类自动出款。月度合成探测只证明路径可达，下一笔真实结算仍需逐事件验收，不能拿探测成功替代资金正确。

   • 追问 1：低流量是否不适合 SLO（服务等级目标）？ 直答 1：仍可设目标，但要结合事件数、覆盖和红线，不能只看滚动百分比。

   • 追问 2：合成探测能替代真实事件吗？ 直答 2：不能替代业务正确性，但能证明无真实流量时基础路径和依赖仍可达。

   • 追问 3：单笔失败都停机会不会过度？ 直答 3：按失败成本和风险单元局部冻结，先阻止同类副作用扩散，再由权威证据决定恢复。

   • 详细章节：低流量与稀有高损失事件

8. 问题：多个依赖串联时，端到端可靠性如何评估和排障？

   口述答案：我先画出关键用户路径，区分必选依赖、可并行依赖、可降级依赖和异步副作用，直接计算端到端业务好事件，而不是把各服务看板机械相乘。若三个必选依赖各自声称 99.9%，在独立假设下串行可用性约 0.999³ = 99.7002999%，但共享网络、数据库或区域会让失败相关，简单乘积反而低估共同故障风险。排障时按同一业务键建立联合失败矩阵，查看失败是否集中于时间、区域、租户、版本或共同故障域；链路用于定位等待，业务审计用于确认最终结果。对于可降级依赖，要明确降级语义，例如轨迹查询可以返回带水位的旧结果，但支付记账不能绕过。超时和重试预算按端到端时限分配，避免每层都用满自身超时导致总时延失控。容量评估还要检查调用放大，入口一次请求可能引发多次回源、查单和通知。止血优先隔离共同故障域、关闭非关键调用和限制重试，而不是同时扩所有服务。恢复后逐段探测只是基础，还要让完整业务路径小流量通过，并验证共享资源有单故障域余量。最终报告既给依赖局部指标，也给用户结果、相关性证据和降级后的承诺边界。我还会为每个依赖维护“慢、错、拒绝、未知”的行为表，避免所有异常都映射为同一种重试。备用依赖上线前要核对配额、数据语义和故障独立性；若与主路径共享证书或网络，切换只会把流量搬到同一故障里，不能算真正冗余。

   假如网关、库存和消息服务的失败都集中在同一网络变更窗口，我会将其归到共同故障域，而不是算三次独立故障。止血关闭非关键消息投递并固定路由，恢复后用同一订单键穿透整条路径，确认局部探测和业务终态一致。

   • 追问 1：依赖可用性可以直接相乘吗？ 直答 1：只有独立、串行且全部必选时可作近似，真实决策应直接测端到端并分析相关故障。

   • 追问 2：共同故障域怎么识别？ 直答 2：对齐时间和业务键，检查共享网络、区域、存储、配置、证书和发布批次。

   • 追问 3：并行调用一定更可靠？ 直答 3：不一定，并行会增加资源和外部配额，只有结果可择一且调用被限并发时才可能提高可用性。

   • 详细章节：复合依赖与相关性

9. 问题：面对“系统能扛多少并发”，你怎样给出可信答案？

   口述答案：我会先澄清并发指什么：查询 QPS（每秒查询率）、下单 TPS（每秒事务数）、同时在途请求、消息任务还是长连接；还要问峰值持续时间、读写比例、数据规模、热点、缓存命中、外部依赖和允许降级。随后给可复算模型。以峰值到达率 600 次/秒、平均停留 0.25 秒为例，平均在途约 150，但不能据此只配 150 个槽位，还要看 P99（99 分位响应时间）、服务时间分布、单故障域和预热。应用容量只是链路一环，我会分别计算线程、连接、数据库事务、消息分区、磁盘、网络和渠道限额，最终能力取最小值，并为管理、补偿和故障留余量。压测采用与生产相符的开环或闭环模型，覆盖热点、长尾、缓存失效和一个故障域失效；结论以满足正确性和时延的成功完成量为准，不取瞬时最高拉取量。报告写清版本、环境、脚本、数据、停止条件、轮次波动和失效条件。上线后用真实到达率、服务时间和排队斜率持续校准。没有生产证据时，我会把数字标为 E3（演练证据），给区间和敏感变量；可信回答的重点不是背一个并发值，而是解释在什么边界下、哪个资源先饱和、如何扩容和降级。最终配置还会做敏感性分析：命中率下降十个百分点、服务时间翻倍或失去一个实例组时，结论是否翻转。若很小的输入变化就越过保护线，我会扩大余量或设计降级，而不是拿均值配置；容量复审日期也与流量增长和依赖配额变更绑定。

   若命中率从 60% 降到 30%，外部回源会从 240 增到 420 次/秒，原应用并发结论立即失效。我会把命中率、单故障域和渠道配额列为重算触发器；压测后还以业务键核对正确完成，防止丢弃慢请求制造高吞吐。

   • 追问 1：并发和吞吐是什么关系？ 直答 1：在稳定窗口内并发近似等于到达率乘停留时间，吞吐还受服务能力和排队影响。

   • 追问 2：压测最高值能当容量吗？ 直答 2：不能，最高值可能已违反时延或正确性，只能把稳定成功完成量作为候选边界。

   • 追问 3：为什么要给失效条件？ 直答 3：流量、热点、依赖配额和版本变化会让旧结论失效，容量承诺必须可触发重算。

   • 详细章节：容量对象、单位与证据

10. 问题：线上尾时延突然升高，你如何定位容量瓶颈？

口述答案：先确认尾时延来自真实用户分布，而不是把实例 P99（99 分位响应时间）求平均；然后按版本、租户、路由键、缓存状态和依赖切片，判断是全局退化还是热点。沿请求路径拆出网关排队、线程池等待、连接获取、数据库执行与锁等待、消息确认、外部调用和返回写出，每段同时看水位、等待时间、成功完成率和错误。第一个出现等待持续增长，而其下游完成量不再增长的位置，是优先瓶颈候选。例如连接获取从 5 毫秒升到 300 毫秒，数据库活跃会话已到安全上限，应用线程又大量占用，说明继续扩应用只会增加排队。此时先限制入口并发和低优先级查询，缩短无效超时与重试，再用小范围降低连接上限或隔离热点验证因果。若服务时间本身变长，检查慢语句、锁、垃圾回收、对象存储或外部渠道；若服务时间稳定而等待变长，则关注队列和资源槽位。恢复判断要求尾时延、等待、在途和业务成功共同稳定，不能靠丢弃慢请求把分位数做漂亮。最后把实际拐点、热点分布和依赖上限回写容量模型，并为下一次压测补上此次失败形态。为了排除观测误差，我会比较入口总量、各段样本量和链路覆盖，确认慢请求没有被采样策略漏掉；必要时对少量租户开启完整计时。任何优化都通过前后对照验证，例如关闭一次重试后等待下降而业务失败不增，才说明放大链被切断。

一个验证动作是把异常路由隔离到同版本专用实例：若其连接等待仍从 5 毫秒升到 300 毫秒，而普通路由稳定，就能把热点与全局退化分开。恢复后再放回少量热点，确认尾部和库存结果均不反弹。

• 追问 1：平均响应时间还有用吗？ 直答 1：有助于观察总体变化，但不能替代尾部和阈值达标率，热点事故常被平均值掩盖。

• 追问 2：如何验证不是下游慢？ 直答 2：分解连接等待与实际执行，做限并发或对照路由实验，并看下游完成量是否随动作改善。

• 追问 3：直接加超时时间行吗？ 直答 3：通常会增加在途和槽位占用；只有业务确实允许且资源余量验证后才能调整。

• 详细章节：利用率与非线性拐点

11. 问题：应用扩容后数据库反而更慢，你会怎样解释和处理？

口述答案：这通常是局部扩容突破共享资源总预算。每个应用实例都有线程池和连接池，实例从十个扩到二十个，若每个连接上限仍为三十，总连接候选从 300 变成 600；数据库安全业务会话可能只有 250，新增实例会让更多事务同时竞争缓存页、锁、日志和磁盘。连接获取看似更快，数据库执行和锁等待却显著增长，超时后重试又形成正反馈。处置时我先冻结继续扩容，按数据库允许总连接减去管理、复制、补偿保留量，反推每实例连接上限；同时对低优先级查询、批量导出和历史任务限并发，保护核心写。用活跃连接、获取等待、事务完成率、慢语句、锁等待和日志刷盘水位判断瓶颈，不只看 CPU（中央处理器）。若热点事务占主因，缩短事务、固定访问顺序、拆出外部调用并按业务键隔离；若读压力可缓存或读副本承接，再验证新鲜度和一致性边界。恢复时小步放开实例与连接，每步观察数据库成功完成量是否增加，若只有并发上升而完成量不变就回退。长期把应用实例数、每实例池上限和数据库总会话做联动门禁，扩容审批同时检查消息、存储和供应商配额，避免“应用自动扩，依赖手工守”的失配。复盘还会检查自动扩容触发是否只看应用 CPU（中央处理器），并改为同时受数据库保护线约束。对于补偿任务另设小连接池，防止事故恢复流量与实时交易争抢全部会话；管理连接始终保留，确保最坏时仍能诊断和止血。

我会给连接预算做状态门禁：十五个实例时业务池总和不得超过 200，补偿池固定 20，管理连接单独保留。变更后若活跃连接上升但每秒提交不增，立即撤回实例或池配置，并检查锁与日志刷盘，而不是继续扩容。

• 追问 1：连接池越小越好吗？ 直答 1：不是，过小会在应用侧排队；目标是匹配数据库有效并发并为故障和管理留余量。

• 追问 2：CPU（中央处理器）不高为何数据库仍饱和？ 直答 2：可能受锁、磁盘、日志刷盘、网络或单热点串行限制，资源饱和不只表现为 CPU（中央处理器）高。

• 追问 3：读写分离能立即解决吗？ 直答 3：只对可接受复制延迟的读有效，热点写、锁和事务日志瓶颈仍在主库。

• 详细章节：线程、连接与数据库资源预算

12. 问题：消息积压事故中，如何计算恢复时间并控制风险？

口述答案：先统一口径：积压按未完成业务任务计算，重复投递和技术重试不当作新业务；完成量必须满足副作用和终态正确。记录当前积压、每秒新到达、成功完成、失败回队、不同优先级和最老年龄。净消化率等于成功完成率减新到达率，只有稳定为正才可能清空。例如积压 240,000，新到达 1,200 个/秒，成功完成 1,800 个/秒，净消化 600 个/秒，静态估算需要 400 秒；如果失败重试让真实完成降到 1,100，积压反而每秒增加 100。恢复不能简单把消费者拉满，我会先确认数据库、对象存储、支付渠道等下游的安全能力，为实时请求保留配额，再按任务价值、年龄、租户和成本分队列。每次提升并发后观察成功完成、最老年龄、重试放大、连接和锁；反弹立即退档。毒任务进入隔离队列，不阻塞正常任务。任务执行使用稳定业务键、租约代次和栅栏，防止恢复期间重复副作用。预计时间滚动重算并给区间，因为任务大小和依赖能力会变化。最终验收包括积压和年龄归零或进入正常水位、失败对象有明确清单、业务不变量通过，不能只看消费者线程繁忙。若积压接近消息保留期，我会优先导出业务键、水位和原始载荷到隔离存储，再决定重放，避免为了提速直接跳过旧消息。恢复期间新增任务和历史任务分别计量，确保报表中的下降来自真实完成，而不是迁移到另一个无人观察的队列。

历史修复会把接近保留期的业务键和原始载荷先归档，隔离队列中的毒任务保留失败原因与负责人。恢复验收除积压外，还核对支付查单、库存释放和导出产物三类副作用，确保长度下降不是静默跳过造成。

• 追问 1：队列长度下降一定健康吗？ 直答 1：不一定，可能丢弃、转死信或只处理新任务，还要看成功完成和最老年龄。

• 追问 2：可以暂停新流量吗？ 直答 2：对非关键入口可排队或拒绝，关键实时业务应保留配额，取决于损失和时效。

• 追问 3：毒任务怎么处理？ 直答 3：按失败类型和业务键隔离，限制重试，保留原始上下文后修复或人工处置。

• 详细章节：消息积压与恢复模型

13. 问题：为什么恢复阶段最重要的是斜率，而不是一个瞬时水位？

口述答案：瞬时水位只告诉我当前存量，无法说明事故正在扩大还是收敛。队列十万条可能在快速下降，也可能刚从一万增长上来；CPU（中央处理器）七成可能稳定，也可能每分钟增加。恢复阶段我关注多组斜率：坏事件新增速度是否接近零，成功完成率减新到达率是否稳定为正，最老未知年龄是否下降，业务差异数量是否减少，下游水位是否因补偿流量反弹。以积压 90,000 为例，完成 1,500 个/秒、到达 1,200 个/秒，净斜率 300，理论五分钟清空；若两分钟后完成降到 1,250，说明依赖退化，原预计已失效。放量采用阶梯，每档记录开始水位、斜率、失败和业务对账，连续多个窗口稳定后再升档。对延迟也看排队增长速度，而非只看某个分位点；若平均稳定但尾部持续恶化，说明长任务或热点正在积累。停止条件设为斜率翻负、正确性差异新增、下游超过保护线或未知年龄不降。业务恢复后继续观察一段时间，确认缓存预热、重试回流和定时任务没有迟发冲击。复盘则比较事故前预测斜率、实际斜率和模型误差，把任务成本分布与依赖限额回填，避免下次仍用静态吞吐估算。斜率计算还要保留置信区间和采样频率，短周期抖动不立即触发频繁动作，长周期恶化又不能被平滑掉。我会把原始点和滚动值同时保存，事故指挥看到的不只是一个箭头，而是它由哪些成功、失败和到达事件组成。

在 Runner（执行器）恢复中我会同时画关键任务与普通任务两条斜率：普通导出下降而支付查单最老年龄上升时，整体曲线不具有放量资格。每档并发保留开始水位、五分钟净斜率和业务差异，翻负后自动退回前一档并锁定该配置。

• 追问 1：斜率窗口选多长？ 直答 1：要覆盖主要服务时间又足够快地发现反弹，通常短长窗口并用，并按业务周期校准。

• 追问 2：斜率为正就能全量放开吗？ 直答 2：不能，还要有故障余量、正确性通过和下游水位稳定，正斜率可能很小且脆弱。

• 追问 3：最老年龄为什么重要？ 直答 3：它能发现老任务饥饿或毒任务，防止系统只处理新任务制造健康假象。

• 详细章节：恢复净消化与业务不变量

14. 问题：磁盘和网络同时接近上限时，如何判断谁限制了有效容量？

口述答案：我先把业务量换成字节速率并区分读写方向。假设导出每秒完成 40 个文件，平均 25 兆字节，理论对象上传需要 1,000 兆字节/秒；节点网络可用只有 800 兆字节/秒，磁盘顺序读可达 1,200 兆字节/秒，网络先成为静态上限。但事故中若磁盘还有临时文件写入、日志刷盘和随机读取，真实有效能力可能更低，所以要看磁盘队列、等待、吞吐、网络发送、重传、拥塞以及应用成功完成。通过受控降低上传并发观察：若磁盘等待明显下降、单任务时延改善而网络仍满，二者存在耦合；再将部分任务路由到独立网络或直接流式上传，验证瓶颈变化。容量模型还要计算存储写满时间，例如临时文件净增长 200 兆字节/秒、可用空间 360,000 兆字节，约 1,800 秒写满，必须提前降级而非等待满盘。止血可暂停大文件、降低并发、缩短保留和保护日志空间，但删除需遵守产物与审计规则。恢复后检查网络、磁盘、对象上传成功率、文件摘要和下载可用性；仅资源水位下降而文件损坏，不算有效恢复。长期按文件大小分级、设置节点与租户额度，并让告警同时包含速率、容量和预计耗尽时间。还要把压缩、加密和校验消耗算入 CPU（中央处理器）与临时空间，避免只按文件字节推导。针对跨区域上传，我会单列出口费用、延迟和失败重传；若改用分片上传，需验证断点续传不会重复计费、拼接顺序和最终摘要仍正确。

若对象上传出现 3% 分片重传，我会按实际发送字节而非文件净大小复算网络需求，并抽样比对最终摘要。恢复完成后再检查临时盘净增长为零、日志保留未被误删、下载探测可用，避免通过删证据或生成损坏文件换取水位下降。

• 追问 1：带宽利用率不高也会慢吗？ 直答 1：会，重传、单连接限制、远端限速或小请求开销都可能让有效吞吐低于链路标称值。

• 追问 2：磁盘满了先删日志吗？ 直答 2：先按保留策略和事故取证要求处理，不能为腾空间删除关键审计；优先停止新增大文件并扩展安全空间。

• 追问 3：流式处理一定更省资源？ 直答 3：通常减少临时盘，但会延长连接和放大下游抖动，需要背压、断点和摘要校验。

• 详细章节：磁盘、网络与存储容量

15. 问题：怎样证明系统在失去一个故障域后仍有容量余量？

口述答案：先定义故障域，不把同机房、同数据库或同供应商的实例误当独立。收集峰值到达率、持续时间、各域正确完成能力、流量迁移时间、预热和共享依赖上限，然后在模型中扣除最大单域。例如三组实例每组稳定完成 300 个任务/秒，峰值 720，常态总能力 900、利用率 80%；失去一组只剩 600，缺口 120，说明平均余量不能覆盖故障。候选方案可以把非关键流量降到 540，为关键业务留 60 个/秒净余量，或提前增加独立域能力。验证时在可控范围隔离一组，确认路由能迁移、剩余域缓存与连接已预热、数据库和消息分区未过载；同时观察尾时延、积压斜率和业务成功，而非只看实例数。恢复能力也要算，故障期间积压若增长，服务恢复后必须有正净消化率。供应商和区域故障还需检查备用渠道配额、数据位置与人员权限，备用存在不等于能承载峰值。演练命中正确性红线或剩余域保护线立即停止。最终证据包括模型输入、实测能力、降级清单、切换时间和业务验收；任何假设变化都触发重算，不能把一次低峰演练外推到大促。为了验证流量迁移不是纸面能力，我会定期让少量真实读流量驻留备用域，持续检查配置、证书和依赖权限；写切换仍通过演练栅栏控制。若故障域容量需要依赖现场扩容，就把扩容就绪时间计入 RTO（恢复时间目标），不能把尚未申请到的资源算作现有余量。

我还会验证备用域不是空壳：持续放入 1% 只读流量检查证书、配置和权限，季度演练再切关键写。若现场扩容需十二分钟，这十二分钟必须计入 RTO（恢复时间目标）；无法在此期间承接的流量提前进入明确降级，而不是算作不存在。

• 追问 1：故障余量固定留百分之二十可以吗？ 直答 1：不能机械固定，应由最大故障域、扩容时间、可降级量和恢复要求反推。

• 追问 2：跨区域部署就独立了吗？ 直答 2：还要检查共享控制面、账号、域名、供应商、数据复制和发布链路是否形成共同故障。

• 追问 3：低峰演练有什么价值？ 直答 3：能验证切换机制和证据链，但峰值容量仍需模型、压测或更接近目标负载的演练补证。

• 详细章节：敏感性与单故障域余量

16. 问题：如何为支付、库存和异步导出分别制定 RPO（恢复点目标）与 RTO（恢复时间目标）？

口述答案：我会先按数据不可替代性、副作用风险和可补偿性分级，而不是给所有系统套同一个分钟数。支付的渠道凭证、支付意图和账务分录要求接近零 RPO（恢复点目标），因为丢失可能导致重复扣款或账实不符；RTO（恢复时间目标）还要拆成恢复受理、恢复查单和完成资金差异清理三个时间。库存重点保护预占身份、余额版本、预占与释放流水以及仓内实扣事实，服务很快拉起但缺少三分钟流水仍可能超卖，因此恢复验收必须重放订单并复算守恒。异步导出通常允许较大的 RPO（恢复点目标），因为任务可重跑，但请求人、查询条件摘要、数据水位和产物权限不能丢；其 RTO（恢复时间目标）可以按高优先级报告和普通历史导出分层。制定目标前列出权威源、复制确认点、备份频率、日志保留、重放能力、人工清单和最大业务损失。假设库存每分钟 6,000 条流水、复制最坏落后三分钟，候选缺口 18,000 条，即使八分钟切换完成也不能宣称数据目标达标。演练分别注入副本落后、逻辑污染和对象存储不可用，记录实际恢复点、能力恢复时间、差异清理时间和补偿完成时间。目标必须由业务确认损失边界，技术团队用演练证明；达不到时公开残余风险和临时保护，不通过修改目标掩盖能力缺口。

目标表还会保存状态阶梯：支付先恢复查单再恢复受理，库存先只读核对再开放预占，导出先恢复高优先级产物。每一级都有开始位置、允许数据缺口和业务签字；若库存重放六分钟才补齐 18,000 条，完整恢复时间必须包含这六分钟。

• 追问 1：RTO（恢复时间目标）从何时开始计？ 直答 1：从业务影响实际发生计，不从人工发现或开始切换才计，否则检测延迟会被隐藏。

• 追问 2：导出可以直接丢任务吗？ 直答 2：只有产品规则允许且用户收到明确失败时才可终止，任务审计和重试入口仍需保留。

• 追问 3：目标达不到怎么办？ 直答 3：缩小承诺范围、增加日志与恢复能力或引入人工控制，并由业务显式接受剩余风险。

• 详细章节：业务分层恢复目标

17. 问题：慢依赖如何演变成线程耗尽和重试风暴，你会怎样止血？

口述答案：慢依赖的危险在于它先增加服务时间，再通过 Little’s Law（利特尔定律）扩大在途量。入口 400 次/秒、外部调用从 100 毫秒变成 2 秒，仅这一段平均在途就从 40 增至 800；线程、连接和内存很快被占满。上游超时若设为一秒，会在原请求仍可能执行时重试，实际到达进一步放大，依赖更慢，形成正反馈。现场先确认慢集中在哪个渠道、租户或接口，按业务价值限制并发，关闭无退避重试，对非关键功能返回带水位的降级结果；支付等副作用链路把超时置为未知，按原业务键查单，绝不换键重做。超时预算按端到端目标分配，连接获取、调用、解析和回写各自有上限，取消要能真正传递到下游，否则只是客户端放弃。观测同时看入口意图、技术尝试、线程占用、连接等待、依赖完成量和最老未知，避免重试量被算成需求增长。恢复时先让依赖在受控并发下稳定，再逐档放开，要求成功完成增加且尾时延、未知和重试倍率下降。长期对每类依赖定义慢、错、拒绝、未知的处置矩阵，隔离线程池和总并发，并通过故障注入验证熔断后关键路径仍能给用户明确结果。

某渠道从 100 毫秒退化到 2 秒后，我会把入口意图、实际下游请求和仍在执行的调用分别计数；若一笔意图平均触发 2.6 次调用，先把放大率降到接近一。历史未知按原键查单，确认渠道已成功的请求只补本地状态，禁止再次发起扣款。

恢复探测只给极小并发，连续三个窗口满足响应、完成量和未知态门槛后才解除熔断。若依赖延迟再次升高，门禁自动退回半开状态，并保留当时的请求样本验证取消是否真的传到下游。

• 追问 1：把超时调短是否一定有效？ 直答 1：不一定，若下游没有取消并继续占资源，只会更快触发上游重试，需要并发限制和幂等配合。

• 追问 2：熔断会不会扩大失败？ 直答 2：会牺牲部分请求，但能阻止资源被慢依赖拖死；应按风险单元熔断并提供明确降级。

• 追问 3：何时恢复重试？ 直答 3：依赖在探测流量下成功和时延稳定后，小比例开启带退避重试，并观察放大率。

• 详细章节：慢、错、拒绝与级联放大

18. 问题：网络分区时如何防止双主写入和脑裂？

口述答案：网络分区不是简单的“网络断了”，而是不同节点对彼此状态有冲突认知。首先明确哪些数据必须保持单一写入权，例如库存余额、支付账务和调度租约；这些链路使用多数派确认、领导任期和单调递增写栅栏，少数派失去仲裁后必须拒绝危险写。旧主即使进程存活，只要无法取得新任期就不能继续提交；最终数据存储或副作用端也要校验任期，不能只在路由层判断。事故中冻结拓扑和任期证据，检查是否有两个区域同时接受写、是否存在时钟或租约误判，并按业务键导出分区窗口的所有写入。若已出现冲突，不用最后写入覆盖：库存按订单与流水重放，支付按渠道凭证与分录核对，任务按当前代次判断有效副作用。恢复选择一个拥有最新安全多数位置的域为权威，撤销其他域写权限，追平后先只读校验，再小流量开放。对于可用性要求高但允许冲突的低风险数据，可以按租户归属或可交换规则多活，但冲突规则和损失边界要事前写清。演练不仅断网络，还要验证控制面、域名、证书和人工权限；业务验收证明唯一写入权、数据位置连续和不变量成立后，才可结束分区事故。

分区演练会记录旧主任期 41、新主任期 42 以及两侧每条写入的业务键；目标存储必须拒绝任期 41 的迟到提交。若已经出现双写，我先冻结冲突对象，库存按订单流水裁决，支付按渠道凭证裁决，绝不按机器时间戳选“最后值”。

网络恢复后，少数派先保持只读，从权威域重建并比较日志位置、对象摘要和业务差异。只有旧任期写入为零、冲突清单闭环且一次小流量切换通过，才重新加入路由；这样恢复网络不会自动把脑裂数据带回主路径。

• 追问 1：租约能完全解决脑裂吗？ 直答 1：不能只靠时间租约，还需多数派和副作用端栅栏，因为时钟漂移或暂停会让旧持有者误判。

• 追问 2：少数派可以提供读吗？ 直答 2：可以在展示水位、陈旧边界且不驱动危险决策时提供受控只读。

• 追问 3：冲突数据为何不能按时间戳合并？ 直答 3：业务动作可能不可交换，时钟也不可靠；应按业务身份和不变量裁决。

• 详细章节：网络分区与写栅栏

19. 问题：副本都正常但数据已被逻辑污染，应该怎样恢复？

口述答案：复制解决介质失效，却会忠实传播错误删除、错误脚本和应用缺陷，因此“所有副本一致”不等于数据正确。发现逻辑污染后先停止相关写和自动补偿，冻结错误版本、脚本、开始时间、最后可信位置和受影响对象范围；若继续写仍有业务价值，则将合法新写导入隔离日志，不能简单把整库回退到事故前。选择污染前的独立备份或时间点恢复到隔离环境，校验备份可读、增量连续和摘要一致，再按表、租户或业务键生成差异。恢复过程分三类：错误变更需要反向修复，事故期间合法新写需要业务合并，外部已发生的支付、出库或通知副作用需要查单而不能随库回退。库存用订单和不可变流水重建余额，支付用渠道凭证与分录决定终态，导出对象可以重建但权限和用户通知需复核。每批合并都记录输入清单、规则版本、前后摘要和不可逆动作，命中差异增长立即停止。服务恢复前先在隔离数据上跑不变量和关键查询，再只读开放、小流量写入，最后处理历史补偿。复盘要求把备份与复制分开治理，限制高危脚本权限，提供影子预览、影响行数门禁和可演练恢复脚本；只有真实恢复成功，备份才是能力而不是文件。

例如错误脚本污染 8,000 条库存记录，但事故后另有 1,200 条合法出库；我会从污染前备份生成基线，再把合法出库按业务身份重放，冲突记录进入人工清单。整体回退会抹掉这 1,200 条现实动作，因此恢复脚本先预览余额和影响行数。

每批修复都保存污染值、候选值、裁决证据和前后摘要，并在隔离库先跑不变量。生产恢复后持续比较库存差异与新写增长；若三副本再次出现相同错误，说明污染源仍在，立即停止后续批次而非继续覆盖。

• 追问 1：为何不直接恢复整个数据库？ 直答 1：会丢掉事故后合法新写并回滚外部已发生事实，需要按业务对象合并。

• 追问 2：三副本都一致能否证明没损坏？ 直答 2：不能，逻辑错误和静默污染可以被复制，必须与业务不变量和独立历史基线核对。

• 追问 3：什么时候允许重新写入？ 直答 3：污染源被移除、权威基线确定、差异规则验证且小流量不再新增异常后。

• 详细章节：静默损坏与逻辑污染

20. 问题：误操作删除数据后，如何在保留事故后合法写入的同时恢复？

口述答案：误操作恢复的关键是区分错误变化和同期合法变化。第一步撤销操作者和自动任务的危险权限，暂停受影响对象的进一步写入，但不要清理日志；固定删除语句、事务身份、执行时间、影响范围和最后可信备份。随后在隔离环境做时间点恢复到删除前位置，从数据库日志、业务事件和上游账本提取事故后合法写入，构造三集合：应恢复的误删记录、应保留的新记录、需要业务裁决的冲突记录。主键存在不代表语义一致，同键状态若已被后续支付或出库推进，不能用旧快照覆盖。恢复脚本必须幂等、可预览，先输出预计行数、金额和库存变化，再由业务负责人双人复核；分批执行后对余额、流水、订单终态、渠道凭证和对象摘要做差异。对于已触发外部副作用的记录，数据库回退不能撤销现实动作，需要查单、冲正或人工联系。若系统必须继续服务，可以将无争议范围先恢复，把冲突对象隔离为只读或人工处理。完成后保留新旧位置、脚本版本、每批结果和未决清单，逐步解除写保护。长期通过最小权限、危险语句影响行数门禁、审批时效、演练过的时间点恢复和不可变审计降低再次发生概率。

一次误删演练中，我会先让恢复脚本输出三张清单：600 条可直接恢复、40 条与新写冲突、12 条已产生外部副作用。前一类分批幂等修复，冲突类由业务裁决，外部类先查单或冲正；任何类别都不能被一个全库覆盖语句处理。

恢复后抽样检查订单终态、库存流水和操作审计，并让原操作者权限保持撤销直至复盘完成。时间点恢复耗时、合法新写合并耗时和人工差异清理分别计入结果，避免只报告数据库装载完成的时刻。

• 追问 1：备份越频繁就越安全吗？ 直答 1：只降低候选数据缺口，不能替代日志连续性、恢复演练和业务合并能力。

• 追问 2：恢复脚本为何必须幂等？ 直答 2：分批失败或重复执行时不能再次改变已修复对象，幂等也便于安全重跑。

• 追问 3：什么时候需要停全站？ 直答 3：错误持续扩散且无法按对象隔离，或继续写会让权威关系不可判定时，应优先冻结危险写。

• 详细章节：误操作与业务合并恢复

21. 问题：区域故障切换到备用区域时，需要验证哪些条件？

口述答案：备用区域“有部署”不等于可以接管。我会从数据、控制面、容量、依赖和人员五方面验收。数据上确认复制位置、落后量、日志连续性和污染状态，按业务目标选择安全恢复点；控制面上检查路由、域名、证书、密钥、配置和写栅栏能在主区域不可达时独立操作；容量按峰值而非日均计算，扣除一个故障域后还要承接实时流量、重试和积压恢复。外部依赖包括支付渠道、仓库、对象存储、消息服务和通知配额，它们可能仍绑定原区域或账号。人员方面验证值班权限、通信和业务验收负责人均可用。切换先撤销旧区域写权，记录新任期和最后安全位置，备用区域预热后只开关键读写，小流量检查错误、尾时延、队列和库存或资金不变量；非关键查询、导出和历史回放保持降级。若备用区域只有峰值 70% 能力，就提前定义保留业务与明确拒绝，不让系统随机过载。历史差异与未知态在独立队列受控清理。主区域恢复后不立即回切，而是从新主重建、追平、只读校验，再安排窗口。整个过程计入实际 RTO（恢复时间目标），数据缺口计入 RPO（恢复点目标），只有两者和业务验收都满足才宣布区域恢复。

切换前我会用表格核对备用区域的复制位置、峰值能力、渠道白名单、密钥和控制面权限；例如备用区只有主区 70% 容量，就先停普通导出并限制历史查询。路由变更后同时监控旧区残余写和新区新任期写，任一双写立即触发栅栏。

业务验收以支付查单、库存预占和关键报警各取一组真实小流量，确认终态与不变量，而不是只做网络探测。原区域恢复后从新区重建，追平和只读核验完成再计划回切；本次故障的积压清理时间也计入完整恢复。

• 追问 1：域名切换成功就完成了吗？ 直答 1：没有，还要确认缓存生效、旧流量收敛、写权唯一、数据位置和用户结果。

• 追问 2：备用区容量不足怎么办？ 直答 2：按业务损失启用预定降级，只保关键交易和查单，同时给低优先级明确排队或拒绝。

• 追问 3：何时回切原区域？ 直答 3：故障根因消除、数据从新主追平、配置一致并通过小流量演练后再决定，不能为恢复原拓扑仓促回切。

• 详细章节：区域故障的联合条件

22. 问题：支付或物流供应商故障时，备用渠道为什么可能救不了场？

口述答案：备用渠道常见问题是配额、数据语义和故障独立性未经验证。主渠道平时承担 800 次/秒，备用合同上限只有 300，全量切换会立即被拒绝；即使配额够，币种、退款、轨迹状态、签名和幂等语义也可能不同。更隐蔽的是两者共享网络、域名解析、云账号或上游清算，故障并不独立。事故中我先按渠道、区域和业务类型确认影响，暂停无界重试；支付超时保留未知并按原交易键查单，物流查询可返回带时间水位的缓存结果，面单创建则明确排队。备用渠道只接经过适配和演练的范围，小比例验证请求身份、金额、状态映射、回调和对账，再逐档提升到合同与技术共同允许的上限。无法切换的流量要有明确拒绝、人工清单或延迟承诺，不能静默丢失。恢复主渠道时先处理两边未知和重复，确认同一业务意图没有在两个渠道各自产生副作用，再决定回迁；支付还要完成渠道、支付单和账务三方对账。长期维护真实探测流量、配额证据、数据可携带性、退出成本和联系人演练，定期故障注入验证控制权。备用真正的价值是已证明可承接指定业务，不是架构图上多画一个供应商。

假设主支付渠道每秒承接 800 笔，备用上限 300 笔，我会先保高价值商户和支持完整查单语义的币种，其余明确排队或拒绝。已经发给主渠道但未知的支付不进入备用，必须按原请求号确认不存在，防止两边各扣一次。

回迁前导出主、备两边的交易身份和终态差集，检查金额、币种、退款能力与账务分录；备用渠道产生的交易保持原归属，不为恢复架构整齐而迁移事实。合同配额、联系人响应和控制权在复盘中分别验证。

• 追问 1：能同时双发两个渠道吗？ 直答 1：查询可在受控条件择优，支付写入通常不能盲目双发，否则会产生双重副作用。

• 追问 2：供应商恢复后立即切回吗？ 直答 2：先探测、查清未知并小流量回迁，避免残余抖动和两边重复。

• 追问 3：合同可用性高就够吗？ 直答 3：不够，还要验证自身调用、语义适配、配额、故障独立性和业务对账。

• 详细章节：供应商配额与退出路径

23. 问题：如何证明备份真的能满足恢复目标？

口述答案：备份存在只能证明写出了文件，恢复能力要靠定期从空环境重建来证明。首先登记备份范围、频率、保留、加密、密钥、校验、增量依赖和责任人，确保备份与生产故障域隔离。演练随机选择一个恢复点，不提前挑“好备份”，在隔离环境恢复全量基线并连续重放增量，记录下载、解密、装载、索引重建、日志追平和应用校验各阶段耗时。容量计算以实际吞吐为准：数据 12 太字节，稳定恢复 1 太字节/小时，仅数据装载就需 12 小时，若业务 RTO（恢复时间目标）是四小时，备份频率再高也不达标。恢复后做结构校验只是起点，还要抽样对象摘要，运行库存余额与流水、支付凭证与分录、任务身份与产物、设备清单与报警覆盖的不变量。逻辑污染场景必须证明能选择污染前位置并合并之后合法写，密钥或权限负责人不可用也要有替代流程。演练结果记录真实 RPO（恢复点目标）、RTO（恢复时间目标）、失败步骤和人工依赖，行动项在下一次演练关闭。生产规模、数据格式、密钥和基础设施变化都会触发重演；未演练的备份只能标为恢复假设，不能写进对外承诺。

我会随机选一个历史恢复点，从空环境下载、解密、装载和重放，不能提前挑已知可用的备份。若 12 太字节数据以每小时 1 太字节恢复，单装载就需十二小时，四小时 RTO（恢复时间目标）显然不成立，必须提高吞吐或缩小恢复集。

装载完成后再做库存守恒、资金分录、任务唯一和报警覆盖校验，并模拟密钥负责人不在线。演练记录每阶段耗时、失败命令、人工依赖与实际数据缺口；下一次格式、密钥或规模变化后重新执行，不能沿用旧证明。

• 追问 1：只恢复几张表算演练吗？ 直答 1：可验证局部流程，但不能证明全系统依赖、吞吐和业务不变量满足目标。

• 追问 2：校验和一致就代表数据正确吗？ 直答 2：只证明文件未意外变化，逻辑错误仍需业务规则和权威凭证核验。

• 追问 3：恢复演练能用生产写吗？ 直答 3：应在隔离环境或严格只读范围进行，防止演练数据和外部副作用进入真实业务。

• 详细章节：复制、备份与真实恢复

24. 问题：开环与闭环压测有什么差别，选错会怎样误判容量？

口述答案：闭环模型通常由固定并发用户发起请求，收到响应后再发下一次；系统变慢时发送速率自动下降，适合模拟受响应节奏约束的人机交互。开环模型按既定到达计划发请求，不因系统变慢而自动减速，更适合订单回调、设备上报和上游固定流量。选错会产生协调遗漏：三百个闭环用户在 0.2 秒响应时约发 1,500 次/秒，响应变成一秒后只发约 300 次/秒，看板可能认为系统仍稳定；真实上游若持续 1,200 次/秒，队列每秒会新增约 900 个等待。设计压测时同时记录计划发送、实际发送、系统接收、正确完成和客户端放弃，避免发压器自身成为瓶颈。工作负载还要包含峰值持续时间、热点键、长尾任务、缓存命中和重试语义，开环也必须设置爆炸半径与停止条件，不能无限堆积拖垮共享环境。对于网页查询可用闭环模拟用户，再叠加开环异步回调；对 IoT（物联网）报警则以开环为主。结论报告明确模型、用户思考时间、连接复用和丢弃策略，并对同一场景用另一模型做校验。容量以满足业务正确性和时延的成功完成量为准，发送成功或客户端并发数都不是最终答案。

我会把发压器的计划发送、实际发送、服务接收和正确完成画成四条曲线。闭环吞吐从 1,500 降到 300 时，若系统响应已变为一秒，这不是压力自然消失；再用 1,200 次/秒开环回放，才能看到每秒约 900 个等待的真实风险。

实验命中队列斜率、错误或业务差异停止线后立即停止并保全样本。恢复阶段继续观察发压停止后的清空速度，核对客户端放弃是否仍在服务端执行；报告明确两种模型适用的用户行为，禁止只挑结果更好的一轮。

• 追问 1：闭环压测没有价值吗？ 直答 1：有，它适合受响应反馈影响的用户行为，但必须承认变慢时会自限流。

• 追问 2：开环压测一定更真实？ 直答 2：不一定，若真实用户会等待或放弃，纯开环会高估持续压力；应按业务来源建模。

• 追问 3：发压端如何验收？ 直答 3：监控自身 CPU（中央处理器）、网络、连接和计划偏差，确保未先饱和并保留发送时间戳。

• 详细章节：六类压测与负载模型

25. 问题：为什么扩容后必须预热，预热失败会产生什么事故？

口述答案：新实例进程存活只代表可以接受探测，不代表能安全承接峰值。预热至少包含连接池建立、路由与证书加载、缓存填充、JIT（即时编译）热点编译、对象分配稳定和必要数据结构加载。若十个新实例同时接全量，它们可能一起回源数据库，形成缓存击穿；连接池同步建立又冲击数据库会话，JIT（即时编译）和 GC（垃圾回收）抖动拉高尾时延，上游超时重试进一步放大。正确做法是先完成基础健康，再用小流量或代表性请求逐步预热，给每实例设置接流斜坡和总回源预算；缓存按热点分批或共享已有结果，避免所有实例请求同一键。观测分开看冷实例与热实例的成功率、P99（99 分位响应时间）、连接等待、缓存命中、编译和垃圾回收，不用集群平均掩盖新实例异常。预热命中下游保护线就暂停接流，旧实例继续承担基线，必要时启用限流或计划扩容。缩容同样要排空连接、任务租约和在途请求，不能直接杀掉仍持有副作用的工作者。演练应覆盖峰前扩容、突发响应扩容和一个实例组失效后的紧急补容，记录从启动到“业务就绪”的真实时间；容量模型使用这个时间决定提前量和故障余量。

一次扩容演练中，二十个冷实例若同时建立每实例 20 个连接，会瞬间新增 400 个数据库会话；我会把全局新建速率限制为每秒 20 个，并让实例按 5%、20%、50% 三档接流。每档比较冷、热实例的命中率、连接等待与 P99（99 分位响应时间）。

若冷实例错误超过保护线，流量立即退回热实例，冷实例保留现场而不是反复重启。完成预热后还要模拟缩容，确认在途请求和 Runner（执行器）租约已经排空；启动快但下线丢任务，同样不能成为自动扩缩容基线。

• 追问 1：健康检查通过为何还不能接流？ 直答 1：健康检查通常不覆盖缓存、真实依赖、热点编译和业务正确性，只证明最小存活。

• 追问 2：预热请求会污染数据吗？ 直答 2：应使用只读或明确隔离的测试身份，写路径通过影子验证，禁止产生真实外部副作用。

• 追问 3：紧急扩容来不及预热怎么办？ 直答 3：先限流和降级降低到达，再以更慢斜坡接流，不能让冷实例直接承接全部峰值。

• 详细章节：缓存、连接、JIT（即时编译）与 GC（垃圾回收）预热

26. 问题：怎样设计一次不会演变成真实事故的混沌演练？

口述答案：演练从稳态假设开始，例如“失去一个工作者后，关键任务结果明确率不下降、最老年龄在五分钟内恢复”。随后写注入对象、强度、持续时间、租户范围、不可触碰的数据和回退命令，爆炸半径优先按最大坏事件数而不是机器数量限制。执行前确认业务负责人、事故指挥、观察人和回滚人在线，监控覆盖技术指标、业务不变量、数据质量与用户反馈；停止条件包括重复扣款、负库存、关键报警遗漏、差异增长、下游保护线和观测失明。先在测试或只读路径验证注入工具，再从单实例、小租户、低风险时段逐级推进，不直接做区域级破坏。注入过程中保持版本、流量和操作审计，任何人工干预都进入时间线。故障撤销后继续验证恢复，计算检测、决策、执行、净消化和业务清理时长，不能服务一启动就结束。对支付超时要查单，对 Runner（执行器）重启要验证旧租约被栅栏，对 IoT（物联网）风暴要按设备清单验收。若演练失败，立即按预案止血并保留证据，失败本身就是有效结果；行动项绑定负责人和复验日期。只有下一轮能在相同或更严格条件下通过，才说明韧性得到提升。

例如只对一个非资金租户注入 500 毫秒依赖延迟，事前计算其最多 60 个坏事件，并设任一库存差异为立即停止条件。注入者、观察者和业务验收人分离，停止按钮先在空流量下验证，避免真正需要时权限或脚本失效。

撤销故障后继续计时，直到队列净斜率稳定、最老任务回到基线且业务清单闭环。若服务存活却差异新增，演练判失败并转真实事故流程；失败记录保留注入强度、版本和人工动作，下一轮针对同一缺口复验。

• 追问 1：生产演练的第一步是什么？ 直答 1：选择可逆、低风险、业务可观察的单实例或单租户故障，并先验证停止按钮。

• 追问 2：谁能终止演练？ 直答 2：任何观察到业务红线的人都应有明确升级与停止路径，不能只由注入操作者决定。

• 追问 3：演练没触发故障算成功吗？ 直答 3：不能直接算，应确认注入真实生效；否则只证明脚本或范围选择有问题。

• 详细章节：稳态假设、爆炸半径与停止条件

27. 问题：压测数据如何隔离，才能避免污染真实支付、库存和通知？

口述答案：我把测试身份、数据路径和外部副作用三层隔离。入口为压测流量注入不可伪造的测试租户、业务前缀和批次标识，鉴权后才接受；服务内部每次状态变化都传播该身份，避免某层丢标后进入真实链路。数据库可以使用独立分区或专用租户，库存预占只操作测试仓商品，支付走沙箱或本地替身，短信、邮件、仓库下单和对象分享全部由出口门禁拦截。仅靠调用方传一个标志不安全，副作用适配器和最终目标都要二次校验。执行前导出测试对象基线，设最大记录数、金额、磁盘和消息量；执行后按批次清理，并核对真实账本、渠道、通知和仓内系统没有对应副作用。假设一千万请求只有 0.01% 漏拦截，也会产生 1,000 个真实动作，因此停止条件应对任一未授权副作用零容忍。日志和指标保留测试维度，容量分析时可以纳入资源消耗，业务 SLI（服务等级指标）则排除经过事前规则认证的测试事件。若无法完全隔离某个供应商，就采用录制回放或限额极小的合同测试，不在大规模压测中直接调用。清理脚本先预览、后分批、可幂等，防止把真实相似数据误删；测试完成需要业务和数据负责人共同签署差异为零。

压测批次开始前我会导出测试仓商品、沙箱支付意图和通知出口基线，并设置最多 5,000,000 条事件与零真实副作用红线。若仅 0.01% 流量漏过出口，一千万请求会制造 1,000 个真实动作，因此第一条漏发就停止，不等比例变大。

清理阶段按批次身份预览待删对象，分批幂等执行后再与真实渠道、仓内系统和通知审计做差集。测试资源消耗保留在容量指标，业务成功率按事前规则排除测试意图；缺失标识的记录一律进入人工核验，不能自动当测试删除。

• 追问 1：测试标识能放请求头吗？ 直答 1：可以作为入口载体，但必须鉴权并写入持久身份，不能允许普通用户伪造绕过业务。

• 追问 2：为什么业务指标要排除测试？ 直答 2：测试不是用户意图，但排除规则要事前可审计；资源指标仍应保留以分析容量。

• 追问 3：清理失败怎么办？ 直答 3：保持测试租户隔离和写保护，按批次差异修复，未确认前不复用该数据空间。

• 详细章节：压测数据与外部副作用隔离

28. 问题：如何判断两轮压测的性能差异是真提升，而不是随机波动？

口述答案：先保证可比性：代码版本、配置、资源、数据基数、热点分布、发压模型、预热状态、外部依赖和后台任务都要记录并尽量一致。每个候选至少重复多轮，随机化执行顺序，避免第二轮因缓存更热天然更快；同时保留单轮成功完成率、分位时延、错误、资源和业务差异，不只比较平均吞吐。假设旧方案五轮正确完成量为 980、1,020、1,000、990、1,010，新方案为 1,015、1,030、1,005、1,025、1,020，均值差不大且区间重叠，不能宣称显著提升；还要检查新方案是否通过更高失败或丢弃换来吞吐。若差异小于轮次噪声，我会报告“未证明改善”，扩大样本或针对瓶颈做受控实验。定位因果时一次只改变关键变量，例如连接上限或缓存策略，并用资源等待变化解释结果。报告给中位数、分位范围或置信区间，同时列出异常轮次是否排除及理由，禁止只挑最好一轮。结论写明适用负载和失效条件，热点比例、数据量或依赖配额变化后重测。生产灰度继续用业务 SLI（服务等级指标）验证，实验结果只是发布依据之一；只有性能、正确性和单位成本共同改善，才把优化纳入基线。

我会随机化新旧方案执行顺序，并把每轮缓存温度、后台任务和依赖水位记录下来。若新方案五轮只比旧方案均值高 2%，但轮次波动为 ±4%，结论写“未证明提升”，继续扩大样本或针对锁等待做单变量实验，不挑最佳轮次宣传。

同时复算单位正确结果：吞吐上升若伴随失败或尾时延越线，不能进入新基线。灰度后再按租户和热点比较，任何生产分布超出实验范围就触发失效标记；原始轮次、排除理由和统计代码都随报告归档，便于复查。

• 追问 1：异常轮次可以删除吗？ 直答 1：只有明确外部干扰且保留原记录时可单列，不能因结果不好就删；异常本身可能暴露稳定性问题。

• 追问 2：平均值和 P99（99 分位响应时间）冲突看哪个？ 直答 2：按用户目标判断，尾时延敏感链路优先看阈值达标率和分布，平均只作补充。

• 追问 3：生产灰度还要重复吗？ 直答 3：要，用不同时间和风险单元观察，避免单一流量样本带来偶然结论。

• 详细章节：重复实验与结论失效条件

29. 问题：怎样用单位正确结果成本比较两种容量方案？

口述答案：比较时先统一“正确结果”定义，支付需终态明确且分录守恒，库存需预占唯一且余额非负，导出需产物完整可下载；受理、拉取和技术返回不能进入分母。成本分子包含计算、存储、网络、第三方配额、日志与链路采集、值守、演练、失败补偿和用户损失的可计量部分。方案甲每小时基础资源 900 元，正确完成 2,000,000 个，补偿与值守 100 元，单位百万结果成本 500 元；方案乙基础资源 700 元，但只正确完成 1,600,000 个，补偿 300 元，单位百万约 625 元，账单低不代表总成本低。还要比较峰值、一个故障域失效和恢复积压下的结果，避免常态便宜、事故昂贵。无法货币化的资金错误、安全漏报和合规风险列为硬门槛，不用预期成本平均掉。对缓存、异步、扩实例和降级分别记录一次性改造、持续运行、锁定与退出成本，并做流量、命中率和失败率敏感性分析。上线后按租户、任务类型或渠道展示归因，标签缺失成本单列而不是平均摊薄。若节省来自减少关键审计或故障余量，方案应被否决；真正优化是在正确性和恢复目标不下降时降低无效重试、冷数据或低价值实时计算。

比较缓存与扩实例时，我会把命中率、正确完成、补偿工时和出口费用带入敏感性表；例如方案乙每小时少花 200 元，却多产生 300 元补偿并少完成 300,000 个结果，单位百万结果成本反而从 500 升到约 647 元。

资金重复、负库存和安全漏报不折算成平均小额成本，而是候选否决项。上线一个账期后，用真实账单和业务终态复核预测；节省若来自降低关键审计或故障余量，立即回退并重新选择冷数据保留、无效重试或低价值实时计算作为优化对象。

• 追问 1：用户损失无法精确计价怎么办？ 直答 1：给区间或作为硬约束单列，不能随意填一个金额制造总分。

• 追问 2：空闲余量算浪费吗？ 直答 2：若用于覆盖增长、冷启动和故障域失效，它是可靠性成本；需通过演练证明必要性。

• 追问 3：谁负责成本归因？ 直答 3：平台提供一致口径，业务和技术共同确认结果身份、共享分摊与例外。

• 详细章节：单位成本与成本分摊

30. 问题：如何把自动扩缩容、限流和降级组合成稳定的容量治理策略？

口述答案：三者解决的时间尺度不同。计划或预测扩容覆盖已知峰值和冷启动，响应扩容处理可横向分摊的突发，限流保护共享依赖，降级则在总能力不足时优先保住高价值与不可错链路。策略设计先找最慢就绪资源和总量上限：应用可以两分钟增加，数据库连接、消息分区或供应商配额却不能同步增长，就必须给应用扩容设置依赖门禁。触发信号不只用 CPU（中央处理器），还结合队列等待、最老年龄、正确完成率、尾时延和下游水位；扩容高阈值与缩容低阈值分开，设置连续窗口、冷却期和最小实例，避免摆动。新实例预热后按斜坡接流，缩容前排空在途与租约。若流量越过故障后安全能力，先限低优先级查询和大导出，支付、库存和关键报警保留独立配额；降级结果要明确告知水位和恢复边界。事故恢复时先暂停缩容，历史积压与实时流量分开限额，每档放量观察净消化和业务差异。成本侧记录扩容时长、空闲时段和降级损失，定期复算阈值。演练覆盖预测偏差、指标滞后、冷实例失败和单故障域丢失，证明自动化在观测缺样时会进入保守模式，而不是继续误扩或误缩。

我会配置一个状态表：连续三窗口最老年龄上升且成功完成率稳定时允许扩容；数据库连接越过保护线时即使队列增长也禁止继续扩，转为限流和降级。扩容实例预热完成前不计有效容量，缩容则要求租约、连接和在途全部归零。

事故恢复时暂停自动缩容，把实时关键流量与历史积压设不同配额；普通导出先降级，支付查单和库存补偿保底。每档动作都记录触发信号、实例数、依赖水位和业务差异，抖动超过次数门槛后切回人工控制并保留最后稳定配置。

• 追问 1：为什么不只用队列长度扩容？ 直答 1：长度是存量且可能由毒任务造成，还需最老年龄、完成率和下游余量共同判断。

• 追问 2：缩容最危险的是什么？ 直答 2：杀掉持有租约、连接或未提交副作用的实例，导致重复执行和容量反弹。

• 追问 3：降级顺序谁决定？ 直答 3：业务按失败损失确认，技术验证依赖和恢复能力，并写入可演练开关。

• 详细章节：扩缩容的滞后、抖动与缩容安全

31. 问题：请串讲一次 WMS（仓储管理系统）热点商品预占导致的超卖事故。

口述答案：我会先说明业务不变量是同一仓商品可售量不能小于零，同一预占意图最多生效一次。事故表现为大促热点商品接口 P99（99 分位响应时间）陡升、锁等待增加，部分上游超时后换新请求重试；全站成功率仍高，但商品甲账面确认预占 1,006 件，期初只有 1,000 件，已触发正确性红线。止血不是先扩应用，而是冻结商品甲继续放量，关闭换键重试，对新请求返回明确售罄；其他商品按分片继续服务。查证以订单意图、库存版本、预占流水、释放流水和仓内拣货凭证为证据，区分重复预占、漏释放和真实实扣，缓存只作线索。容量侧发现同键条件更新必须串行，应用扩容反而增加数据库锁竞争，于是对热点键限并发、缩短事务，把通知等非关键动作移出裁决事务。恢复按唯一意图逐条核对，可安全取消的重复预占幂等释放，已进入仓内拣货的订单转业务协调；每批后复算期初加补入减预占减实扣加释放等于期末。验收要求新增负库存为零、热点等待回落、未知清单逐笔有结论，缓存从权威余额重建。复盘增加热点识别、业务键强制校验、库存红线与故障演练，改进效果只在下一次热点回放通过后确认，不虚构生产收益。

查证阶段会形成商品甲的状态表：1,006 条确认预占、998 条仓内拣货、4 条可安全取消、2 条需要业务协调。任何修复都引用原预占号，释放前确认未实扣；缓存保持只读，权威余额与流水对齐后再整体重建。

恢复采用同仓其他商品作为对照，小比例开放商品甲并观察条件更新失败、锁等待和新负库存。连续窗口无新增差异后才扩大，历史两条争议订单仍由责任人跟踪；复盘压测固定热点比例，而不是用均匀商品流量掩盖串行裁决。

• 追问 1：为什么明确售罄优于排队？ 直答 1：库存正确性已受威胁时，明确拒绝能阻止未知预占继续扩大，排队只适合容量可恢复且身份稳定的场景。

• 追问 2：条件更新还会超卖吗？ 直答 2：单一权威点正确执行不会，但多权威源、缓存独立扣减或补偿越权仍可能破坏不变量。

• 追问 3：超卖六件为何不能被全站预算覆盖？ 直答 3：这是高损失正确性红线，大分母可用率不能抵消已确认的库存承诺错误。

• 详细章节：WMS（仓储管理系统）下单与热点库存

32. 问题：WMS（仓储管理系统）波次任务积压时，如何兼顾出库时效和库存正确性？

口述答案：波次积压先按业务任务而非消息条数统计，区分待分配、已锁库、已下发仓内、执行中和未知状态。出库时效重要，但库存裁决和任务副作用不能为追吞吐让步。现场固定截单时间、仓、承运商和优先级，计算新到达与正确完成；例如积压 36,000 单，新到达每分钟 3,000，仓内稳定完成每分钟 4,200，净消化 1,200，静态需要三十分钟。若工作者扩容后仓内接口拒绝上升，实际完成降到 2,800，积压仍增长，必须回退并发。止血把加急、临近截单和普通订单分队列，给关键仓与承运商保留配额；尚未锁库的低优先级波次可延后，已锁库任务必须保留租约和释放规则，不能直接删除。查证连接订单、库存预占、波次身份和仓内回执，重复消息使用原业务键查询结果。恢复按仓逐档提高并发，每档观察最老年龄、仓内限额、库存锁等待、重复下发和释放差异；毒任务隔离。验收不仅是队列回到正常水位，还要保证每个预占要么对应有效出库，要么按规则释放，截单承诺和人工清单有结论。复盘将仓内配额、净消化能力和波次成本分布回填容量模型，并在大促前做计划扩容与单仓失效演练。

我会把 36,000 单积压按临近截单、已锁库、普通待分配三类建状态队列。已锁库任务不能因超时直接删除，需延长受控租约或按订单终态释放；反复失败的仓内请求进入隔离队列，并保存承运商、仓和失败码供人工处置。

每次把仓内并发提高 10%，都复算正确完成减新到达的净值，并检查库存锁等待与重复下发。最老关键订单持续下降、释放流水守恒、仓内限额未反弹后才升档；普通订单获得最低配额和年龄提升，避免为保新单永久饥饿。

• 追问 1：先处理新订单还是老订单？ 直答 1：按截单损失和年龄提升组合，不能只追新订单成功率，也不能让关键新单被毒任务阻塞。

• 追问 2：暂停波次会锁死库存吗？ 直答 2：已预占任务需延长受控租约或按订单终态释放，暂停不能跳过库存闭环。

• 追问 3：仓内接口恢复就能拉满吗？ 直答 3：不能，需从探测和小批开始，确认限额、重复与实际完成稳定后再升档。

• 详细章节：消息积压、净消化与恢复时间

33. 问题：请串讲一次支付渠道超时导致大量未知态的事故。

口述答案：事故开场我会强调超时不是失败。某窗口 20,000 个支付意图中，19,400 个返回成功、300 个明确失败、300 个超时；异常集中在渠道乙的新版本。第一步冻结该版本和渠道乙新增流量，保留原支付意图与渠道请求号，页面显示处理中，禁止用户换键重复支付；可安全切换的币种小比例转备用渠道，不能确认语义的保持明确排队。查证对齐入口、渠道请求、回调、主动查单、支付单和账务分录，发现渠道响应变慢且部分成功回包丢失。对 300 个未知按原键查单，260 个确认成功、30 个失败、10 个仍未知；成功中 8 个缺少账务分录，因此业务待处理为 18 个，不是入口剩余的 10 个。恢复先补齐 8 个唯一分录，再对 10 个未知限制退款和出款并转人工核验；回调迟到通过状态机合并，不能覆盖已确认终态。小流量恢复后同时观察结果明确率、最老未知、重复扣款、金额币种差异和渠道限额。事故关闭需渠道、支付单、账务三方差异归零或逐笔有处置。复盘补多窗口未知态告警、渠道隔离、查单容量和超时注入演练，所有数字标 E3（演练证据）。

事故中我会给 300 个超时意图建立状态表，保存渠道请求号、最后查单时间、支付单和分录。查单确认的 260 个成功只推进原状态并补缺失分录，30 个失败允许重新支付，剩余 10 个冻结自动退款和履约，不能混成一个失败批次。

渠道恢复后先用新意图做小流量，再检查迟到回调不会覆盖查单终态。业务验收同时要求最老未知下降、重复扣款为零、金额币种差异清零；入口错误恢复仅是新增影响停止，历史 18 个资金待办全部有凭证后才关闭。

• 追问 1：页面显示失败可以减少投诉吗？ 直答 1：不能在终态未知时显示失败，会诱导再次支付；应显示处理中并提供查询入口。

• 追问 2：查单也超时怎么办？ 直答 2：保持未知、限制后续副作用并带退避重查，超过窗口进入人工和对账清单。

• 追问 3：为何成功还会缺分录？ 直答 3：渠道终态与本地事务可能跨边界，响应丢失或本地失败需靠发件箱、查单和对账补齐。

• 详细章节：支付业务成功与技术成功

34. 问题：支付对账发现小额差异，但错误预算仍健康，你会怎么处理？

口述答案：资金差异按正确性红线处理，不等全局错误预算显著变化。先确认差异来源和范围：渠道账单、支付单、账务分录、退款和冲正分别按支付意图与渠道交易号连接，核对商户、金额、币种、方向和时间。若一百万笔中只有三笔差异，比例很小，但可能是一笔重复入账、一笔成功未记账和一笔退款超过实付，三种处置完全不同。止血按风险单元冻结自动退款、出款或受影响渠道版本，不必停掉无关商户；保留原始账单和事故窗口，禁止批量把本地状态覆盖成渠道状态。查证重复入账需要识别唯一分录和是否已经结算，漏记账需确认渠道凭证后幂等补分录，超额退款则检查累计实付和冲正链路并升级业务。每个修复动作双人复核、分批执行，前后做借贷平衡和渠道差集；无法确认的对象保持未知并限制自动操作。恢复标准包括新增差异为零、历史三笔逐一有凭证、补偿无重复、下一结算批次对账通过。错误预算继续用于总体可用性，但资金红线独立驱动发布门禁。复盘追溯幂等约束、金额币种校验、对账时效和差异自动分流，要求用构造的重复回调、迟到查单和退款并发场景复验。

三笔差异会分别建立处置状态：重复入账先冻结结算并标记唯一有效分录，成功未记账以渠道凭证幂等补账，超额退款则核对累计实付后冲正。每笔都保存原始金额、币种、审批人与前后借贷平衡，禁止一条覆盖语句统一修复。

下一结算批次通过并不自动关闭旧差异，还要反查补账是否重复进入账单、冲正是否被渠道接受。恢复门槛是窗口新增差异为零、三笔各有外部凭证和本地分录、自动退款与出款门禁逐项解除；错误预算健康不改变这套红线。

• 追问 1：能以渠道账单为唯一真相吗？ 直答 1：渠道证明外部资金事实，本地账务仍要满足分录与业务归属，两者需对账而非单向覆盖。

• 追问 2：三笔差异是否可以人工记账？ 直答 2：可以受控处理，但必须保留原因、审批、凭证和可逆方式，不能绕过系统审计。

• 追问 3：为何冻结退款而非支付？ 直答 3：取决于差异类型；按最小风险单元止血，防止扩大损失同时保留无关能力。

• 详细章节：错误预算与正确性红线动作

35. 问题：跨境物流轨迹渠道变慢时，如何区分缓存、容量与供应商问题？

口述答案：先把用户目标定义为在时限内拿到有效轨迹或明确暂无结果，并把轨迹新鲜度单列。入口峰值 600 次/秒，平时缓存命中 40%，穿透约 360 次/秒，低于渠道 400 次/秒限额；事故中命中降到 20%，穿透变成 480，即使渠道单次服务能力未变也会排队。排查按地区、承运商、轨迹状态和缓存水位切片，比较缓存命中、回源请求、连接等待、渠道响应、拒绝与页面结果；链路若显示等待集中在渠道，仍需判断是渠道变慢还是本地回源过量。止血先限制回源总并发，对已签收等稳定终态延长缓存，对运输中结果展示数据时间并异步刷新；关键客户或异常件保留优先查单，非关键批量查询排队。关闭同步无界重试，避免一次页面请求放大多次渠道调用。恢复时先让穿透降到配额内，再小批提升刷新速度，观察 P99（99 分位响应时间）、新鲜度、覆盖、渠道拒绝和队列最老年龄；技术错误回落但某地区仍持续旧轨迹，业务未恢复。长期将命中率下降作为容量敏感项，维护备用渠道状态映射与真实探测，压测同时注入缓存失效和渠道慢，避免只验证单一因素。

我会固定事故地区与承运商的样本，比较命中率从 40% 降到 20% 前后的回源和渠道拒绝；穿透 480 次/秒超过 400 限额时，先把回源压回安全线。运输中轨迹展示最后更新时间，签收终态延长缓存，异常件保留优先查单。

历史恢复按轨迹水位而不是请求数验收，避免重复刷新抬高吞吐。渠道探测恢复后分批刷新，并按区域检查新鲜度与覆盖；若某地区仍陈旧，继续隔离该地区，不让全局 P99（99 分位响应时间）转绿掩盖局部业务失败。

• 追问 1：返回旧轨迹算成功吗？ 直答 1：只有在产品允许的新鲜度边界内并明确展示数据时间，才能算降级好事件。

• 追问 2：为什么不直接扩缓存？ 直答 2：若失效策略、热点或数据更新链有问题，扩容量不能恢复命中，还可能延长陈旧数据。

• 追问 3：渠道限额如何纳入扩容？ 直答 3：把回源总并发作为全局门禁，应用实例增加时每实例额度反向调整，不能突破合同上限。

• 详细章节：跨境查询的缓存敏感性

36. 问题：跨境面单供应商故障，切备用供应商时如何避免重复下单？

口述答案：面单创建属于有外部副作用的写操作，主供应商超时后不能立即把同一包裹发给备用方。先为本地面单意图建立稳定业务键，记录包裹、地址摘要、服务等级、费用和主供应商请求号；超时进入未知，暂停该包裹自动切换并主动查单。事故按供应商、地区和产品确认影响，未发送的意图可以路由备用，已发送但未知的必须先取得主方明确不存在或由人工裁决。备用供应商上线前核对地址、计费、标签格式、取消能力、幂等语义和日配额，小流量验证打印与仓内扫描，不能只看接口成功。若主方查单确认已创建，则补拉原面单并写本地映射；确认失败才以同一本地意图进入备用，并记录供应商代次，防止迟到回调覆盖。恢复期间对“本地意图、主外部单号、备用外部单号、对象文件、仓内扫描”做差集，任何一包多单都冻结发运并取消无效标签。容量上为临近截单包裹设优先级，普通面单排队且明确告知。主供应商恢复后先清理未知，再逐步回迁，不双发比较。复盘将查单、取消和供应商代次纳入状态机，定期演练主超时、迟到成功和备用配额耗尽，证明退出路径可用。

每个包裹会维护本地意图、主供应商请求号、备用供应商代次和仓内扫描四个状态。主方超时后先查单，确认不存在才允许备用创建；若迟到回调带回主面单，栅栏根据已生效代次拒绝发布，并把双单放入费用与取消清单。

备用放量按地区和产品小批验证标签格式、地址语义、价格与取消能力，临近截单包裹优先，普通包裹明确排队。恢复验收要求一包只有一个可扫描面单、无效标签已取消、对象文件和费用差异闭环；主方回迁前先清空全部未知。

• 追问 1：两个供应商都生成面单怎么办？ 直答 1：立即冻结包裹发运，依据仓内扫描和业务选择保留一个，取消另一个并保留费用差异。

• 追问 2：供应商请求号谁生成？ 直答 2：优先使用本地稳定意图派生且对方可查询的身份，避免每次重试生成新号。

• 追问 3：备用更贵是否仍切换？ 直答 3：按截单损失、客户等级和费用上限决策，成本不能静默突破，未切流量需明确排队。

• 详细章节：供应商故障、配额与控制权

37. 问题：大批量导出导致 JVM（Java 虚拟机）内存压力和任务雪崩，你怎么排障？

口述答案：我先把导出成功定义为冻结查询条件下产物完整、摘要正确、权限可用，而不是工作线程结束。事故中按任务大小、租户和版本切片，查看堆占用、GC（垃圾回收）停顿、直接内存、线程、数据库游标、临时盘、对象带宽和最老任务年龄。若每任务平均占 256 兆字节，节点安全任务内存 4,096 兆字节，内存并发上限是 16；数据库连接只允许 12，对象带宽又只支持 8，真实并发上限取 8。止血暂停超大与低优先级导出，入口限制单租户任务数，保留任务和分片状态；不直接重启清空队列，因为旧任务可能已上传部分产物。查证对象是否整表加载、分页是否保持引用、客户端是否复用、临时文件是否及时释放，区分 Java（编程语言）堆、直接内存和容器限制。修复采用流式分页、分片产物、受控缓冲和确定性对象键，外部上传失败可从检查点续传。恢复先用小文件验证，再按成本队列放量，观察正确完成率而非拉取量；旧产物通过代次和摘要避免覆盖。验收抽样行数、摘要、对象回读、权限和下载，孤儿文件清单单独清理。复盘把文件大小分布、资源最小值和单租户额度写入容量模型，并通过稳定性压测覆盖长时间运行。

我会从失败节点保留一次堆、直接内存、任务大小和对象上传水位快照，确认是整表驻留、分页引用未释放还是客户端重复创建。修复版本先用 1、4、8 三档并发跑相同大文件，若内存稳定但对象带宽在八并发饱和，就把八写成资源门禁而不是继续加堆。

历史半成品按任务代次和对象摘要扫描：可续传分片从检查点恢复，旧代次孤儿对象延迟清理，已通知却损坏的链接先撤销。验收用用户身份下载并核对行数、摘要和权限，GC（垃圾回收）恢复只是技术证据之一。

• 追问 1：增加堆内存能解决吗？ 直答 1：可能延缓失败，但若并发、对象生命周期或其他资源不变，会带来更长停顿且数据库和带宽仍可能先饱和。

• 追问 2：为何不用一次性查询更快？ 直答 2：会把数据集驻留内存并延长事务，流式分页用可控资源换取稳定交付。

• 追问 3：重启后任务如何继续？ 直答 3：从持久化分片清单和检查点续跑，使用新租约代次，不能依赖进程内状态。

• 详细章节：异步导出的多资源容量

38. 问题：导出任务显示完成，但用户下载到空文件或无权限，如何恢复？

口述答案：这类事故说明技术任务状态和业务交付定义脱节。先冻结异常版本继续发布，把事故窗口的任务清单按租户、请求人、查询摘要和产物对象连接，统计任务完成、对象存在、大小非零、摘要通过、授权正确和下载探测六个阶段的差异。假设 12,000 个任务中 11,950 个标完成，对象只有 11,880 个有效，下载探测通过 11,700 个，至少有 70 个产物差异和 180 个可用性差异，不能报 99.58% 完成率。止血暂停自动发送错误链接，对受影响用户显示处理中；权限越界对象立即撤销访问并保留审计。查证分片是否完整、状态是否在上传前提交、对象键是否被旧尝试覆盖、授权是否使用错误租户。恢复使用确定性任务键和新代次重建缺失产物，先回读并校验行数或摘要，再原子发布下载指针和权限，通知去重。大任务进入限并发队列，防止补跑再次压垮数据库和存储。验收以用户身份做下载探测，并核对越权访问日志、孤儿对象和重复通知。复盘把“完成”拆成计算完成、产物就绪、授权就绪和交付完成状态，建立每段 SLI（服务等级指标）与回放演练。

我会给 250 个异常任务建立六段状态：受理、分片齐全、上传、回读、授权、下载探测；缺哪一段就从该段前的确定性检查点恢复。空文件不直接覆盖原对象，而是写新代次临时键，摘要和权限通过后原子切换下载指针，防止用户再次读到半成品。

对越权对象先撤销访问并查阅下载审计，确认是否发生实际泄露；通知重发使用原任务身份去重。连续两个窗口新增差异为零、全部旧链接失效、用户探测成功后再恢复自动通知，孤儿文件按审计保留期分批清理。

• 追问 1：对象大小大于零就正确吗？ 直答 1：不够，还要核对格式、行数或摘要、数据水位和权限，非空文件也可能漏分片。

• 追问 2：旧链接如何处理？ 直答 2：撤销或失效旧指针，发布新链接并做通知去重，同时保留访问审计。

• 追问 3：用户主动未下载算失败吗？ 直答 3：通常不算，但服务必须证明链接在承诺期内可用且通知已按规则送达。

• 详细章节：技术成功与用户拿到产物

39. 问题：Runner（执行器）工作者失联后被接管，怎样防止旧工作者重复提交？

口述答案：超时只能说明调度器暂时看不到工作者，旧进程可能仍在执行，因此不能靠重新派发实现“只执行一次”。我会把承诺改成同一业务任务最多形成一次有效副作用。任务有稳定业务键，每次领取生成单调递增的租约代次和截止时间；续租、读取检查点、写结果都携带代次。调度器判定失联后可以发新代次，但最终副作用端必须校验当前代次，旧工作者网络恢复后提交会被栅栏拒绝。若对象存储不支持条件写，就先写代次化临时对象，只有当前租约者能原子更新发布指针；外部调用则使用对方可查询的幂等请求号，无法确认时进入人工。事故中固定任务、旧新工作者、代次和副作用清单，检查是否存在同键不同参、租约续期延迟或时钟误判。止血暂停高风险任务类型，不清空任务表。恢复先验证新工作者从持久检查点继续，旧工作者不能覆盖，再逐批接管；每批核对业务结果、重复副作用和孤儿产物。容量方面将续租和执行线程隔离，防止任务繁忙导致心跳饥饿。复盘演练进程暂停、网络分区和完成后确认丢失三种序列，栅栏在目标端通过才算闭环。

具体查证会列出旧工作者代次 17、新工作者代次 18、最后续租和每次副作用提交。对象存储只允许代次 18 更新发布指针，旧进程恢复后即使上传成功也只能留下隔离临时对象；支付类外部动作则按原请求号查单，不能再次调用。

接管先选十个无资金副作用任务验证栅栏，再扩到高优先级队列。历史上同键不同参的冲突不视为幂等成功，而是冻结并人工核对；验收要求旧代次有效提交为零、新代次从检查点继续、任务状态与产物一一对应。

• 追问 1：数据库唯一约束能替代租约吗？ 直答 1：只能防部分重复结果，不能控制并发执行、外部副作用和旧工作者覆盖，仍需代次与状态机。

• 追问 2：租约时间设多长？ 直答 2：依据任务时长和续租抖动设定，并监控暂停；过短误接管，过长恢复慢。

• 追问 3：旧工作者还能读数据吗？ 直答 3：读取可以存在，但任何状态推进和副作用提交都必须被当前代次校验。

• 详细章节：Runner（执行器）积压、回放与恢复

40. 问题：Runner（执行器）任务积压并伴随重试风暴时，如何恢复容量？

口述答案：先把新业务、技术重试和历史补偿分开计数。某时刻积压 180,000 个业务任务，新到达 1,500 个/秒，工作者拉取 2,400 个/秒，但 500 个失败回队，正确完成只有 1,900，净消化 400 个/秒，理论清空 450 秒。表面拉取很高，真实恢复能力并不充裕。止血关闭立即重试，按错误类型设置退避和最大次数，把固定失败的毒任务移入隔离队列；关键支付查单、库存补偿与普通导出分别保留资源配额。检查数据库连接、外部限额、线程和消息分区，确定当前安全完成量，工作者扩容不能突破总连接和供应商配额。任务租约、代次和业务键保证重放不重复副作用。恢复采用阶梯并发，每档观察成功完成、最老年龄、重试倍率、下游水位和业务差异；若完成降到新到达以下立即退档。预计清空时间按最近稳定窗口滚动重算，并向业务给区间和优先级影响。接近消息保留期的任务先固化原始载荷和水位，不能静默跳过。验收要求积压回到基线、老任务无饥饿、隔离清单有责任人、支付库存不变量通过。复盘把任务成本分层、总并发门禁和失败分类写入调度策略，并演练下游慢而工作者仍健康的场景。

我会把失败回队从拉取量中扣除，并按支付查单、库存补偿、导出三个任务族分别画净斜率。若普通导出每秒消化 700 个而支付最老年龄仍增，整体 400 个/秒净值不能用于放量；先将通道和连接配额转给支付，导出保留最低吞吐。

接近保留期的任务先归档业务键与载荷，毒任务记录最后错误和人工入口。恢复结束时抽样验证查单终态、库存释放和导出产物，确认队列下降不是死信迁移或静默丢弃；新增分区只有在下游完成量同步增加时才保留。

• 追问 1：增加分区能立即解决吗？ 直答 1：只有消费并行度是瓶颈且下游有余量时有效，分区迁移本身也有成本。

• 追问 2：重试次数设多少？ 直答 2：按错误可恢复性、时效和副作用风险分类型设置，不用统一固定次数。

• 追问 3：优先队列会饿死普通任务吗？ 直答 3：给普通队列最小配额和年龄提升，同时隔离毒任务，避免永久饥饿。

• 详细章节：队列背压与净消化治理

41. 问题：请串讲一次 IoT（物联网）报警风暴事故。

口述答案：事故目标不是把所有消息尽快消费完，而是关键设备报警不漏且在时限内可见。假设 100,000 台设备两分钟各上报三条，入口约 2,500 条/秒，消费者稳定能力 2,000，两分钟积压 60,000。我先按安全等级冻结自动关闭规则，启用设备、规则版本和时间窗聚合，关键报警进入独立队列并保留原始事件，普通重复只合并展示；同时限制单设备和单租户噪声，不能让异常设备占满全局。查证以权威设备清单和应触发规则为分母，对比原始事件、报警实例、通知回执和人工确认，查看关键覆盖、新鲜度、最老年龄、队列与重试。若关键通道能力低于关键到达，就从普通通道调配容量或暂停低价值处理，而不是平均分配。恢复先补关键历史事件，按设备清单逐个确认，普通事件按合规要求聚合或归档；每档放量观察关键漏报、通知渠道限额和下游存储。技术吞吐恢复但某地区关键设备没有结果，事故仍未结束。验收包括关键覆盖达到目标、原始证据可追溯、通知或人工接管闭环、普通队列回到可控水位。复盘校准聚合窗口、关键配额和设备异常隔离，并通过开环峰值与通知故障联合演练复验。

风暴窗口会保存设备、规则版本、原始事件数、聚合实例和通知回执五列证据。某设备一分钟上报 200 次可以聚成一个持续报警，但严重级别升级必须产生新实例；聚合器不得删除原始位置，验收人员能从报警反查全部源事件。

恢复时关键队列先获得额外 80 条/秒配额，把原净积压 50 条/秒转为净消化 30 条/秒；普通状态同步暂缓。按设备清单补送后，关键覆盖、新鲜度和人工确认均达标才恢复自动关闭，普通历史事件依合规规则聚合归档。

• 追问 1：去重后消息少了如何证明没丢？ 直答 1：保留原始事件与聚合映射，按设备和规则清单核对每个关键报警实例。

• 追问 2：普通报警可以丢弃吗？ 直答 2：仅在产品、合规和审计规则允许时聚合或过期，不能静默删除关键状态变化。

• 追问 3：设备疯狂上报怎么隔离？ 直答 3：按设备和租户限额、窗口聚合并保留最后状态，异常对象单列，不占满关键通道。

• 详细章节：IoT（物联网）报警峰值与关键覆盖

42. 问题：IoT（物联网）消费者恢复后，为什么还可能有关键报警漏报？

口述答案：消费者恢复只证明当前可以处理消息，历史事件可能已过保留期、被错误去重、在通知环节失败，或集中覆盖少数设备。我要从权威设备与规则清单反推应有关键报警，而不是从已消费消息正向统计。事故窗口按设备、规则版本和时间建立期望集合，再与原始事件、报警实例、通知回执和人工确认做四段差集：没有原始事件要查设备或采集，没有报警实例要查规则和去重，没有回执要查通知渠道，已有回执仍需确认接收责任。假设总处理量恢复到 6,000 条/秒，但关键队列到达 300、完成 250，每秒仍积压 50，总吞吐绿色无法证明关键路径收敛。止血时关键队列独立扩容或借用普通配额，暂停自动关闭和低价值历史回放；接近保留期的原始事件先归档。补送使用报警实例身份去重，避免重复触发控制动作，并保留“首次发生时间”和“补送时间”，不能让迟到通知看起来满足实时目标。验收要求关键差集为零或逐项人工签收，新鲜度回到窗口，通知限额和普通队列稳定。复盘增加对象覆盖指标、规则版本审计、保留期预警和关键通知多渠道演练。

我会从 80,000 台权威设备生成期望集合，与原始事件、报警实例、通知回执和工单确认做四次差集。缺原始事件查网关水位，缺实例查规则版本，缺回执查渠道，缺确认交现场负责人；每类有独立修复动作，不能统一重放消息。

补送保留首次发生与实际送达两个时间，使用报警身份防止重复控制。关键差集归零后仍观察一个规则周期，确认新鲜度和通知限额不反弹；历史普通事件是否重放由保留与业务价值决定，但关键源事件和升级状态不可丢。

• 追问 1：补送后能把时效指标改成成功吗？ 直答 1：不能，最终覆盖可修订为完成，但原始迟到必须保留为时效失败。

• 追问 2：通知回执等于人已处理吗？ 直答 2：不一定，关键场景还需接收确认或工单状态，回执只证明渠道送达阶段。

• 追问 3：没有原始事件一定是设备故障吗？ 直答 3：不一定，还可能是网关、采集或分区丢失，要沿设备心跳和链路水位查证。

• 详细章节：恢复演练中的报警覆盖

43. 问题：预算受限时，如何在 WMS（仓储管理系统）、支付、导出和报警之间分配容量？

口述答案：我不会按团队平均分机器，而是按不可违反的不变量、失败损失、时效和可恢复性分层。支付扣款、账务查单、库存裁决和关键安全报警属于高损失链路，需要独立最小容量、故障余量和审计；普通轨迹查询、历史导出和重复报警可以通过缓存、排队、聚合或延后交付吸收峰值。先把各链路的峰值到达、服务时间、下游配额、允许等待、单故障域和净恢复能力换成同一资源约束，再设置不可借用的保底与可借用上限。例如预算只支持 1,000 个任务槽位，可以为支付查单 250、库存补偿 250、关键报警 200 保底，剩余 300 在导出和普通任务间弹性分配；真实比例需由业务证据校准。扩容先看共享数据库和渠道，避免高优链路用更多应用线程把下游压垮。成本比较采用单位正确结果，纳入失败补偿、值守和供应商费用；资金差异与安全漏报作为硬门槛，不被低价抵消。高峰时按预定降级顺序关闭大导出、降低查询新鲜度、聚合普通报警，向用户展示明确水位。恢复按正确性基础、实时交易、历史积压、体验功能顺序小批放开。每季度用账单、业务结果和单故障域演练复算配额，避免永久保留已无价值的容量，也不因短期省钱删掉未经替代验证的余量。

配额演练会同时失去一个实例组，再检查支付 250、库存 250、关键报警 200 的保底是否仍可完成；如果共享数据库只支持 600 个槽位，就不能宣称三类保底共 700。我会先削减非关键读取与批处理，重新按真实服务时间换算。

历史导出降级要记录排队水位与用户时限，超过承诺则明确失败或预约，不无限积累隐藏负债。每个账期比较单位正确结果、补偿工时和闲置余量；只有替代机制经故障演练通过，才下调保底，资金和安全红线不参与平均降本。

• 追问 1：高优先级能无限借容量吗？ 直答 1：不能，仍受共享依赖上限约束，并要给其他不可中断链路保底。

• 追问 2：历史导出全部延后可行吗？ 直答 2：需看合同和用户时限，超期应明确失败或预约，不能无限排队。

• 追问 3：如何证明配额合理？ 直答 3：用峰值模型、失败成本、账单和故障演练共同复算，并记录输入变化触发调整。

• 详细章节：多租户公平、隔离与容量预算

44. 问题：面试中如何在五分钟内讲清一场容量事故，而不是堆砌术语？

口述答案：我会选一个主矛盾明确的事故，按“背景与不变量、量化影响、止血、根因、恢复、验收、复盘”组织。开头三十秒说明业务，例如 Runner（执行器）承载支付查单和普通导出，关键要求是查单终态不丢、同一任务副作用唯一。接着给 E3（演练证据）量化：峰值到达 1,500 个/秒、正确完成 1,100、积压每秒增长 400，最老关键任务超过窗口；不要只说 CPU（中央处理器）很高。止血讲决策理由：暂停大导出、关键队列保底、关闭立即重试，因为下游渠道与数据库已到保护线，扩工作者会放大失败。根因用证据链说明慢依赖拉长服务时间、在途上升、重试加倍，而非一句“并发太高”。恢复给公式和顺序：修复后正确完成 1,900、新到达 1,500，净消化 400，按优先级小批清理；租约代次阻止旧工作者提交。验收说最老未知下降、支付查单与分录一致、导出产物抽样通过，告警绿色只是其中一项。复盘落到重试矩阵、总并发门禁、错误预算与混沌演练，并说明哪些数字待核对。这样每个术语都服务于一个判断，面试官能听到业务责任、计算、失败边界和工程反思。

为让口述可核验，我会带一张最小数据卡：事故前完成率、故障到达率、净斜率、最老年龄、受影响业务键和恢复后业务差异。面试官追问时能从 1,500 - 1,100 = 400 的积压增长推到为何限流，再从 1,900 - 1,500 = 400 解释清空时间。

如果项目材料只能证明我参与调度改造，生产规模和收益就明确待核对；演练数字只展示方法。结尾给一个反事实：当时若继续扩工作者会突破渠道限额，所以选择停导出保查单；这种取舍比罗列消息队列、线程池和监控名词更能证明判断力。

• 追问 1：五分钟说不完先删什么？ 直答 1：删组件列表和次要时间线，保留业务影响、关键决策、可复算数字、验收和反思。

• 追问 2：没有真实数字怎么办？ 直答 2：明确待核对，用 E3（演练证据）展示算法和敏感项，不把练习数字冒充生产。

• 追问 3：根因很多怎么讲？ 直答 3：区分触发因素、放大机制和长期系统缺口，主线只讲有证据且改变决策的部分。

• 详细章节：容量排障与持续校准

45. 问题：事故复盘怎样把一次故障真正转化为架构稳定性提升？

口述答案：复盘从受损用户结果和不变量出发，不从寻找个人责任开始。先用统一时间线拆检测、升级、决策、执行、技术恢复和业务恢复，给每个节点附原始证据；再区分触发因素、级联放大和潜在控制缺口。例如渠道慢是触发，立即重试和共享线程池是放大，未知态没有业务指标与查单容量是长期缺口。影响按业务意图、资金、库存、任务和关键设备对象复算，不能只报接口错误。行动项分为立即保护、短期工程和长期架构，每项必须写关联失效模式、负责人、截止日期、量化门槛、回滚和复验方式。不是“加强监控”，而是“支付未知最老年龄超过窗口时冻结渠道放量，并用超时演练证明查单在目标内闭环”；不是“增加容量”，而是“失去一个实例组后关键完成率和净消化仍满足保护线”。同时更新 SLI（服务等级指标）、SLO（服务等级目标）、错误预算动作、容量模型、RPO（恢复点目标）、RTO（恢复时间目标）、降级开关和供应商清单。无法立即解决的风险由业务责任人签署接受范围和到期日，不能藏在会议纪要。下一次演练按相同故障重放，若指标和业务不变量未通过，行动项保持开放。最终衡量不是工单关闭数，而是检测更快、影响更小、恢复可证且相同放大链不再出现。

例如将渠道慢定义为触发、立即重试定义为放大、缺少未知态目标定义为控制缺口，三层分别对应供应商隔离、重试矩阵和 SLI（服务等级指标）改造。行动项不写“加强监控”，而写最老未知超过十五分钟冻结渠道放量，并指定支付负责人和超时演练日期。

下一次演练记录检测从 12 分钟降到 4 分钟、业务差异清理从 40 分钟降到 15 分钟，同时验证无重复分录；任一项失败，工单保持开放。长期改造来不及时，先上线限流、人工清单和到期风险接受，不能用会议结束代替风险关闭。

• 追问 1：复盘需要找唯一根因吗？ 直答 1：不必强求，复杂事故通常有触发、放大和控制缺失，多层改进比编造单点根因更有效。

• 追问 2：行动项太多怎么排优先级？ 直答 2：按失败损失、再次发生概率、检测与止血收益、可逆性排序，先消除高风险放大链。

• 追问 3：如何防止复盘流于形式？ 直答 3：行动项进入发布或演练门禁，逾期风险公开，只有复验通过才能关闭。

• 详细章节：错误预算、恢复与复盘链路

3. 复习与验收清单

• 能在三至五分钟内按用户结果、止血、查证、恢复、验收和复盘讲完整事故。
• 能现场复算错误预算、Little’s Law（利特尔定律）、净消化率、恢复时间、单故障域余量和单位正确结果成本。
• 能区分技术成功与业务成功、技术恢复与业务恢复、复制与备份、拉取量与正确完成量。
• 能用 WMS（仓储管理系统）、支付、跨境物流、导出、Runner（执行器）和 IoT（物联网）分别说明领域不变量。
• 能为压测、混沌、扩缩容、降级和恢复设置停止条件，并说明证据等级与失效边界。
• 能沿 00–05 的详细章节回查每个结论，不把综合题答案变成孤立话术。