被攻击期间的业务降级，核心策略是“先保核心功能存活，再谈体验，最后恢复全量”，通过流量清洗、静态化降级、功能裁剪三步走，把损失控制在最小范围。
网站被攻击这件事,有点像人突然生病，平时身体再好，真到高烧不退的时候，也得先把命保住，再考虑补营养，业务系统也一样，DDoS打过来、CC攻击刷起来，CPU和带宽瞬间被打满，这时候硬扛不是好办法，反而容易把整个服务拖垮，该降级就降级，这不是认怂，是一种主动的自我保护，我们今天就聊聊，真到那一步的时候，降级策略到底该怎么定。
第一步先分清攻击类型，再决定降级方向
很多人一看到监控告警就慌了,立刻把CDN开满、服务器重启一遍，结果发现没多大用，原因很简单，压根没搞明白对方是怎么打的。攻击类型不同，降级的侧重点完全不同。
- 流量型攻击（DDoS/反射放大）：核心问题是带宽被塞满，正常用户进不来，这时候降级的重心是砍掉非核心流量，比如日志上报、统计接口、图片加载，优先保证HTML页面和接口能被访问。
- 连接型攻击（SYN Flood/慢连接）：核心问题是连接池被占满，新用户连不上，这时候降级要做的第一件事是关闭所有非必要的长连接，WebSocket该断就断，推送服务该停就停。
- 应用层攻击（CC/代码漏洞利用）：核心问题是CPU和数据库被吃光，这时候降级重点是把动态请求变静态，把查询数据库的逻辑尽量换成缓存或者静态文件。
行业共识认为,多数情况下攻击会混合出现，也就是说你先挨了一顿DDoS，紧接着CC攻击跟着来了，所以降级策略不能是单点的，要有个先后顺序，先判断是带宽满了还是CPU满了，这决定了你要先砍流量还是先砍计算。
降级策略的三个层次，按需启动
业务降级不是一刀切,而是分层执行的，我们按严重程度从低到高分三个层级，方便你对照自己的实际情况来设定触发条件。
一层降级：非核心功能让路
这是最常被忽视的一层,很多团队一谈降级就想着把整个网站关掉，实际上在攻击强度没那么大的时候，只需要让非核心的东西先让路。
- 关闭实时统计：访问量统计、用户行为埋点，这些接口先切到日志文件里，不推送到实时计算。
- 暂停推荐模块：千人千面的推荐列表，如果平时依赖复杂的实时计算，这时候直接换成运营配置的静态推荐内容。
- 图片走懒加载：首屏之外的图片都延迟加载，节省带宽资源。
- 降低日志级别：从DEBUG切到ERROR，减少磁盘IO和日志上报的网络开销。
这一层降级的效果是“你没什么感觉，但服务端压力明显降下来了”，适合在攻击刚开始、监控显示负载上升但还没崩溃的时候启动。
二层降级：核心逻辑改为精简模式
如果一层降级不够,负载还在涨，那就得动核心逻辑了，这一步的目标是用不坏的方式替代复杂的方式。
- 搜索功能降级为数据库LIKE查询：如果用了ES做全文搜索，这时候可以把搜索切换到数据库的简单LIKE查询，虽然慢一点，但能保证搜索框不是白板的。
- 商品详情页静态化：把热门的商品详情页提前生成静态HTML，直接由OpenResty或者CDN返回，不经过应用服务器。
- 登录态宽松化：把“必须登录才能操作”放宽为“允许游客状态下只读浏览”，强制登录校验会消耗大量会话存储和加密计算资源。
- 限流策略开启：普通用户的接口调用频率从每秒100次降到每秒10次，这个操作在Nginx层就能做，用limit_req模块就可以，不一定要改代码。
业内专家指出,这一层降级的关键动作是“动静分离”，把能静态化的页面全部静态化，让动态计算的流量降到最低，如果这一步做好了，应用服务器的压力能降到原来的三成左右。
三层降级：牺牲体验保住可用性
到了这一步,说明情况已经很严峻了，这时候不要想着怎么维持体验了，核心目标是“互联网上还能看到你的网站，并且能正常下单”。
- 全站静态化兜底：提前准备一份整个网站首页和核心栏目的静态HTML，当检测到应用服务器持续超载5分钟以上，自动切换到这个兜底页面。
- 核心流程只留白名单：只允许登录用户的请求通过，游客全部返回“系统繁忙”的提示页，这个操作靠Nginx的allow/deny规则配合Cookie判断就能实现。
- 隐藏次要入口：论坛、评论、站内信这些功能直接关闭入口，不提供页面链接。
- 接口返回快速失败：所有非核心接口直接返回预置的JSON错误码，不让请求穿透到后端。
三层降级做完,你的网站就变成了一本“电子画册”，能看、能点，但想干点复杂的事可能不行，不过没关系，这总比全站打不开强得多。
高防IP和WAF什么时候该启用，怎么配合
你买了高防IP但一直没启用,攻击来了才想起来要切，这里有个细节需要记住：提前切，别等被打死了再切。
- DNS切换到高防IP的TTL设置建议在300秒左右，太短容易造成解析波动，太长则切换生效慢。
- 源站IP一定要保密，高防IP只是第一层，如果源站IP暴露了，攻击流量会直接绕过高防打在源站上。
- 高防IP背后的回源策略,建议把回源HOST改为CDN域名，这样CDN也能分担一部分缓存压力。
WAF的作用更多是拦CC攻击,建议把WAF的“人机验证”功能打开，检测到高频访问就弹出JS验证，这比单纯的封IP要有效得多，因为现在CC攻击的IP池很大，你封一个，它换一个，永远封不完。
如果攻击量级特别大，比如上百Gbps的流量，一般高防IP也扛不住，这时候建议直接跟运营商配合做黑洞路由，黑洞的意思就是直接让流量丢失，你的网站暂时从互联网上消失，等攻击停了再恢复，这看起来是下策，但在极端情况下，这是唯一不让机房整体受影响的办法。
降级之后怎么恢复，先恢复什么后恢复什么
降级不是终点,恢复才是，很多团队在攻击停止后想赶紧把功能打开，结果刚打开又被第二波攻击打趴，来回折腾几次，用户就流失了。
- 观察期至少保持24小时，攻击停止后不要立刻恢复，先在降级状态下观察一天。
- 先恢复读接口，再恢复写操作，比如商品浏览可以先恢复，但下单结算要再等等。
- 恢复时逐步放流量：先开放10%的流量试运行，确认稳定后放开到50%，然后全量。
- 监控预警阈值要调低一档，攻击刚结束的一两天内，攻击者可能是在试探，把监控阈值调低一些，早发现早应对。
另外有个容易被忽略的动作：降级期间沉淀的数据要在恢复后尽快补处理，比如降级时用户提交的工单、留言、订单，都先存在临时表里，恢复后第一时间做数据迁移和状态同步。
Q&A：关于业务降级策略，你可能还会问这几个问题
网站被攻击了但不确定是不是真的攻击，怎么快速判断？
看四个指标：带宽占用率、TCP连接数、CPU使用率、错误日志率，如果带宽占满但业务量没有上涨，或者连接数暴增但完成握手比例极低，大概率就是攻击，另一个快速判断方式是看访问来源IP的分布，正常用户的IP是分散的，攻击流量往往集中在某几个C段或特定地区，一旦确认，先启动一层降级并行观察，不用等全确认了再动。
业务降级和限流有什么区别，为什么要放在一起用？
限流是限制请求速率,比如单个IP每秒最多请求5次；降级是调整服务能力和功能范围，比如把推荐模块关了。限流管的是“量”，降级管的是“内容”，单独用限流，能挡住一部分高频CC，但防不住大流量带宽攻击，单独用降级，业务是精简了，但如果访问量本身还是爆炸的，服务器照样扛不住，所以真实场景里两者是组合拳，限流加上降级，一方面控制请求量，一方面减小单次请求的资源消耗。
攻击结束后怎么防止马上再被攻击，有什么能提前做好的预案？
把降级策略固化到代码和配置里,不要等到攻击来了临时写脚本，具体可以做三件事：第一，核心页面每月自动生成一次静态备份，存放在独立存储中；第二，写一个一键降级脚本，参数化控制哪些模块关闭、哪些接口限流，执行后自动生效；第三，跟高防服务商确认好应急预案，包括黑洞触发的流量阈值、解除黑洞的操作方法、回源IP变更的流程，这些都提前问清楚并记录在文档里。
对付攻击这件事,比拼的不是谁的技术更强，而是谁的准备更充分，降级策略的核心不在于“多复杂”，而在于“能不能在关键时刻自动且准确地执行”，把预案写好，把脚本写好，把监控设置好，真遇到事了，你就能像按开关一样自如应对。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/792364.html
