流量突然升高，不一定代表正在遭受攻击；流量看似平稳，也不等于服务没有风险。制定抗攻击服务的告警阈值与值班响应机制，关键是同时观察流量、请求特征、服务状态和防护资源，并提前写明谁来判断、如何升级、何时采取措施。阈值如果脱离业务基线，容易造成告警泛滥，真正需要处理的异常反而被淹没。
先确定监测对象，再设阈值
不要只盯着每秒请求数或带宽。至少应把监测分为四类：入口流量与连接数、请求行为特征、防护设备或服务的资源使用情况，以及用户实际能否完成关键操作。比如，登录页面访问量上升时，如果成功登录比例稳定、服务器资源充足，未必需要按攻击处理；反之，流量变化不大但连接持续占满、页面请求超时，也值得触发排查。
阈值应依据正常业务基线设置。可按工作日与休息日、活动时段与平常时段分别观察历史数据，再定义“提醒”和“紧急”两档。初始试运行可把连续数分钟偏离基线作为提醒条件，把异常持续、多个指标同时恶化或关键功能不可用作为紧急条件；具体分钟数和偏离幅度应结合业务波动、采样周期及服务恢复时间调整，而非套用固定数值。
用组合信号降低误报与漏报
流量变化要看持续时间和来源分布
短时尖峰可能来自正常活动，也可能是异常请求集中到达。可同时比较单位时间请求量、并发连接、来源分布及请求路径变化。单个来源数量突然增加只是线索，不宜直接作为封禁依据；共享网络、代理出口或爬虫都可能造成来源集中。
资源和业务指标用于验证影响
将网络入口指标与 CPU、内存、连接队列、应用错误率及关键业务探测结果对照。如果请求量升高而服务正常，可先观察并核实流量特征；如果资源耗尽、错误率上升或关键操作失败，应提高事件等级。健康检查也要覆盖实际业务路径，单纯确认进程存活，不能证明用户能够正常使用服务。
这套抗攻击服务的告警阈值与值班响应机制还应区分“发现异常”和“确认攻击”：告警说明指标越界，不自动等于攻击结论。值班人员应先检查多个信号是否相互印证，再按授权范围处置。
把告警后的动作写成值班流程
- 接收并确认：记录告警时间、涉及的服务、触发指标和持续时长；在约定时限内确认已接收，避免告警无人认领。
- 核对影响：检查用户侧可用性、服务器资源、防护状态和近期业务变更，判断是服务故障、正常流量增长，还是疑似恶意请求。
- 分级与升级：仅有单项轻微偏离时先观察并记录；多项指标持续恶化或关键功能受影响时，通知事件负责人和相关技术人员。无法判断时应升级，而不是等待问题自行消失。
- 执行授权措施：按预案采用限速、挑战验证、临时规则或扩容等手段。记录执行人、时间、变更内容和回退条件；涉及可能影响正常用户的操作，应遵循既定审批与授权规则。
- 复核并复盘：处置后检查业务是否恢复、异常是否仍在以及措施是否产生副作用。事件结束后补充时间线，调整误报较多或发现过晚的阈值。
值班安排不能只写一个电话号码
值班表应明确主值班人与替补、告警渠道、接收确认时限、升级对象及交接方式。还要标明谁有权修改防护规则、谁负责评估业务影响，以及无法联系负责人时的后备路径。跨团队响应时，可用统一事件记录保存指标截图、判断依据、操作和恢复情况，避免口头交接造成信息丢失。
定期演练比单纯增加告警更能检验流程。可用模拟告警检查通知是否送达、值班人员能否找到操作手册、升级联系人是否有效；演练中不必真实制造攻击流量，也不应在未经批准的情况下修改生产防护规则。
常见问题
阈值多久调整一次？
业务流量或架构发生明显变化后应复核；没有变化时，也可定期查看误报、漏报和处置记录。频率由团队风险与运维节奏决定。
流量超过阈值就应封禁吗？
不应只凭流量自动封禁。先核对服务影响、请求特征和来源情况，再按预案采取可回退的措施。
小团队没有全天候值班怎么办？
明确非工作时段的告警接收人、严重事件升级路径和无法响应时的替代安排，并优先保障关键服务的紧急告警。
怎样判断机制是否有效？
检查告警是否及时送达、责任人是否明确、关键影响能否被识别，以及处置后能否验证恢复。抗攻击服务的告警阈值与值班响应机制应随这些结果持续修订，而不是设定后长期不变。