事故一：注册中心的空列表雪崩
现象：机房交换机抖动两分钟，全站接口超时，恢复网络后还持续了五分钟。定位：调用方日志一片 "no instances available"，注册中心后台健康实例数归零。根因：保护阈值没开，网络抖动导致心跳批量超时，健康实例被全部误杀，调用方拿到空列表。修复：开保护阈值（0.8）+ 调用方本地缓存兜底 + 网络恢复演练。教训：宁可旧列表，不要空列表。
事故二：配置全量推送改崩线程池
现象：晚上十点改了个"无伤大雅"的参数，半小时后订单积压。定位：变更记录显示线程池核心数被从 20 改成 2（少打一个 0），全量推送秒级生效。根因：配置变更无灰度、无审批、无范围校验。修复：生产配置双人复核 + Beta 灰度先行 + 关键参数上下限校验。教训：配置生效有多快，错误生效就有多快。
事故三：网关连接池打满
现象：大促开门红，全站 502 三分钟。定位：网关到下游的连接数顶死在默认值 500，队列溢出。根因：网关压测时用的是单接口小流量，真实流量下下游 RT 变长、连接占用时间翻倍，连接池按低估的容量配的。修复：按"峰值 QPS × 下游 P99 RT × 冗余系数"重算池容量，全链路压测常态化。教训：容量是算出来的，不是默认出来的。
事故四：重试风暴放大三倍
现象：下游服务 GC 停顿 10 秒，上游集体超时重试，下游恢复后立刻被三倍流量打死，再也没起来。定位：下游 QPS 曲线在故障期是平时的 3.2 倍。根因：多级调用方各自配了 3 次重试且立即重试，故障期流量层层放大。修复：重试次数降到 1、指数退避加抖动、重试进熔断器统计、下游入口限流兜底。教训：每一层的好心，叠起来就是雪崩。
事故五：观测系统拖垮业务
现象：接入全量链路追踪一周后，高峰期业务线程偶发卡顿。定位：追踪后端存储打满、上报堆积，Agent 同步上报占住业务线程。根因：全量采样 × 每请求几十个 Span，超出后端容量；Agent 未配异步与丢弃策略。修复：按流量定采样率、错误强制保留、Agent 异步上报且队列满即丢弃。教训：观测是系统的一部分，也会成为故障源。
事故六：灰度标签在 MQ 断链
现象：灰度验证一切正常，全量后出现零星数据错乱。定位：灰度订单发出的消息没带版本标签，消费方按旧版逻辑处理了新版数据。根因：标签透传清单里漏了 MQ 这一段——HTTP 链路全打通了，消息链路没人管。修复：标签透传做成框架级拦截，HTTP、MQ、定时任务全覆盖，缺标报警。教训：灰度链路只要断一跳，就是薛定谔的版本。
复盘的共同点
六个事故，三类根源：变更失控（二、六）、默认值陷阱（一、三、五）、放大器效应（一、四）——而每一类，前面章节都给过对应的闸门。下一篇收官，把整个系列的地图拼成一张全景图。
评论 (0)