核心方法论

单点是系统中"一旦故障或达到瓶颈就影响全局"的资源。拆分的本质是把一个"大单点"变成"一个小单点 + N 个并行资源"——单点压力下降一个数量级，系统容量上升一个数量级。拆分可递归进行，直到单点不再是瓶颈。每一次拆分都在回答同一个问题：当前的资源竞争在哪，怎么把它拆开。

单点不只是服务器——数据库是单点、缓存是单点、消息队列是单点、甚至机房和地域都是单点。架构师的核心能力就是递归地识别每一层单点并选择正确的拆分维度。

可用公理的工程化：多数可用性问题可归约为故障域过大或恢复路径缺失（经典单点是其一）。单点就是那个"一旦故障就影响全局"的资源。动静分离把静态资源和动态请求的竞争消除；读写分离把读和写的竞争消除；分库分表把数据层面的竞争消除。每一级拆分都在回答：当前的资源竞争在哪，怎么把它拆开。

被问"如何设计高并发系统"时，第一句话是"先找单点"，而不是直接抛方案。画出系统架构图，标注每个组件的 QPS 上限，找出最先到达瓶颈的那个——那就是第一拆分目标。这句话本身就是架构思维和高级开发的分水岭。

拆分有顺序，性价比递减但容量递增：动静分离 → 读写分离 → 负载均衡 → 分库分表 → 异地多活。每一级解决上一级产生的新单点。不是上来就异地多活，而是被业务逼着一步步演进。一个 10 万 DAU 的系统上来就异地多活不是技术先进，是资源浪费；一个百万 QPS 的系统还在单机 MySQL 不是技术克制，是事故预警。

AKF 三轴的工程落地——动静分离是 Y 轴（功能拆分）、读写分离是 X 轴（数据复制/只读副本）、负载均衡是 X 轴（水平复制）、分库分表是 Z 轴（数据分区）、异地多活是 Z 轴（地理分区）。每一级拆分都在 AKF 立方体上推进一个维度。

画出拆分阶梯图，标注每级的触发信号。被问"你会怎么设计电商系统"时，给出分阶段方案：当前用动静分离+读写分离够用，QPS 破 5000 演进到分库分表，QPS 破 5 万演进到异地多活。关键是说清每一步的触发条件和取舍代价。

同步调用是最大的单点耦合——下游慢则上游堵，上游堵则全局雪崩。消息队列把"同步等待"变成"异步投递"，削峰填谷、故障隔离。代价是引入三个新问题：消息丢失、消息重复、消息积压。异步不是银弹，是把"同步的确定性"换成了"异步的吞吐量"。

异步解耦的精髓在于核心链路同步、非核心链路异步。电商下单：扣库存+创建订单走同步（核心），发短信+推物流+记日志走异步（非核心）。如果全异步，一致性难以保证；如果全同步，吞吐量上不去。

将串行资源竞争（等待下游响应占用线程）变为并行（投递后立即释放线程），减少资源竞争。从利特尔定律角度看，异步降低了 W（平均等待时间），在相同 L（并发数）下提升了 λ（吞吐量）。

被问"如何设计秒杀系统"时，用异步解耦回答：用户请求先入消息队列（削峰），后端按消费能力处理订单。前端立即返回"排队中"。吞吐量提升 10 倍，代价是用户体验从"即时"变成"排队"。

AKF X 轴——无状态服务在负载均衡器后运行多个相同副本。实现最简单，但要求服务无状态（状态外置到 Redis/DB）。有状态服务的水平扩展需要一致性哈希或分片，复杂度陡增。这是"无状态设计"成为架构原则的根本原因。

水平扩展的瓶颈不在应用层（加机器即可），而在数据层——数据库不能简单地加副本解决写入瓶颈。所以水平扩展通常配合读写分离、分库分表一起使用。

把 1 个资源的竞争分散到 N 个副本，每个副本压力降为 1/N。从利特尔定律看：L（并发数）不变，但分散到 N 个副本后每个副本的 L/N 很小，排队等待时间 W 大幅下降，吞吐量 λ 近线性增长。

被问"如何扩容"时，先问"有状态还是无状态"——无状态直接加机器+负载均衡，有状态先拆状态（Session 外置到 Redis）再扩容。这个反问本身就是架构思维的体现。

当上游生产速率超过下游消费速率时，下游向上游施加反向压力，防止自身被压垮。本质是流量控制——宁可快速失败也不要无界缓冲（无界缓冲 = 延迟失败 + 资源耗尽）。Java 9 Flow API / Reactive Streams 采用信用机制（credit-based flow control），下游告诉上游"我还能处理 N 个"。

线程池的拒绝策略就是背压的工程实现：队列满后，新请求被拒绝（AbortPolicy）或由调用者执行（CallerRunsPolicy）。这不是"bug"而是"背压设计"——用快速失败防止全局雪崩。

利特尔定律 L = λ × W 中 L（并发请求数）的有界化。无界队列导致 L→∞，最终 OOM。背压通过限制 L 的上界，保证系统在过载时"优雅降级"而非"崩溃"。

被问"线程池满了怎么办"时，回答"拒绝策略是背压设计，不是异常。CallerRunsPolicy 让调用者线程执行，自然降低上游投递速率；AbortPolicy 快速失败，让上游感知过载。关键是不要用无界队列——那是把雪崩从下游转移到上游内存"。

响应式背压契约（prefetch / onBackpressure* / 半响应式零容忍）见 M08.07；本卡管线程池拒绝与有界队列的工程背压。

线程池拒绝策略与有界队列背压见 M08.06；背压≠限流——限流/熔断边界见 M09.03。

热点问题的本质是"流量在空间上的不均匀分布导致局部资源竞争"——99% 的请求打到 1% 的资源上。治理核心是一个字："打散"。高并发系统的热点不只是热点 Key（缓存），还有热点账户（数据库行锁）、热点商品（秒杀）、热点分区（消息队列）。

热点治理三层模型：识别 → 拆散 → 削峰。识别靠监控（单 Key QPS 超阈值告警）；拆散靠分桶（影子账户/分片/本地缓存）；削峰靠异步（MQ 聚合 + 批量处理）。三层递进，从"发现问题"到"消除瓶颈"到"平滑流量"。

热点账户经典方案——"记账分离 + 异步汇总 + 影子账户"：将记账（写流水）与更新余额解耦，高并发请求只写流水表（按 accountId 分库无热点），余额更新异步聚合批量执行（单账户从 3 万 TPS 降到几百 TPS）；极端热点用影子账户拆分——主账户拆为 N 个子账户，请求按 Hash 路由并行扣减消除单行锁，定时汇总回主账户。本质是 AKF 的 Z 轴（数据分区）在单行级别的微观落地——把一个热点行拆成 N 个非热点行。

被问"热点账户怎么处理"时，三层治理框架回答："第一层识别——监控单账户 QPS 和锁等待时间，超阈值告警；第二层拆散——影子账户把主账户拆 16 个子账户，按 txId Hash 路由并行扣减，消除单行锁竞争；第三层削峰——扣款请求先入 Kafka 按 accountId 分区，消费者聚合 100ms 窗口内同账户流水批量更新余额，单账户 TPS 从 3 万降到几百"。最后补一句"读余额走缓存准实时，强一致读走 DB for update，T+1 对账兜底"。

利特尔定律（Little's Law）：L = λ × W——系统中平均并发请求数 = 平均到达率 × 平均响应时间。这是容量规划的数学基础：

• 响应时间 W 不变时，吞吐量 λ 与并发数 L 成正比 → 提吞吐需提并发能力
• 吞吐量 λ 不变时，降低响应时间 W 可减少系统内排队请求数 L → 减少资源占用
• 解释了无界队列的危险：W 增大导致 L 无限增长，最终 OOM

L 就是竞争同一资源的请求数，L 越大资源竞争越激烈。利特尔定律把"资源竞争"从定性描述变成了可计算的数学公式，是高并发容量规划的定量基础。

被问"系统支撑多少 QPS"时，用 L=λ×W 反推：已知单请求平均 200ms，线程池 200 个线程，则 λ = L/W = 200/0.2 = 1000 QPS。要提升到 5000 QPS，要么加线程到 1000 个（受 CPU 核数限制），要么把响应时间降到 40ms（优化 DB 查询/缓存）。

利用率靠近 1 时延迟非线性恶化（排队 / Kingman，见 M01.12）；本卡 Little 管稳态 L=λW 关系，不替代高利用率尾延迟模型。

结构化四步——①识别单点（压测/监控定位瓶颈）→ ②选择拆分维度（AKF 三轴：X 水平复制 / Y 功能分解 / Z 数据分区）→ ③评估取舍代价（一致性/延迟/复杂度/成本）→ ④实施并验证（灰度→全量→监控）。每步都有明确的输入输出和决策点，不是"想到哪做到哪"。

将"找出单点→拆分"从口号变成可执行流程。第①步是"找出单点"，第②步是"选择拆分维度"，第③步是"说清取舍代价"，第④步是"验证拆分有效"——完美映射核心哲学的三步闭环。

被问到"你会怎么设计高并发系统"时，按四步推进而不是直接抛方案："第一步我先压测找瓶颈，假设瓶颈在 DB；第二步我选择读写分离+分库分表拆分数据单点；第三步取舍是引入最终一致性；第四步灰度切换并监控慢查询"。这个回答结构本身就是可审计的设计表达：假设→拆分→取舍→观测。

总骨架见 M05.01 事前-事中-事后。

高可用不是"不故障"（不可能），而是"故障后用户无感"。核心是冗余 + 自动故障转移。架构师要假设每个组件都会故障，设计时问"它挂了系统还能跑吗"。可用性公式：Availability = MTBF / (MTBF + MTTR)，提升可用性 = 降 MTTR（恢复快）或升 MTBF（少故障）。

关键认知：100% 可靠是不现实的，也是不必要的——100% 可靠会扼杀创新速度。架构师要定义"够用的可用性"（SLO），用量化的错误预算管理稳定性与迭代速度的平衡。

可用公理：故障域过大或恢复路径缺失是主因（经典单点是其一）。冗余把单点变多副本，故障转移让故障透明。MTBF 对应"消除单点"（冗余越多单点越少），MTTR 对应"快速恢复"（自动转移比人工快）。

被问"如何保证高可用"时，不列技术清单，而是按"冗余→检测→转移→恢复"四步回答："第一层冗余——多副本部署；第二层检测——心跳探针+健康检查；第三层转移——自动 failover；第四层恢复——故障节点修复后自动加入集群"。

可用性级别与 RTO/RPO 选型方法论见 M09.02；本卡立「故障无感」思维与冗余检测转移。

多活架构分级——冷备（备机待命不服务，切换慢）→ 热备（备机同步数据，切换快）→ 主从（主写从读，读高可用）→ 双活（双中心同时服务，写路径须防双写冲突）→ 多活（异地多活，机房级容灾）。级别越高可用性越好但复杂度越高。

选择依据是 RTO（恢复时间目标，故障后多久恢复）和 RPO（恢复点目标，最多丢多少数据）。金融级 RTO<30s → 多活；互联网 RTO<5min → 主从+自动切换；日志类 RTO<1h → 冷备即可。

冗余程度递增——从 1 份到 N 份，从同步到异步，从单机房到跨地域。每一级都在消除更大范围的单点：冷备消除进程单点，主从消除单机单点，双活消除机房单点，多活消除地域单点。

被问"你的系统可用性方案"时，先给 RTO/RPO 需求再给方案："业务要求 RTO<1min、RPO=0，所以选 MySQL MHA+同步半复制（主从级）+同城双活（机房级），不选异地多活因为成本超预算"。

高可用落地检查单

• SLO 定义：可用性 / 延迟 / 错误率指标与阈值已明确？
• 冗余拓扑：单点是否消除到对应机房 / 地域级？
• 故障演练：定期混沌 / 切换演练，RTO/RPO 真实验证？
• 容量余量：峰值水位 < 70%，扩容预案就绪？
• 监控覆盖：关键链路指标有告警与 oncall 闭环？

可用性公式与思维开路见 M09.01。HA 级别是目标，不等于复制拓扑商品名；金融 RTO 目标是充分条件参考，同城同步亦可达成部分场景。

口径：熔断/限流/降级的总则见法层 M06.01 面向失败设计（熔断/降级/限流）；本卡只留参数化实践（算法选型、阈值、三级联防）。

三板斧各有定位——限流（入口防护，控制请求量）、熔断（中间防护，防止级联失败）、降级（末端防护，保核心弃非核心）。

限流算法：固定计数器（简单但有临界突刺）→ 滑动窗口（平滑）→ 漏桶（平滑输出，不允许突发）→ 令牌桶（允许突发，最常用）。熔断三状态：Closed（正常）→ Open（跳闸快速失败）→ Half-Open（试探恢复）。降级：返回默认值/过期缓存/关闭非核心功能。

全链路限流是三板斧在生产环境的高级形态——从单机限流到三级联防：第一级 Nginx 限流（limit_req 按 IP/URI 挡恶意流量），第二级网关集群限流（Redis + Lua 分布式令牌桶，按服务/API 维度），第三级 Sentinel 应用级限流（QPS/并发线程数维度，保护单实例）。三级阈值需协调配合：网关阈值 > 应用阈值 × 实例数，避免互相打架。核心原则是就近防御——在离故障源最近的地方熔断，避免故障向上游扩散。

从利特尔定律看：限流控制 λ（到达率），熔断缩短 W（减少等待时间），降级减少 L（并发请求数）。三者都在控制利特尔定律的变量，防止系统过载后雪崩。

限流算法选型矩阵：计数器适合总量控制（如每天 1000 次），实现简单但有临界突刺；滑动窗口适合平滑统计（如每秒 QPS），解决临界突刺但无法控制突发速率；漏桶适合匀速出口（如保护下游 DB），固定速率出水但不允许突发；令牌桶适合允许突发入口（如 API 网关），按需取令牌且可累积突发。实践中网关层用令牌桶（允许突发流量），下游保护用漏桶（匀速消费保护 DB），两者配合形成"入口突发 + 出口匀速"的流量整形闭环。

设计秒杀系统时，三层防线：网关限流（令牌桶 1 万 QPS）→ 订单服务熔断（错误率 50% 跳闸 10s）→ 非核心降级（关闭推荐/评论/搜索）。被问"三者区别"时，一句话："限流防外部压垮，熔断防内部级联，降级保核心链路"。

容灾能力递进模型——数据冷备 → 同城双活 → 异地双活 → 两地三中心，每一级解决上一级的单点：同城双活消除机房级单点，异地双活消除城市级单点。容灾不是一步到位，而是随业务规模和 SLA 要求逐级演进。一个日均百万级交易、SLA 99.9% 的系统上异地多活不是技术先进，是资源浪费。

异地多活的核心难题不是同步技术，而是路由闭环——单元化架构（Cell-Based）按用户维度切分流量，让读写闭环在单个单元内完成，从根本上避免跨城双写冲突。Fencing 租约锁是切换原子性的最后防线。

单元化架构三要素：① 路由层——按用户 ID 哈希取模将流量固定路由到归属单元，保证同一用户读写同一单元；② 数据同步层——基于 Binlog 增量同步做闭环复制（A→B 且 B→A），延迟控制在 50ms 内，每日全量校验补偿；③ 调度层——DNS/GSLB 入口调度 + Fencing 租约锁保证切换原子性，先停写再切流防脑裂。RPO=0 的核心在于"同步落盘后再应答"或"单元内强一致 + 跨单元异步但有补偿校验"。

被问"如何设计容灾架构"时，先反问 RTO/RPO 要求和业务规模，再给分级方案：日均百万级用同城双活够用；千万级且 SLA 99.99% 需异地双活；金融级需两地三中心。关键说清三个核心难点：单元化路由如何避免跨城双写、Binlog 闭环同步延迟与补偿、Fencing 租约锁如何防脑裂。最后补一句"每月做一次真实切流演练"——很多团队建了异地多活但从没演练过。

发布是高可用最大的变量——每次发布都是一次受控故障。灰度的本质是缩小爆炸半径：小流量验证假设，用数据决定是否放量。前置条件只有两条：可观测 + 可回滚；没有可演练回滚的灰度是在赌。数据迁移是发布的特殊形态，步骤权威在 M05.13 数据迁移四步法，本卡只讲流量面策略，不复述迁移四步。

流量染色（Header/Tag 路由）实现全链路灰度隔离：网关打标 → RPC 透传 → MQ 属性 → 影子库表。策略选型：金丝雀适合高风险；蓝绿适合需完整环境验证；滚动适合无状态服务。决策树见 M05.11，回滚原则见 M06.06。

被问"如何做零停机发布"时，四步回答：① "流量染色——网关按用户 Hash 打灰度标签，全链路透传到 RPC 和 MQ"；② "灰度策略——先金丝雀 1% 观察 RT 和错误率，达标后滚动放量到 10%→50%→100%"；③ "数据面——金丝雀打真实生产数据以验证假设；影子表/染色压测另案隔离，勿与灰度混用"；④ "回滚机制——Nacos 动态配置秒级切回全量旧版本，无需重新部署"。如果涉及数据迁移，补充"双写+校验+切流+可回滚"四步法。

容量评估的本质是"用数学证明系统能扛住大促"——从经验估算（拍脑袋）到全链路压测（数学证明）的演进。核心矛盾是"压测真实性"：压测流量模型与真实用户行为越接近，容量结论越可靠。一个关键认知：容量瓶颈永远在最弱环节，全链路压测的价值就是提前暴露这个环节。

容量评估不是一次性活动，而是持续运营：每次大促后更新容量基线，每次架构变更后重新压测，形成"压测→建模→告警→扩容"的闭环。

五步压测法：① 流量染色——压测请求携带统一标记（Header x-stress-test=1），全链路透传；② 影子隔离——压测数据路由到影子库表（stress_ 前缀），Redis 用独立 DB Index；③ Mock 兜底——第三方接口用 MockServer 返回固定响应，避免触发风控或产生费用；④ 梯度加压——从 1× 日常流量开始，每 10 分钟增加 1×，错误率 > 0.1% 或 RT 翻倍时停止；⑤ 容量建模——用 Little's Law（L = λ × W）换算：所需机器数 = (峰值 QPS × 目标 RT) / (单核处理能力 × 目标 CPU 利用率)。

被问"大促前如何做容量评估"时，结构化回答："第一步定基线——单机压测得到单实例极限 QPS 和 RT；第二步找瓶颈——全链路压测暴露最弱环节，通常是 DB 或下游依赖；第三步做隔离——流量染色 + 影子库表 + Mock 下游，确保压测不污染生产；第四步梯度加压——1×→3×→5×→10× 逐步加压，记录每级资源利用率；第五步容量建模——用 Little's Law 换算所需机器数，预留 30% 安全冗余"。

分布式一致性的本质是在 CAP/PACELC 约束下选对一致性级别与补偿边界。强一致贵（协调、锁、尾延迟），最终一致要付对账与补偿成本。能力不在背全方案，而在按业务不变量选型。经验口径：资金/库存等硬不变量优先本地事务 + 明确补偿（TCC/Saga/事务消息是手段不是宗教）；积分/通知等可延迟链路用消息表或事务消息。一刀切强一致是过度设计，一刀切最终一致且无对账是事故预警。心智层见 M07.03，模型词汇见 M09.09。

选型决策树：① Seata AT——改造小、有全局锁损耗，适合 CRUD；② TCC——侵入大但精确控制资源；③ 本地消息表——同事务落库再投递，通用最终一致；④ 事务消息——半消息协议。共同前提：幂等。不变量决定级别，工具只是实现。

被问"分布式事务怎么做"时，先分类再选型："核心交易链路（下单扣库存扣券）用 TCC——Try 冻结库存和券、Confirm 确认扣减、Cancel 释放，性能高且精确控制；非核心链路（积分、通知）用本地消息表——订单与消息同事务写入，异步投递保证最终一致。如果团队不熟悉 TCC，降级用 Seata AT——无侵入自动回滚，但 TPS 有损耗。关键强调：所有方案都必须做幂等，否则重试导致数据错乱"。

消息可靠性的本质是"用幂等 + 重试 + 死信对冲分布式系统的不确定性"——不丢、不重、不积压难以同时极致（工程上的张力，不是形式化定理），工程上通过分段保障逼近最优解。消息丢失发生在生产、Broker、消费三个环节，每个环节都需独立保障；消息重复在网络环境下不可避免，必须在业务层幂等；消息积压是生产消费速率不匹配，需动态扩容与降级。

三段式保障链路：① 生产端可靠——RocketMQ 事务消息（半消息 → 本地事务 → commit/rollback）或本地消息表（业务与消息同事务写入，定时扫描投递），保证消息一定到 Broker；② Broker 可靠——同步刷盘（SYNC_FLUSH）+ 主从同步复制（SYNC_MASTER），牺牲 30%-50% TPS 换零丢失；③ 消费端可靠——关闭自动 ACK，业务成功后手动 CONSUME_SUCCESS，失败进重试队列，16 次后进死信队列（DLQ）人工处理。幂等设计用 Redis SETNX + DB 唯一索引双保险，消息体携带 bizId 去重。顺序保证用分区顺序——同一 orderId 路由到同一 Queue，单线程消费。

被问"如何保证消息不丢不重"时，全链路分析："防丢失三段式——生产端用事务消息或本地消息表保证必达 Broker，Broker 配同步刷盘+主从复制保证持久化，消费端手动 ACK + 重试 + 死信队列。防重复——消费者维护幂等表（Redis+DB 双保险），bizId 去重。保顺序——同一业务 Key 路由到同一 Queue 分区顺序消费。治积压——三层降级：动态扩消费者、批量消费、降级非核心消息"。

CAP（Brewer 2000）：分区时一致性 C 和可用性 A 二选一。分布式系统 P 必选，故实际在 CP vs AP 间权衡。PACELC（Abadi 2010）补充了无分区时的权衡：if Partition 则 PA vs PC，Else 则 Latency vs Consistency。BASE是 AP 的实践落地：基本可用 + 软状态 + 最终一致。

典型选型：DynamoDB = PA/EL（分区时重可用，平时重延迟）；Spanner = PC/EC（分区时重一致，平时也重一致）。大多数互联网系统选 AP+最终一致，金融系统选 CP+强一致。

CAP（Gilbert–Lynch）说的是：出现网络分区时，线性一致与可用性不可兼得——不是流行课上的「C/A/P 三选二不可能三角」。PACELC 补上无分区时的延迟 vs 一致。选型时写清分区策略与平时延迟预算，而不是背「选 AP」。Dynamo/Spanner 是经典坐标，产品线已有强一致选项，勿当死标签。

被问"CAP 怎么选"时，不答"选 AP"就完了，而是用 PACELC 回答："分区时选 AP（保可用），平时选 EL（重延迟），因为用户容忍秒级延迟但不能容忍超时。如果做支付系统则反过来：PC+EC，因为一致性比延迟重要"。

最终一致性不是"不管"，而是"保证最终收敛"。手段：读修复（读时发现不一致则修复）、反熵（后台 Gossip 协议同步）、向量时钟（冲突检测）、CRDT（无冲突复制数据类型，从数据结构层面保证最终一致）。

工程实践中，缓存一致性是最常见的渐近一致性场景——"先更新 DB 再删缓存 + 延迟双删"容忍秒级不一致窗口，用最小复杂度换取可用性和性能。

BASE 中"E"（Eventually Consistent）的工程实现——不是放弃一致性，而是将同步一致性降级为异步收敛。取舍思维：用秒级不一致窗口换取写入吞吐量和系统可用性。

被问"缓存和 DB 不一致怎么办"时，回答"这是最终一致性的工程实现——先更新 DB 再删缓存，配合延迟双删解决主从延迟。如果需要强一致则用 Write-Through 模式，但写入延迟会增加 2-3 倍"。

口径：冗余/容错的总则见法层 M06.01 面向失败设计（熔断/降级/限流）；本卡只讲参数化实践（副本数、仲裁、脑裂）。

冗余是手段，容错是目的。主从冗余解决读单点；主备冗余解决写单点；多活冗余解决机房单点。故障转移的关键挑战是脑裂（split-brain）——多节点同时认为自己是主，需仲裁机制（Quorum / Raft / ZooKeeper）。故障检测要避免误判（网络抖动→假死→误切换）。

N 个副本可容忍的故障数：Paxos/Raft 需多数派（N/2+1），即 3 副本容忍 1 故障，5 副本容忍 2 故障。副本越多可用性越高但写入延迟越大（同步复制开销）。

消除单点 = 增加冗余副本。冗余副本间的数据同步引入一致性问题（CAP 取舍），副本越多一致性协调开销越大。这是"消除单点"与"减少资源竞争"之间的张力。

被问"主从切换脑裂怎么办"时，回答"Quorum 仲裁——多数派确认才算主，少数派自动降级为从。3 节点集群需 2 票当选，网络分区时少数派（1 节点）无法当选，避免双主"。被问"几个副本合适"时，回答"3 副本容忍 1 故障是性价比最高的配置"。

SLI（指标）：可用性、延迟 P99、吞吐量。SLO（目标）：如 30 天内 99.9% 请求成功。Error Budget = 1 − SLO = 0.1% 的失败请求额度（与 M11.01 同口径）；若改用时间型可用性 SLO，才可换算为约 43 分钟/月不可用，二者不可混算。核心思想：100% 可靠会扼杀创新速度。预算未用完→可加快发布、承担风险；预算耗尽→冻结新功能、转投稳定性（发布闸门执行归 M11.01；组织政策真源见 M05.10）。Burn Rate（燃烧率）监控预算消耗速度，提前告警。

把"可用性"从定性描述变为可量化的工程指标，让取舍有数据支撑。这是取舍思维在运维领域的落地——不是"越稳定越好"，而是"在错误预算内追求最大迭代速度"。

被问"如何平衡稳定性和迭代速度"时，用 Error Budget 回答："SLO 定 99.9% 请求成功，错误预算按失败请求额度核算（时间型可用性才谈分钟）。预算内放手发版（预算耗尽时的冻结与发布闸门归 M11.01）。用 Burn Rate 告警——1 小时烧掉 2% 预算就告警，不用等预算耗尽才发现问题"。

通过在生产环境主动注入故障（杀节点/断网络/满磁盘），验证系统在动荡条件下的稳态。四步实验法：①定义稳态指标（吞吐量/错误率/延迟）→ ②假设稳态在控制组和实验组都会持续 → ③注入真实故障 → ④通过寻找两组稳态差异来证伪假设。核心不是"制造混乱"而是"验证稳态假设"。

五个高级原则：围绕稳态行为建立假设、变化真实世界事件、在生产环境运行实验、自动化持续运行、最小化爆炸半径。

从被动等故障（MTBF 驱动）到主动发现弱点（MTTR 驱动），是高可用保障的演进。混沌工程把"故障演练"从偶发事件变成持续实验，让冗余和故障转移设计在真实故障前得到验证。

被问"如何验证高可用"时，回答"混沌工程——定期杀节点演练，验证故障转移是否真的自动。先在测试环境跑，再逐步到生产。重点不是'制造混乱'而是'验证稳态假设'——如果杀一个节点系统吞吐量下降，说明负载均衡或健康检查有问题"。

全生命周期四阶段——①设计期（冗余架构 + SLO 定义）→ ②开发期（防御性编程 + 故障测试）→ ③运行期（监控告警 + 混沌演练）→ ④故障期（止血→排查→复盘→改进）。每阶段有明确产出物和检查点，形成闭环。

关键认知：高可用不是一次性设计，而是持续运营。设计期的冗余架构决定上限，运行期的混沌演练决定下限，故障期的复盘改进决定演进速度。

将"消除单点"从一次性设计变成持续运营的闭环流程。演进思维在高可用领域的落地——每次故障都是高可用能力的演进输入，每次混沌演练都是对冗余设计的验证。

被问到"你的高可用方案"时，按四阶段回答而不是只讲架构图："设计期——多副本+自动 failover+SLO 定 99.95%；开发期——防御性编程+故障注入测试；运行期——Prometheus 告警+月度混沌演练；故障期——5 分钟止血+24 小时复盘+改进项跟踪"。

总骨架见 M05.01 事前-事中-事后。

性能优化不是"调参数"，而是"消除等待"。等待来自四类——CPU 等待（计算密集）、IO 等待（磁盘/网络）、锁等待（并发竞争）、GC 等待（内存回收）。先 profiling 定位等待类型，再对症下药。二八定律：80% 性能问题来自 20% 代码。

关键认知：不同等待类型的优化路径完全不同——CPU 等待优化算法/数据结构、IO 等待加缓存/批处理/异步、锁等待减少临界区/用无锁结构、GC 等待调 GC 参数/减少对象分配。混淆等待类型是性能调优最常见的错误。

资源竞争的不同形态——CPU 竞争（计算资源）、IO 竞争（带宽资源）、锁竞争（并发资源）、内存竞争（GC 回收资源）。高性能思维就是精准识别竞争类型并消除它。

被问"系统慢怎么排查"时，先问"CPU 高还是 IO 高"——CPU 高看火焰图找热点方法，IO 高看慢查询日志找磁盘瓶颈，锁竞争看线程 dump 找 BLOCKED 线程，GC 频繁看 GC 日志找 FullGC 原因。不同等待类型走不同路径。

分层 ROI 方法论见 M10.03；JVM 调参入口见 M10.02。本卡先分清四类等待。

分层优化，ROI 递减——架构层（缓存/异步/拆分，10 倍提升）→ 系统层（连接池/线程池/IO 模型，2-5 倍）→ 应用层（算法/批处理，2-3 倍）→ 代码层（减少锁/避免逃逸，1.5 倍）→ JVM 层（GC 调优，1.2 倍）→ 硬件层（SSD/内存，1.5 倍）。先解决上层瓶颈再往下走。

关键认知：一个缓存可能比所有 JVM 调优加起来效果大。过早优化是万恶之源——先测量再优化，遵循二八定律。

每一层都在消除该层的资源竞争——架构层消除请求级竞争（缓存减少 DB 访问），系统层消除资源级竞争（连接池减少连接创建），JVM 层消除 GC 停顿竞争。上层竞争消除后，下层竞争才会暴露。

被问"性能优化从哪入手"时，回答"从架构层——一个缓存可能比所有 JVM 调优加起来效果大。先加缓存解决 80% 的 DB IO 等待，再考虑连接池/线程池优化系统层，最后才到 JVM GC 调优。过早优化是万恶之源"。

性能落地检查单

• 目标量化：延迟 / 吞吐 / QPS 目标与基线已测出？
• 瓶颈定位：profile / 火焰图确认热点，非拍脑袋？
• 压测口径：压测场景 / 数据 / 并发模型与生产对齐？
• 优化优先级：按 ROI 分层（架构→系统→应用），先高后低？
• 回归防护：性能基线测试进 CI，防止劣化回潮？

高性能思维（四类等待）见 M10.01；定目标函数见 M10.02。本卡给分层优化次序。

公理层「近则快」见 M01.14 局部性原理。本卡只谈术：存储层次链 L1/L2/L3 → 内存 → SSD → 磁盘 → 网络，每远一层延迟约高一个数量级。优化动作是把热点往上层推，并认清每一层都是速度 vs 容量的取舍。ClickHouse 类 OLAP 可放弃热缓存、用并行扫盘换扩展，不适合 OLTP 延迟画像。Buffer Pool 命中率、缓存行对齐、批量预读，都是局部性在引擎上的落点——先问数据在哪一层，再谈调 SQL。

时间局部性 → 热点缓存 / TTL 策略；空间局部性 → 预读、批处理、顺序 IO。B+ 树叶子链表适合磁盘预读，是空间局部性的教材例；缓存有效 = 局部性被利用，而不是「多加一层 Redis」本身。

被问"如何优化慢查询"时，第一问"数据在内存还是磁盘"——Buffer Pool 命中率是第一指标。如果命中率低于 95%，说明数据频繁从磁盘读取，优化索引让热点数据留在内存比调 SQL 更有效。

被问"为什么 B+ 树比 B 树更适合数据库"时，用空间局部性回答——"B+ 树叶子节点用顺序链表连接，磁盘预读时可以一次性读取连续页，利用空间局部性。B 树非叶子节点也存数据，预读效率低"。

四种缓存模式——Cache-Aside（旁路，最常用，应用负责一致性）、Read-Through（读穿透，缓存层代理读 DB）、Write-Through（写穿透，同步写缓存+DB，强一致但延迟高）、Write-Behind（异步写回，只写缓存异步刷 DB，高吞吐但有丢失风险）。写操作推荐"先更新 DB 再删除缓存"而非更新缓存，避免并发写导致脏数据。

缓存三大问题：穿透（查不存在→布隆过滤器/缓存空值）、击穿（热点 key 过期→互斥锁/永不过期+异步更新）、雪崩（大量 key 同时过期→过期时间加随机偏移/多级缓存/高可用集群）。

缓存 = 空间换时间 + 局部性利用。把数据从慢层（磁盘）推到快层（内存），利用时间局部性（热点数据反复读）。三大问题本质是缓存失效后的资源竞争——穿透是无效请求竞争 DB、击穿是并发请求竞争同一 DB 行、雪崩是大量请求同时竞争 DB。

设计缓存方案时，先选模式（Cache-Aside 默认）、再防三大问题、最后考虑一致性策略。被问"缓存一致性怎么保证"时，回答"先更新 DB 再删缓存+延迟双删，容忍秒级不一致。需要强一致则 Write-Through 但写入延迟翻倍。没有完美方案只有合适场景"。

三种引擎各有定位——B+Tree（行存）：OLTP，点查/范围查/事务，MySQL InnoDB，读优化。列存：OLAP，聚合分析，ClickHouse/Doris，压缩率高只读所需列。LSM-Tree：写多读少，HBase/Cassandra/RocksDB，随机写转顺序写+后台 compaction，写优化但有读放大/空间放大。

选型决策树：事务+点查→B+Tree、分析聚合→列存、海量写入→LSM-Tree。没有万能引擎，选型本质是取舍——读优化牺牲写、写优化牺牲读、分析优化牺牲事务。

不同引擎优化不同局部性——B+Tree 优化点查局部性（索引定位）、列存优化列级聚合局部性（只读所需列）、LSM-Tree 优化写入局部性（顺序写）。选型就是选择优化哪种局部性。

被问"为什么不用 MySQL 做分析"时，回答"行存在聚合时要扫全行（100 列读 5 列浪费 95 列 IO），列存只读所需列+高压缩率，10-100 倍差距。MySQL 适合 OLTP 点查事务，ClickHouse 适合 OLAP 聚合分析"。

术侧四象限，道在 M01.08 代价转移与资源守恒。空间换时间：缓存、索引、预计算、冗余。时间换空间：压缩、稀疏、懒加载。彼时间换此时间：预热、批处理、错峰、异步。彼空间换此空间：多级缓存、CDN、分片。

反向取舍：OLAP 列存常不靠行级热缓存吃满命中率，而用高压缩 + 只读所需列 + 并行扫盘换吞吐——是「少读无效字节」相对「堆行级缓存」的路径，不是「放弃内存」。ClickHouse 仍大量用内存（查询缓存、字典、uncompressed cache）；真正放弃的是 OLTP 点查与行级事务便利。

取舍思维在性能领域的体现——不是所有场景都空间换时间。OLTP 热点少，缓存有效；OLAP 宽表扫描多，行级缓存命中率低，列存压缩+并行扫描往往更优。

被问"为什么用 Redis"时，回答"空间换时间——用内存空间换磁盘 IO 时间，代价是内存成本和一致性。但如果场景是全表扫描的 OLAP，缓存命中率低，不如用列存+并行扫描"。

结构化五步——①测量（profiling 定位瓶颈，火焰图/Arthas）→ ②假设（基于分层方法论推测瓶颈层）→ ③实验（针对性优化一层）→ ④验证（对比优化前后指标）→ ⑤回归（确保无副作用）。先测量再优化，避免过早优化。

关键认知：不测量就优化等于盲人摸象。性能优化的第一步永远是 profiling，不是猜。优化后必须回归测试——一个"优化"可能引入新的性能问题（如缓存减少了 DB 压力但增加了 GC 压力）。

将"减少资源竞争"从直觉变为可重复的工程流程。测量找到竞争点，假设推测竞争类型，实验消除竞争，验证竞争是否消除，回归确保不引入新竞争。

被问到"系统 RT 突然升高怎么排查"时，按五步推进——"第一步 Arthas 看火焰图定位热点方法，不要猜。假设是 DB 慢查询，实验加索引/缓存，验证 RT 下降，回归确保不影响写入"。

总骨架见 M05.01 事前-事中-事后。

并发正确性的三个维度（可见性 / 原子性 / 有序性）已在 M05.06 并发三性总则 立总则。本卡聚焦 Java 如何以 JMM 与原语兑现这三性：理解 JMM、happens-before、线程池、锁、CAS、AQS、CompletableFuture、虚拟线程；认清三大并发问题的 Java 表现。共享可变状态是万恶之源——优先不可变对象、并发集合、无状态。

volatile 保证可见性但不保证原子性；synchronized 与 ReentrantLock 实现互斥；CAS + AQS 支撑并发包；不可变对象天然无并发问题。异步不是目的，解耦和吞吐才是；虚拟线程让同步代码获得并发能力，缓解阻塞代价。

被问并发问题，从"共享可变状态"切入：能不可变更不可变、能无状态则无状态、必须共享则用并发集合与显式锁；区分业务线程池与 IO 线程池避免相互阻塞。追问时说清三大并发问题与对应的解决手段。

成对卡见 M12.02 并发先三性后原语：先分型负载与取消语义，再选锁/CAS/VT；虚拟线程盯 pin 与同步阻塞。上下文显式传递，拒绝隐式 ThreadLocal 穿透请求边界。

理解对象生命周期、GC 算法、类加载机制、JIT、字节码；写代码时考虑对象的创建成本、内存占用、逃逸分析、GC 压力。调优时看 GC 日志、堆转储、JFR/JMC。写 JVM 友好的代码是 Java 专家的底色。

GC 分代与算法选择影响吞吐与延迟；逃逸分析/标量替换决定能否栈上分配；避免过度创建、超大对象、无界缓存，合理设置堆与 GC 参数。Java 工程原则：优先不可变对象、减少 Raw Types（泛型保类型安全）、遵循 Effective Java 条目。

被问"线上 OOM 或 GC 问题"，按"现象→堆转储/GC 日志→定位→调参或改码→验证"作答；追问时展示对类加载与元空间/堆的分层理解。强调 JVM 调优一定以数据（JFR/JMC）驱动，不靠猜。

成对卡见 M12.04 JVM 落区归因与容器预算：先分诊 OOM vs OOMKilled，再把堆/元空间预算映射 cgroup；先证据链（JFR/heap dump）再改 -Xmx。

Spring 核心是 IoC 和 AOP——理解 Bean 生命周期与自动配置原理；不滥用反射与动态代理；声明式事务要理解传播机制与失效场景。数据访问要理解事务边界、ORM 阻抗失配、N+1 问题、连接池、批处理、分页。

IoC 反转让依赖从硬编码 new 变为容器注入（依赖倒置落地）；AOP 把事务/日志/安全等横切关注点抽离。数据库视角：索引设计、慢 SQL、读写分离、分库分表；缓存设计处理穿透、击穿、雪崩与一致性。

被问"为什么 Spring 事务失效"，从代理机制（自调用、非 public 方法、异常被吞）作答；被问"列表查询慢"，答 N+1→使用批量抓取或联查。体现你对框架机制与底层 SQL 语义都懂，而非只会用注解。

成对卡见 M12.06 Spring 代理边界与配置契约：代理边界决定事务是否生效；配置即契约；启动失败即失败——条件装配必须可解释，半初始化不接流量。

安全不是功能，是约束：假设每个组件都会被攻破，问「它失守后系统是否仍可接受」。四原则（最小权限 / 零信任 / 纵深 / 左移）的立法在法层 M06.10，本卡不再复述定义；术侧补失败安全（异常默认拒绝）与够用的安全——攻击成本高于收益即可，金融可上 HSM，普通业务不必按金融选型。

OWASP Top 10 与 NIST 零信任把约束落成检查面：访问控制失效、加密失败、认证失效、供应链、异常处理。CIA 三性（机密/完整/可用）与限流、脱敏、密钥轮转同表评审。招式卡：纵深 M13.02、认证 M13.03、数据保护 M13.04、密码学 M13.05。

被问安全架构时，先挂法层四原则（M06.10：最小权限 / 零信任 / 纵深 / 左移），再补术侧失败安全（异常默认拒绝、不泄堆栈）。落地：权限与凭证→M13.03；纵深与网关→M13.02 / C10.13；左移门禁→M06.11；密码学与数据→M13.04/M13.05。安全是成本权衡，按业务敏感度选型，不另立第二套「四大」。

纵深防御的核心是"不把鸡蛋放在一个篮子里"——网络层、应用层、数据层各自独立防护，任一层被突破不导致全盘失守。业务层不可将安全责任完全外包给网关或框架——WAF 拦不住业务逻辑漏洞，Spring Security 挡不住 SQL 注入如果用了 ${} 拼接。

四道纵深防线：认证授权（你是谁、你能做什么）→ 会话管理（会话令牌安全、CSRF 防护）→ 输入验证（白名单优先、注入防御）→ 输出编码（按上下文编码、CSP 策略）。每道防线独立有效，不依赖前一道。

输入安全三原则：白名单优先（只允许已知合法输入，黑名单永远不完备）、全入口校验（所有外部数据都需校验，包括 HTTP 参数、Header、MQ 消息、文件内容）、上下文输出编码（HTML 上下文用 HTML 实体编码、JS 上下文用 JS 编码、URL 上下文用 URL 编码）。注入防御：SQL 用 #{} 不用 ${}，命令注入用白名单参数化，XXE 禁用外部实体，反序列化禁原生 ObjectInputStream 处理不可信数据。CSRF 防护：SameSite Cookie + anti-CSRF token，GET 禁止状态变更。

被问"你的 Web 安全防护体系"时，四道防线回答："第一道认证授权——OAuth2+JWT+RBAC，服务端强制校验不信任前端；第二道会话管理——HttpOnly+Secure+SameSite Cookie，CSRF 用 token 防护；第三道输入验证——MyBatis #{} 防注入、文件上传魔数校验、反序列化用 ObjectInputFilter；第四道输出编码——按上下文编码 + CSP 策略防 XSS"。强调"每道防线独立有效，不依赖前一道"。

认证（Authentication）解决"你是谁"，授权（Authorization）解决"你能做什么"——两者不可混淆，认证通过不等于授权通过。口令存储的核心原则是"加盐 + 自适应慢哈希"，工作因子可随硬件升级定期提升，使 GPU 爆破成本始终高于攻击收益。

授权遵循默认拒绝原则：权限显式授予，未明确允许即禁止。服务端必须强制执行授权校验，不可信任前端的隐藏菜单、按钮或路由守卫。IDOR（不安全直接对象引用）是最常见的授权漏洞——用自增 ID 暴露资源且不做归属校验。

口令存储优先级链（OWASP Password Storage）：Argon2id（PHC 获奖，抗 GPU/ASIC，内存困难型）> scrypt > bcrypt（cost ≥10）> PBKDF2-HMAC-SHA-256（迭代 ≥600000；若用 SHA-512 则 ≥210000）。禁用 MD5/SHA-1/SHA-256 直接哈希口令（CWE-916），禁用全局共享 salt（CWE-759/760）。OAuth2 用授权码 + PKCE，禁用隐式流程。JWT 必须显式指定算法防 alg=none 攻击，access_token 短生命（15min），refresh_token 可撤销。MFA 中 TOTP 优于短信 OTP（SIM 劫持风险），WebAuthn/Passkey 抗钓鱼。

被问"口令怎么存"时："用 Argon2id 加盐慢哈希，每用户唯一 salt，工作因子定期评估。禁止 MD5/SHA 直接哈希——GPU 秒级爆破"。被问"OAuth2 安全"时："用授权码 + PKCE，严格白名单匹配 redirect_uri，校验 state 防 CSRF；OIDC 另校验 nonce 防重放，禁用隐式流程"。被问"JWT 安全"时："显式指定算法防 alg=none，access_token 15 分钟过期，refresh_token 可撤销，不存敏感信息在 payload"。

数据保护三维度——机密性（加密存储 + 传输加密）、完整性（HMAC/签名校验）、可用性（备份 + 冗余）。密钥全生命周期管理是核心：生成 → 存储（HSM/KMS）→ 轮换 → 销毁（byte[] 清零）。密钥泄露等于加密形同虚设。

错误处理是安全被忽视的攻击面——OWASP 2025 新增 A10「异常条件处理不当」。失败安全原则：异常时默认拒绝，不泄露堆栈信息，不降级为明文处理。生产环境必须关闭 actuator/swagger 调试端点。

数据保护工程实践：敏感数据加密存储——3 亿用户敏感数据用 AES-GCM 加密，密钥存 HSM/KMS 不落库；密钥轮换——定期轮换（如 90 天），旧密钥只解密不加密，双密钥过渡期平滑迁移；数据脱敏——手机号脱敏为 138****8888，身份证脱敏为前 6 后 4，日志全链路脱敏；API 响应最小化——字段裁剪只返回必要字段，分页防全量爬取；错误处理——全局异常处理器返回统一错误码，不输出堆栈到客户端，日志记录完整堆栈但不返回；审计日志——记录安全事件 who/what/when/result，禁止记录口令/密钥/令牌，日志防篡改。

被问"敏感数据怎么保护"时，三维度回答："机密性——AES-GCM 加密存储，密钥存 KMS 不落库，90 天轮换，TLS 1.3 传输加密；完整性——HMAC 或数字签名校验；不可否认——仅非对称签名（HMAC 不能抗抵赖）；可用性——异地备份+冗余。补充：日志全链路脱敏（手机号 138****8888），API 响应最小化只返回必要字段，生产关闭 swagger/actuator 调试端点，异常处理不泄露堆栈"。

密码学第一原则：不自实现密码算法——用 JCA/Bouncy Castle 标准库，不自己拼 AES/RSA。Kerckhoffs 原则：安全性依赖密钥而非算法保密。AEAD（认证加密）优先——同时提供机密性和完整性，AES-GCM 是事实标准。

NIST SP 800-131A 将 SHA-1、RSA-1024、两密钥 3DES 等列入过渡/禁用路径；DES/RC4 等更早被业界与相关规范弃用——选型以当前 SP 800-131A 与 FIPS 批准算法为准，勿把 RC4 误记为 131A 专表条目。后量子密码（PQC）标准 ML-KEM/ML-DSA/SLH-DSA 已于 2024 年正式发布（FIPS 203/204/205），高风险系统 2030 前需启动迁移。

选型速查：对称加密用 AES-128/256-GCM（AEAD，IV 不可重复，禁 ECB），非对称加密用 RSA-OAEP（≥2048 位），签名用 RSA-PSS 或 ECDSA（确定性签名 RFC6979），哈希用 SHA-256/SHA-3（禁 MD5/SHA-1），口令哈希用 Argon2id（每用户 salt + pepper 分离存储），MAC用 HMAC-SHA-256/512（常量时间比较），随机数用 SecureRandom CSPRNG（禁 java.util.Random/Math.random），TLS≥1.2 优选 1.3（ECDHE+GCM，HSTS，禁 trustAll）。密钥管理：生成用 KeyGenerator，存储用 HSM/KMS，轮换有周期，销毁用 Arrays.fill 清零 byte[]。

被问"加密算法怎么选"时，分类回答："对称加密用 AES-GCM——AEAD 同时提供机密性和完整性，IV 不可重复，禁 ECB；非对称用 RSA-OAEP 2048 位以上；哈希用 SHA-256 或 SHA-3，禁 MD5/SHA-1；口令用 Argon2id 加盐慢哈希；随机数用 SecureRandom 不用 Random；TLS 1.3 + HSTS"。最后强调"不自实现密码算法，用标准库"。

核心原则——"先止血再排查"。故障发生时优先恢复服务；止血动作按故障类型选路（变更引入→回滚；过载→降级/限流/扩容；机房/依赖域故障→切流量），不要把「切流量」固定排在末位当普适全序，不要在故障现场 debug。保留现场（dump/日志）后离线分析。止血速度决定 MTTR，MTTR 决定可用性。

关键认知：在故障现场 debug 是最大的错误——每多一分钟排查，MTTR 就多一分钟，用户影响就多一分钟。正确做法是：先止血恢复服务，保留现场快照（jstack/jmap/tcpdump），然后离线分析。

线上问题处理是高可用设计的兜底防线——设计再好也会有故障，排障能力决定故障影响范围。止血优先 = 降 MTTR = 提可用性。这和高可用思维中"Availability = MTBF/(MTBF+MTTR)"直接对应。

被问"线上 CPU 100% 怎么办"时，第一句"先止血——扩容/限流保业务，同时 jstack dump 线程保留现场。然后离线分析 dump 找死循环/GC 频繁的原因。不要在生产环境直接 debug"。

四步闭环——①止血（恢复服务，保留现场）→ ②定位（可观测性三支柱交叉定位）→ ③根因（5Whys 深挖）→ ④复盘（blameless postmortem + 改进项跟踪）。每步有明确的工具和产出物。

常见误区：跳过止血直接 debug（MTTR 飙升）、止了血不保留现场（根因丢失）、复盘变成追责会（团队不敢报问题）、有改进项无跟踪（同样的问题反复发生）。

将"找出单点"从设计阶段延伸到运行阶段——排障就是在故障中找单点。止血是"隔离故障单点"，定位是"找出故障单点"，根因是"理解单点为何故障"，复盘是"防止单点再次故障"。

描述一次线上故障处理经历时，按四步闭环讲述——"先止血（3 分钟回滚恢复服务），保留 jstack dump 后定位（Arthas 找到死锁线程），根因（5Whys 发现是锁顺序不一致），复盘（加锁顺序规范+静态检查工具+改进项跟踪）"。突出止血速度和复盘改进。

排障检查单

• 止血：先恢复服务、保留现场（dump / 日志）？
• 定位：可观测三支柱交叉，缩小范围？
• 根因：5Whys 深挖到机制层面？
• 复盘：blameless，改进项有 owner / 期限 / 验证？
• 防呆：把根因变成检查 / 自动化，避免再发？

故障自愈的本质是"把人的经验沉淀为机器的自动决策"——从人工排障（MTTR 15 分钟）到自动止血（MTTR 小于 5 分钟）的跃迁。核心不是"替代人"，而是把高频、有确定处理方案的故障自动化，让人聚焦于复杂、未知的故障。

自愈的边界：网络抖动、实例 OOM、依赖超时、以及已演练的自动 failover 可自愈；数据损坏、错误配置扩散、未演练的脑裂/切换须人工介入。自愈动作必须可回滚、可观测——"宁可慢一点摘除，也不要误摘除"。

"感知 → 决策 → 执行 → 恢复"四阶段闭环：感知层——多级健康检查（K8s Liveness/Readiness 探针 + 自定义业务探针检测 DB/Redis 连通性）+ 监控指标实时采集；决策层——基于规则的决策引擎（连续 N 次失败摘除、超时 M 秒重启），结合熔断器状态判断故障等级；执行层——渐进式摘除（先降权重 50% → 观察 → 全摘除）、重启容器、切流；恢复层——健康检查恢复后自动加回流量，未完成请求走幂等重试 / 补偿队列 / 事务消息，而非 Binlog 回放。核心原则：自愈动作要可回滚、可观测，自愈与人工干预的边界通过告警升级机制区分。

被问"如何实现故障自愈"时，四阶段闭环回答："感知层——K8s Liveness/Readiness 探针 + 自定义业务探针检测依赖连通性，5 秒一次；决策层——规则引擎判断：连续 3 次失败摘除、OOM 重启、单机房故障切流；执行层——渐进式摘除先降权重 50% 观察，不是一刀切；恢复层——健康检查通过后自动加回流量，切流时未完成请求走幂等重试 / 补偿队列 / 事务消息，而非 Binlog 回放。最后强调自愈边界：可自愈的自动化处理，不可自愈的告警升级到人工"。

三支柱各有定位——Metrics（可聚合，低成本，回答"发生了什么"，告警驱动）、Logging（离散事件，高成本，回答"为什么发生"，诊断驱动）、Tracing（请求作用域，中等成本，回答"在哪里发生"，调用链驱动）。三者互补不替代，运维成本梯度：Metrics（低）→ Tracing（中）→ Logging（高）。

关键认知：没有可观测性就是"盲飞"——故障发生了不知道，知道了不知道在哪，找到了不知道为什么。可观测性是高可用和线上排障的基础设施。

术层口径：三支柱信号的立法见法层 M06.07 可观测性三支柱；本卡只讲用法——各自定位、成本梯度、交叉定位，不复述原则。

可观测性是"找出单点"在运行阶段的眼睛——Metrics 发现异常（单点表现），Tracing 定位链路（单点位置），Logging 提供细节（单点原因）。三者交叉验证才能精确定位。

被问"如何设计监控系统"时，按三支柱回答——"Metrics 做告警（Prometheus + Grafana，低成本高覆盖），Logging 做诊断（ELK，高成本但细节全），Tracing 做定位（Jaeger，中等成本串联调用链）。三者通过 traceId 关联，告警触发后可快速跳转到 trace 和 log"。

丰田生产系统方法论——对问题连续追问"为什么"直到触及根本原因。原则：关注流程和系统问题而非"谁犯错"（blameless）；避免停留在表面现象或人为失误；根因应指向可改进的系统/流程/自动化缺陷。Google SRE 提倡无指责复盘（Blameless Postmortem）——假设所有人在当时信息下做了最佳决策。

复盘是"演进思维"在故障领域的应用——每次故障都是系统演进的输入。5Whys 是"递归拆分"在故障分析中的体现：把"大问题"一层层拆成"小根因"，直到找到可修复的最底层。

描述复盘流程时，给出 5Whys 示例——"为什么超时？→GC 停顿 3s →为什么 GC 停顿？→FullGC →为什么 FullGC？→老年代空间耗尽 →为什么耗尽？→未分页一次加载 10 万条导致大对象晋升高频填满老年代 →根因：代码缺陷 + Code Review 缺失。改进：加分页 + Review checklist + 大对象告警"。

完整时间线——告警触发 → 值班响应（3min 内）→ 止血决策（回滚/降级/限流）→ 现场保留（jstack/jmap/tcpdump）→ 根因排查（日志+链路+监控交叉）→ 修复验证 → 复盘文档（24h 内）→ 改进项落地（负责人+截止日）→ 混沌演练验证。关键指标：MTTD（发现时间）、MTTR（恢复时间）。

将"止血→排查→复盘"从经验变为可重复的标准流程。每个环节都有明确的工具、产出物和时间要求，确保不同的人处理同一个故障都能达到相同的效率和质量。

被问到"讲一次你处理的线上故障"时，按完整时间线讲述——"告警触发（Prometheus P99 延迟告警）→ 3 分钟响应 → 5 分钟止血（回滚上一次发布）→ 保留 jstack → 离线分析定位死锁 → 24h 内复盘文档 → 改进项（加锁顺序规范+静态检查+混沌演练验证）。MTTR 15 分钟"。

总骨架见 M05.01 事前-事中-事后。