“我们承诺99.99%的可用性。”
这句话,很多人都在CDN服务商的产品页面、销售方案和合同里见过。
数字很漂亮。
四个9,看起来距离100%只差一点点,给人的感觉是:系统几乎不可能出问题,就算偶尔有波动,也应该很快恢复。
可真正使用以后,有些企业却会遇到一种很尴尬的情况。
服务商后台显示正常,SLA也没有违反,但用户就是打不开网站。
北京访问正常,广州出现超时;电信用户没有问题,移动用户不断刷新;监控系统没有触发严重告警,客服却已经收到了几十条投诉。
这时候去找服务商,对方可能会回复:
“平台整体可用性正常。”
“当前没有检测到大面积故障。”
“该问题未达到SLA赔付标准。”
听起来每句话都有道理,可用户打不开网站也是真的。
问题到底出在哪里?
很大一部分原因,是我们把“SLA承诺”和“用户真实可用率”当成了同一件事。
实际上,它们关系密切,却不是一个概念。
SLA首先是一份服务承诺
SLA是Service Level Agreement的缩写,通常译为服务等级协议。
它本质上是一套服务承诺和责任规则。
在SLA里,服务商会说明:
承诺达到多少可用性;
按什么时间周期统计;
哪些情况计入不可用;
哪些情况不计入;
发生故障后如何认定;
达不到承诺时如何赔付;
用户需要在多长时间内提交申请。
所以,当一家CDN写着“可用性不低于99.99%”时,不能只看这一个数字。
还要继续看后面的定义。
它统计的是整个平台,还是你的具体域名?
统计周期是一个自然月,还是连续30天?
只有所有节点都不可用才算故障,还是部分地区不可用也算?
单次故障需要持续多长时间才会被记录?
计划维护、用户配置错误、源站故障、运营商故障、不可抗力是否被排除?
SLA里的99.99%,通常不是一句孤立承诺。
它一定建立在一套统计口径和责任边界上。
如果不看这些条件,只记住“四个9”,很容易高估它能解决的问题。
99.99%究竟意味着多少不可用时间?
为了更直观,我们可以按一个月30天简单换算。
如果可用率是99%,理论不可用时间大约是7小时18分钟。
99.9%,大约是43分钟48秒。
99.95%,大约是21分钟54秒。
99.99%,大约是4分钟23秒。
99.999%,大约是26秒。
这些时间只是理论换算,不代表具体服务商一定按照这种方式认定故障。
但它能帮助我们理解一个事实:
可用率里小数点后面多一个9,背后的差距并不小。
问题在于,真实故障不会平均分散到每一天。
4分钟可能发生在凌晨三点,也可能发生在支付高峰;可能只是一个不重要的图片节点短暂异常,也可能是登录、下单和付款同时受到影响。
从月度统计看,它们可能都是4分钟。
从业务角度看,影响却完全不同。
一个资讯网站凌晨中断几分钟,可能几乎没有人发现。
一个正在直播带货的商城,在用户集中付款时中断4分钟,损失可能远远超过一个月的CDN费用。
所以,企业真正应该关心的,不只是“一个月允许中断多久”,还要关心:
它在什么时间发生?
影响了哪些用户?
影响了哪些业务?
恢复用了多长时间?
有没有反复出现?
这已经超出了一个简单SLA数字能够回答的范围。
为什么用户打不开,服务商却没有违反SLA?
这看起来矛盾,其实在很多场景下完全可能发生。
只有部分地区受到影响
CDN本身就是一个分布式网络。
某个地区节点异常,不代表全球节点同时不可用;某个省份访问缓慢,也不代表其他地区无法访问。
如果服务商的SLA按照整体平台或更大范围统计,一次局部故障未必会让总体可用率跌破承诺值。
但对于恰好位于这个地区的用户来说,网站就是打不开。
站在平台角度,这是局部异常。
站在用户角度,这是一次完整故障。
只有某个运营商出现问题
同一座城市里,电信、联通、移动用户可能走完全不同的网络路径。
如果只有移动用户访问超时,而电信和联通仍然正常,服务商后台看到的整体成功率可能依然很高。
但如果你的客户主要使用移动网络,这次“局部问题”就可能变成严重业务问题。
SLA看的是服务商约定的统计口径。
企业应该看的是自己的用户分布。
两者关注的对象不完全一样。
问题出在源站,不在CDN节点
如果静态资源能够从CDN缓存正常返回,但动态接口、登录或者支付请求需要回到源站,而源站恰好出现故障,用户依然可能无法完成操作。
这时候CDN节点本身可能是正常的。
服务商也可能根据协议,将源站故障排除在SLA之外。
可用户不会区分是CDN坏了还是源站坏了。
他只知道页面打不开、付款失败或者账号登不上去。
故障时间没有达到认定标准
有些服务协议会规定,故障需要持续一定时间,或者连续达到某种失败条件,才会被计入不可用时间。
如果网站每隔几分钟短暂超时几十秒,每次都没有达到单次故障认定标准,SLA报表可能依然很好看。
但用户体验会变得非常差。
这种“没有彻底挂掉,却一直时好时坏”的情况,往往比一次明确故障更难排查。
DNS、运营商和网络出口不在统计范围内
用户访问网站,需要经过DNS解析、本地网络、运营商、骨干网、CDN节点以及可能的回源链路。
任何一个环节出现问题,都可能导致访问失败。
但SLA一般只覆盖服务商明确承诺的服务范围,不可能把整条互联网链路全部包进去。
因此,SLA正常并不等于所有用户一定能够正常访问。
它只能说明:按照协议约定的统计方式,服务商提供的那部分服务达到了承诺标准。
SLA和真实可用率,应该分别怎么看?
可以把两者理解成两个不同视角。
SLA站在合同和服务责任的角度。
它关心的是服务商有没有履行承诺,如果没有履行,应该如何处理。
真实可用率站在用户访问的角度。
它关心的是用户从不同地区、不同运营商发起请求时,网站究竟能不能正常打开。
SLA是商业规则。
真实可用率是使用结果。
一家CDN可能完全符合SLA,但部分用户仍然遇到访问问题。
同样,一次短暂抖动可能影响了少量用户,却不代表这家CDN整体不稳定。
因此,判断CDN稳定性时,不能用其中一个完全替代另一个。
正确的做法是把三类数据放在一起看:
第一类是服务商SLA。
了解承诺值、统计规则、排除条件和赔付方式。
第二类是外部主动监测。
从不同地区和网络持续发起请求,观察实际成功率、失败类型、延迟和时间变化。
第三类是企业自己的业务数据。
包括访问日志、接口错误、订单失败、用户投诉、地区分布和运营商分布。
三者结合,才能接近真实情况。
外部可用率是怎么测出来的?
最基本的方法,是从外部探测点定期请求一个目标资源。
如果请求成功,并且返回内容符合预期,就记录为一次成功。
如果出现DNS解析失败、连接超时、TLS握手失败、HTTP错误或者内容异常,就根据预先定义的规则记录为失败或异常。
经过一段时间后,可以计算:
成功请求次数 ÷ 总请求次数。
看起来很简单,但真正影响结果的,恰恰是那些容易被忽略的细节。
例如,请求超时时间设为2秒还是10秒,结果会不一样。
HTTP 500算不算不可用,返回200但内容错误又该怎么算?
只测试一个地区,还是覆盖多个地区?
只使用一家运营商,还是覆盖电信、联通、移动及海外网络?
测试的是一个很小的静态文件,还是需要回源的动态页面?
一次失败立即计入,还是需要重复确认?
这些规则不同,最后得到的可用率也会不同。
所以,任何可用率数据都不应该脱离方法、样本量和时间窗口单独存在。
只写一个99.99%,却不告诉用户怎么测出来的,参考价值就会大打折扣。
在CdnChart上,稳定性应该怎么判断?
CdnChart会展示CDN的可用率、延迟、地区表现、样本数量和更新时间,并公开相应的测评方法与已知局限。
这样做的目的,不是再制造一个“绝对正确”的数字。
而是提供一个来自服务商之外的观察角度。
使用时,可以按下面的顺序判断。
先看整体可用率。
它能帮助你了解当前统计窗口内,这家CDN被观测到的整体成功情况。
再看地区数据。
如果整体可用率不错,但某个地区明显偏低,就要判断这个地区是不是你的主要用户市场。
如果问题集中在与你业务无关的地区,实际影响可能有限。
如果恰好发生在核心市场,就不能被整体数字掩盖。
接下来,看时间窗口和样本数量。
短时间数据适合发现近期变化,但也容易受到临时抖动影响。
较长时间数据更适合观察趋势,却可能把刚发生的异常平均掉。
样本量不足时,更不能因为一两次失败就匆忙下结论。
最后,要结合延迟一起看。
有些请求虽然最终成功,但耗时特别长。
从可用率角度看,它仍然是一次成功;从用户体验角度看,等待十几秒和打不开的区别可能已经不大。
所以,判断稳定性不能只看“是否成功”,还要看成功得够不够快。
CdnChart提供的是一套观察和比较工具。
它可以帮助用户发现不同CDN、不同地区和不同时间窗口之间的差异,但最终选型仍然应该结合自己的业务测试、服务合同和实际用户数据。
签CDN合同之前,要重点看这几项
很多人谈CDN采购时,最先问价格,第二问防护,最后才扫一眼SLA。
其实,SLA不应该只看承诺数字。
至少要看清下面几个问题。
可用性的统计对象是什么?
是整个CDN平台、某项产品,还是企业自己的域名和实例?
如果统计对象不同,数字的意义也会不同。
统计周期是什么?
按自然月、小时、天,还是其他周期计算?
一段时间表现很差,也可能被更长周期里的正常数据平均掉。
不可用如何定义?
连接失败算不算?
HTTP 5xx算不算?
响应特别慢但最终成功算不算?
部分节点、部分地区或者单个运营商异常是否计入?
哪些情况会被排除?
计划维护、不可抗力、运营商故障、用户配置错误、源站故障、攻击事件,是否属于排除范围?
不同服务商的排除条款可能差别很大,必须以实际合同为准。
赔付方式是什么?
很多SLA赔付并不是现金赔偿,而是服务代金券、账户余额或一定比例的费用抵扣。
赔付金额也不一定与企业的实际业务损失挂钩。
SLA的价值在于明确责任,不是替企业承担全部经营风险。
谁负责提交证明?
有些服务需要用户主动申请,并提供监控记录、故障时间和相关信息。
如果企业自己没有保存外部监测数据,真正需要申请时可能缺少证据。
这也是为什么,重要业务不能只依赖服务商自己的监控后台。
企业应该建立自己的可用性目标
除了关注厂商SLA,企业还应该根据自己的业务,设定内部可用性目标。
这个目标通常可以理解为:为了保证用户体验和业务结果,我们自己希望系统达到什么水平。
它不一定和厂商承诺完全一样。
例如,一个企业网站可以接受夜间偶发短暂波动。
一个支付系统、交易平台或者在线游戏,对可用性的要求会高得多。
更重要的是,内部目标要贴近用户。
可以分别设置:
首页可用率;
登录接口可用率;
下单和支付链路可用率;
静态资源可用率;
核心地区可用率;
核心运营商可用率;
P95响应时间;
故障发现和恢复时间。
这样一来,当问题发生时,团队不会只争论“CDN到底有没有违反SLA”。
而是能够更快回答:
哪些用户受到了影响?
哪个业务环节出现了问题?
问题持续了多久?
是CDN、源站、DNS还是运营商?
现在应该切换、回滚,还是继续观察?
这才是稳定性管理真正有用的地方。
一套可以直接执行的CDN稳定性检查方法
如果你正在评估一家CDN,可以按照下面的流程操作。
第一步,保存服务商的SLA文本。
记录承诺值、统计对象、计算周期、故障定义、排除条件和赔付方式。
第二步,明确自己的核心用户。
列出主要国家、地区、运营商和业务高峰时间。
第三步,建立外部测速基线。
可以使用CdnChart查看不同CDN的可用率和地区表现,也可以通过网站测速功能观察自己的域名在不同网络下的访问情况。
第四步,不要只测首页。
还要测试图片、脚本、下载文件、登录接口以及真正影响业务的关键地址。
第五步,保留故障时间线。
包括开始时间、恢复时间、影响地区、错误类型、DNS结果、CDN节点、源站状态和用户反馈。
第六步,按周或按月复盘。
观察可用率是否长期下降,P95是否持续升高,问题是否集中在固定地区或固定时间。
这套方法不会让网站永远不出故障。
但它能避免每次出问题时,只剩下服务商说正常、企业说不正常、用户在中间不断刷新。
最后想说
99.99%不是一句谎话。
但它也不是“所有用户随时都能正常访问”的保证。
它是一项建立在具体规则、统计范围和责任边界之上的服务承诺。
真正的用户体验,却发生在一个个具体时刻。
可能是广州的一位移动用户打开商品页,可能是海外客户登录后台,也可能是活动开始时几千个人同时提交订单。
这些访问是否成功、是否足够快、是否稳定,不能只靠一份SLA回答。
所以,选择CDN时既要看合同里的承诺,也要看外部网络中的实际表现。
发生问题时,既要核对服务商状态,也要检查地区、运营商、DNS、源站和具体业务链路。
SLA帮助我们明确责任。
真实可用率帮助我们看见用户。
两者都重要,但永远不要把它们当成一回事。
你可以通过CdnChart查看不同CDN的可用率、P50/P95延迟、地区表现、样本数量和更新时间,也可以使用网站测速功能,从不同地区观察自己的域名是否存在访问失败或稳定性波动。
