大流量攻击下业务连续性保障，不只是把服务器扩容。流量可能先挤满网络入口，也可能集中冲击登录、搜索或提交接口；若只盯着主机负载，容易漏掉支付、存储等依赖环节。以下五项检查可作为值班人员的现场清单，按影响范围逐项执行。
一、确认入口是否拥塞，区分异常流量与正常增长
先记录流量进入的网络位置、协议类型、请求路径、来源分布及变化趋势，并与平日同一时段比较。结合网络设备、负载均衡器和应用日志，判断压力是在入口带宽、连接数，还是某个应用接口。若入口链路已饱和，单纯增加应用服务器通常无法解决，应尽快联系网络服务提供方核查上游防护和流量清洗能力。
检查是否有大量重复请求、异常短连接或集中访问少数路径。不要仅凭单一特征封禁来源：共享网络、代理和自动化客户端都可能造成误判。记录判断依据和执行时间，便于回滚规则及交接。
二、核对容量与依赖，找出先失效的环节
按请求链路逐项确认负载均衡、应用实例、缓存、数据库、对象存储和第三方接口的容量余量。查看连接池、线程池、队列长度、错误率及响应时间；同时确认扩容是否受配额、启动时间或冷启动影响。扩应用实例并不一定能缓解数据库连接耗尽，缓存也可能因热点失效而把压力转移到数据库。
对每个关键依赖写明负责人、告警入口和临时处置方式。若某个外部接口变慢，确认调用超时是否有限、重试是否带退避，避免请求不断重试形成放大效应。
三、检查防护规则，避免挡住真实用户
确认流量清洗、WAF及负载均衡规则处于预期状态，检查规则更新时间、覆盖入口和告警接收人。网络层防护适合应对链路或连接压力；WAF更适合筛查符合规则特征的应用请求，二者不能相互替代。若攻击流量已经占满上游链路，应用层规则可能来不及生效。
需要调整规则时，先限定受影响的路径、请求特征或速率，再观察拦截量、正常请求成功率和误拦反馈。优先使用可撤销的小范围变更；涉及全站拦截、地域限制或认证策略的改动，应由授权人员复核并留存记录。
四、明确业务降级边界，守住关键数据
提前列出必须保持的操作和可以暂缓的功能，例如保留账户提交与交易确认，同时降低非必要的复杂筛选、报表生成或高频刷新。具体取舍应依据业务风险确定，不能假定所有系统都存在相同的优先级。
通过限流控制单个接口的并发或请求速率；依赖故障时可用熔断阻止持续调用，并为用户提供明确的稍后重试提示。涉及写入的操作要检查幂等处理、重复提交保护和状态核对流程，避免恢复后出现重复记录或结果不一致。对重要数据操作保留审计记录，不因应急而绕过权限控制。
五、验证恢复条件，并做好交接
恢复不应只看流量下降。值班人员还应确认错误率和响应时间回到可接受区间、队列持续消退、依赖服务稳定，且关键写入结果经过抽样核对。规则和临时限流分批撤销，每次变更后观察一段时间；观察时长应按流量波动和业务响应周期确定。
- 记录事件开始时间、影响范围、已采取措施和未解决风险。
- 指定一人汇总指标与用户反馈，避免多人同时修改同一策略。
- 将临时配置、回滚方式及恢复判据交接给下一班，并在事后复盘容量缺口和告警盲区。
把这些步骤写入值班手册并定期演练，才能让大流量攻击下业务连续性保障从临场判断转为有据可查的流程。检查重点始终是：入口是否可用、依赖是否承压、防护是否误伤、数据是否一致，以及恢复是否经过验证。
常见问题
流量突然升高，第一步该做什么？
先确认受影响入口和指标变化，保留日志与时间线，再判断是链路拥塞、接口集中受压还是正常业务增长；不要未经验证就全站封禁。
增加服务器能解决大流量攻击吗？
不一定。若网络入口已饱和，扩应用实例帮助有限；若瓶颈在数据库或第三方依赖，扩容还可能加重下游压力。
限流会不会影响正常用户？
可能。应按接口和请求特征逐步调整，并同时观察成功率、错误率与用户反馈，准备明确的回滚条件。
什么时候可以撤销临时防护？
当入口流量、应用错误率、依赖状态和关键数据核对均符合预设恢复标准后，分批撤销并持续观察，而非仅凭流量回落决定。
