买了高防不等于买了保障。DDoS防护SLA里写的是承诺，赔付条款里写的往往是例外。本文用 10 个问答拆开清洗能力的口径、可用性怎么算、赔付能赔多少、哪些情况不赔，以及怎么自己验证承诺有没有兑现。
Q：DDoS防护SLA一般承诺哪几件事？
- 四类条款，缺一类就说明这份 SLA 不完整：
- 清洗能力：保底多少 Gbps、多少 Mpps，峰值能临时调到多少。
- 可用性：月度或季度可用率承诺，例如 99.9%。
- 响应时效：从报障到有人介入要多久，攻击期间谁对接。
- 处置边界：超出保底能力时怎么处理（限速、黑洞、还是回源），误杀后的补偿方式。
- 提醒：绝大多数合同把清洗能力写成保底值。超出保底后进入限速或黑洞，一般不算违约——这一条比赔付比例更值得逐字读。
Q：清洗能力的数字该怎么读？
- 至少问清三个数字，缺一个都判断不了：保底清洗（合同承诺、稳定可用的部分）、弹性峰值（能临时调到多高）、峰值持续时间（这个峰值能撑几分钟还是几小时）。
- 单位要看两个：Gbps 与 Mpps。小包攻击下带宽数字很漂亮，先打满的往往是 pps：
# 小包放大效应估算（64 字节 UDP 载荷）
# 每包约 64 + 8(UDP) + 20(IP) + 14(以太) = 106 字节 ≈ 848 bit
# 1 Gbps ÷ 848 bit ≈ 1.18 Mpps
# 反过来说：设备标称 10 Mpps，对应 64 字节小包只有约 8.5 Gbps
# 线上确认当前 pps（每秒新建连接与包量）
sar -n DEV 1 5 | awk 'NR>3 {print $1, $2, $3, $6}'- 结论很直接：标 Gbps 不谈 pps 的方案，遇到小包洪水会先崩。选型时两个指标要同时对上自己的业务形态。
Q：可用性 99.9% 是怎么算出来的？
- 公式很简单：可用时长 ÷ 统计周期。真正有争议的是「可用」的定义——探测点在哪、多久探测一次、连续失败几次才判定不可用。
- 服务商常用自己的探测点，可能只探一个节点、五分钟一次。你的用户在全国各地，感受和报表往往对不上。
- 常见排除项（等同于不算故障）：计划维护（提前通知）、超出保底清洗能力、客户源站自身故障、上游运营商或骨干网故障。
- 把排除项逐条看完，你会发现能主张赔付的窗口其实很窄。这不是说 SLA 没用，而是别把它当成保险。
Q：赔付条款常见有哪几种，能赔多少？
- 三种形态：按不可用时长折算服务费（例如每小时赔月费的百分之几）、代金券或延长服务期、封顶为当期服务费或数倍。
- 关键认知：赔付通常是服务费抵扣，不是业务损失赔偿。间接损失、商誉损失、客户流失，绝大多数合同里明确不承担。
- 举个例子：月费五千的方案，可用性掉到 99%，按小时折算赔下来可能只有几百块。而你一天的业务损失可能是五位数。
- 所以看 SLA 的正确姿势是：它约束的是服务商的响应义务，不是你的损失兜底。
Q：哪些情况不赔？
- 按出现频率排序，前五条覆盖了绝大多数拒赔：
- 超出保底清洗能力：攻击量超过合同承诺，进入限速或黑洞属于约定内处置。
- 未按接入要求配置：源站 IP 仍然暴露、没开回源白名单、证书没上传，导致攻击绕过防护直接打源站。
- 源站自身问题：应用层报错、数据库慢查询、磁盘满，这些不是 DDoS 防护能解决的。
- 未在约定时限内报障：没有工单就等于没发生，这条最容易吃亏。
- 不可抗力：上游运营商封堵、骨干故障、机房不可用。
Q：被打进黑洞算不算故障？
- 一般不算。黑洞是保护机制：主动丢弃流量保住网络与同机房其他客户，属于约定内的处置手段。
- 但两件事必须写进合同，否则事后扯不清：多快解封（自动还是人工申请）、解封后如何恢复（是否需要换 IP）。
- 现实里最常见的坑：黑洞由运营商侧触发，服务商也只能提交申请，恢复时间取决于上游。这条链路要在采购前就问清楚，而不是被打时才知道。
Q：怎么验证承诺有没有兑现？
- 三份证据缺一不可：自建拨测（外部视角）、源站日志（内部视角）、工单时间线（责任视角）。
- 自建拨测不需要复杂工具，一个定时任务就够了：
# 每分钟探测一次，把状态码与耗时写到 csv，月底统计可用率
* * * * * curl -s -o /dev/null -m 8 \
-w '%{http_code},%{time_total}\n' https://www.example.com/ >> /var/log/sla_probe.csv
# 月度可用率（非 200 视为不可用）
awk -F, '{t++; if ($1 != 200) bad++} END {printf "total=%d bad=%d avail=%.4f%%\n", t, bad, (t-bad)*100/t}' \
/var/log/sla_probe.csv- 工单这一环最容易被忽略。故障必须以工单形式留痕，聊天记录里的「我们马上处理」在事后主张赔付时几乎没有效力。
Q：采购前必须问清的六个问题？
- 保底清洗的 Gbps 与 pps 各是多少，弹性峰值多少、能撑多久？
- 超保底之后怎么处理：限速、黑洞，还是直接回源？回源有没有带宽上限与额外流量费？
- 可用性怎么判定，探测点与频率在哪，排除条款具体有哪些？
- 赔付上限是多少，走什么流程，多久到账？
- 套餐里是否包含七层防护（CC、恶意爬虫），还是只清洗四层？
- 攻击期间是否有专属对接人，响应时效怎么承诺？
- 这六问的答案，比任何一份参数表都更能反映实际防护水平。
Q：除了 SLA，还要看什么？
- 清洗阈值的可调性：能不能按业务调整触发阈值，而不是一刀切。
- 误杀率：清洗过程中会不会把正常请求一起丢掉，丢多少。
- 数据透明度：能不能看到攻击类型、来源分布、被清洗的请求样本。只给一个「已防护」的绿标，等于没有信息。
- 应急能力：真正的差距在攻击发生的那 30 分钟——有人接电话，还是只有一个工单系统自动回复。
Q：还有什么补充建议？
- 小站优先级建议：先把源站 IP 藏好，再谈清洗能力和 SLA。IP 暴露时，再高的保底能力也可能被绕过。
- SLA 是底线不是保险。真正的连续性来自自己的预案：切换路径写清楚、降级页准备好、备份线路演练过一次。
- 最后一句判断标准：服务商报表漂亮不算数，能自己拨测出来、能落到工单上的才算数。采购时多花半小时读排除条款，比事后追赔付划算得多。