最近“阿里云赔一个亿”在网上传开，不少人的第一反应是云厂商出了大事故，或者有人拿到了天价赔偿。标题确实抓眼球，但如果你用过云上服务，会发现这个数字背后的逻辑并不神秘。弄清楚云服务赔付是怎么算的，比盯着数字本身更有用。
一个亿从哪里来
云计算行业普遍用服务等级协议（SLA）约定可用性。以某产品承诺月度可用性99.95%为例，实际可用性低于这个值，用户通常能按比例获得服务时长或代金券。计算基数一般是该产品当月的费用，多数协议还设有上限。具体条款每个产品都不一样，要以你所用产品的官方文档为准。
所以“赔一个亿”更可能是几种情况叠加的结果：大客户全年或多个产品的累计消费，或者标题在传播中被放大。看到这类数字，先问三件事：赔的是谁，按什么口径算，给的是现金还是代金券。问清楚这三点，大部分数字都会降温。
一次故障的赔付账怎么算
假设一家中型电商在大促期间使用某云平台的数据库和对象存储，某次区域性故障让订单系统中断约40分钟。这是为了说明逻辑的假设案例，并非某家企业的真实情况。
这类事情发生后，比较稳妥的做法通常是三步：
- 用自己的监控数据确认故障的起止时间和影响范围，不要只依赖对方的通知。
- 打开服务协议，把实际不可用时长换算成可用性，和承诺值比一比。
- 提交工单，附上日志和业务损失证明。证据越具体，沟通越顺畅。
按99.95%的月度承诺算，一个30天的月份共43200分钟，允许的不可用时间约为21.6分钟。40分钟明显超出，所以这家企业有了赔付资格。协议里的比例规则算下来，拿到的是当月部分服务费用的代金券。
这笔补偿和订单损失相比差距很大。不少用户赔付后会失望，往往是因为预期和计算方式对不上。云厂商看不到你的营收和利润，它能依据的只有你买了什么、用了多少，所以赔付按账单来算也就不奇怪了。
赔付为什么往往不够覆盖损失
多数云厂商的SLA有几个共同点，读的时候可以重点看：
- 赔付基于你购买的服务费用，不基于营收或利润。业务损失再大，赔的仍然是账单上的那部分。
- 设有单月赔付上限，超出部分一般不承担。
- 不可抗力、用户自身配置错误、计划内维护通常被排除在外。这些排除项有时比赔付比例更值得细看。
- 申请需要在规定时间内提交，证据不全可能被驳回。
这些条款不完全是为了推脱责任。大规模服务本身就需要一套风险分担的办法，赔付只是其中一块。对用户来说，更能扛住事故的，通常是系统本身的设计，赔付只能补回一部分钱。
降低风险可以从哪里做起
如果你的业务跑在阿里云或其他云上，下面几件事投入不大，但比研究赔付条款更能直接减少损失：
- 把对应产品的SLA文档读一遍，记下承诺值、计算方式和申请时限，并以官网当期公布的内容为准。
- 关键业务考虑多可用区部署。单个可用区出问题时，流量能不能切过去，要实际验证，不能只停留在架构图上。
- 配置独立于云厂商的监控和告警。故障当天，你需要自己的数据来核对。
- 定期演练故障切换和数据恢复。备份文件存在不等于能恢复，最好每隔一段时间真实恢复一次。
- 大客户可以在采购合同中约定明确的服务指标，必要时与服务商协商专属条款。
怎么看待这类赔付新闻
“阿里云赔一个亿”这类标题，说明业务对云基础设施的依赖越来越深，大家对稳定性也越来越敏感。把数字拿出来讨论很正常，但它替代不了对自身系统的判断。
赔付能弥补一部分经济损失，却补不上工程上的准备。先检查自己的业务在故障时能不能撑住，这件事比琢磨一个数字更有用。
