当你选CDN时,第一反应是不是看SLA承诺?99.9%、99.99%……数字越高越好,对吧?但作为一个天天和CDN打交道的技术人,我得泼盆冷水:SLA不是护身符,而是一张带有无数“但书”的保险单,今天咱们就拆开看看,那些条款到底藏着什么坑,以及怎么用技术手段真正把SLA落到实处。

CDN SLA解读,别被四个9忽悠,拆开条款看真相
概念拆解:SLA里到底保了什么?
先看最基础的“可用性(Uptime)”,主流厂商通常按“月度可用率”计算,公式是:
(总分钟数 – 不可用分钟数)/ 总分钟数 × 100%
但问题来了——“不可用”怎么定义? 常见门槛是“连续5分钟以上完全不可用”才计入故障,也就是说,如果你业务在深夜挂了4分50秒自动恢复,对不起,这不算SLA事件,更狠的是,有些厂商把“国内节点不可用”和“海外节点不可用”分开算,你全球业务可能只保某一个区域。
再看请求成功率,SLA里承诺的“99.9%请求成功”,往往只算HTTP 2xx/3xx/4xx(客户端错误不算),但如果你源的服务器响应慢,CDN返回504,这归谁?条款里通常写明“源站错误导致的失败不计入SLA”。换句话说,SLA只保CDN自己的边缘节点和网络,不保你的源站、DNS解析、甚至你自己配置的缓存规则。
还有细节:“维护窗口”,几乎所有厂商都写明“计划内维护(通常每周几小时)不计入不可用时间”,你半夜被踢下线,第二天一查,哦,是版本升级,你找谁赔?没门。
延迟(Latency) 和丢包率呢?大部分SLA根本不承诺这些,即使有,也往往是“P95延迟<X毫秒”,而且基于厂商自己的测量数据,你用第三方监控工具测出来的超标,他们不认。
方案对比:不同厂商的SLA条款,差距有多大?
拿国内常见的阿里云、腾讯云、以及国际厂商AWS CloudFront和Akamai来对比一下。
| 维度 | 阿里云CDN | 腾讯云CDN | AWS CloudFront | Akamai |
|---|---|---|---|---|
| 标准承诺 | 9% | 9% | 9% | 99% |
| 赔付比例 | 月费10%~30%(阶梯) | 月费10%~40% | 月费10%~25% | 月费5%~50%(需协商) |
| 赔付上限 | 月度服务费 | 月度服务费 | 月度服务费 | 多倍服务费(部分合同) |
| 故障认定 | 连续5分钟不可用 | 连续5分钟不可用 | 连续5分钟不可用 | 连续1分钟(部分场景) |
| 海外节点 | 单独计算,不计入总SLA | 单独计算 | 全球统一 | 全球统一 |
| 第三方监控 | 不认 | 不认 | 不认 | 可协商引入 |
注意:99%承诺的Akamai,价格是99.9%的3~5倍,而且需要你购买“企业级套餐”并签署附加条款,它的“不可用”计算方式更严格(1分钟门槛),但另一方面,很多小故障会被排除(如域名未备案、未按最佳实践配置等)。
关键差异在于“赔付方式”:国内厂商多给代金券,且只能用于后续消费,国外厂商部分给现金返还,但流程繁琐,你为了一次大故障索赔,可能折腾三个月,最终拿到当月服务费的10%——而故障造成的业务损失可能是月费的几百倍。SLA本质是“降低信任门槛”,不是“风险对冲工具”。
适用场景分析:你的业务需要什么样的SLA?
-
静态资源分发(图床、静态页)
可容忍秒级故障,选择99.9%即可,重点看缓存命中率和带宽单价,SLA数字再高,缓存没配好,用户一样卡。 -
直播/实时音视频
对延迟和可用性极度敏感,建议选择承诺99.99%且支持“多地域负载均衡”的厂商,但要注意:很多厂商的“高可用SLA”要求你必须同时启用两个及以上边缘节点区域,否则不保,例如某厂商写“若客户仅使用单个节点,则SLA不适用”。 -
电商大促、抢票等高并发场景
SLA在此时意义有限——故障可能发生在流量峰值前几秒,但事后计算月可用率仍可能是99.9%以上。更重要的是弹性扩容能力和DDoS防护能力,选型时,除了看SLA,还要看其“主动扩容”的自动化程度(如是否支持预膨胀节点)。 -
全球化业务
海外节点质量参差不齐,单独看中国厂商的海外SLA往往只有99.5%甚至更低,这种情况下,建议采用“多云CDN”策略:国内用阿里/腾讯,海外用CloudFront或Akamai,然后通过DNS智能调度实现自动容灾。
选型建议:怎么避开SLA的坑?
-
别只看数字,逐字读条款
重点看:故障认定时间门槛(5分钟还是1分钟)、排除项(源站、DNS、自家配置)、维护窗口、赔付形式,最好让法务或商务同事把““除外”条款标红。 -
建立自己的监控体系
用第三方工具(如听云、博睿、或者自建拨测节点)独立测量延迟、可用性,一旦发现连续异常,立即截图保留证据,因为厂商的监控数据你拿不到原始日志,只有自己的数据才能作为交涉筹码。 -
冗余设计比SLA更可靠
- 多CDN供应商:比如同时接入两家,通过权重调度或主备切换,即使其中一家SLA不达标,另一家可以兜底。
- 多源站:把源站分散在不同机房,配合CDN健康检查自动剔除故障源。
- 边缘脚本:在CDN边缘节点上做降级逻辑(如缓存失效时返回静态内容),减少对后端依赖。
-
成本效益分析
99.99%的SLA单价高且附加条件多,建议只用于核心业务节点,对边缘或非关键路径,用一个便宜的正常SLA厂商即可,自建冗余来补齐可靠性。 -
签订合同前要“实战测试”
申请为期一周的试用,模拟真实流量,重点测试:节点故障时切换速度、源站抖动时CDN是否产生大量502、大流量下缓存命中率是否达标。SLA是纸上君子,实测才是真皇帝。
还没有评论,来说两句吧...