第1章 异常检测概述

各位同学好。咱们开始第一堂课。

先问一个问题：你有没有遇到过系统突然变慢，或者某个接口被刷爆了？我猜多半都遇到过。这背后往往就是——实时访问异常。

说白了，就是那些不该出现的请求，或者可疑的访问行为，在它刚发生时就抓住它。别等用户投诉了才去翻日志，那就太晚了。

1.1 什么是实时访问异常

实时访问异常，指的是对系统资源（Web页面、API接口、数据库连接等）的访问行为，在很短时间内偏离了正常模式。比如一个IP每秒发1000次请求，正常人做不到对吧？或者凌晨三点突然有人遍历你的用户ID，这就是异常。

我自己的定义更简单：让系统压力突增、数据安全受威胁、或者业务逻辑被绕过的访问模式，都算异常。

• 频率异常：单位时间请求量远超历史基线
• 模式异常：访问路径、参数值、请求头组合怪异
• 来源异常：来自黑名单IP、新注册账户、TOR出口节点
• 时间异常：非业务高峰期的大量请求

举个真实例子：我之前接手过一个电商平台，每天下午三点准时慢成狗。查了一圈发现，是某个爬虫用了几百个代理IP在扫库存页面。后来加了实时检测，秒级封禁，系统立马就稳了。

1.2 常见场景

实时访问异常不只是理论概念，它在下面三个场景里天天出现。我每个都吃过亏，你们引以为戒。

场景一：Web请求

网页浏览，用户正常访问一个页面大概需要几百毫秒到几秒。但攻击者会用自动化工具瞬间发送大量请求：CC攻击、爬虫、撞库登录、暴力破解。这类异常的特征就是请求频率高、User-Agent奇怪、Referer缺失或伪造。

我印象很深的一次：某投票活动页面，开赛当晚被刷票脚本打到数据库连接池耗尽。当时如果有个实时异常检测，直接阻断非正常IP，根本不会出事。

场景二：API调用

现在的系统基本都是微服务架构，API之间互相调用。异常可能来自：

• 客户端SDK bug，反复重试同一个接口
• 恶意用户逆向工程你的API签名，发起重放攻击
• 内部服务异常导致的调用风暴

我建议对外暴露的API必须做速率限制和动态风控。比如一个在10秒内调用了50次创建订单的接口——正常用户不可能，直接降级或拒绝。

曾经有一次，我们某个内部API因为客户端缓存逻辑错误，每秒刷了上万次请求。没有实时检测的话，整个集群都会被拖垮。

场景三：数据库访问

慢SQL、全表扫描、大量并发写，这些都会引发数据库抖动。更危险的是SQL注入，攻击者通过恶意参数让数据库执行非预期操作。实时检测需要捕获异常查询模式，比如：

• 查询中出现 OR 1=1 等注入特征
• 某个表的扫描行数突然飙升
• 写操作集中在异常时间段

我记得有一次，一个同事不小心在日志里打印了完整SQL语句，结果被中间件捡走，对方用SQL注入拖走了几十万条用户数据。那之后我们就在数据库网关层加了实时异常检测——所有SQL都要过一遍规则引擎。

1.3 异常检测的重要性

你可能会想：不就是异常吗，事后查日志修复不就行了？嗯，如果你这么想，十有八九会被老板骂。

实时异常检测的价值在于三个字：快、准、早。

维度	事后排查	实时检测
发现时间	分钟到小时级	秒级
损失控制	业务已受影响	及时阻断
定位成本	大海捞针	自动打标，精准定位
用户体验	用户先崩溃	无感或轻微影响

说几个逃不过的坑：

• 流量增长高峰时，异常和正常请求的边界会变得模糊——你要用动态基线，别死守固定阈值
• 误报率如果太高，运维团队会麻木，最后把预警关掉。我就见过一个组因为误报太多直接关掉了告警，结果出了真问题都不知道
• 单纯检测还不够，还要有自动响应策略。封IP、降级、熔断、告警，缺一不可

最后，我把整个异常检测的知识内核画成了一张图，方便你脑中建立整体框架。

这张图你可以存下来。它展示了实时访问异常检测的基本闭环：请求进来，经过检测引擎，区分正常与异常，异常类型被识别，然后触发自动响应，最后再通过反馈不断优化规则。嗯，这就是我们后面整个课程要展开的内容了。