摘要：# 当网站被“点杀”时，你的业务能撑多久？ 前两天，一个做电商的朋友半夜给我打电话，声音都变了调：“哥，网站瘫了，后台登不上去，客服电话被打爆，说是有人在疯狂刷登录页面。”我一听，心里咯噔一下——这味儿太正了，典型的CC攻击（Challenge Coll…

当网站被“点杀”时，你的业务能撑多久？

前两天，一个做电商的朋友半夜给我打电话，声音都变了调：“哥，网站瘫了，后台登不上去，客服电话被打爆，说是有人在疯狂刷登录页面。”我一听，心里咯噔一下——这味儿太正了，典型的CC攻击（Challenge Collapse，挑战黑洞），专挑你业务最核心的登录、搜索、下单这些接口，用海量垃圾请求把你“点杀”到瘫痪。

说实话，很多老板舍得花大钱买高防IP、高防CDN，PPT方案做得天花乱坠。可真到了被打的时候，才发现问题往往不是“盾”不够厚，而是“人”和“流程”没跟上。攻击来了，技术手忙脚乱，业务部门两眼一抹黑，恢复全靠运气。这哪行？

今天咱不聊那些复杂的算法原理，就说点实在的：从攻击预警到业务完全恢复，这一整套流程到底该怎么跑？你的业务连续性计划（BCP），真的经得起实战检验吗？

一、攻击来了，你的第一反应是什么？（别说是百度！）

想象一下这个场景：周一上午十点，促销刚开，运营正盯着飙升的GMV傻乐。突然，图表曲线断崖式下跌，用户开始抱怨“页面白屏”、“支付失败”。监控大屏一片飘红。

这时候，你的团队第一反应是什么？

我见过太多团队，第一步是技术同学埋头查日志、封IP，业务同学在群里疯狂@所有人，老板不停地问“什么时候能好？”。整个场面，像极了没排练过的灾难片。

说白了，缺乏一个清晰的“战时指挥体系”和“应急预案触发机制”，是业务连续性的第一个断点。你得在风平浪静时，就明确好：

• 谁来判断这是不是攻击？ 是监控告警自动触发，还是需要运维主管人工确认？阈值设多少？别等CPU跑满100%了才反应过来。
• 谁有权限决策切换高防？ 是技术总监，还是需要上报CTO？决策链每多一环，恢复时间就多流失十分钟。
• 谁负责对外发声？ 客服话术、官方公告、用户安抚，这些信息谁统一口径？别让用户从微博小道消息才知道你们被打了。

（私货：很多公司把预案锁在Confluence里吃灰，真出事了根本没人记得看。定期演练，哪怕只是桌面推演，都比完美的文档有用一百倍。）

二、防御启动，别让“隐藏”变成“自埋”

一确认是CC攻击，常规操作肯定是立刻把流量切到高防清洗中心或者WAF（Web应用防火墙）。这里有个巨坑：源站隐藏。

理论上，用高防IP或CDN做代理，把真实服务器IP藏起来，攻击者就打不到了。这思路没错。但很多团队配置的时候，留了“后门”。

比如：

• 你的服务器是不是还在某些地方（员工电脑的Hosts文件、第三方统计平台、老旧API接口）直连了真实IP？
• DNS解析记录里，是不是除了CNAME到高防，还留着一条不起眼的A记录指向源站？
• 切流量时，是高防“拉”源站内容，还是源站主动“推”到高防？网络策略开对了吗？别高防那边扛住了，回源链路却被垃圾流量挤爆。

我自己就见过一个案例，一家公司的高防配置得严严实实，结果攻击者通过一个早已废弃的、却忘了下线的手机App接口，直接摸到了源站IP。这就好比给大门装了十道锁，却把厨房窗户大开着。

所以，业务连续性计划的第二步，必须包含一份详尽的“暴露面自查清单”。定期扫描，确保你的源站真的“隐身”了。

三、对抗中的“微操”：识别、调度与用户体验的平衡

流量切到清洗中心，战争才刚进入白热化。CC攻击最烦人的一点，是它模拟正常用户。你很难一刀切地把所有请求都干掉，否则误杀真实用户，业务照样完蛋。

这时候，考验的就是防御策略的“微操”了：

1. 精准识别： 别只依赖IP频率。得结合行为特征——这个IP是不是在短时间内，疯狂请求同一个API，但从不加载页面上的图片、CSS？它的User-Agent是不是一堆乱码或者老掉牙的版本？它访问的路径是不是异常地集中？（比如只刷 /login，不看商品页）
2. 动态调度： 好的高防服务，能基于实时分析，把可疑流量导入“慢速通道”或验证码挑战，把正常流量放行到“快速通道”。这需要你的业务能容忍一定的验证环节。你得提前想好：在攻击期间，哪些核心操作（比如支付）可以加一层滑块验证？哪些次要功能（比如商品评论）可以暂时降级或关闭？
3. 有损服务： 这是最现实的一课。当攻击流量远超防御带宽时，你必须做出选择：保核心，舍边缘。比如，优先保障登录、购物车、支付链路，暂时关闭实时推荐、积分商城这些非关键功能。在业务连续性计划里，必须有一张清晰的“业务功能优先级矩阵”，并和技术上的“服务降级开关”对应起来。关键时刻，壮士断腕，是为了活下去。

四、恢复，不是攻击停了就万事大吉

攻击流量下去了，监控曲线恢复正常。很多人长舒一口气：“总算扛过去了。”

——停！这时候松懈，前面可能都白忙活了。

恢复阶段，往往藏着二次伤害的风险。

• 数据一致性检查： 攻击期间，由于大量失败请求和降级操作，数据库里有没有产生脏数据？订单状态、库存数量、用户会话，这些核心数据必须做一次兜底校验。
• 缓存与Session重建： 如果攻击期间你重启过服务或者清了缓存，现在用户登录态可能全丢了。你得有平滑的Session恢复方案，而不是让所有用户重新登录，那体验简直是灾难。
• 复盘与迭代： 这事儿不能拖。趁热打铁，把整个攻击时间线、决策过程、措施效果全部复盘一遍。攻击源有什么新特征？我们的告警是不是太慢了？切换流程卡在了哪个人身上？防御规则有没有误杀？ （这里插一句大实话：很多公司的复盘会最后变成了甩锅会。记住，复盘的目标是优化系统和流程，不是找替罪羊。）

五、把计划，变成肌肉记忆

说到底，CC攻击防御中的业务连续性，不是一个技术方案，而是一套融合了技术、流程和人的应急响应体系。

它不应该是一份写完就归档的Word文档。它需要：

• 定期演练： 像消防演习一样，每季度甚至每月来一次“攻击模拟”。不一定要真打，可以桌面推演，检验通讯是否畅通、决策是否果断。
• 明确到人的RACI矩阵： 谁负责（Responsible），谁批准（Accountable），咨询谁（Consulted），通知谁（Informed）。打仗时，最怕“我以为他做了”。
• 工具化、自动化： 尽可能把预案变成可一键执行的脚本。比如，攻击确认后，能自动触发DNS切换、封禁特定ASN流量、拉起备用计算资源。

最后说点感性的。

做网络安全这么多年，我越来越觉得，最强的防御不是某个银弹产品，而是一个团队在压力下的冷静、有序和专业。当攻击来袭，所有人能像经过无数次排练的机组人员处理险情一样，各就各位，按章操作，同时保有一份应对意外的灵活。

你的业务连续性，就藏在这份从容里。

行了，不废话了。赶紧去看看你的预案，是不是还在吃灰吧。