压测、恢复与混沌演练方法

适用边界：本册讨论如何用可复算实验验证容量、过载保护、故障隔离与恢复闭环。文中所有数字均为 E3（演练证据），只用于展示建模和判定方法，不代表任何生产流量、容量、故障时长、SLA（服务等级协议）或项目收益。真实结论必须绑定版本、环境、脚本、原始证据和业务验收。

正式时序图的 PlantUML（开源建模工具）源见 reliability-load-chaos-drill.puml。

学习地图

本册固定 12 个知识小节，每节包含表格、E3（演练证据）数字演绎、Mermaid（图表语法）图和 3 道六字段热门面试题。全册至少 12 张图，其中时序图不少于 8 张；读者应沿“证据边界、负载模型、压测分型、排队拐点、瓶颈定位、运行时预热、混沌控制、恢复回放、数据隔离、统计置信、项目排障、复习审计”完成独立学习。

1. 压测先声明目标、反目标与环境证据边界 {#53-04-k01}

压测目标不是追逐一个最大的吞吐数字，而是在指定版本、工作负载和故障假设下，找到同时满足业务正确性、延迟、资源水位、恢复时效与停止条件的可运行区间。反目标包括用测试环境数字冒充生产容量、为了成绩关闭校验、把错误或降级计入成功、越过停止线继续施压，以及只公布峰值不保存失败样本。生产、影子和离线环境提供的证据强度不同，结论只能外推到已经被实验覆盖的边界。

flowchart LR
    G[目标与业务不变量] --> E{环境选择}
    E -->|生产受控| P[真实依赖与故障域证据]
    E -->|影子流量| S[请求分布与读取路径证据]
    E -->|离线环境| O[可重复极限与故障注入证据]
    P --> B[记录版本 数据与爆炸半径]
    S --> B
    O --> B
    B --> D{证据是否支持外推}
    D -->|支持| C[形成带范围的结论]
    D -->|不支持| U[保留未知与残余风险]

图解读：三类环境分别提供真实性、低副作用观察和可控重复性，不能互相替代。任何结论都要经过版本、数据、依赖、故障域和业务不变量校验；缺少的生产因素必须列为未知，而不是通过换算系数藏起来。

数据演绎 1：环境折算不能替代证据

E3（演练证据）：离线环境有 4 个相同规格实例，在合成均匀键下以 800 请求/秒 运行 20 分钟并满足候选延迟；即使生产有 8 个实例，也不能直接声称容量是 800 ÷ 4 × 8 = 1600 请求/秒。若影子样本显示最热键占 18%，离线仅占 2%，且生产还共享数据库连接池，则线性条件已经不成立。可保留的结论是“单实例在该离线版本和均匀负载下完成 200 请求/秒”，生产边界仍为 E0（待核对）。

热门面试题

1. 问题：压测最重要的目标是什么？
   • 考点：可运行区间与业务正确性。
   • 回答思路：从版本、负载、成功、延迟、资源和恢复六个边界回答。
   • 详细答案：压测要证明指定条件下的安全运行区间和首个失败边界，包括有效吞吐、尾延迟、业务不变量、资源水位、过载动作与恢复能力。最高吞吐只是一处观测点，若错误、未知态、降级比例或历史积压不可接受，就不是可承诺容量。
   • 进阶追问：为什么还要定义反目标？
   • 进阶回答：反目标能约束团队不为追求成绩关闭校验、放大队列或越线施压，避免实验激励扭曲用户结果。
2. 问题：影子压测为什么不能证明支付写容量？
   • 考点：外部副作用与锁竞争缺失。
   • 回答思路：说明读取回放与真实写入的资源路径不同。
   • 详细答案：影子请求通常会拦截扣款、通知和账务写，因此没有真实事务锁、唯一约束、渠道配额、回调及未知态。它适合校准请求形状和读取成本，支付写容量仍需在受控账套、渠道沙箱或生产小爆炸半径下另行验证。
   • 进阶追问：影子结果还有什么价值？
   • 进阶回答：可用于发现参数分布、热点、序列化成本、缓存回源和代码版本差异，并为离线模型提供输入。
3. 问题：怎样避免把离线数字冒充生产成绩？
   • 考点：证据等级与外推边界。
   • 回答思路：给每个结论绑定事实卡。
   • 详细答案：报告必须记录环境、规格、版本、配置、数据规模、键分布、依赖替身、脚本、时间窗和原始结果，并明确未复现的生产因素。所有样例数字标成 E3（演练证据），只陈述该环境中直接观察到的事实，生产结论保持待核对。
   • 进阶追问：什么情况下可以增强结论？
   • 进阶回答：当生产小流量、真实业务审计和多次同版本实验与模型一致，并覆盖主要故障域后，才可在明确范围内增强证据。

2. 工作负载必须同时描述持续峰值、热点、长尾与数据基数 {#53-04-k02}

工作负载模型不是一条固定速率。它至少描述业务动作混合、到达过程、峰值持续时间、租户与键偏斜、请求和响应大小、长短任务比例、数据基数、状态命中、读写放大、重试与时间相关性。平均流量相同的两组请求，可能因为单热仓、超大订单、缓存冷键或高基数聚合产生完全不同的资源竞争。压测脚本应从业务意图生成尝试，并保持同一业务键的幂等关系，避免把随机请求器当作真实用户。

sequenceDiagram
    participant B as 业务样本
    participant M as 负载模型
    participant G as 流量生成器
    participant S as 被测系统
    participant V as 业务验证器
    B->>M: 动作混合 峰值持续 热点 长尾 基数
    M->>G: 到达计划与关联业务键
    G->>S: 按事件时间发起请求
    S-->>V: 响应 状态与副作用
    V->>V: 归并重试并校验不变量
    alt 分布与样本一致
        V-->>M: 接受本轮覆盖范围
    else 热点或长尾遗漏
        V-->>M: 修正模型后重跑
    end

图解读：业务样本先转成可声明的分布，再驱动请求并由独立验证器检查结果。正常路径接受有限覆盖，失败路径回到负载模型；关键是保留事件间关联，而不是只让每秒请求数相同。

数据演绎 2：相同均值会产生不同的局部压力

E3（演练证据）：候选入口均为 1000 请求/秒。均匀模型把请求分到 100 个仓，每仓约 10 请求/秒；热点模型让 1 个仓承载 20%，即 200 请求/秒，其余 99 个仓合计 800 请求/秒。若该仓写入需串行 8 毫秒，单键理论上限约 1 ÷ 0.008 = 125 次/秒，全局资源尚有余量时热点队列也会每秒新增约 75 个请求。结论是总吞吐均值不能发现键级不稳定。

热门面试题

1. 问题：一份完整工作负载模型至少包含什么？
   • 考点：速率、分布、关联和状态。
   • 回答思路：从动作混合、时间、键、大小、数据和副作用展开。
   • 详细答案：至少包含业务动作比例、开闭环到达方式、平均与峰值、峰值持续、热点键、长尾对象、数据基数、缓存状态、读写与重试放大、请求间关联及业务时效。每项都要有来源或明确假设，不能只给一个 QPS（每秒查询率）。
   • 进阶追问：为什么数据基数影响结果？
   • 进阶回答：小数据可能全部驻留缓存并选择理想索引，大基数会改变工作集、索引层级、扫描行数、磁盘读取和聚合内存。
2. 问题：热点压测为何不能只提高总流量？
   • 考点：局部串行资源。
   • 回答思路：区分全局容量与单键、单分片上限。
   • 详细答案：提高总流量但保持均匀分布，只会增加各分片相近的负担；真实热点会集中争抢同一锁、分区、缓存槽或账户余额。应固定热点占比和键生命周期，单独观察局部等待、冲突、拒绝和迁移能力。
   • 进阶追问：热点键是否应永远固定？
   • 进阶回答：既要测固定热点的持续竞争，也要测热点迁移造成的缓存冷却与路由变化，两者风险不同。
3. 问题：长尾请求占比很低，为什么仍要压测？
   • 考点：资源占用时间放大。
   • 回答思路：用占用量而非请求数解释。
   • 详细答案：少量大订单、慢查询或大消息可能长期占用线程、连接、堆和网络，并形成队首阻塞。它们按数量占比很低，却可能贡献大部分资源时间；模型应按大小和服务时间分桶，并验证隔离队列和并发上限。
   • 进阶追问：只看平均响应时间会怎样？
   • 进阶回答：平均值会被大量短请求稀释，必须同时看高分位、最长年龄、分桶吞吐和资源持有时间。

3. 六类压测各回答不同问题，开环与闭环必须协调 {#53-04-k03}

负载压测验证目标负载下是否满足要求；压力压测寻找非线性拐点和失败边界；浸泡压测验证长时间泄漏、热状态与累积副作用；尖峰压测验证突增、扩容延迟和保护；容量压测在业务约束下确定可运行区间；故障压测把资源或依赖失效叠加到负载。开环生成器按计划到达，能暴露系统跟不上时的排队；闭环生成器等待响应后再发下一次，适合用户会等待的会话，但系统变慢时会自动降速，容易产生协调遗漏。协调遗漏是生成器或统计方式漏掉本应到达却因阻塞未发出的请求，从而把过载延迟统计得过于乐观。

sequenceDiagram
    participant P as 到达计划
    participant O as 开环生成器
    participant C as 闭环生成器
    participant S as 被测系统
    participant R as 结果记录器
    P->>O: 每 10 毫秒计划一个到达
    O->>S: 到时即发并记录计划时间
    P->>C: 用户会话开始
    C->>S: 发出请求后等待响应
    S-->>C: 变慢后才允许下一次
    S-->>R: 开环响应与排队
    C-->>R: 闭环会话体验
    R->>R: 对比计划到达与实际发送
    alt 存在未发请求
        R-->>P: 报告协调遗漏和缺失量
    else 到达完整
        R-->>P: 接受统计窗口
    end

图解读：开环回答外部到达不因系统变慢而减少时会发生什么，闭环回答等待型用户的完成节奏。二者必须分别命名并对照计划到达；若只统计实际发出的闭环请求，系统越慢，样本反而越少。

数据演绎 3：闭环吞吐会在变慢时自动下降

E3（演练证据）：100 个闭环虚拟用户每次收到响应后等待 100 毫秒再发请求。响应为 100 毫秒时，候选吞吐约 100 ÷ (0.1 + 0.1) = 500 请求/秒；系统过载后响应升到 900 毫秒，生成器只会发约 100 ÷ (0.9 + 0.1) = 100 请求/秒。若真实外部事件仍以 500 请求/秒 到达，闭环报告会漏掉每秒约 400 个应到请求。应增加开环场景或按计划时间补偿统计，而不是宣称系统在 100 请求/秒下稳定。

热门面试题

1. 问题：负载、压力和容量压测有什么区别？
   • 考点：目标负载、失败边界和可运行区间。
   • 回答思路：分别回答“能否”“在哪里坏”“哪里可长期运行”。
   • 详细答案：负载压测在预定工作负载下验收指标；压力压测逐级施压，寻找吞吐不增、等待陡升或业务错误出现的拐点；容量压测综合延迟、正确性、资源、故障和恢复约束，给出低于极限的可运行区间。
   • 进阶追问：最高吞吐能否作为容量？
   • 进阶回答：不能，最高点常位于不可恢复或高错误区域，容量必须满足持续运行和单故障域余量。
2. 问题：什么是协调遗漏？
   • 考点：计划到达与实际发送差异。
   • 回答思路：解释系统变慢如何反向降低生成器压力。
   • 详细答案：当生成器因等待响应、线程阻塞或自身资源不足，未按原计划发出请求，只统计已发送样本就会漏掉本应等待的用户，尾延迟和过载程度被低估。应保存计划到达时间、生成器排队与未发数量，并用开环结果校验。
   • 进阶追问：闭环压测是否没有价值？
   • 进阶回答：有价值，它适合用户完成一次再发下一次的会话，但必须说明用户思考时间和并发，并且不能替代固定外部到达率场景。
3. 问题：故障压测为何必须叠加业务负载？
   • 考点：稳态与降级容量。
   • 回答思路：空闲时成功切换不代表高峰可承载。
   • 详细答案：无负载重启只能验证功能可用，无法验证连接重建、缓存回源、重试、积压和剩余实例承载。故障应在受控稳态负载下注入，观察用户结果、保护动作和恢复净消化率，同时受爆炸半径与停止条件约束。
   • 进阶追问：第一次故障实验应选高峰吗？
   • 进阶回答：不应，先在离线和低风险小流量证明注入、停止与回滚可靠，再逐步扩大负载和范围。

4. Little’s Law（利特尔定律）只能描述守恒窗口，拐点要看排队斜率 {#53-04-k04}

稳定边界内，Little’s Law（利特尔定律）为 L = lambda × W，其中 L 是平均在途量，lambda 是平均有效到达率，W 是平均停留时间。压测中必须统一入口与出口、事件时间和对象口径，把排队、执行及等待确认都纳入停留。定律不能把持续增长的积压解释成稳定并发，也不能直接把 P99（99 分位响应时间）代入声称平均在途。排队拐点通常表现为有效吞吐增幅变小、等待和在途斜率增大、资源首饱和、超时重试开始正反馈；应在业务红线前自动停止。

sequenceDiagram
    participant G as 开环生成器
    participant Q as 有界队列
    participant W as 工作线程
    participant D as 下游依赖
    participant M as 监测器
    G->>Q: 以 lambda 到达并记录事件时间
    Q->>W: 等待后获得服务单元
    W->>D: 执行业务调用
    D-->>W: 返回或超时
    W-->>M: 完成结果与服务时间
    Q-->>M: 等待时间和队列斜率
    alt 吞吐增幅收窄且等待陡升
        M-->>G: 停止升压并保全现场
    else 仍满足稳态条件
        M-->>G: 保持平台期继续观测
    end

图解读：记录器分别观测到达、等待、服务和完成，才能判断在途增长来自哪一段。正常路径保持平台期验证守恒，失败路径在非线性拐点触发停止；只看处理器使用率不足以判定。

数据演绎 4：用速率差识别队列拐点

E3（演练证据）：阶梯从 400 提到 500 请求/秒 时，有效完成率从 395 增到 485 请求/秒，每秒净积压约 15；升到 600 请求/秒 后，有效完成率仅 490 请求/秒，每秒净积压约 110。若平台保持 120 秒，理论新增积压约 110 × 120 = 13200 个。吞吐只增加 5，积压斜率却增加约 95，说明已经跨过排队拐点；此时继续加线程若下游完成率不变，只会扩大在途。

热门面试题

1. 问题：如何在压测里正确使用 Little’s Law（利特尔定律）？
   • 考点：守恒边界与平均量。
   • 回答思路：声明对象、窗口、入口、出口和稳定条件。
   • 详细答案：在到达与完成近似守恒、积压斜率接近零的窗口，用平均到达率乘平均端到端停留时间估算平均在途，并与队列、执行中和待确认状态求和交叉验证。持续积压时改用到达减完成的速率差，不把结果称为稳定容量。
   • 进阶追问：为什么不能直接用 P99（99 分位响应时间）？
   • 进阶回答：定律连接的是平均量；高分位可用于尾部保护和上界场景，但不能冒充平均停留时间。
2. 问题：怎样判断非线性排队拐点？
   • 考点：吞吐边际与等待斜率。
   • 回答思路：比较相邻阶梯的有效吞吐、等待、在途和错误。
   • 详细答案：当增加到达率后，有效吞吐增幅明显收窄，而排队等待、在途、最老年龄、超时或重试快速上升，就进入敏感或拐点区。还要找到最先变化的资源等待段，并排除生成器自身饱和。
   • 进阶追问：处理器没有满载为何也会拐？
   • 进阶回答：瓶颈可能是单热键、连接、数据库锁、磁盘、MQ（消息队列）分区或下游配额，平均处理器指标会掩盖局部串行点。
3. 问题：队列很长但错误率为零，能继续压吗？
   • 考点：延迟失败与业务时效。
   • 回答思路：队列只是延迟暴露失败。
   • 详细答案：不能仅凭零错误继续。若最老年龄、预计清空时间或用户时效已失守，排队中的请求实际已不可接受；大队列还会消耗内存并在恢复期制造压力，应按预先定义的等待和业务红线停止。
   • 进阶追问：队列上限如何确定？
   • 进阶回答：由最大可接受等待、峰值速率差、对象大小、恢复净消化率和业务优先级共同反推。

5. 瓶颈定位要沿客户端到下游逐层拆等待与服务 {#53-04-k05}

端到端变慢时，按客户端生成、网络入口、网关排队、应用线程、连接获取、数据库执行、缓存命中与回源、MQ（消息队列）生产消费、下游调用和业务确认逐层拆分。首个饱和点是时间线上最先出现服务时间或等待突变、且能解释后续级联的资源，不一定是利用率最高的资源。生成器、客户端端口、入口限流、日志输出也可能先饱和。每层同时记录到达、有效完成、等待、服务、在途、拒绝和重试，避免把后果当根因。

sequenceDiagram
    participant C as 客户端
    participant I as 入口网关
    participant T as 应用线程池
    participant P as 连接池
    participant D as 数据库与缓存
    participant Q as MQ
    participant X as 外部下游
    C->>I: 请求与计划到达时间
    I->>T: 入口等待后转发
    T->>P: 获取数据库连接
    P->>D: 查询 写入或缓存回源
    D-->>T: 结果与锁等待
    T->>Q: 发布异步事件
    T->>X: 调用受配额依赖
    X-->>T: 返回 明确失败或未知
    T-->>C: 用户结果
    Note over C,X: 每段记录等待 服务 在途 拒绝与重试

图解读：一条用户路径可能同时经过同步和异步资源。诊断时按时间线找最早异常段，再用上下游速率和业务键验证因果；例如数据库变慢先增加连接持有，线程池排队和客户端重试随后出现，不能反过来把线程池视为首因。

数据演绎 5：连接等待会把数据库变慢放大成线程耗尽

E3（演练证据）：应用有 80 个线程、30 个数据库连接，候选数据库持有时间从 40 毫秒升到 200 毫秒。连接理论完成能力从 30 ÷ 0.04 = 750 次/秒 降为 30 ÷ 0.2 = 150 次/秒；入口仍为 300 请求/秒 时，每秒至少新增约 150 个等待。线程随后阻塞在连接池，活跃线程达到 80，但首因是数据库服务时间改变。把连接扩到 60 只能把候选压力推到 60 ÷ 0.2 = 300 次/秒，若数据库本身已饱和，延迟还会恶化。

热门面试题

1. 问题：容量事故中如何找首个饱和点？
   • 考点：时间线与等待链。
   • 回答思路：先定界，再逐段比较最早变化。
   • 详细答案：先固定版本、流量和受影响路径，对齐客户端到达、入口、线程、连接、数据库、缓存、MQ（消息队列）和下游时间线。找到最先出现等待或服务时间突变、且能解释后续在途和重试的层，再用链路、资源指标和业务键验证。
   • 进阶追问：为什么不能先看使用率最高的资源？
   • 进阶回答：后续资源可能因排队或重试被动升高，平均使用率也可能掩盖单锁、单分片和配额瓶颈。
2. 问题：连接池耗尽是否应该直接加连接？
   • 考点：瓶颈转移。
   • 回答思路：先分解连接等待和持有时间。
   • 详细答案：若连接持有变长来自慢查询、锁或数据库饱和，加连接会增加并发冲击；只有数据库仍有余量且池配置确实过小时才调整。止血通常先限入口、暂停低优先级、缩短无效事务并治理慢路径。
   • 进阶追问：如何证明数据库仍有余量？
   • 进阶回答：结合执行与锁等待、磁盘、日志写、处理器、连接活跃和增加并发后的有效吞吐边际判断。
3. 问题：MQ（消息队列）总积压不高，为什么仍可能有故障？
   • 考点：分区热点与最老年龄。
   • 回答思路：总量不能代表键级时效。
   • 详细答案：单分区、单租户或单顺序键可能因慢消息停滞，而其他分区快速消费使总积压看似正常。应看每分区生产消费速率、最老年龄、未确认、重试和死信，并用业务清单检查关键对象是否完成。
   • 进阶追问：扩消费者一定有效吗？
   • 进阶回答：受分区数、顺序约束和下游能力限制；若瓶颈是单键或外部配额，扩消费者不会提高有效吞吐。

6. 预热必须拆分缓存、连接、JIT（即时编译）与 GC（垃圾回收）阶段 {#53-04-k06}

冷启动数据不能直接作为稳定容量，稳定数据也不能掩盖发布后的冷启动风险。预热至少拆成实例拉起、类与配置加载、连接建立、JIT（即时编译）编译、缓存填充、热点数据进入内存、GC（垃圾回收）进入周期稳态和自动扩容新实例接流。需要同时保留冷态、预热过程和热稳态结果，并用业务请求覆盖主要代码路径。盲目用全量生产键预热会制造数据库尖峰、数据泄露或缓存污染，预热本身也必须限速、有失效策略和停止条件。

sequenceDiagram
    participant D as 发布系统
    participant A as 新实例
    participant J as JIT运行时
    participant C as 缓存与连接
    participant G as GC监测
    participant R as 流量路由
    D->>A: 启动指定版本与配置
    A->>C: 建立受限连接并加载小热集
    A->>J: 执行代表性代码路径
    J-->>A: 编译热点方法
    A->>G: 产生受控分配并观察回收
    G-->>A: 堆回落与停顿进入稳态
    alt 预热门槛通过
        A-->>R: 小批接流后渐进放量
    else 数据库或回收水位异常
        A-->>D: 停止接流并保全证据
    end

图解读：预热不是固定等待若干秒，而是连接、代码、缓存与内存状态依次达到可验收门槛。正常路径小批接流，失败路径停止晋级；每次扩容都要避免所有新实例同时回源形成二次尖峰。

数据演绎 6：同时扩容会把预热变成回源尖峰

E3（演练证据）：候选扩容 20 个新实例，每个实例预热 5000 个热键，若 10 秒内同时加载，总回源率为 20 × 5000 ÷ 10 = 10000 查询/秒。改为每批 2 个实例、每批 20 秒，单批回源约 2 × 5000 ÷ 20 = 500 查询/秒，但完整预热需约 200 秒且仍要叠加前台流量。该演绎只展示批次对尖峰的影响；真实批次由数据库余量、缓存价值和扩容时效验证，不能照抄。

热门面试题

1. 问题：为什么压测必须区分冷态和热稳态？
   • 考点：发布风险与持续容量。
   • 回答思路：冷态验证启动，热态验证长期运行。
   • 详细答案：冷态包含建连、缓存回源、JIT（即时编译）和初始分配，能暴露发布与扩容风险；热稳态反映主要路径编译、缓存稳定和 GC（垃圾回收）周期后的持续能力。只报热态会漏掉上线尖峰，只报冷态又会低估稳定容量。
   • 进阶追问：预热完成由时间判断吗？
   • 进阶回答：不只看时间，应由连接、缓存、编译活动、延迟、分配率和回收后占用等门槛共同判断。
2. 问题：缓存预热为什么可能压垮数据库？
   • 考点：并发回源放大。
   • 回答思路：实例数乘热键数会形成新负载。
   • 详细答案：多个新实例若同时加载相同或不同热键，会在前台流量之外制造集中查询，还可能争抢连接和磁盘。应按批次、速率和键优先级预热，使用单飞或共享结果，并在数据库保护线前停止。
   • 进阶追问：是否应预热全部数据？
   • 进阶回答：通常不应，只覆盖有证据的热集和关键代码路径；全量加载成本高，还会污染缓存并扩大数据治理风险。
3. 问题：短时间压测为什么容易漏掉 GC（垃圾回收）问题？
   • 考点：堆周期与长期累积。
   • 回答思路：初始余量会延后暴露回收压力。
   • 详细答案：短测可能只看到堆持续增长，尚未经历足够回收周期，也看不到长期存活对象、直接内存、线程本地引用和日志缓冲累积。浸泡阶段要观察多轮停顿、分配率、晋升、回收后基线及容器总内存。
   • 进阶追问：堆能回落就能证明无泄漏吗？
   • 进阶回答：不能，还要比较多轮回收后的基线是否上移，并检查堆外、线程、文件句柄和任务积压等非堆资源。

7. 混沌工程以稳态假设、爆炸半径、停止条件和可逆注入为合同 {#53-04-k07}

混沌工程不是随机破坏，而是用受控实验反驳一个可观测的稳态假设。实验前写清用户路径、业务不变量、正常波动区间、故障机制、注入对象、爆炸半径、停止条件、恢复动作、责任人和禁止时段。故障注入应尽量贴近真实机制，例如延迟、丢包、连接拒绝、进程终止、磁盘余量下降、配额收紧或时钟偏差；单纯改监控数值只能验证告警逻辑。首次实验从离线和最小故障域开始，只有停止与恢复被证明可靠，才逐级扩大。

sequenceDiagram
    participant O as 实验负责人
    participant M as 稳态监测器
    participant F as 故障注入器
    participant S as 被测系统
    participant B as 业务验证器
    O->>M: 登记稳态假设与停止条件
    M->>S: 采集用户结果和资源基线
    B->>S: 校验业务不变量
    O->>F: 授权最小爆炸半径
    F->>S: 注入指定故障机制
    S-->>M: 延迟 错误 积压与降级信号
    B-->>M: 资金 库存或事件差异
    alt 任一停止条件触发
        M-->>F: 自动撤销注入
        M-->>O: 冻结放量并保全现场
    else 稳态假设仍成立
        M-->>O: 保持至预定观察窗
    end

图解读：注入器只负责制造已声明故障，独立监测器和业务验证器决定继续或停止。停止条件优先级高于实验完整性；撤销注入后仍需验证恢复，不能把“故障已关”当成系统已恢复。

数据演绎 7：爆炸半径用最坏坏事件上限约束

E3（演练证据）：候选入口为 600 请求/秒，首次实验只覆盖 1% 流量并最多持续 30 秒，若注入路径全部失败，理论受影响尝试上限为 600 × 1% × 30 = 180。若每个业务意图平均有 1.2 次尝试，按业务键归并后的受影响意图不应直接按 180 计算，需由独立账本去重。该上限仍不代表可接受损失；支付重复扣款等业务红线可要求第一笔即停止。

热门面试题

1. 问题：混沌工程和随机杀进程有什么区别？
   • 考点：可证伪假设与实验合同。
   • 回答思路：从假设、范围、停止、恢复和证据回答。
   • 详细答案：混沌实验先定义稳态假设和真实故障机制，再以有限爆炸半径注入，独立观察用户结果与业务不变量，达到停止条件立即撤销，并完成恢复验收。随机杀进程若没有这些合同，只是不可解释的破坏。
   • 进阶追问：杀进程是否完全无价值？
   • 进阶回答：它可作为进程故障机制，但只能证明该对象与范围下的拉起、路由和恢复，不能代表网络、区域或数据损坏。
2. 问题：稳态假设应该怎么写？
   • 考点：用户结果与可观测区间。
   • 回答思路：写成可被数据反驳的陈述。
   • 详细答案：稳态假设要指定用户路径、观察窗、正常波动、业务不变量和数据完整度，例如核心库存写在单实例失效时仍保持唯一扣减，未知态不持续增加。不能只写处理器正常或服务可用。
   • 进阶追问：没有生产基线怎么办？
   • 进阶回答：先以 E3（演练证据）候选区间影子观察，保守设置停止线，并保持生产结论待核对。
3. 问题：停止条件为什么必须自动化？
   • 考点：检测与人工反应延迟。
   • 回答思路：实验风险按持续时间累积。
   • 详细答案：故障可能在人工看板和沟通期间持续制造坏事件，观测失明时人工还可能误判。自动停止应直接读取业务红线、资源保护线、数据质量和实验超时，并具备独立权限撤销注入。
   • 进阶追问：自动停止失效怎么办？
   • 进阶回答：还要有注入超时保险、人工紧急撤销、入口隔离和实验前演练过的回退命令，且不能与注入器共享单点故障。

8. 恢复要计算净消化率，并闭环回放、未知态与业务不变量 {#53-04-k08}

停止故障只表示破坏源被移除，不代表恢复完成。恢复同时面对新流量、历史积压、重试回放、结果未知和外部依赖限额。净消化率等于安全有效完成率减当前新到达率；只有持续为正，积压才会下降，预计清空时间才有意义。回放必须保留原业务键、原事件顺序要求、规则版本和副作用状态，先查证未知态再决定重做。验收分为新流量正常、历史对象闭环、未知态收敛、业务不变量通过、观测完整和恢复后稳定观察六层。

sequenceDiagram
    participant I as 新流量入口
    participant Q as 历史积压
    participant R as 恢复调度器
    participant S as 业务服务
    participant X as 外部依赖
    participant A as 审计账本
    I->>S: 受保护的新业务意图
    Q->>R: 按优先级提供历史对象
    R->>A: 查询原业务键与未知状态
    alt 已确认产生副作用
        A-->>R: 标记完成或进入差异处理
    else 可安全回放
        R->>S: 用原业务键受控重放
        S->>X: 调用并遵守配额
        X-->>A: 回执或新的未知态
    end
    A->>A: 校验业务不变量与差异
    alt 净消化为正且差异收敛
        A-->>R: 渐进提高恢复并发
    else 新流量或下游受损
        A-->>R: 降低回放并保留现场
    end

图解读：恢复调度器不能绕过审计账本直接重发。新流量优先级、历史回放和外部配额共同决定安全完成率；任何未知或不变量差异都必须有明确归宿。

数据演绎 8：恢复时间由净消化率而非总吞吐决定

E3（演练证据）：事故积压 72000 条，恢复期安全有效完成率为 500 条/秒，新到达持续 380 条/秒，净消化率只有 500 - 380 = 120 条/秒，理想清空时间为 72000 ÷ 120 = 600 秒。若回放使下游变慢，有效完成降至 400 条/秒，净消化仅 20 条/秒，时间变为 3600 秒；若新到达超过 400，积压反而增长。估算还要扣除未知态查证和不可并行对象。

热门面试题

1. 问题：什么是恢复净消化率？
   • 考点：历史吞吐与新流量竞争。
   • 回答思路：用安全有效完成减新到达。
   • 详细答案：恢复净消化率是系统在不伤害新流量和下游的前提下，每秒有效完成总量减去每秒新增工作量。只有它持续为正，历史积压才会下降；总消费率很高但几乎都在处理新流量时，恢复仍可能停滞。
   • 进阶追问：为何强调有效完成？
   • 进阶回答：拉取、重试或技术返回成功不等于业务完成，必须扣除重复、失败、未知和违反不变量的结果。
2. 问题：外部调用超时后为什么不能直接回放？
   • 考点：未知态和重复副作用。
   • 回答思路：超时只证明未收到响应。
   • 详细答案：支付扣款、仓单创建或通知可能已在下游提交，只是响应丢失。直接换键重做会造成重复；应持原业务键查单、核对回执和账务，明确未执行后才受控回放，无法确定则进入隔离人工。
   • 进阶追问：没有查单接口怎么办？
   • 进阶回答：降低自动重试，用渠道账单、回调、审计日志或人工核验建立替代确认路径，并推动补齐查询能力。
3. 问题：队列清零是否代表恢复完成？
   • 考点：技术积压与业务结果差异。
   • 回答思路：队列只是一个中间状态。
   • 详细答案：消息可能被丢弃、转死信、错误确认或产生未知副作用，队列清零不能证明业务正确。还要核对事故窗口权威对象、新流量结果、最老未知、资金库存不变量、任务产物和观测完整度。
   • 进阶追问：什么时候可以关闭事故？
   • 进阶回答：新流量稳定、历史对象闭环、未知收敛、不变量通过、观测可信且经过恢复观察窗后才关闭。

9. 压测数据必须可识别、可清理，并隔离所有外部副作用 {#53-04-k09}

压测数据治理覆盖来源、脱敏、生成、标识、权限、生命周期、清理和审计。生产样本只能在批准范围内最小化提取并不可逆脱敏，合成数据要保持关联、基数、热点和状态分布。每个测试业务键带独立命名空间和实验标识，数据库、缓存、MQ（消息队列）、对象存储、搜索索引及审计链都能追踪。外部支付、物流下单、短信、邮件、库存占用和设备控制必须通过沙箱、替身、拒绝列表或双重门禁隔离；仅在请求头加测试标记不足以防旁路消费者和历史回放。

sequenceDiagram
    participant G as 数据生成器
    participant I as 测试命名空间
    participant S as 被测服务
    participant E as 副作用网关
    participant X as 外部系统
    participant A as 清理审计器
    G->>I: 创建带实验标识的业务对象
    I->>S: 发起读写与异步事件
    S->>E: 请求支付 物流 通知或设备动作
    alt 沙箱或替身允许
        E-->>S: 返回可控结果与回执
    else 真实副作用路径
        E-->>S: 拒绝并触发停止条件
    end
    S-->>A: 写入数据库 缓存 消息和对象清单
    A->>A: 按实验标识核对残留
    A-->>I: 受控清理并保留审计摘要

图解读：隔离必须位于副作用出口，而不是只依赖上游自觉。清理审计器先盘点再删除，防止清理脚本跨实验或跨租户；需要保留的原始证据按权限和期限单独归档。

数据演绎 9：小比例漏拦截也会形成大量副作用

E3（演练证据）：候选压测 15 分钟、400 请求/秒，其中 5% 路径会发通知，总通知尝试为 15 × 60 × 400 × 5% = 18000。若出口门禁漏拦截 0.1%，理论仍可能产生 18 次真实通知。对扣款或设备控制而言，18 次也不可接受，因此隔离验收应以真实账号和渠道账单零副作用为目标，而不是只看拦截率接近百分之百。

热门面试题

1. 问题：为什么仅给压测请求加标记不够？
   • 考点：异步传播与旁路出口。
   • 回答思路：标记可能在跨服务和回放时丢失。
   • 详细答案：请求经过数据库、消息、定时任务和历史回放后，头部标记可能未持久化，旁路消费者也可能不识别。应把实验标识写入业务对象和事件合同，并在支付、物流、通知和设备控制出口设置独立强制门禁。
   • 进阶追问：出口门禁如何防误配？
   • 进阶回答：默认拒绝测试命名空间访问真实账号，配置需双人审批，压测前用探针验证拒绝路径并把漏放设为停止条件。
2. 问题：压测数据清理为什么不能直接按时间删除？
   • 考点：事件时间、迟到和生产混入。
   • 回答思路：时间窗不能唯一识别实验对象。
   • 详细答案：同一时间存在真实业务，异步事件还可能迟到，按时间范围删除容易误伤生产或漏掉残留。应使用实验命名空间、批次和权威对象清单，先核对数据库、缓存、消息、对象和索引，再按依赖顺序受控清理。
   • 进阶追问：清理后还保留什么？
   • 进阶回答：保留去敏后的实验元数据、数量摘要、版本、时间线、结果和清理证明，原始敏感数据按最短期限销毁。
3. 问题：合成数据怎样避免过于理想？
   • 考点：关联、偏斜和坏数据边界。
   • 回答思路：从真实分布提取结构而非复制敏感值。
   • 详细答案：合成器要保留订单行数、租户和仓热点、状态比例、键基数、消息大小、长尾对象、重复与迟到等统计特征，并构造边界和异常样本。分布来源、脱敏方法和未覆盖因素必须写入报告。
   • 进阶追问：可以直接复制生产库吗？
   • 进阶回答：不能默认复制，必须经过授权、最小化和不可逆脱敏；许多场景应使用统计驱动的合成数据替代。

10. 结论必须带重复实验、置信区间、版本基线与失效条件 {#53-04-k10}

单次压测只能证明一次观测，不能区分稳定能力、环境噪声和偶然幸运。每个场景先冻结制品、配置、规格、数据快照、脚本和依赖版本，随机化或轮换实验顺序，至少重复多轮并保存每轮原始分布。对吞吐、错误比例和延迟分别报告样本量、中心位置、离散程度和置信区间；尾延迟不能只用平均数，时间相关样本也不能假装完全独立。版本比较优先使用同环境交错实验和效应区间，若区间跨过无差异或业务门槛，就报告证据不足。任何代码、配置、数据基数、依赖或硬件变化都可能使基线失效。

flowchart TD
    F[冻结版本 配置 数据与脚本] --> R1[基线轮次一]
    F --> C1[候选轮次一]
    R1 --> X[交错重复多轮]
    C1 --> X
    X --> Q[检查生成器 数据质量与异常轮次]
    Q --> S[计算分布 差值与置信区间]
    S --> D{区间是否越过业务门槛}
    D -->|否| A[形成限定版本结论]
    D -->|是| U[报告证据不足或实际退化]
    A --> T[登记基线失效条件]

图解读：基线和候选交错运行可降低时间漂移影响，异常轮次只能按事前规则处理。统计显著不等于业务重要，业务门槛也不能代替置信程度；两者需同时报告。

数据演绎 10：均值差异可能小于轮次噪声

E3（演练证据）：同一场景基线 5 轮有效吞吐为 480、505、492、510、488 请求/秒，候选 5 轮为 500、508、497、515、506 请求/秒。两组均值约为 495 与 505，表面提升约 2%，但单轮波动范围分别达到 30 和 18。没有交错顺序、离散度和差值置信区间时，不能宣称候选稳定提升；应报告原始轮次并继续重复，且同时核对延迟与业务错误是否变差。

热门面试题

1. 问题：为什么压测结果要重复多轮？
   • 考点：随机波动与可重复性。
   • 回答思路：单轮无法估计结果分布。
   • 详细答案：共享环境噪声、缓存状态、JIT（即时编译）、GC（垃圾回收）、数据热点和依赖波动都会改变单轮结果。重复并交错基线与候选，才能估计中心、离散和差值区间，识别偶然最好成绩。
   • 进阶追问：重复三轮一定够吗？
   • 进阶回答：没有固定万能轮数，应根据波动、效应大小、风险和样本独立性决定；证据不足就继续实验或降低结论强度。
2. 问题：置信区间在压测报告里解决什么问题？
   • 考点：估计不确定性。
   • 回答思路：区间表达与数据相容的效果范围。
   • 详细答案：它帮助判断观测差异是否可能来自样本波动，并展示效果可能落入的范围。报告还要结合业务门槛；即使差异统计上清晰，若收益很小或以错误、成本和恢复退化为代价，也不应晋级。
   • 进阶追问：样本很多就一定可信？
   • 进阶回答：不一定，同一时间段请求高度相关、生成器协调遗漏或数据口径错误会让大量样本形成虚假精度。
3. 问题：哪些变化会让版本基线失效？
   • 考点：比较边界。
   • 回答思路：列出任何改变工作或资源映射的因素。
   • 详细答案：代码、配置、运行时、实例规格、数据库版本与统计信息、索引、数据基数、键分布、缓存策略、消息分区、依赖配额和压测脚本变化都可能使旧基线不可比。报告要登记触发重测的失效条件。
   • 进阶追问：硬件不同能按处理器核数折算吗？
   • 进阶回答：只能作为候选模型，数据库、内存、网络和串行瓶颈未必线性，必须用同场景实验校准。

11. WMS（仓储管理系统）与支付项目要用不变量驱动压测和排障话术 {#53-04-k11}

WMS（仓储管理系统）库存压测围绕订单意图、预占、释放、扣减、仓与商品热点、波次峰值和防超卖不变量；支付压测围绕支付意图、渠道调用、回调、查单、账务分录、幂等和资金未知态。项目话术必须先说业务风险，再说工作负载和证据边界，然后讲阶梯、故障、停止、恢复与对账。排障时先保护资金和库存，冻结高风险变更，按业务键确认影响对象；技术错误回落后仍要处理事故窗口的未知支付、长期预占、重复回调和账实差异。

sequenceDiagram
    participant O as 订单入口
    participant W as WMS库存服务
    participant P as 支付服务
    participant X as 支付渠道
    participant A as 业务审计
    O->>W: 创建订单并按仓商品预占
    W-->>A: 记录预占版本与库存流水
    O->>P: 创建支付意图与幂等键
    P->>X: 发起扣款
    X-->>P: 成功 失败或超时未知
    alt 支付明确成功
        P->>W: 用原订单键确认扣减
        W-->>A: 校验可售非负与唯一扣减
    else 支付未知
        P->>X: 按原意图查单
        P-->>A: 保持未知并禁止换键重扣
    end
    A->>A: 对账支付 库存 订单与回调

图解读：库存和支付各有权威流水，通过订单和支付意图关联。任何超时先进入未知态，不能用技术重试覆盖；演练验收以唯一扣款、库存守恒和全部未知有结论为准。

数据演绎 11：库存热点和支付未知必须分开计数

E3（演练证据）：候选波次包含 12000 个订单行，计划 10 分钟完成，平均需 20 行/秒；若热商品占 30%，该商品约 6 行/秒，不能用全库平均判断单键锁能力。支付侧有 3000 个意图，其中 2% 在注入超时后进入未知，即 60 个待查证对象；即使接口重试后全部返回成功，也不能把 60 个未知从分母删除，必须按原意图逐笔查单并对账。

热门面试题

1. 问题：怎样讲一次 WMS（仓储管理系统）库存压测方案？
   • 考点：业务负载、不变量和恢复。
   • 回答思路：按风险、模型、执行、停止和验收组织。
   • 详细答案：先定义订单行、热仓热商品、波次持续和重试模型，以可售量非负、唯一预占扣减、释放闭环为红线。执行负载、热点、尖峰、浸泡和单节点或数据库变慢场景，逐层看锁、连接、消息与最老年龄；恢复按订单行清单对账。
   • 进阶追问：如何避免虚构项目数字？
   • 进阶回答：只讲已核对事实，样例计算统一标 E3（演练证据），生产峰值、收益和事故时长保持待核对。
2. 问题：支付压测遇到渠道超时如何处置？
   • 考点：资金未知态。
   • 回答思路：先停止放大，再按原意图查证。
   • 详细答案：触发停止条件后冻结新故障注入和自动重试，保留支付意图、渠道请求、回调与时间线；使用原幂等键查单，对明确成功入账，对明确失败按策略处理，无法确定的隔离人工，禁止换键重扣。
   • 进阶追问：接口成功率恢复后能否结束？
   • 进阶回答：不能，还要确认事故窗口未知归零或有责任单、渠道账单与账务分录一致且无重复扣款。
3. 问题：线上出现库存接口慢和支付重试同时上升，先查什么？
   • 考点：影响定界与级联关系。
   • 回答思路：先保护不变量，再对齐时间线找首因。
   • 详细答案：先暂停高风险重试和低优先级波次，按订单和支付意图圈定对象；比较入口、库存锁与连接、支付渠道耗时、线程等待和消息积压的首次变化。支付等待可能占满共享线程拖慢库存，也可能库存事务阻塞延长下单导致客户端重试，需用链路和业务账本验证。
   • 进阶追问：是否立即扩线程池？
   • 进阶回答：不立即扩，先确认首个等待段和下游余量，否则会扩大锁竞争与渠道冲击。

12. Runner（执行器）与 IoT（物联网）演练要覆盖积压、回放和报警风暴 {#53-04-k12}

Runner（执行器）容量不能只按任务数，要按任务工作量、租约、分片、优先级、检查点和下游配额建模；IoT（物联网）报警风暴要区分设备事件、规则命中、聚合、通知和人工确认。故障压测叠加执行器宕机、租约过期、消息重复、单分区热点、通知限额和观测缺样，验证任务不并发越权、检查点可续跑、关键报警不被普通风暴淹没。排障按到达、有效完成、最老年龄、工作量和业务清单定位，恢复先关键后普通，控制回放速率并核对产物摘要、设备覆盖与通知回执。

sequenceDiagram
    participant Q as 任务与事件队列
    participant R as Runner执行器
    participant C as 检查点与租约
    participant D as 下游与通知渠道
    participant A as 业务验收
    Q->>R: 分配任务或设备事件
    R->>C: 获取带任期的租约
    R->>D: 执行分片或发送关键通知
    D-->>R: 回执 限流或未知
    R->>C: 提交检查点和结果摘要
    alt 执行器故障或租约过期
        C-->>Q: 从可信检查点重新排队
        Q->>R: 新任期受控回放
    else 任务完成
        C-->>A: 交付产物与事件链
    end
    A->>A: 核对唯一提交 设备覆盖和回执

图解读：租约任期防止旧 Runner（执行器）恢复后覆盖新结果，检查点减少全量重做。IoT（物联网）通知限流时，关键事件仍需独立队列和逐设备责任；队列清空不代表漏报已经补齐。

数据演绎 12：任务数相同不代表恢复工作量相同

E3（演练证据）：积压 1000 个 Runner（执行器）任务，其中 900 个各需 1 个工作单位，100 个各需 50 个工作单位，总剩余工作量为 900 × 1 + 100 × 50 = 5900，大任务只占 10% 数量却占约 84.7% 工作量。若安全处理能力为 100 工作单位/秒，新任务持续 40 工作单位/秒，理想净消化为 60，清空约需 5900 ÷ 60 ≈ 98.3 秒；按 1000 个任务数平均会严重误判。

热门面试题

1. 问题：Runner（执行器）宕机后如何避免任务重复提交？
   • 考点：租约任期、幂等和检查点。
   • 回答思路：执行可以重复，权威提交必须受控。
   • 详细答案：调度器发放带任期的租约，Runner（执行器）按稳定任务键和分片写检查点，结果提交校验当前任期与幂等键。旧实例恢复后即使继续计算，也不能覆盖新任期结果；外部副作用还要查证或使用确定性对象键。
   • 进阶追问：只用分布式锁够吗？
   • 进阶回答：不够，旧持有者可能在网络分区后继续运行，需要数据层任期栅栏和幂等提交共同约束。
2. 问题：IoT（物联网）报警风暴如何压测又不丢关键报警？
   • 考点：分级、聚合、限流与审计。
   • 回答思路：普通重复可聚合，关键事件要保留逐设备责任。
   • 详细答案：模型包含设备基数、区域相关性、严重度变化和通知配额，注入重复、突增和渠道限流。普通同根因事件可按规则聚合，关键报警进入独立优先队列并保留原始事件、规则版本、通知和确认回执，停止条件看关键漏报而非总吞吐。
   • 进阶追问：没有新报警是否代表恢复？
   • 进阶回答：不代表，可能是采集断开或规则错误抑制，必须对照应到设备清单、采集水位和合成探测。
3. 问题：异步任务积压线上排障怎么讲？
   • 考点：工作量、首瓶颈和恢复验收。
   • 回答思路：从速率差、最老年龄、任务分桶走到下游。
   • 详细答案：先按任务类型、租户和版本比较到达、有效完成、剩余工作量与最老年龄，再查 Runner（执行器）租约、线程、检查点、数据库、对象存储和下游配额，定位最先变慢段。止血暂停低优先级和无效重试，恢复按原键回放并核对产物和副作用。
   • 进阶追问：扩 Runner（执行器）数量一定有效吗？
   • 进阶回答：不一定，任务可能受单分片、数据库、存储或外部配额限制，扩执行器只会增加竞争。

线上排障闭环

1. 保护用户：资金重复、库存超卖、关键漏报等业务红线出现时，立即停止压测或故障注入，冻结高风险变更，限制入口、重试与回放；不等待全部根因证据齐全。
2. 固定现场：保存版本、配置、脚本、计划到达、实际发送、原始指标、链路、日志、业务键、实验时间线和停止原因；观测缺失本身按风险处理。
3. 影响定界：按用户路径、租户、仓、商品、支付渠道、任务类型、设备区域和版本切片，区分明确失败、未知、迟到和未到达。
4. 定位首因：沿客户端、入口、线程、连接、数据库、缓存、MQ（消息队列）、下游逐层比较到达、有效完成、等待、服务与在途的首次变化。
5. 恢复验收：新流量正确只是第一层，还要计算恢复净消化率，按权威清单处理历史积压与未知态，并核对业务不变量和观测完整度。
6. 回填模型：把真实工作负载、首个拐点、失败机制、停止动作、恢复时间和残余风险写回基线、门禁、运行手册与下一次演练。

项目话术模板

我先从业务风险和证据边界讲，而不是先报吞吐数字。WMS（仓储管理系统）重点保护库存守恒和唯一扣减，支付重点保护资金唯一性与未知态，Runner（执行器）重点保护租约任期、检查点和唯一提交，IoT（物联网）重点保护关键事件覆盖与通知回执。工作负载同时描述峰值持续、热点、长尾、数据基数和重试；执行按基线、阶梯、平台、故障、自动停止、恢复回放和业务验收推进。定位时找首个等待或服务突变，恢复时用净消化率和权威清单，而不是只看错误率或队列清零。所有样例数字均为 E3（演练证据），生产容量和收益只在有直接证据时陈述。

复习清单与数量自检

• 能说清压测目标、反目标以及生产、影子、离线环境各自能证明和不能证明什么。
• 能建立包含峰值持续、热点、长尾、数据基数、动作混合和重试关联的工作负载模型。
• 能区分负载、压力、浸泡、尖峰、容量、故障六类压测，并解释开环、闭环与协调遗漏。
• 能正确使用 Little’s Law（利特尔定律），通过吞吐边际与排队斜率识别非线性拐点。
• 能沿客户端、入口、线程、连接、数据库、缓存、MQ（消息队列）和下游定位首个饱和点。
• 能拆分缓存、连接、JIT（即时编译）和 GC（垃圾回收）预热，并同时报告冷态与热稳态。
• 能写出混沌实验的稳态假设、爆炸半径、停止条件、故障机制、撤销和恢复合同。
• 能计算恢复净消化率，处理回放与未知态，并用资金、库存、任务和报警不变量验收。
• 能治理压测数据全生命周期，并在副作用出口阻断真实扣款、物流、通知和设备控制。
• 能用重复实验、置信区间和版本基线表达不确定性，不选择最好一轮冒充稳定结论。
• 能完整复述 WMS（仓储管理系统）、支付、Runner（执行器）、IoT（物联网）的演练与排障方案。
• 数量自检：知识 ### 恰好 12 个，知识标记恰好 12 个，每节表格不少于 1、E3（演练证据）数字演绎不少于 1、Mermaid（图表语法）图不少于 1、六字段题恰好 3 道；全册 Mermaid（图表语法）图恰好 12 张，其中时序图恰好 10 张；综合题恰好 20 道，每题一个 560–800 有效字符口述答案和 4 组追问直答。

综合题使用说明

综合题用于 3–5 分钟项目复述和连续追问。建议先按“业务风险与证据边界、工作负载、实验阶段、停止条件、首瓶颈、恢复与业务验收、残余风险”完整口述，再用追问直答校验概念边界。答案中的数字均为 E3（演练证据），不应替换为未经核对的生产成绩。

综合题库

1. 问题：如何从零设计一套可信的压测、恢复与混沌演练计划？

   口述答案：我先把压测从“打多少流量”改成一份可证伪合同。第一步确定业务路径和不变量，例如库存不能超卖、支付不能重复扣款、任务不能重复提交、关键报警不能漏；同时声明环境是生产受控、影子还是离线，哪些结论只能作为 E3（演练证据）。第二步从真实或经批准的统计样本建立工作负载，包含动作混合、峰值持续、热点、长尾、数据基数、重试和外部配额，冻结版本、配置、规格、脚本与数据快照。

   执行按基线、阶梯升压、峰值平台、浸泡、尖峰和故障叠加推进。开环用于验证外部到达不随系统变慢而下降，闭环用于会话体验，两者都记录计划到达以识别协调遗漏。每个阶段同时看有效吞吐、等待、服务、在途、最老年龄、业务错误和观测完整度，达到资金库存红线、资源保护线、排队拐点或观测失明时自动停止，保全时间线与失败对象。

   故障注入前写稳态假设、爆炸半径、机制、撤销和责任人，从最小故障域渐进扩大。撤销故障后不立即宣布成功，而是保护新流量，按原业务键查证未知态，用安全有效完成减新到达计算净消化率，受控回放历史积压并校验业务不变量。最后交付原始轮次、置信区间、版本比较、首个失败边界、恢复证据和残余风险；任何生产外推都由小流量与业务审计校准，而不是按实例数线性换算。

   计划还要写清谁批准工作负载、谁能触发停止、谁确认业务恢复，以及版本、数据基数、渠道配额变化后的重测条件。若实验只覆盖单区域读路径，我只承诺该路径的证据，不声称写链路、跨区切换或灾难恢复已被证明；这种边界声明也是验收产物，并要进入复审记录。

   • 追问 1：最高吞吐能当容量吗？ 直答 1：不能，容量要同时满足正确性、尾延迟、恢复和故障余量。

   • 追问 2：先做哪类故障？ 直答 2：先离线验证最小故障域、停止和撤销，再逐步扩大。

   • 追问 3：观测失明怎么办？ 直答 3：按停止条件撤销注入，冻结放量并用业务账本保守定界。

   • 追问 4：如何避免夸大？ 直答 4：绑定证据等级、版本、环境、原始数据和明确外推边界。

   • 详情：压测目标、证据边界与完整方法

2. 问题：生产、影子和离线环境的压测证据应如何组合？

   口述答案：我不会把三种环境排成简单高低，而是按它们能回答的问题组合证据。离线环境最适合可重复阶梯、极限、长稳和危险故障注入，可以冻结规格、版本、数据与替身行为，但缺少生产网络、共享资源、噪声邻居、真实热点和外部配额，所以结论只覆盖该离线合同。影子环境可以复制真实请求形状、参数关联、键分布和读取路径，发现热点、序列化、缓存回源与版本差异；但通常拦截写入和渠道副作用，不能证明事务锁、账务、回调和恢复能力。

   生产受控实验最接近真实路由、资源竞争、账号、配额和观测链，却必须以用户保护为先。我会先在离线证明脚本、自动停止与撤销可靠，再用影子校准分布，最后只对必要假设做白名单、小租户、单实例或极低流量的生产验证。三处使用相同业务意图和版本事实卡，但不强行让结果数值一致；差异本身用于定位环境模型遗漏。

   外推时逐项列出实例规格、数据基数、热点、依赖、故障域和背景流量是否等价。只有被覆盖的因素才能进入结论，无法复制的跨区域网络、真实渠道上限或季节性峰值保留为残余风险，并由在线限流、灰度和业务审计继续保护。离线单实例吞吐不能乘生产实例数冒充容量，影子零错误也不能证明真实支付写安全。最终报告把“观察到什么、推断什么、仍未知什么”分开，避免环境名称替代证据分析。

   三类环境还要共享停止线和业务验收口径，避免离线算技术成功、生产却算业务终态。若影子显示热键或长尾超出离线模型，就回到离线重建数据而不是修改生产阈值；生产验证结束后必须盘点测试对象、未知和外部账单，确认没有遗留副作用。

   • 追问 1：影子压测最适合验证什么？ 直答 1：真实请求形状、热点、读取和计算路径。

   • 追问 2：生产压测一定最可信吗？ 直答 2：只对实际覆盖范围更真实，未覆盖季节和故障仍不能外推。

   • 追问 3：离线结果如何升级？ 直答 3：用影子分布和生产小流量业务证据逐项校准。

   • 追问 4：环境差异怎么处理？ 直答 4：写入事实卡和残余风险，不用未经验证的折算系数掩盖。

   • 详情：容量模型的证据等级与单位边界

3. 问题：如何为 WMS（仓储管理系统）大促建立可执行的工作负载模型？

   口述答案：我先从业务意图而不是接口列表建模。WMS（仓储管理系统）大促至少包含订单创建、库存预占、释放、扣减、波次分配、出库和异步通知，每种动作都有比例、依赖和状态前置。时间维度要描述爬升、秒级尖峰、峰值平台和回落，尤其说明峰值持续多久；数据维度要保留仓、商品、租户和订单行数的偏斜，构造固定热商品、迁移热点、大订单长尾与足够大的索引和缓存工作集。

   请求器使用稳定订单键和库存键，重试仍归属于原业务意图。开环模拟外部订单持续到达，闭环只用于需要等待前一步的用户流程；报告同时给计划到达、实际发送和生成器排队。压测脚本按订单行数、仓和商品分桶，记录入口尝试、有效业务成功、锁等待、连接持有、MQ（消息队列）分区积压、最老年龄和回源，避免总 QPS（每秒查询率）掩盖单热键串行瓶颈。

   验收以可售量非负、预占释放闭环、唯一扣减和跨仓隔离为红线，不以接口成功率替代。先做均匀基线，再逐步叠加热仓、热商品、超时重试、消费者失效和数据库变慢；任一库存不变量失守立即停止。恢复阶段用事故窗口订单行权威清单核对预占、释放、扣减和消息，按净消化率受控回放。所有量级来自脱敏统计或 E3（演练证据）假设，未核对的生产峰值不进入项目成绩。

   项目边界还包括促销规则版本、仓路由、库存分片和下游履约是否与生产一致。报告保存每阶热键占比、锁链、消息分区和失败订单行；恢复验收除账面守恒外，还要确认暂停波次重新开放后没有新的长期预占，才能把该版本纳入容量基线，并登记下一次热点复演日期和责任人。

   • 追问 1：为何要测热点迁移？ 直答 1：它会同时改变锁竞争、缓存热度和路由，风险不同于固定热点。

   • 追问 2：订单数能代表工作量吗？ 直答 2：不能，还要按订单行、大对象和写放大分桶。

   • 追问 3：何时停止？ 直答 3：库存红线、排队拐点、资源保护或观测失明任一触发即停止。

   • 追问 4：如何验收恢复？ 直答 4：按订单行清单验证新流量、历史状态、未知和库存守恒。

   • 详情：工作负载的峰值、热点、长尾与基数

4. 问题：开环与闭环压测如何配合，怎样识别协调遗漏？

   口述答案：我先根据业务到达语义选择模型，而不是按工具默认值。订单事件、设备报警和消息生产通常不会因为服务端变慢就停止，因此用开环按计划时间发起；用户搜索或分步操作可能收到响应后才继续，可以用闭环并明确虚拟用户数和思考时间。两种模型回答不同问题，不能把闭环吞吐直接当外部固定到达下的容量，也不能用无限开环制造不符合业务的洪峰。

   协调遗漏发生在生成器等待响应、线程阻塞、自身处理器或网络饱和时，本应按计划到达的请求没有发出。若报告只统计实际发送到响应完成的耗时，系统越慢，生成器反而降速，未发用户完全消失，尾延迟看起来更好。我会记录每个请求的计划到达、实际发送、服务端进入和完成时间，展示未发数量、生成器排队和本机资源；开环生成器分布到多机并用时钟校验，避免压测端成为首瓶颈。

   执行时先用闭环验证会话逻辑和单用户体验，再用受控开环验证计划峰值与持续期，最后比较两者的有效吞吐、等待、超时和业务结果。若开环积压增长而闭环稳定，说明闭环背压隐藏了外部需求；若两者都发不满，先排查生成器。统计高分位时以计划到达作为等待起点，或明确报告已经校正协调遗漏的口径，不能只给漂亮的服务端处理时间。

   停止线还要覆盖生成器未发比例、服务端最老年龄和业务未知，而不只看错误率。恢复阶段关闭开环新增或降到正常入口，保留闭环少量探测，确认积压按净消化率下降且业务终态完整。项目边界应声明用户是否真的会等待、放弃或重试，否则所选模型无法外推，并需另测真实放弃行为、重试反馈与恢复后的会话完成率。

   • 追问 1：闭环是否一定错误？ 直答 1：不是，它适合等待型会话，但不能替代固定外部到达。

   • 追问 2：协调遗漏看哪个量？ 直答 2：计划到达与实际发送之差，以及生成器内部等待。

   • 追问 3：开环是否越高越好？ 直答 3：不是，到达计划必须来自工作负载并受停止条件约束。

   • 追问 4：生成器饱和怎么办？ 直答 4：分布式扩展并监控发送端资源，先证明它能稳定产生目标负载。

   • 详情：六类压测与开闭环协调

5. 问题：如何用 Little’s Law（利特尔定律）和排队斜率找到容量拐点？

   口述答案：我先统一统计边界：对象是请求、任务还是消息，入口按事件时间还是发送时间，出口是技术响应还是业务确认，等待是否包含线程、连接和外部回执。在积压斜率接近零、到达与有效完成近似守恒的稳定窗口，用 Little’s Law（利特尔定律）L = lambda × W 估算平均总在途，再与排队、执行中和待确认状态求和核对。这里使用平均到达率和平均停留时间，不能把 P99（99 分位响应时间）直接代入后宣称平均并发。

   阶梯压测每一级保持足够平台期，比较增加一单位到达率带来的有效吞吐增量。余量区吞吐随到达近似增加，等待和在途稳定；进入敏感区后吞吐边际收窄，高分位等待、连接获取、最老年龄或重试上升；拐点区则有效吞吐几乎不增，队列斜率快速变大。此时用每秒到达减有效完成计算净积压，而不是继续用稳态公式解释。

   定位还要找最先变化的等待段。处理器平均值未满不代表安全，单商品锁、数据库连接、MQ（消息队列）分区和下游配额都可能先饱和。停止线由业务时效、资金库存红线、资源和观测共同决定，通常位于理论极限之前。最终容量取满足延迟、正确、故障余量和恢复目标的区间，并记录服务时间、热点或重试变化后何时触发重测，不能把刚好越过拐点的最高完成率写成容量。

   为证明拐点不是偶然噪声，我会在拐点前后重复平台轮次，并核对生成器、数据分布和依赖版本一致。撤压后还要观察等待是否回落、积压能否清空以及未知是否收敛；若资源恢复而队列不降，说明有效完成口径或隐藏瓶颈仍未解决，不能形成容量结论或发布门禁。

   • 追问 1：积压增长还能用定律吗？ 直答 1：只能描述窗口现象，不能称为稳定容量，应改用速率差。

   • 追问 2：为什么看吞吐边际？ 直答 2：它能显示新增压力是否只转化为等待而非有效完成。

   • 追问 3：处理器未满为何会拐？ 直答 3：局部锁、连接、分区或下游配额可能先串行饱和。

   • 追问 4：队列无错误能继续吗？ 直答 4：不能，最老年龄和业务时效失守也是失败。

   • 详情：Little’s Law（利特尔定律）与非线性排队拐点

6. 问题：压测中端到端延迟恶化，如何找到首个瓶颈而不是盲目扩容？

   口述答案：我先确认现象是否真实：对齐版本、压测阶梯、计划到达、实际发送、数据完整度和业务结果，排除生成器发不满、时钟漂移或统计口径变化。然后按用户路径和业务切片定界，比较哪个租户、仓、商品、渠道、任务或分区先变慢。时间线上同时放置到达率、有效完成率、等待、服务、在途、拒绝和重试，首个瓶颈应是最先发生突变且能解释后续级联的等待或服务段。

   我会从客户端和入口开始，依次检查网关排队、线程入队、连接获取、数据库锁与扫描、缓存命中和回源、MQ（消息队列）生产消费、磁盘网络及外部配额。链路中要拆分获得资源前等待和真正执行时间。例如数据库查询变慢会先拉长连接持有，随后连接池等待、线程耗尽和客户端重试；此时线程使用率虽最高，首因仍可能是数据库。扩线程或连接会把更多并发推向已饱和下游。

   止血动作针对首因并保护业务：限入口、暂停低优先级、隔离热键或慢渠道、抑制重试、回滚变更，只有工作可并行且下游有余量时才扩容。恢复后验证新流量、历史积压、未知态和不变量，再将实际服务时间、命中、锁、配额和故障域回填模型。证据冲突时保留多个假设并补实验，不为了快速复盘编造单一故事，也不把后出现的高资源水位当根因。

   我还会保存每层等待的时间戳、池配置、查询或分区样本和业务键，作为因果证据。停止线按首瓶颈前的用户时效和不变量设置；修复复验必须重放相同热点与长尾，并证明瓶颈没有只是转移到下游。未覆盖的跨区和真实渠道噪声继续列为项目边界，由线上限流、熔断、灰度与业务对账持续兜底。

   • 追问 1：第一步为何不是加机器？ 直答 1：未定位首因时可能把压力推向更弱的共享下游。

   • 追问 2：如何证明因果？ 直答 2：用首次变化时间、链路等待和受控降载或隔离实验交叉验证。

   • 追问 3：连接池满说明什么？ 直答 3：说明连接供需失衡，仍需区分池过小和持有时间异常。

   • 追问 4：错误回落就结束吗？ 直答 4：不结束，还要清积压、未知和业务差异。

   • 详情：客户端到下游的瓶颈分解

7. 问题：如何设计发布和弹性扩容场景的预热压测？

   口述答案：我会把预热拆成可观测阶段，而不是固定等待一分钟。新实例先完成类、配置和域名加载，受限建立数据库与下游连接，再用代表性业务路径触发 JIT（即时编译），按证据明确的小热集预热缓存，并观察多轮 GC（垃圾回收）后的分配率、停顿和回收后基线。冷态、预热过程和热稳态分别报告，既不能用热态成绩掩盖发布风险，也不能用首次请求延迟代表长期容量。

   负载设计覆盖主要代码路径、热点和长尾，而不是只调用健康检查。预热流量带实验标识、限速和停止条件，避免真实扣款、通知与设备动作。多个实例按小批次接入，每批先建连和加载有限热键，再接极小比例真实或影子流量；如果数据库回源、连接建立、GC（垃圾回收）停顿或错误预算越线，停止下一批。所有新实例同时预热会把实例数乘热键数转成数据库尖峰，弹性反而成为事故放大器。

   验收门槛包括连接可用、缓存命中和回源趋稳、JIT（即时编译）活动回落、延迟分布稳定、回收后占用不持续上移，以及业务结果正确。浸泡阶段继续观察堆外内存、线程、文件句柄、临时文件和日志缓冲，不能仅凭堆回落断言无泄漏。最后分别记录发布、故障替换和高峰扩容需要的预热时间，把批次、流量上限、失败撤销和数据库余量写入自动扩容运行手册。

   预热场景还要固定热集来源、代码路径覆盖、连接上限和实例批次，保存冷态首批请求、回源与编译证据。停止线包括数据库保护、连接失败、回收停顿和业务错误；撤销后确认预热流量清理且缓存未污染其他租户。项目结论只适用于该运行时和制品版本，并随依赖升级重测。

   • 追问 1：预热为何不用全量数据？ 直答 1：会制造回源尖峰、污染缓存并扩大数据风险。

   • 追问 2：时间到就算预热完成吗？ 直答 2：不算，要由连接、缓存、编译、延迟和内存门槛判断。

   • 追问 3：短测能发现泄漏吗？ 直答 3：通常不能，需要多轮回收和长稳观察非堆资源。

   • 追问 4：扩容越快越好吗？ 直答 4：不是，批次速度受下游建连、回源和接流余量约束。

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

8. 问题：浸泡压测发现内存缓慢上升，应该如何判断和处置？

   口述答案：我先不把所有上升都叫泄漏，而是固定负载、版本和任务状态，区分堆扩张、长期存活对象、直接内存、线程栈、映射文件、日志缓冲、临时文件与积压对象。观察至少覆盖多轮 GC（垃圾回收）周期，比较每轮回收后的基线、分配率、晋升、停顿和容器总内存；若负载稳定而回收后基线持续上移，才形成更强泄漏证据。容器被杀但没有 Java（编程语言）堆异常时，还要检查堆外和系统级内存。

   接着按压测阶段和业务键关联增长来源。阶梯结束后内存是否回落，停止新任务后引用是否释放，大订单、导出分片、MQ（消息队列）批次和缓存基数是否同步增加。保存堆摘要、类实例趋势、线程、直接缓冲、文件句柄和任务清单，但在生产受控环境遵守采集成本与数据权限。只调大堆可能推迟失败并增加停顿，不是首选结论。

   止血时降低新任务和并发，隔离异常实例，保护在线交易并保留现场；修复后用相同数据基数、动作混合和平台时长复现，比较基线与候选多轮结果。验收要求有效吞吐和延迟不退化，回收后基线稳定，堆外、句柄、临时文件和积压同样有界，并在故障替换和恢复回放下再次验证。若实验时长不足以覆盖原增长周期，就只能报告尚未复现，不能宣布问题消失。

   模型输入还包括对象生命周期、缓存基数、大任务占比、分配速率和容器限制，停止线可用总内存预计耗尽时间与业务延迟共同触发。证据必须能关联到具体类、任务或资源，而不是一张总内存曲线；恢复后重新接流仍要观察基线是否再次上移，并完整覆盖原故障周期、任务生命周期和下一次弹性扩容。

   • 追问 1：堆上升就是泄漏吗？ 直答 1：不是，要看稳定负载下多轮回收后的基线是否持续上移。

   • 追问 2：先调大堆可以吗？ 直答 2：不先调，可能只延后失败并放大停顿。

   • 追问 3：还要看哪些资源？ 直答 3：直接内存、线程、句柄、临时文件、日志与积压对象。

   • 追问 4：如何证明修复？ 直答 4：同负载长稳复现，所有内存面有界且业务指标不退化。

   • 详情：JVM（Java 虚拟机）内存与线上排障

9. 问题：如何把混沌工程做成可安全运行的实验，而不是随机破坏？

   口述答案：我从稳态假设开始，写成能被用户结果反驳的句子，例如单个库存实例失效时，核心订单仍保持唯一扣减，未知态不持续增长，观测分母完整。然后描述真实故障机制，是进程终止、延迟、丢包、连接拒绝、磁盘余量、配额收紧还是时钟偏差；只修改监控数字只能验证告警，不代表服务真的经历故障。实验对象、版本、负载平台和依赖范围全部冻结。

   安全合同包含爆炸半径、禁止时段、审批、责任人、自动停止、注入超时保险、人工撤销和业务值守。首次从离线单实例或单租户开始，先证明停止器与撤销路径独立可靠，再扩大到单分区和受控流量。监测器同时读取用户结果、业务不变量、尾延迟、最老年龄、资源保护线和观测完整度；支付重复、库存超卖、关键漏报等红线可在第一笔坏事件时终止，不因整体比例很低而容忍。

   注入期间保持基线对照和完整时间线，确认实际故障是否到达目标，而不是只看注入命令成功。自动停止后立即撤销、冻结放量、保全失败对象和依赖证据。恢复阶段保护新流量、查证未知态、受控回放并核对不变量，经过观察窗才关闭。复盘评价假设是否被反驳、保护何时动作和残余风险，不以“系统没挂”作为唯一成功标准，也不把单进程实验外推为区域容灾能力。

   每个实验还应列出模型输入，如稳态负载、热点比例、依赖超时和单故障域余量，并保存注入前后业务对象清单。若停止器、监测器或回退与目标共享故障域，实验不得扩大；恢复验收要证明保护动作解除后不会反复启停，也没有遗留未知副作用，并经过完整稳定观察窗、业务复核和失败对象抽样回查。

   • 追问 1：稳态能只写可用率吗？ 直答 1：不能，还要含业务结果、未知态和数据完整度。

   • 追问 2：注入命令成功够吗？ 直答 2：不够，要证明目标实际经历了声明的故障机制。

   • 追问 3：何时扩大半径？ 直答 3：小范围停止、撤销、恢复和业务验收多轮可靠后。

   • 追问 4：撤销故障等于恢复吗？ 直答 4：不等于，还要处理积压、未知和业务差异。

   • 详情：故障模型、爆炸半径与恢复设计

10. 问题：故障注入触发自动停止后，现场保全和恢复应如何衔接？

口述答案：自动停止的第一目标是限制新增坏事件。监测器命中业务红线、资源保护线、最老年龄、观测失明或实验超时后，使用独立权限撤销注入，同时冻结下一阶梯和自动扩半径；入口按业务等级限流，暂停低优先级回放与无效重试。停止器要记录触发规则、原始值、数据截止时间和执行结果，若撤销失败则升级到人工紧急隔离，不能只在看板上变红。

现场保全与止血并行。保存制品、配置、注入参数、计划到达、实际发送、路由、实例、链路、日志、队列水位、业务键、外部请求和操作时间线；对可能含敏感数据的证据执行最小权限和保留期。不要为快速恢复重启全部实例、清空队列或覆盖未知状态，这会破坏首个异常点和业务追查。观测系统若与故障共享故障域，就用入口账本、渠道回执和独立探测补证，并明确未知边界。

恢复先验证故障机制确实撤销、剩余实例与依赖有安全余量，再小批恢复新流量。历史对象按原业务键查证，明确未执行才回放；计算安全有效完成减新到达的净消化率，按优先级提高恢复并发。最终用新流量、积压、最老未知、资金库存或任务报警不变量和观测完整度共同验收。复盘关联自动停止延迟、坏事件上限与恢复时间，把失败的门槛、权限或撤销动作修正后重新从小范围演练。

演练报告还要给出停止前计划负载、实际受影响对象上限、撤销耗时和证据缺口。若只覆盖单实例延迟注入，项目边界就不包含区域故障、数据污染和真实渠道中断；这些场景需独立建模。复验必须再次触发同一停止线并证明现场自动归档完整，由业务验收人和实验负责人共同确认并归档。

• 追问 1：先恢复还是先取证？ 直答 1：保护用户优先，同时自动保全关键现场，不能为取证继续放大。

• 追问 2：为何不直接清队列？ 直答 2：会丢失历史对象并掩盖未完成和未知副作用。

• 追问 3：停止器与注入器能同机吗？ 直答 3：不宜共享单点故障，应保有独立撤销路径。

• 追问 4：恢复何时放量？ 直答 4：新流量稳定、依赖有余量且净消化和不变量持续通过时渐进放量。

• 详情：混沌稳态、停止条件与可逆注入

11. 问题：如何计算积压恢复时间，并证明恢复不会伤害新流量？

口述答案：我先把总消费改成安全有效完成。拉取、重试、技术响应或错误确认都不算业务完成，要按原业务键归并，扣除失败、重复、未知和违反不变量的结果。恢复净消化率等于安全有效完成率减当前新到达率，只有在持续窗口内为正，积压才会下降；预计清空时间用剩余工作量除以净消化率，而不是用任务条数除以总消费者吞吐。长短任务差异明显时，工作量按行数、字节、分片或成本权重计算。

为保护新流量，我会给在线请求、关键历史对象和普通回放分级，先为新流量保留线程、连接、数据库与下游配额，再把余量分给恢复。恢复从小并发开始，每批观察新流量尾延迟、错误、未知、下游限流、最老积压和净消化斜率；若总吞吐升高但新流量恶化，立即降低回放。扩消费者只有在分区可并行且下游有余量时有效，否则会增加锁、连接和配额竞争。

恢复对象来自事故窗口权威清单，按原业务键查证后回放，保持顺序、规则版本、租约任期和幂等。清空估算持续滚动更新，因为新到达、服务时间和未知查证都会变化。退出条件不是队列清零，而是新流量稳定、历史对象逐一闭环、最老未知收敛、业务不变量通过和观测完整。最终保存恢复并发、净消化区间、失败批次及下游水位，作为下次容量与灾难恢复模型的输入。

模型输入必须包含事故窗口、任务权重、优先级、新到达预测、外部配额和不可并行比例。停止线不仅看新流量延迟，也看重复副作用、未知增长和下游拒绝；任一越线就回退到上一恢复批次。若工作量权重来自离线样本，清空时间只作为 E3（演练证据），不能承诺生产完成时刻。

• 追问 1：为何不用总吞吐？ 直答 1：它包含新流量、重复和失败，不能表示历史积压减少速度。

• 追问 2：净消化为零怎么办？ 直答 2：积压不会恢复，应降新到达或提高真实瓶颈的有效能力。

• 追问 3：恢复并发越高越好吗？ 直答 3：不是，必须为新流量和下游保留安全余量。

• 追问 4：何时清零事故？ 直答 4：历史、未知、不变量和观测共同闭环后。

• 详情：净消化率、回放与业务恢复

12. 问题：支付故障后存在大量超时未知，如何设计查单、回放与对账？

口述答案：我先明确超时只代表没有收到响应，不代表渠道没有扣款。止血阶段暂停换键重试和故障注入，保留支付意图、原幂等键、金额币种、渠道请求、回调、账务分录和时间线；新支付可按渠道和风险分级限流。以支付意图为权威分母，将结果分为明确成功、明确失败、未知和冲突，任何未知都不能因接口重试成功从分母删除。

查证优先使用原业务键调用渠道查单，并与异步回调、渠道账单和内部账务交叉验证。明确成功但内部未入账的走幂等补记，明确失败且业务仍有效的才按原意图受控重试；金额、币种、订单或多次成功冲突进入隔离人工。没有查单接口时降低自动化程度，使用账单、回执和人工建立替代证据，不能凭经验把未知批量改成失败。所有修复写追加审计，不覆盖原始事实。

回放按渠道配额和新流量余量小批进行，持续看重复扣款红线、未知年龄、回调积压和净消化率。验收不仅是支付接口恢复，还要确认事故窗口每个意图有终态，渠道成功与内部账务分录一致，无重复扣款、金额币种差异和孤立订单；差异单有负责人和期限。复盘再验证幂等、查单、回调乱序、渠道限流与自动停止，将生产数字保持在证据范围内，不把演练样例写成真实资金成绩。

压测模型还要声明渠道分流、金额分桶、回调迟到、查单频率和账户隔离，停止线把第一笔重复扣款、金额冲突或账务不平作为硬红线。恢复证据保存渠道原始回执、查单时点和修复分录；若使用沙箱，只能证明流程与幂等，不能外推真实渠道限额、清算和资金风险，生产仍需小批受控校准、独立对账并覆盖迟到回调观察窗。

• 追问 1：超时后能换键重试吗？ 直答 1：不能，可能造成第二次真实扣款。

• 追问 2：查单成功后做什么？ 直答 2：按原意图幂等补记并核对账务，不再扣款。

• 追问 3：无查单能力怎么办？ 直答 3：依赖账单、回执和人工，降低自动重试并推动补齐能力。

• 追问 4：接口恢复够吗？ 直答 4：不够，每笔未知和账务差异都必须闭环。

• 详情：支付未知态、幂等与恢复

13. 问题：如何治理压测数据并证明没有触发真实外部副作用？

口述答案：我把压测数据当成有完整生命周期的受管资产。来源先经过授权和最小化，生产统计只提取建立分布所需信息，敏感字段不可逆脱敏；合成数据保留租户、仓、商品、订单行、消息大小、热点、长尾、状态和迟到关联，不复制真实身份。每次实验使用独立租户或命名空间、批次和稳定测试业务键，实验标识持久化到数据库记录、MQ（消息队列）事件、对象、索引和审计，而不是只放在请求头。

外部副作用在出口强制隔离。支付、物流下单、短信、邮件、库存实占和设备控制使用沙箱、替身、独立账号与出口拒绝列表，默认拒绝测试命名空间访问真实渠道；压测前用探针验证拒绝路径，将任何漏放设为自动停止条件。异步消费者、定时任务、重试和历史回放都必须传播实验身份，旁路系统没有门禁就不能进入该实验。测试响应成功不等于隔离成功，还要查渠道账单、通知回执和设备审计确认零真实动作。

清理前由权威清单盘点数据库、缓存、消息未确认、重试、死信、对象和搜索索引，按依赖顺序受控删除，不能按时间窗粗删。清理操作带影响数量、版本、审批和回滚保护，防止跨租户误删；去敏后的脚本、分布、数量摘要、结果和清理证明按期限归档，原始敏感数据最短保留。最终用“创建多少、流转多少、残留多少、真实副作用多少”的可复算账本验收，而不是只声明脚本带测试标记。

数据模型输入、脱敏版本和生成种子也要可追溯，停止线包含标识丢失、跨命名空间写入和任一真实渠道动作。若系统无法证明旁路消费者已接入出口门禁，该路径就排除在生产实验之外；恢复验收还要确认测试缓存、索引和延迟消息不会在实验结束后重新污染线上。

• 追问 1：请求头标记够吗？ 直答 1：不够，跨消息、定时和回放时可能丢失。

• 追问 2：为何出口也要门禁？ 直答 2：它能阻断上游漏标和旁路消费者造成的真实动作。

• 追问 3：清理能按时间吗？ 直答 3：不能，会误删同期生产并漏掉迟到对象。

• 追问 4：怎样证明零副作用？ 直答 4：用渠道账单、回执和设备审计独立核对。

• 详情：压测数据治理与副作用隔离

14. 问题：如何比较两个版本的压测结果，避免选择最好一轮和虚假提升？

口述答案：我先冻结可比合同：制品、配置、运行时、实例规格、数据库和索引、数据快照、键分布、缓存起点、依赖行为、脚本与生成器资源。基线和候选采用交错或随机顺序运行，避免上午和下午的环境漂移全部落在某一版本；每轮经历一致的预热、平台和恢复阶段。异常轮次只能按实验前定义的生成器故障、数据缺失等规则剔除，不能看到结果后删除不利样本。

报告保留每轮原始值，并按指标类型选择摘要。有效吞吐看各轮中心、离散和差值区间；错误与未知同时给分子、分母、绝对坏事件和比例区间；延迟给多个分位、样本量、计划到达口径与协调遗漏；资源和恢复看水位、斜率及净消化。时间连续的请求并非完全独立，不能用海量单请求制造过窄置信区间，优先以轮次或稳定时间块做比较。

结论同时检查统计不确定性和业务门槛。候选吞吐略升但 P99（99 分位响应时间）、资金未知、库存差异或恢复退化，就不能称整体提升；差值区间跨过无差异或验收门槛时，报告证据不足并增加轮次。最终结论只对该版本合同有效，代码、配置、硬件、数据基数、热点、依赖配额或脚本变化都登记为基线失效条件。没有生产证据时，只陈述演练差异，不写“线上提升了某比例”。

比较计划还要预注册主要指标、停止线和最小业务差异，避免结果出来后改问题。每轮保存生成器健康、背景噪声、失败对象和恢复清理；候选若触发业务红线，即使样本不足也先判不晋级。只覆盖离线环境时，置信区间描述离线重复性，不代表生产季节性与故障域不确定性，结论必须限域并标注复审日期。

• 追问 1：三轮一定够吗？ 直答 1：不一定，轮数取决于波动、效应和风险。

• 追问 2：样本多就可信吗？ 直答 2：不一定，相关样本和口径错误会制造虚假精度。

• 追问 3：统计显著就晋级吗？ 直答 3：不，仍要满足业务正确、延迟、成本与恢复门槛。

• 追问 4：何时重建基线？ 直答 4：任何改变工作负载或资源映射的关键因素变化时。

• 详情：重复实验、置信区间与版本基线

15. 问题：线上容量告警与用户变慢同时出现，如何完成从止血到复盘的闭环？

口述答案：我会并行推进用户保护和证据确认。先冻结高风险发布、配置与实验，按业务等级限流，暂停低优先级任务和无效重试；支付重复、库存超卖、关键漏报等红线不等待根因确认。随后核对告警口径、数据水位、计划到达、入口计数和业务账本，区分真实流量、重试放大、服务率下降与观测缺样，并按租户、区域、版本、仓、渠道和任务类型确定影响范围。

定位沿等待链展开：客户端和入口、线程入队、连接获取、数据库锁与扫描、缓存回源、MQ（消息队列）分区、磁盘网络和外部配额。对齐发布、流量、依赖和人工操作时间线，找到最先变化且能解释后续级联的服务或等待段。止血针对首因，例如回滚慢查询、隔离热键、限制回源、暂停回放或降低渠道并发；未证明下游有余量前不盲目扩线程和连接。

指标回落后继续处理事故窗口。保护新流量，按权威清单圈定积压与未知，计算净消化率并分级回放，核对资金、库存、任务产物和关键报警；观测不完整时明确未知并延长保守策略。关闭后把实际到达、服务时间、首个拐点、自动保护延迟、恢复耗时和残余风险回填容量模型，补充压测或混沌场景。复盘行动写负责人、期限、验证和下一次演练，不用“扩容完成”替代为什么门禁未更早止损。

现场证据至少包括流量和完成速率、池等待、首个异常业务键、依赖回执与操作时间线，停止线和恢复门槛必须沿用事故前版本。若问题只发生在特定租户或区域，止血与恢复都保持该边界，避免全局动作扩大影响；尚未复现的根因明确标为未知，不用相关性代替因果，并安排同负载、同版本复现实验。

• 追问 1：先定位还是先限流？ 直答 1：业务红线已触发时先保护用户，同时保全证据定位。

• 追问 2：第一告警就是首因吗？ 直答 2：不一定，要按时间线和等待链验证。

• 追问 3：扩容何时有效？ 直答 3：工作可并行且真实瓶颈与下游仍有余量时。

• 追问 4：复盘最重要输出是什么？ 直答 4：可验证的门禁、运行手册和复演行动，而非故事。

• 详情：容量事故排查与资源模型

16. 问题：请用项目话术完整讲一次 WMS（仓储管理系统）库存防超卖压测与恢复方案。

口述答案：我会先讲业务风险：大促或波次集中时，同仓同商品并发、客户端超时重试和消息乱序可能把库存从容量问题放大为超卖或长期占用。模型以订单行为业务意图，描述热仓、热商品、订单行长尾、峰值持续、预占释放比例、数据库写放大和 MQ（消息队列）分区；所有样例量级标为 E3（演练证据），不把未核对的生产峰值和收益写进项目成绩。

执行从均匀基线开始，逐级增加开环订单到达，再叠加固定热点、热点迁移、尖峰、浸泡、单实例失效、数据库变慢和消费者暂停。每阶同时记录有效订单行、线程与连接等待、库存锁、版本冲突、消息最老年龄和重试归并。停止条件以可售量为负、重复扣减、跨仓污染等业务红线优先，其次是排队拐点、数据库保护和观测失明；停止后冻结新故障与无效重试，保全订单键、库存流水和时间线。

恢复不直接重放全部消息，而是按事故窗口订单行清单核对预占、释放、扣减和终态。对结果未知的操作用原业务键查状态，明确未执行才回放；为新订单保留容量，按净消化率逐批处理历史对象。验收要求新流量稳定、最老积压收敛、每个订单行闭环、可售与实物及流水守恒、无重复副作用。最后把热点上限、锁顺序、队列时效、限流和恢复并发写入运行手册，并用同场景复演验证修复。

证据包会保留每阶仓商品分布、事务锁链、库存版本、消息水位和停止触发点。若离线环境没有生产仓路由、数据库规模或履约联动，我只把它作为机制验证；生产容量仍需小流量校准。恢复后还要模拟一次重复消息，证明幂等保护没有因修复而退化，并复核长期预占。

• 追问 1：接口成功能证明不超卖吗？ 直答 1：不能，要核对库存流水、版本和守恒不变量。

• 追问 2：热点如何压？ 直答 2：固定热键与迁移热点都要测，并观察单键锁和分区。

• 追问 3：消息能全部重放吗？ 直答 3：不能，先按原业务键查证，避免重复扣减。

• 追问 4：恢复先看什么？ 直答 4：新订单正确、历史订单行闭环和库存守恒。

• 详情：WMS（仓储管理系统）与支付不变量驱动演练

17. 问题：请用项目话术完整讲一次支付资金一致性故障压测？

口述答案：我先定义不能突破的业务边界：同一支付意图最多一次有效扣款，金额币种和订单一致，渠道终态与内部账务可对账，所有超时未知最终有结论。负载模型按支付意图而不是请求次数统计，包含渠道比例、峰值持续、回调延迟、查单、超时重试、限额和长尾金额；真实渠道只在批准的小爆炸半径或沙箱验证，离线与影子数字保持 E3（演练证据）。

基线先证明正常支付、回调和对账，再叠加渠道延迟、响应丢失、回调乱序重复、配额收紧、单渠道隔离和内部数据库变慢。每个请求保留原幂等键，独立账本记录支付意图、渠道请求、回调、查单与账务。自动停止同时看重复扣款、金额冲突、未知年龄、尾延迟、渠道限流和观测完整度，任何资金红线第一笔即撤销故障，不用整体错误率稀释。

恢复先限制新尝试和换键重试，对未知按原意图查单，与渠道账单、回调和账务分录交叉验证；明确成功走幂等补账，明确失败才按规则受控重试，冲突进入隔离人工。回放受渠道配额和新流量余量约束，按净消化率小批提高。验收要求事故窗口每笔意图有终态、无重复扣款、金额币种一致、账务平衡、差异单闭环。复盘把超时预算、查单、回调去重、渠道隔离、自动停止和演练频率固化，不虚构真实资金量或改进比例。

模型输入和证据还包括渠道账号、路由规则、金额分桶、签名、回调重放与查单水位，第一笔重复扣款或金额冲突就是停止线。沙箱无法证明真实清算、风控和渠道容量，因此项目话术明确机制已验证、生产边界待核对；恢复观察窗要覆盖迟到回调，防止封账后再次改写终态，并核对渠道账单。

• 追问 1：支付压测成功口径是什么？ 直答 1：渠道终态与账务一致，不是接口返回成功。

• 追问 2：未知能算失败吗？ 直答 2：不能，要保留未知并查单或对账确认。

• 追问 3：回调重复如何测？ 直答 3：按原事件重复和乱序注入，验证幂等与账务唯一。

• 追问 4：资金红线能容忍小比例吗？ 直答 4：不能被整体比例稀释，可第一笔即停止。

• 详情：支付故障、未知态与业务不变量

18. 问题：Runner（执行器）任务积压并发生实例故障，如何压测和恢复？

口述答案：我先把任务数换成剩余工作量。不同任务的行数、分片、对象字节、外部调用和长尾差异很大，模型要包含任务类型、优先级、峰值持续、热点租户、检查点间隔、租约时长、重试和下游配额。有效完成以产物通过摘要和业务交付为准，拉取、执行结束或队列确认都不能替代；所有任务使用稳定业务键，租约带任期，结果提交校验任期与幂等。

压测从单任务资源成本和均匀调度开始，再叠加大任务长尾、单分片热点、尖峰、浸泡、Runner（执行器）进程终止、网络分区、租约过期、数据库或对象存储变慢。观察到达、有效完成、剩余工作量、最老任务、线程、连接、临时磁盘、检查点、重复执行和下游限流。停止条件包括旧任期提交成功、重复外部副作用、在线业务受损、积压斜率越线和观测缺失。

故障后旧 Runner（执行器）即使恢复也不能覆盖新任期结果。恢复调度器按优先级从可信检查点续跑，先查外部副作用和已有对象摘要，避免全量重做；为新任务和在线交易保留资源，用安全有效工作量吞吐减新工作量到达计算净消化率。验收要求新任务时效稳定、历史任务逐一闭环、检查点连续、产物可访问且摘要一致、无重复提交和孤立临时文件。最后回填任务权重、并发上限、租约、检查点与下游配额，复演同一故障。

实验保存任务分桶、租约任期、检查点偏移、产物键、下游限流和旧实例提交证据，任一越权提交或重复副作用立即停止。若测试对象存储和生产一致性模型不同，就不能外推交付语义；恢复完成后还要等待旧租约和迟到消息过期，确认不会产生第二次提交。

• 追问 1：为什么不按任务数估时？ 直答 1：长尾任务可能占绝大部分剩余工作量。

• 追问 2：锁能防旧实例提交吗？ 直答 2：仅靠锁不够，还要数据层任期栅栏。

• 追问 3：恢复要全量重跑吗？ 直答 3：不，要从可信检查点按原键续跑并查证副作用。

• 追问 4：扩执行器何时无效？ 直答 4：单分片或下游数据库、存储和配额饱和时。

• 详情：Runner（执行器）任务、租约与恢复演练

19. 问题：IoT（物联网）报警风暴如何设计故障压测并证明关键事件未漏？

口述答案：我先区分设备原始事件、规则命中、聚合告警、通知和人工确认，不能把入口消息数直接当业务成功。工作负载描述设备基数、区域相关性、单设备抖动、严重度变化、峰值持续、消息大小、乱序迟到和通知配额；构造普通重复风暴与少量关键安全事件混合，保留设备、规则版本和事件时间。关键事件覆盖、新鲜度、通知回执和确认是红线，总吞吐和队列长度只是诊断量。

压测先做正常基线，再叠加区域尖峰、单设备高频、单分区热点、消费者失效、规则计算变慢、通知渠道限流和采集观测缺样。普通同根因事件可按版本化规则聚合和抑制，但原始审计不能丢；关键事件进入独立优先队列并保留逐设备责任。自动停止观察关键漏报、最老关键事件、通知未知、数据库与 MQ（消息队列）水位以及应到设备和实到事件差，采集断开时不能把没有新告警当健康。

恢复先保护当前关键事件和通知容量，再按设备清单处理事故窗口。比较安全有效处理率与新事件到达，优先回放关键事件，普通重复按规则聚合；对已通知但无回执的查证，不盲目重复轰炸。验收要求原始序列连续或差异有解释、关键设备覆盖和新鲜度通过、通知与确认闭环、规则版本可追溯、积压和未知收敛。复盘回填峰值、聚合比、渠道配额和人工确认能力，并复演消费者或通知渠道失效。

证据包还包含应到设备清单、采集水位、原始事件摘要、规则输入输出和通知渠道回执；关键漏报或采集失明立即停止。若实验使用模拟设备，只证明协议与规则路径，不能替代真实区域网络和设备时钟。恢复后要抽样回放严重度变化，确认聚合没有吞掉升级事件。

• 追问 1：队列清零能证明恢复吗？ 直答 1：不能，要核对设备覆盖、规则命中和通知回执。

• 追问 2：普通事件能丢吗？ 直答 2：可按批准规则聚合抑制，但原始审计和严重度变化要保留。

• 追问 3：无新报警代表什么？ 直答 3：可能正常，也可能采集断开或规则错误，需对照应到清单。

• 追问 4：恢复先处理谁？ 直答 4：先保障新关键事件，再回放历史关键，普通事件分级处理。

• 详情：IoT（物联网）报警风暴、回放与验收

20. 问题：请用高级开发项目话术串讲容量评估、压测、混沌、恢复和复盘？

口述答案：我的主线是把可靠性从单个吞吐数字变成可验证闭环。先按业务路径定义用户结果和红线：WMS（仓储管理系统）保护库存守恒，支付保护资金唯一与未知态，Runner（执行器）保护任期和唯一提交，IoT（物联网）保护关键覆盖与通知回执。所有输入注明证据等级，生产、影子、离线分别说明能证明和不能证明什么，不用实例数或行业值线性外推。

工作负载同时建动作混合、峰值持续、热点、长尾、数据基数、重试与外部配额。执行由冷态基线、预热、阶梯、峰值平台、浸泡、尖峰和故障叠加组成；开闭环各自匹配业务到达，并记录计划时间消除协调遗漏。定位时用 Little’s Law（利特尔定律）核对稳态在途，用到达减有效完成识别积压，沿客户端、入口、线程、连接、数据库、缓存、MQ（消息队列）和下游找到首个等待或服务突变。业务红线、排队拐点、资源保护和观测失明任一触发自动停止。

混沌实验写稳态假设、爆炸半径、真实故障机制、撤销和责任人。停止后保护新流量、保全现场，对未知按原业务键查证，以净消化率分级回放，并用权威清单验证资金、库存、产物和报警，而不是只看错误率或队列清零。结果通过交错重复、置信区间和版本基线表达，报告失败样本与残余风险。最后把首个拐点、保护延迟、恢复证据写回门禁、运行手册和下一次演练；没有直接生产证据的数字始终保持 E3（演练证据），确保项目表达既深入又诚实。

面试收尾我会主动说明模型负责人、停止权限、业务验收人和基线失效条件，并区分已经演练的单实例、单渠道场景与尚未验证的跨区、数据污染风险。这样方案不仅有公式和工具，还有组织责任、证据链、恢复出口和明确项目边界。

• 追问 1：这套方法的核心公式是什么？ 直答 1：稳态看在途等于到达率乘停留时间，恢复看到达与有效完成的速率差。

• 追问 2：最重要的停止线是什么？ 直答 2：资金、库存、关键漏报等业务红线优先于技术指标。

• 追问 3：怎样证明真正恢复？ 直答 3：新流量、历史对象、未知、不变量和观测共同通过。

• 追问 4：怎样保证话术可信？ 直答 4：区分事实、推断和未知，绑定版本、环境、原始证据与残余风险。

• 详情：可靠性指标、容量与恢复学习入口