99.99% SLA不等于真实可用率:CDN稳定性要这样判断

“我们承诺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延迟、地区表现、样本数量和更新时间,也可以使用网站测速功能,从不同地区观察自己的域名是否存在访问失败或稳定性波动。