黄金半小时：当整个服务“塌了“

黄金半小时：当整个服务"塌了"

周五下午 4:30，大促预热刚开，监控大屏突然一片血红。

"杨工！所有服务都在报 503！" 小刘从工位上弹起来，"下单、支付、商品详情……全挂了！客服电话已经打不进来了！"

我扫了一眼监控：QPS 断崖式下跌，错误率飙到 90%，CPU 正常，内存正常，但接口全部超时。

"别慌。" 我拉开椅子坐下，"黄金半小时，按优先级来。"

第一幕：回滚优先——最快止血

小刘："要不要先抓线程栈？"

我："先问一个问题——今天有没有发布？"

运维老陈插话："两点钟发了一版推荐服务，加了个新的个性化算法。"

我："那就先回滚。两点到四点半之间所有变更，全部回滚。回滚比排查快得多。"

五分钟后，回滚完成。

小刘："还是没好……"

我："那就不是这次发布的问题。进入下一步——降级。"

第二幕：降级——保核心链路

我："现在不是排查根因的时候，是先让核心业务活下来。"

我在白板上画了一条线：

核心链路：商品详情 → 加购 → 下单 → 支付 非核心：推荐、评论、个性化、积分、优惠券

我："把非核心功能全部关掉。推荐服务直接返回空列表，评论服务返回默认文案，个性化关掉走兜底策略。全力保下单和支付。"

小刘在配置中心把降级开关全部打开。三十秒后，下单接口恢复了，支付也通了。

小刘："下单和支付好了！但商品详情还是很慢。"

第三幕：限流——控住入口流量

我："入口流量有没有被打爆？"

老陈调出网关监控："下单接口 QPS 从平时的 500 涨到了 8000，应该是用户发现服务恢复后疯狂重试。"

我："限流。Sentinel 把下单接口限到 1000 QPS，超出的直接返回'系统繁忙，请稍后重试'。保护后端不被打穿。"

限流生效后，后端服务的压力骤降，商品详情接口也开始恢复。

第四幕：熔断——切断故障源

小刘："杨工，商品详情接口恢复了，但还是偶尔超时。"

我："看依赖。商品详情调了哪些下游？"

小刘翻调用链："调了商品服务、库存服务、价格服务……还有一个新加的'相似商品推荐'。"

我："查一下'相似商品推荐'的错误率。"

老陈调出监控："错误率 70%，平均响应时间 8 秒。"

我："找到病根了。熔断它。错误率超 50% 自动跳闸，快速失败，不让它拖垮整个商品详情。"

熔断配置生效后，商品详情接口彻底稳定了。

第五幕：根因定位

止血完成后，我们开始复盘根因。

小刘："所以是'相似商品推荐'这个新接口导致的？"

我："对。它调了一个第三方推荐引擎，没有设置超时，也没有熔断。第三方引擎挂了之后，我们的线程全卡在socketRead0上，200 个 Tomcat 线程被占死，引发连锁雪崩——商品详情超时 → 用户重试 → 流量暴增 → 限流没开 → 整个服务塌了。"

小刘："那为什么回滚没用？"

我："因为推荐引擎是外部依赖，不是我们代码的问题。回滚代码救不了外部服务挂掉。"

第六幕：限流、熔断、降级的区别（面试必问）

复盘会上，小刘问了一个经典问题：

小刘："杨工，限流、熔断、降级到底有什么区别？我面试老被问。"

我画了一张表：

表格

我："打个比方：

• 限流是商场门口限流，人太多就不让进了；
• 熔断是商场里某家店着火了，把防火门关上，不让火势蔓延到其他店；
• 降级是商场停电了，电梯停运但楼梯还能走，保基本运营。

三者配合使用，才能扛住大故障。"

第七幕：事后复盘——体现成熟度

故障结束后，我写了复盘报告，三段式：

故障时间线

• 14:00 发布推荐服务 v2.3，新增"相似商品推荐"功能
• 16:28 第三方推荐引擎故障，响应时间飙升至 8s
• 16:32 商品详情接口线程池耗尽，开始超时
• 16:35 用户大量重试，下单接口 QPS 暴涨至 8000
• 16:40 全服务雪崩，错误率 90%
• 16:45 开始应急：回滚 → 降级 → 限流 → 熔断
• 17:10 核心链路恢复
• 17:30 全服务恢复

根因

• 新增外部依赖未设置超时和熔断，第三方故障直接拖垮主链路
• 缺少限流保护，用户重试流量打爆后端
• 监控告警滞后，故障发生 5 分钟后才收到告警

改进项

表格

尾声

晚上八点，故障复盘会结束。

小刘："杨工，今天学到的东西，够我吹一年面试了。"

我："记住，大故障应急的核心就一句话：先止血，再查因。黄金半小时里，回滚、降级、限流、熔断、扩容，按优先级来，别一上来就抓线程栈。止血完了再慢慢排查。"

他点点头，补了一句："还有，以后加外部依赖我一定先配超时和熔断。"

我笑了："这才是今天最大的收获。"

监控大屏恢复绿色，大促流量平稳涌入。但我知道，下一场"雪崩"迟早会来。

不过没关系，套路熟了，就不怕了。