摘要

  • 云服务 SLA 更接近一个有限责任的风险分配公式，而不是停机损失保险。百分比只有在计量对象、架构条件、停机定义、信用额分母、索赔时限、证据义务、排除项、赔付上限和不可叠加规则全部确定之后，才有经济含义。同一个“99.99%”，可以对应完全不同的风险边界。

  • 对买方而言，最重要的问题不是“供应商承诺几个 9”，而是：**哪些故障进入计算，谁能证明故障，哪些资源进入赔付基数，最高能拿回多少钱，以及剩余风险由谁承担。**公开 SLA 可以降低部分服务费风险，却通常不会把端到端工作负载风险、业务中断损失和恢复责任完整转移给供应商。

一笔 3.47% 的信用额说明了什么

Cloudflare 的例子之所以有价值，不是因为 3.47% 本身大或小，而是因为它把 SLA 的内部结构暴露得很清楚。

其 Enterprise SLA 对受覆盖 Service 公布 100% uptime，但信用额并不是“停机一分钟退一分钟的钱”。受影响客户比例以中断期间受影响的唯一访客数除以唯一访客总数计算；信用额又把中断分钟乘以 5、受影响比例乘以 5，再除以计划可用分钟。所谓计划可用时间，也不是自然月分钟数的简单复制，而要扣除客户计划停机以及不可抗力造成的停机。最后得到的比例，只作用于与该 Service 相关的月度经常性服务费。(Cloudflare)

于是，合同里的“可用性”和企业财务意义上的“业务可用性”发生了第一次分离。

假设一次事故让一家电商的结算路径停摆一小时，业务损失可能来自订单流失、客服拥堵、营销浪费、退款、人工恢复和客户流失。但 Cloudflare SLA 的公式并不试图计算这些项目。它计算的是一个经过定义的服务事件，对一个经过定义的费用分母所产生的信用额。

这正是理解云 SLA 的第一原则：它通常不是损害赔偿模型，而是服务费调整模型。

因此，“100% uptime”与“发生事故后供应商承担 100% 损失”之间，没有逻辑上的直接连接。前者可以是服务级承诺；后者只有在合同另行规定赔偿、保险或其他责任承担机制时才可能成立。对于任何具体客户，订单、主协议、附加条款和谈判后的责任安排都可能改变结果；本文比较的只是公开标准机制，而不是特定客户的最终合同结果。

分母决定赔多少，边界决定什么算事故

信用额最容易被忽视的部分，往往不是百分比，而是分母。

AWS 的 EC2 Region-Level SLA 是 99.99%，但这一承诺并非无条件适用于任意 EC2 部署。所有运行实例需要同时部署在同一区域的至少两个可用区；单实例则属于另一套 99.5% 的 Instance-Level SLA。区域级信用档位为 10%、30% 和 100%，但信用额的基数是没有达到 SLA 的受影响区域 EC2 月账单；单实例索赔则以对应单实例为范围，并且 Reserved Instance 的一次性预付款等项目不进入相同的月账单信用基数。(Amazon Web Services, Inc.)

这意味着一个买方首先要为取得较高层级的承诺支付自己的架构成本：至少两个可用区、额外实例、复制机制、流量切换，以及相应的运维复杂度。SLA 并不是在架构之外额外赠送的一层保障，它往往把某种部署方式作为进入更高保障区间的前提。

Google Compute Engine 同样显示出这种结构。月度可用率和信用额按 Project、Region 计算，单实例则按实例计算；Premium Tier 下，多可用区实例一般对应 99.99% 目标，而单实例根据实例家族对应较低目标。Google 对 Downtime Period 还设有时间颗粒度：不足一分钟的部分分钟或间歇性中断不计入 Downtime Period。信用档位为 10%、25%、100%，对应的仍是受影响 Covered Service 的月账单，而不是企业总损失。(Google Cloud)

于是两个在用户体验上相似的故障，可以在合同里变成两个不同事件。一个连续 61 秒的失败，和几十次每次不到一分钟的间歇失败，可能对应用形成相近的操作痛苦，却不一定形成相同的 SLA 结果。

计量制度不是事故发生以后才出现的会计问题。它从一开始就在定义“什么叫事故”。

架构前提其实是一种风险共担

IBM 对 SLO 与 SLA 的区分尤其适合说明这一点。IBM 明确把 SLO 描述为目标而非合同保证，同时指出，要让一个 workload 充分利用其 VPC 99.999% SLO 的示例，需要在一个多区区域的三个可用区分别部署虚拟服务器，并配置负载均衡器。少部署一个区，成本下降，但工作负载韧性也随之下降。IBM 对责任边界的表述同样清楚：IBM 负责 cloud 本身的韧性和恢复，客户负责其 workload 的韧性与恢复。(IBM Cloud)

这使“几个 9”从营销数字重新变成一个资本配置问题。

较高可用性通常要求更多实例、更复杂的状态复制、更昂贵的跨区流量、更成熟的故障转移设计，以及更高的测试和人员成本。供应商承诺的百分比，只有和达到该承诺所需的买方投入一起看，才有经济意义。

如果一个架构只有单实例，却拿多区 SLA 作为自己的内部可靠性假设，那么它实际上没有购买那项风险转移。如果一项服务的高可用配置成本高于预计故障损失，企业也可能理性地选择较低冗余。问题不是追求最高百分比，而是找到冗余成本、剩余损失与可恢复性之间的均衡点。

索赔时钟会把理论权利变成实际权利

SLA 的第二个常见错觉，是把“有资格获得信用额”理解为“信用额会自动到账”。

Cloudflare 要求客户首先在事件后五个工作日内通知 Customer Support。正式材料需要包含事件说明、持续时间、traceroute、受影响 URL、客户采取的解决尝试等；充分证据最迟应在事件发生月份之后的下一个计费月结束前提交。Cloudflare 同时明确，全面监控客户内容是客户责任，但会考虑客户使用的商业上合理的独立测量系统，并利用合理可得的信息验证索赔和计算受影响比例。(Cloudflare)

AWS 的机制不同，但逻辑一致。EC2 信用索赔需要在事故发生后的第二个计费周期结束前提交，并提供日期、时间、区域或可用区、资源 ID，以及能够佐证中断的请求日志。缺少所要求的信息可能直接失去信用资格。区域级和实例级索赔对于同一实例不能叠加。(Amazon Web Services, Inc.)

Google 要求客户在获得 Financial Credit 资格后的 60 天内通知技术支持，并提交显示 Downtime Period 及日期时间的日志；未满足这些条件会丧失信用权利。Oracle 的 PaaS/IaaS pillar 同样要求客户提交具体服务、事故情况、时间和持续时长、Region、相关 OCID、处理尝试以及审计或操作系统日志，并要求 Oracle 在问题发生后 60 个日历日内收到索赔。(Google Cloud)

这意味着企业购买 SLA 时，同时购买了一项内部流程义务：监控、留存、归因、通知和索赔。

如果没有这些能力，账面上的 SLA 权利可能没有变化，实际可实现价值却会明显下降。

谁掌握故障面，谁就掌握一部分证据权

这里存在一个更深的激励问题。

云供应商掌握主机、网络、控制平面和平台内部遥测；客户掌握端到端请求、业务交易、应用日志和用户侧体验。一次故障到底发生在哪个边界，往往不能由单方数据完整证明。

如果所有证据都依赖供应商内部指标，客户很难独立验证。如果只采用客户侧监测，又可能把应用缺陷、第三方网络或客户自己的配置故障错误归因给平台。

因此，更好的共同计量规则不应追求庞大，而应追求“薄”：指标数量少、定义明确、时间颗粒度确定、资源身份明确，并允许双方用独立数据复核。

Cloudflare 接受商业上合理的独立测量，就是这种结构的一个有用信号：服务商仍负责判断 SLA 是否成立，但买方不必完全依赖服务商自己生成的观察结果。(Cloudflare)

沿着 Heng Lu 的思路，核心不是要求一份无边界的保证，而是让真正掌握某个故障面的参与者承担相应的可见证据责任。供应商掌握基础设施故障面，就应当能够给出足够清晰的服务侧证据；买方掌握 workload，就应当保持自己的端到端观测和恢复记录。共同计量的价值，在于减少事故后的解释空间，而不是制造更多指标。

信用额不是保险金

公开 SLA 的补救设计进一步限制了风险转移的深度。

Cloudflare 把 SLA 违规的 Service Credit 定义为唯一补救，年度信用额总额最高不超过客户累计月度服务费的六个月，而且只针对相关 Service 的月度经常性费用计算。(Cloudflare)

AWS 的信用通常用于抵扣未来 EC2 付款，并明确不能因为 SLA 信用自然获得其他退款或付款；标准条款把 SLA 信用作为相应不可用或未履约情形下的唯一补救机制。(Amazon Web Services, Inc.)

Google 的最高月度 Financial Credit 不超过相应区域未满足 SLO 的 Covered Services 当月应付金额，并用于未来 Covered Service 的使用。对特定虚拟机的停机，单实例与多可用区口径不能同时取得信用。(Google Cloud)

Oracle 的设计进一步说明信用额的“资源局部性”：信用只针对没有达到承诺的具体 Cloud Service，以测量期内实际使用的不合规服务数量对应的净费用为基础。若同一事件同时落入多个 SLA，一般只按照能产生最高信用额的那一项获得信用，而不能把多项信用相加。信用的使用和失效方式还随 PAYG、Monthly Universal Credits、Annual Universal Credits 和 Funded Allocation Model 等采购模式变化。其公开 pillar 将相应 Service Credit 界定为适用服务承诺失败时的唯一补救和 Oracle 的全部责任。(甲骨文)

不可叠加规则在经济上非常重要。一个事故可能同时击穿计算、网络、负载均衡和应用链路，也可能同时满足多个指标失效条件，但信用机制通常不是把所有受损维度加总成为一张损失表。合同更倾向于为同一故障定义一个有限的补救路径。

因此，一次导致企业损失 100 万元的停机，可能只对应几万元甚至更少的服务信用；反过来，信用达到受影响服务月费的 100%，也不等于企业获得了全部损失赔偿。两者使用的是不同分母。

百分比为什么不适合做供应商排行榜

AWS、Google、Cloudflare、Oracle 和 IBM 的公开条款可以放在一起比较，但不宜因此得出“谁更可靠”的排名。

原因很简单：这些数字计量的对象不同。

AWS 区域级 EC2 SLA 需要跨 AZ 部署；Google 区分多区、单实例、网络层级和地区；Cloudflare 引入受影响客户比例；Oracle 按具体服务甚至可用性、可管理性和性能等不同承诺设计信用；IBM 则特别提醒 SLO 和合同 SLA 不是一回事。(Amazon Web Services, Inc.)

比较这些数字而忽略计量边界，就像比较两份保险的“赔付比例”，却不看免赔额、承保标的、除外责任和最高赔偿额。

真正应该横向比较的是一组更不显眼的变量：停机从哪里开始计时；必须有多少资源同时失败；是否要求跨区架构；什么费用进入赔付基数；客户必须保存哪些日志；由谁判定归因；多少天内必须索赔；哪些事件排除；同一事故能否叠加；信用何时失效。

名义标签只是合同首页。真正购买的是依赖关系和补救路径。

SLA 留下的那部分风险去了哪里

一旦把 SLA 看成有限风险分配工具，一个更实际的问题就出现了：没有被转移的风险由谁承担？

答案通常仍然是客户。

Cloudflare 的标准条款把网站、互联网连接、内容、数据库、应用等客户侧资源的可用性责任留给客户；IBM 更直接把 cloud 的韧性和 workload 的韧性分开。(Cloudflare)

这部分风险只能通过其他工具处理：架构冗余、故障隔离、跨区或跨区域部署、备份与恢复、流量迁移、供应商多样化、业务连续性计划、保险、合同谈判和退出能力。

这也是 Heng Lu 所强调的区分真正有价值的地方：不要把一项名义保证当成已经购买的风险转移。先确认依赖和补救，再给剩余风险定价。

SLA 解决的是有限问题。把它要求成为完整保险，会得到一份极其昂贵甚至无法定价的合同；把它误认为完整保险，则会让企业在最需要补偿的时候发现，大部分风险从未离开自己的资产负债表。

来源