凌晨两点十七分，网站监控大屏上跳动的演练数字终于不再撒谎。攻击流量从每秒三百兆飙到每秒一点二吉，防守防火墙规则表在第三轮变种攻击后彻底失效。报告我们看着负载均衡器像溺水者那样挣扎，网站然后一切归于平静——网站挂了，演练不是防守被攻破，是报告被打瘫了。

防守演练选在周四深夜，网站因为领导说"白天影响业务"。演练结果攻击方也没客气，防守上来就是报告混合型DDoS加CC攻击，还掺着几个针对老旧API的网站SQL注入尝试。说实话，演练前半小时我们还挺乐观，防守WAF拦截日志刷得飞快，误报率低得惊人。可到第四十分钟，问题来了——清洗设备自己的管理端口被扫到了。这就像你家防盗门没事，猫眼被人堵了。

最讽刺的是，我们花大价钱买的抗D设备，最后成了瓶颈。攻击流量没把带宽打满，倒是设备自身的会话表先溢出了。技术员老周蹲在机柜旁，一边重启设备一边骂："这玩意儿说明书上写支持八百万并发，实际连八十万都扛不住。"后来查了日志，原来是设备固件版本太老，有个已知的内存泄漏bug。厂商售后电话打过去，语音提示"工作时间请联系您的客户经理"。

真正的转折出现在凌晨三点十分。我们放弃了硬扛，直接把网站切到静态缓存页，数据库全部只读。攻击方发现动态请求全被挡在门外，流量开始衰减。这时候我们才腾出手来，用脚本把攻击源IP段一个个拉黑。有个IP来自某个云厂商的跳板机，我们打电话过去，对方值班工程师睡眼惺忪地说"哦那个啊，是我们客户在跑压测，忘报备了"。

演练结束复盘，几个细节特别扎眼。第一，我们的告警短信发到了值班经理的备用手机上，但那个手机放在他家里充电。第二，应急预案里写着"每十五分钟向领导小组汇报进展"，实际上我们连着四十分钟没人接电话。第三，最有效的防御动作，居然是运维小哥手动写的一个nginx限流规则，花了不到五分钟。

这次演练没赢也没输，但暴露的问题比攻击本身更值得警惕。设备冗余不够，人员响应链条太长，厂商支持形同虚设。真正把网站救回来的，不是那些花哨的安全产品，而是一个老运维的经验和一台能跑shell的笔记本。网络安全这事儿，很多时候拼的不是技术，是应急时刻人能不能醒着、手机能不能打通、决策能不能快过攻击者的脚本。

(责任编辑：休闲)