一、体量异常概述

大家好，我是你们这门课的老朋友。今天咱们聊聊一个让所有SRE都睡不好觉的话题——体量异常。

先问个问题：你半夜被报警电话吵醒过吗？我反正被吵醒过不少次。有一次凌晨三点，告警说某核心接口的QPS突然掉了80%。我迷迷糊糊爬起来，第一反应是“完了，服务挂了”。结果查了半天，发现是上游一个配置变更，把流量全导走了。嗯，这就是典型的体量异常。

说白了，体量异常就是系统的关键指标——比如QPS、TPS、带宽、连接数、存储水位——在短时间内出现了不符合预期的剧烈变化。它不一定是故障，但往往是故障的前兆，或者故障本身。

1.1 什么是体量异常

体量异常，我习惯把它定义为：系统在单位时间内承载的请求量、数据量或资源消耗量，偏离了正常基线，且偏离幅度超过了业务可接受阈值。

这里有几个关键点：

• 正常基线：不是拍脑袋定的，而是基于历史数据统计出来的。比如过去30天同一时刻的平均值±3σ。
• 偏离幅度：不是所有波动都算异常。5%的抖动可能只是网络波动，但50%的突降大概率是事故。
• 业务可接受阈值：这个很关键。支付接口掉10%可能就触发熔断，但日志采集掉50%可能还能忍。阈值得跟业务方一起定。

1.2 体量异常的分类

我在实际工作中，把体量异常分成三大类。每一类的根因、排查思路、处理方式都不一样。你想想看，流量突增和流量突降，排查方向完全是反的。

1.2.1 突增

流量突然暴涨，像洪水一样冲过来。常见场景：

• 营销活动：双11、秒杀、红包雨。我记得有一次某电商平台搞“1元抢购”，流量瞬间飙到平时的100倍，数据库连接池直接被打满。
• 热点事件：某明星官宣、某股票涨停、某游戏新版本上线。用户像潮水一样涌进来。
• 攻击流量：DDoS、CC攻击。这种流量往往带有明显的恶意特征，比如来源IP分散、请求路径单一。
• 程序Bug：死循环、重试风暴、数据倾斜。我曾经遇到过一段代码，因为一个缓存失效，导致所有请求都穿透到数据库，QPS瞬间翻了10倍。

1.2.2 突降

流量突然断崖式下跌。这比突增更可怕，因为突增至少说明业务还在跑，突降往往意味着服务已经挂了。

• 服务宕机：进程崩溃、OOM、宿主机宕机。流量直接归零。
• 网络故障：DNS解析失败、负载均衡器挂掉、专线中断。流量被“堵”在门外了。
• 上游限流/熔断：调用方发现你响应变慢，主动切走了流量。这就是我开头说的那个案例。
• 配置变更：路由规则改错了、灰度比例调成了0%、域名被误删。这种最坑，因为代码没动，但流量没了。

1.2.3 周期性波动

这种异常最隐蔽。它不是突然发生的，而是像潮汐一样，每天、每周、每月规律性地出现。比如：

• 日周期：早高峰、晚高峰、凌晨低谷。正常。
• 周周期：工作日高、周末低。正常。
• 异常周期：比如每周三下午3点准时飙高，查了半天发现是某个定时任务在扫全表。这种波动虽然规律，但属于“不该有的规律”。

下面这张图，是我自己总结的体量异常分类框架，你可以对照着看：

1.3 体量异常的影响与挑战

体量异常不是小事。它带来的影响，往往是连锁反应。我把它总结为三个层面：

影响层面	具体表现	典型后果
用户体验	页面加载慢、接口超时、下单失败、视频卡顿	用户流失、客诉飙升、品牌口碑受损
系统稳定性	CPU打满、内存溢出、连接池耗尽、数据库死锁	服务雪崩、数据不一致、级联故障
业务指标	GMV下跌、转化率下降、广告收入减少	直接经济损失、KPI不达标、商业合同违约

但说实话，比影响更棘手的是挑战。我做了这么多年SRE，觉得体量异常最难的地方在于：

• 发现难：不是所有异常都能被告警覆盖。比如流量从1000涨到2000，阈值设的是1500，那它就不会告警。但2000的流量可能已经把数据库打到了极限。
• 定位难：体量异常的根因往往不在第一现场。流量突增，根因可能是上游的重试风暴；流量突降，根因可能是DNS解析失败。你得顺着调用链一层层扒。
• 恢复难：有些异常不是重启就能解决的。比如数据倾斜导致的存储水位暴涨，你得先做数据再均衡，这个过程可能持续几个小时。
• 预防难：你永远不知道下一个异常是什么样。双11的流量模型和平时完全不一样，压测也模拟不出来。

好了，这一章的内容就到这里。体量异常的分类和影响，是后续所有根因分析的基础。你记住一句话就行：异常不可怕，可怕的是你不知道它为什么异常。后面的章节，我会带你一步步拆解每一种异常的根因，并给出可落地的修复方案。