案例一、二：超时与重试的连环坑
事故一：没有超时的等待——某服务调用风控接口没设超时，风控侧流量突增 RT 从 200ms 涨到 30s，Tomcat 线程 10 分钟内耗尽，整个服务连登录都挂了。复盘：任何跨网络调用必须有超时（第 15 篇），风控这类非核心依赖还要做舱壁隔离（第 14 篇）与熔断（第 10 篇），三件武器一件都不能少。
事故二：恢复即雪崩——缓存服务重启，首页接口超时重试 3 次，恢复瞬间重试流量是常态 4 倍，二次打挂，反复三轮回不来。复盘：指数退避 + 抖动（第 16 篇）必须配上重试预算，熔断 OPEN 期间禁止重试；用户侧配「稍后自动重试」的友好页，别让用户手动 F5 当重试器。
案例三、四：资源没有隔离
事故三：一个慢依赖拖垮全站——所有下游调用共享 Tomcat 线程池，推荐服务慢性病 RT 3s，把线程一点点占光，下单陪葬。复盘：核心下游独立线程池（第 14 篇舱壁模式），边缘下游信号量限制 + 熔断，Tomcat 主池只留给核心链路。
事故四：报表拖垮交易——运营报表 SQL 与交易共库共连接池，一次全表扫描把 DB 连接占满，交易写入排队。复盘：核心库与边缘库分实例、连接池分舱（第 14 篇），报表查询限流并只读从库。
案例五、六：熔断参数的教训
事故五：凌晨的误跳闸——错误率阈值 50% 但没配最小请求数，凌晨窗口里 2 个请求挂 1 个，熔断 30 秒，拨测告警半夜连响三次把值班同学吵醒。复盘：minRequestAmount（第 11 篇）不是可选参数，是防误诊的护栏。
事故六：横跳的半开——半开放行 1 个探测请求，撞上网络抖动立即打回 OPEN，熔断—半开—熔断横跳一小时，恢复期被拉长十倍。复盘：探测请求数 3~5 个、连续成功才闭合（第 11 篇），休眠时长按下游真实恢复时间定。
案例七、八：降级与开关
事故七：陈年缓存——详情服务降级返回缓存兜底，降级持续 20 分钟，用户看到的是三天前的价格，投诉比故障本身还多。复盘：兜底数据要有保鲜机制（第 13 篇），静态榜单定时刷新；价格类数据宁可显示「暂时无法展示」，也不能错。
事故八：开关在哪台机器——故障现场要关掉推荐功能，发现降级开关配在配置中心，而配置中心自己正故障，改不了。复盘：救火用的开关要有本地兜底配置（第 13 篇），每个开关都要写明「最后一公里」的手动操作路径。
案例九、十：流量与预案
事故九：热 key 打爆分片——大促爆款商品详情成为热 key，单个 Redis 分片被打满，同分片的其他 key 全部超时。复盘：热点识别 + 本地缓存挡在最前（限流篇的多级思想），key 加随机后缀打散；这类隐患压测时就该暴露（第 18 篇）。
事故十：一次毫发无损的故障——某月支付渠道抖动，熔断 5 秒内跳闸，降级自动切到备用渠道，用户只感知延迟略增，无工单无投诉。复盘的关键不是技术，是这个预案当月刚演练过（第 13、18 篇）：谁按开关、走什么检查单、怎么恢复，全是肌肉记忆。
复盘的方法
每次故障，无论大小，回答三个问题：为什么没提前发现——监控有没有覆盖这个指标；为什么没自动止损——哪一层机制缺位或参数不对；为什么还需要人在场——哪些手动动作可以变预案、再变自动化。事故是比压测更贵的演练，别人交的学费，要记进自己的手册。
十个案例对应十件武器，机制全部讲完——最后一篇收官，把整个稳定性体系拼成一张全景图。
评论 (0)