Appearance
应急预案三板斧：限流、降级、切流
定位：金融级稳定性方法论（3/6）。故障发生后的前 10 分钟，架构师能动的只有三个动作。限流（少接一点）、降级（少做一点）、切流（换一拨机器做）。本篇写三板斧各自的适用瞬间、预案的自动化与预案库、演练驱动，以及"1-5-10"应急响应目标。前置阅读：SLO 与稳定性工程（为什么恢复优先于定位）。容量阈值从哪来见 容量规划与全链路压测。切流操作的细节见 系统切流通用方案。
一、三板斧总览：三个动作对应三种故障形态
| 动作 | 解决的故障形态 | 生效时间 | 代价 | 决策难度 |
|---|---|---|---|---|
| 限流 | 过载（流量 > 容量） | 秒级 | 拒绝部分请求 | 低：阈值可预置 |
| 降级 | 依赖故障（下游挂了） | 秒级 | 功能损失 | 中：降谁、降到什么方向 |
| 切流 | 机房级故障 | 分钟级 | 损失一半容量，切回要谨慎 | 高：不可轻易撤销 |
用户流量
│
▼
┌───────────┐ 过载 ──► 限流：入口/热点/DB 前，拒绝超额部分
│ 网关/LB │────────────────────────────────────┐
└───────────┘ ▼
│ （超额请求被拒绝）
▼
┌───────────┐ 依赖故障 ──► 降级：非核心链路熔断让路，
│ 核心服务 │──────► 依赖（风控/征信/营销/消息）
└───────────┘ 核心依赖走安全侧策略
│
▼
┌───────────┐ 机房级故障 ──► 切流：单元化路由摘掉故障单元，
│ 机房 A/B │ 流量整体迁移（见系统切流通用方案）
└───────────┘判断顺序自上而下。先问"是不是流量问题"（限流），再问"是不是依赖问题"（降级），最后问"是不是场地问题"（切流）。三板斧可以叠加使用——切流后剩余容量减半，通常要配合限流。
二、限流：过载的瞬间
- 三层布防：入口限流（网关全局 QPS，保住大盘）。热点参数限流（单账户/单商户维度，防刷子与重试风暴打穿分片）。资源前限流（DB/渠道连接前设闸，保护最先死的那个资源）。
- 阈值从压测来，不是拍的。容量验证到拐点在 8 万 QPS、日常水位目标 50%，则入口限流按双活容量折算。数字链条见 容量规划与全链路压测。
- 金融的限流要按业务优先级分级，不是先到先得：放款/还款交易 > 账单查询 > 营销活动。账单日容量吃紧时先停营销查询，绝不能让"查询把扣款挤出去"。
限流算法选型速查：
| 算法 | 特点 | 适用 |
|---|---|---|
| 固定窗口计数 | 最简单，窗口边界有 2 倍突刺风险 | 粗粒度兜底 |
| 滑动窗口 | 平滑边界问题，内存略高 | 入口全局限流 |
| 令牌桶 | 允许突发（桶里攒令牌），平均速率可控 | 大多数场景默认 |
| 漏桶 | 绝对平滑，削峰填谷 | 保护脆弱下游（如渠道调用） |
| 集群限流（中心配额） | 全局精确，依赖中心组件可用性 | S0 资金链路，必配本地兜底 |
集群限流的陷阱：中心配额服务自己挂了怎么办——必须能降级到"本机令牌桶按节点数均摊"。否则限流组件成了新的单点。它的故障形态本身就该在混沌演练的注入清单里，见 混沌工程与故障演练。
- 反例一：只在入口限流，DB 慢查询把连接池拖死——入口 QPS 还没到阈值，库先死了。保护点要放在最先死的资源前面，而不是流量进来的地方。
- 反例二：限流返回"系统繁忙"但客户端疯狂重试，实际流量放大 3 倍——限流响应必须携带"退避指令"（重试间隔/不重试标记），否则限流本身制造重试风暴。
三、降级：依赖故障的瞬间
降级的核心是预先回答一个问题：这个依赖挂了，核心业务能不能继续，以什么姿态继续。
- 非核心链路：直接关。营销推荐、积分计算、消息通知——开关一键关闭，主链路吞吐立刻回升。这些开关要在方案设计期就埋好（见 如何出一个技术方案 的"异常与降级"一节）。
- 核心链路：读写分开定方向。
- 读场景可以兜底：额度查询超时，返回带标注的缓存旧值，可用性换弱一致。
- 写场景必须安全侧：风控决策超时，动作是拒绝放款而不是"放行兜底"或"给默认额度"。金融的降级方向是"宁可少做，不可做错"（对照 SLO 与稳定性工程 的资损定级）。
- 反例（真实教训型）：降级逻辑写成"风控超时返回默认通过"，上线半年无人触发，某次风控集群故障两小时内放出去的每一笔都是没有决策过的——降级预案里最危险的一句话就是"给个默认值继续跑"。
- 工程要求：降级开关默认值 = 安全值。支持按比例降级（10% → 50% → 100%，观察生效）。降级本身要有监控（降级命中率、降级期间的交易通过率）。
降级清单（设计期就要填好的表，随方案评审一起过）：
| 依赖 | 类型 | 降级动作 | 方向 | 开关名 |
|---|---|---|---|---|
| 营销推荐 | 非核心 | 直接关闭，返回默认位 | 可用性 | deg_marketing_off |
| 风控决策 | 核心写 | 超时拒绝放款 | 安全侧 | deg_risk_reject |
| 额度查询缓存 | 核心读 | 返回带标注旧值 | 弱一致 | deg_quota_stale |
| 短信通知 | 旁路 | 停发 + 入库延后补发 | 延迟 | deg_sms_hold |
四、切流：机房级的瞬间
- 触发条件：整个机房的电力/网络/核心交换故障，或区域性灾难——前两板斧对"场地没了"无效。
- 决策与预授权：切流是重动作，等汇报链走完损失已经扩大。正确机制是预授权。满足预设条件时，值班架构师有权直接执行，事后复盘。预设条件如：核心 SLI 在故障机房归零且持续 N 分钟、探测确认非应用层问题。授权条件写进预案库，而不是靠临场勇气。
- 单元化下的切流本质是路由表操作：摘掉故障单元，流量按权重摊到健康单元，分钟级完成。难点在数据层（切流前的增量复制、切流后的双向对账）。见 系统切流通用方案 的白名单到百分比节奏。
- 反例：切流演练只切了"入口流量"，没切定时任务。切流后两个机房同时跑扣款 Job，重复扣款直接把 P2 故障升级成 P1 资损。切流清单必须覆盖：流量、Job、MQ 消费组、回调地址。
五、预案的自动化与预案库
一条预案的标准结构：
预案 = 触发条件（指标 + 阈值 + 持续时间）
+ 动作（限流到 X% / 关闭 Y 开关 / 摘除 Z 单元）
+ 影响面评估（受影响的业务、比例、预估客诉）
+ 回退方法（恢复条件 + 回退动作 + 验证）
+ 责任人与预授权级别（自动 / 值班一键 / 需审批）- 分级自动化：熔断类不需要人（自动预案）。限流降级做成"一键执行 + 平台审批留痕"（半自动）。跨机房切流保留人工确认但预授权（手动预案要有 runbook）。
- 预案库按"故障场景 × 系统"索引。每次故障复盘的产出之一就是"新预案入库"或"旧预案修正"。预案库的更新频率是稳定性投入是否落地的真实指标。
- 执行结果要验证生效。点了限流按钮，平台要回读"当前入口 QPS 是否真的降下来了"，而不是只记录"按钮已按下"。反例：预案库里躺着 200 条预案，真故障时发现开关早已失配。服务改了名、脚本里写死的机器 IP 扩容后失效。预案不演练 = 没有预案，演练机制见 混沌工程与故障演练。
预案库片段示例（按"场景 × 系统"索引，平台可一键执行）：
| 编号 | 场景 | 动作 | 触发 | 自动化级别 |
|---|---|---|---|---|
| YJ-001 | 入口 QPS 超容量 120% | 网关限流降到安全水位 | 自动（压测阈值联动） | 自动 |
| YJ-014 | 风控决策超时率 > 50% | 放款走安全侧拒绝 + 营销全停 | 一键 | 半自动 |
| YJ-032 | 账单 DB 主库不可用 | 主从切换 + 扣款 Job 暂停重入 | 一键（值班预授权） | 半自动 |
| YJ-051 | 机房级失联 | 单元化切流摘机房 | 双人确认 + 预授权 | 手动（runbook） |
六、1-5-10：应急响应的时间目标
| 阶段 | 目标 | 支撑手段 | 对应文档 |
|---|---|---|---|
| 1 分钟发现 | 告警必须先于客诉 | 业务 SLI 告警 + burn rate 告警，告警带维度与责任路由 | 观测性三件套 |
| 5 分钟定位 | 说出故障在三板斧哪一层 | 分层 dashboard、变更时间线对齐、trace 快速归因 | 问题定位步骤 |
| 10 分钟恢复 | 预案执行完成且生效校验通过 | 预案自动化 + 预授权 + 演练肌肉记忆 | 本篇 + 混沌工程篇 |
MTTR 分解（按月看趋势，别混成一个大数）：
MTTD ───► MTTA ───► MTTI ───► MTTF
发现 响应 定位 止血
≤1min ≤2min ≤5min ≤10min（从事发点计）
│ │ │ │
告警体系 oncall dashboard 预案自动化
覆盖度 纪律 +变更时间线 + 预授权两个关键认知：
- 恢复不等定位。10 分钟的目标不是"找到根因"而是"止血完成"——先三板斧，再查根因。见 问题定位步骤 的"先止血再找根因"。用 MTTR 分解度量：MTTD（发现）+ MTTA（响应）+ MTTI（定位）+ MTTF（止血），每段单独看趋势，别混在一个大数里自我安慰。
- 1-5-10 是设计目标不是考核口号。做不到 1 分钟发现，先补监控覆盖。做不到 5 分钟定位，先补 dashboard 分层与变更可视化。做不到 10 分钟恢复，先补预案自动化——每个数字背后对应一项稳定性基建投资。
七、通报与升级：别让信息比故障慢
三板斧解决"恢复"，通报解决"协同"——客服、业务方、合作银行都在等同一个答案：
故障确认 5 分钟内 ──► 一号通报：有故障、影响面初判、正在止血
每 15 分钟更新 ──► 进展通报：三板斧执行到哪一步、恢复预期
恢复后 24 小时 ──► 初步复盘：时间线 + 直接原因
恢复后 5 个工作日 ──► 完整复盘：根因 + 预算消耗 + 预案改进项入库升级机制（escalation）：15 分钟未止血自动升级域架构师，30 分钟升级稳定性委员会。升级不是追责，是把更大的决策权（如切流的预授权）更快地搬到现场。
反例：故障群里 40 条消息全是"有进展了吗"，没有一条"当前结论"。通报要有固定模板（现象/影响/已执行动作/下次更新时间），让阅读者 10 秒拿到结论；一号通报宁要"初步判断"不要"还在查"——信息的价值随时间衰减，比故障恢复慢的通报等于没有通报。
一句话总结
限流保自己不死，降级保核心不断，切流保场地没了还能活。预案 = 触发条件 + 动作 + 影响面 + 回退 + 预授权，放在库里、接在平台上、每年演练。1-5-10 里最贵的是第一个 1——发现不了，后面全是空谈。
2026-10 新增（金融级稳定性方法论系列）。