被CC攻击时业务方如何启动人工审核模式

CC攻击打到业务系统上，最直观的感受不是带宽跑满，而是正常用户进不来，登录、注册、下单、发帖这些核心动作全部卡死在验证码或提交环节。服务器可能还没宕机，但业务已经实质瘫痪。这时候如果还指望全自动的WAF规则或限速策略把攻击流量和正常流量精准分开，风险极大，因为攻击者往往会模拟真实浏览器行为，把攻击请求混在正常业务逻辑里。人工审核模式不是一种技术防护手段，而是一套业务流程上的应急切换机制，目的是在自动化防线被穿透或无法准确决策时，由运营团队直接介入，对关键动作进行人审放行。

平时业务系统追求的是低摩擦、高转化，用户从提交到完成操作最好在毫秒级完成。但CC攻击期间，这套逻辑必须反转，业务目标从“极致体验”切换为“阻断恶意、放行真实用户”。人工审核模式的本质，就是把原本由程序自动判定的通过权，临时收回到人工后台。所有关键写操作不再直接落库生效，而是进入一个待审队列，由审核人员逐条确认后才放行。这意味着产品端、运营后台、风控系统三方要提前打通一条应急链路，而不是等被打穿了才临时想办法。

并不是所有请求都值得进人工审核，全量接入等于自建一个DDoS瓶颈。真正需要拉闸的点就那么几个：账号注册、密码修改、手机号绑定、支付确认、内容发布、私信发送、API高频调用。这些动作的共同特征是，一旦被恶意执行，要么产生脏数据，要么触发短信资费损耗，要么造成内容污染。人工审核开关在设计上最好做成一个全局配置项，可以在后台一键切换，把指定action的同步处理改为异步待审。开关的粒度至少要支持按接口、按用户等级、按IP归属地三个维度组合控制，这样攻击时可以先对低等级用户或境外IP开启审核，避免一刀切影响全部业务。

人工审核不是把请求堆在一个列表里让人一条条看，那样几分钟就会崩溃。队列必须分层。第一层是机器预筛，把那些携带明显攻击指纹的请求直接丢弃，不进入审核池，比如UA缺失、Cookie禁用、请求间隔固定毫秒级、Referer为空等。第二层是灰度池，命中风控规则但评分处于临界区间的请求进这里。第三层才是真正推到人工面前的待审池。人工审核界面要支持批量操作，提供请求快照，包括IP、UA、请求参数、账号历史行为摘要、设备指纹、最近几条操作记录。审核人员需要在一个屏幕内完成“看、判、点”三步，单条审核耗时不应超过五秒，否则人力根本顶不住CC攻击的请求量。

CC攻击往往持续数小时甚至数天，单靠安全团队那几个人根本审不过来。业务方需要提前建立跨部门的人审预备池，把客服、运营、产品甚至研发都纳入培训范围，确保每个人都知道什么样的请求该放、什么样的该拒。审核后台要区分角色权限，一线人员只能做放行或拒绝操作，不能修改规则配置。轮值制度必须明确，每两小时换一班，避免疲劳导致误判。审核操作全程留日志，谁在什么时间放了哪条请求，全部可追溯。攻击结束后这些日志也是复盘的关键材料，能反哺风控规则。

人审最大的问题不是慢，是错。一个正常用户被误拒，投诉和客诉成本远高于漏放一个攻击请求。降低误伤率的核心在于给审核人员提供足够的上下文。单纯一个IP加一个请求体，神仙也判断不了这是真人还是脚本。审核界面必须展示该账号的注册时间、历史订单、常用IP段、设备信息、最近一次成功操作的时间戳。如果能接入用户行为序列，比如鼠标轨迹、页面停留时长、输入节奏，这些弱特征在机器判断时权重不高，但在人工判断时非常有用。另一个有效手段是二次验证，对审核存疑的请求，自动弹出一个短信或邮件验证环节，把最终确认权交还给用户本人，审核人员只做“看起来可疑就发验证”这一步判断。

开启人工审核后，用户端的提示语设计直接影响客诉量和品牌形象。不能直接告诉用户“你的操作需要等待人工审核”，这种冷冰冰的文案会让用户以为账号出了问题。更合适的做法是结合场景给出温和但明确的预期，比如“当前访问人数较多，系统正在排队处理，预计需要2分钟，请稍候”。同时在页面上提供一个轮询或WebSocket通道，审核通过后前端自动跳转，不需要用户手动刷新。如果审核拒绝，也不要直接封死，可以引导用户联系在线客服或完成实名认证后自动重试。这些兜底流程需要在产品设计阶段就预留好，攻击时直接启用，而不是临时改代码上线。

人工审核产生的每一条通过或拒绝记录，都是高价值的标注数据。攻击结束后，安全团队应该把这些数据导出来，和当时的请求日志做关联分析，找出人工判定为恶意但机器没拦住、以及人工判定为正常但机器误拦的两类样本。用这些样本去训练或调整风控模型的阈值，可以让下一次攻击时的自动化拦截更精准，减少对人审的依赖。这个闭环如果跑不起来，每次CC攻击都得靠人海战术硬扛，成本高且不可持续。比较好的做法是在审核后台直接加一个“加入黑样本”或“加入白样本”的快捷按钮，审核人员在判定的同时就完成了数据标注，事后批量导出即可。

人工审核模式对技术架构有一个硬性要求：关键业务链路必须支持同步转异步。很多业务系统的写操作是同步阻塞的，请求进来直接写库返回，这种架构在攻击时很难在不发版的情况下切入审核模式。建议在设计阶段就把核心写操作抽象成一个Job，平时同步执行，紧急状态下通过配置中心下发开关，把Job投递到审核队列而不是直接执行。队列中间件要选支持延迟消息和优先级调度的，比如RocketMQ或Redis Stream，避免审核积压时消息超时丢失。审核后台的查询和操作接口要做严格限流和鉴权，防止攻击者直接打审核接口本身。另外，审核数据库要和业务主库物理隔离，避免审核查询拖垮线上交易。

人工审核模式能不能在真实攻击中起作用，不取决于设计得多完善，而取决于有没有真正拉练过。每季度至少做一次红蓝对抗，模拟CC攻击打到业务不可用的场景，要求运营团队在规定时间内完成审核模式切换、人员召集、队列处理、客诉应对全流程。演练结束后输出SOP修订版，把每个环节的负责人、联系方式、操作步骤、预期耗时全部写清楚，放到内部知识库置顶。真正攻击来的时候，没有人有时间翻文档，但演练形成的肌肉记忆会让团队知道第一步该点什么按钮、第二步该通知谁。这套SOP还需要包含降级策略，当审核积压超过阈值时，自动放开低风险接口的审核，优先保障核心交易链路。

启动人工审核不是零成本的，人力投入、用户体验折损、潜在订单流失都是真金白银。业务方需要提前算清楚一笔账：当前业务每分钟的营收是多少，CC攻击每分钟造成的直接损失和间接损失是多少，开启人工审核后每分钟能挽回多少损失，同时人力成本增加多少。这个盈亏平衡点算出来，才能决定什么级别的攻击值得启动人工审核。一般来说，如果攻击已经导致核心转化率下降超过30%，且自动化缓解措施在15分钟内未见效，就应该果断切换。犹豫不决的代价往往比误伤几个用户更大，因为攻击持续越久，攻击者的信心越足，后续清洗难度越高。

人工审核模式不应该是一个长期状态，它是从全自动失效到恢复全自动之间的过渡态。在过渡期内，业务方应该加速推进半自动化审核能力，把人工判定的逻辑逐步固化到规则引擎里。比如审核人员连续对某个特征段的请求点了拒绝，系统应该自动生成一条临时拦截规则，后续同类请求直接拒绝，不再进审核队列。再比如审核人员对某个账号点了通过，系统可以自动将该账号的信任分临时提升，后续该账号的其他操作自动放行。这种人机协同的半自动化模式，能让人审的吞吐量提升数倍，同时保持对未知攻击模式的灵活应对能力。最终目标是让人只处理那些机器完全无法判断的极少数边界case，把99%的审核工作交还给自动化系统。