黄金半小时当整个服务塌了周五下午 4:30大促预热刚开监控大屏突然一片血红。杨工所有服务都在报 503 小刘从工位上弹起来下单、支付、商品详情……全挂了客服电话已经打不进来了我扫了一眼监控QPS 断崖式下跌错误率飙到 90%CPU 正常内存正常但接口全部超时。别慌。 我拉开椅子坐下黄金半小时按优先级来。第一幕回滚优先——最快止血小刘要不要先抓线程栈我先问一个问题——今天有没有发布运维老陈插话两点钟发了一版推荐服务加了个新的个性化算法。我那就先回滚。两点到四点半之间所有变更全部回滚。回滚比排查快得多。五分钟后回滚完成。小刘还是没好……我那就不是这次发布的问题。进入下一步——降级。第二幕降级——保核心链路我现在不是排查根因的时候是先让核心业务活下来。我在白板上画了一条线核心链路商品详情 → 加购 → 下单 → 支付 非核心推荐、评论、个性化、积分、优惠券我把非核心功能全部关掉。推荐服务直接返回空列表评论服务返回默认文案个性化关掉走兜底策略。全力保下单和支付。小刘在配置中心把降级开关全部打开。三十秒后下单接口恢复了支付也通了。小刘下单和支付好了但商品详情还是很慢。第三幕限流——控住入口流量我入口流量有没有被打爆老陈调出网关监控下单接口 QPS 从平时的 500 涨到了 8000应该是用户发现服务恢复后疯狂重试。我限流。Sentinel 把下单接口限到 1000 QPS超出的直接返回系统繁忙请稍后重试。保护后端不被打穿。限流生效后后端服务的压力骤降商品详情接口也开始恢复。第四幕熔断——切断故障源小刘杨工商品详情接口恢复了但还是偶尔超时。我看依赖。商品详情调了哪些下游小刘翻调用链调了商品服务、库存服务、价格服务……还有一个新加的相似商品推荐。我查一下相似商品推荐的错误率。老陈调出监控错误率 70%平均响应时间 8 秒。我找到病根了。熔断它。错误率超 50% 自动跳闸快速失败不让它拖垮整个商品详情。熔断配置生效后商品详情接口彻底稳定了。第五幕根因定位止血完成后我们开始复盘根因。小刘所以是相似商品推荐这个新接口导致的我对。它调了一个第三方推荐引擎没有设置超时也没有熔断。第三方引擎挂了之后我们的线程全卡在socketRead0上200 个 Tomcat 线程被占死引发连锁雪崩——商品详情超时 → 用户重试 → 流量暴增 → 限流没开 → 整个服务塌了。小刘那为什么回滚没用我因为推荐引擎是外部依赖不是我们代码的问题。回滚代码救不了外部服务挂掉。第六幕限流、熔断、降级的区别面试必问复盘会上小刘问了一个经典问题小刘杨工限流、熔断、降级到底有什么区别我面试老被问。我画了一张表表格机制作用位置一句话限流入口控制请求频率超出直接拒绝防瞬间流量打爆熔断调用侧下游错误率超阈值就跳闸快速失败防线程被耗尽、故障扩散降级业务侧主动舍弃非核心功能返回兜底数据保核心可用我打个比方限流是商场门口限流人太多就不让进了熔断是商场里某家店着火了把防火门关上不让火势蔓延到其他店降级是商场停电了电梯停运但楼梯还能走保基本运营。三者配合使用才能扛住大故障。第七幕事后复盘——体现成熟度故障结束后我写了复盘报告三段式故障时间线14:00 发布推荐服务 v2.3新增相似商品推荐功能16:28 第三方推荐引擎故障响应时间飙升至 8s16:32 商品详情接口线程池耗尽开始超时16:35 用户大量重试下单接口 QPS 暴涨至 800016:40 全服务雪崩错误率 90%16:45 开始应急回滚 → 降级 → 限流 → 熔断17:10 核心链路恢复17:30 全服务恢复根因新增外部依赖未设置超时和熔断第三方故障直接拖垮主链路缺少限流保护用户重试流量打爆后端监控告警滞后故障发生 5 分钟后才收到告警改进项表格改进方向具体措施负责人时间代码规约超时、熔断、幂等三件套进默认模板新建服务必须配置老张下周监控告警外部依赖响应时间 1s 立即告警不要等错误率老陈本周应急预案大促前做全链路压测 故障演练验证降级开关和限流配置小刘每月容量规划核心接口限流阈值按峰值 1.5 倍预设不要等故障再配老陈本周尾声晚上八点故障复盘会结束。小刘杨工今天学到的东西够我吹一年面试了。我记住大故障应急的核心就一句话先止血再查因。黄金半小时里回滚、降级、限流、熔断、扩容按优先级来别一上来就抓线程栈。止血完了再慢慢排查。他点点头补了一句还有以后加外部依赖我一定先配超时和熔断。我笑了这才是今天最大的收获。监控大屏恢复绿色大促流量平稳涌入。但我知道下一场雪崩迟早会来。不过没关系套路熟了就不怕了。