云厂商宕机那天，你的业务能撑多久？SLA 别只看那个百分比

选云服务时，几乎所有人都会看一眼服务等级协议（SLA）：99.9%、99.95%、99.99%。数字越漂亮越安心。

但真遇到故障那天，你会发现两件事：第一，赔付远没有想象中多；第二，业务停摆的损失，SLA 一分不赔。

一、那几个 9，换算成时间是多久

按一年 365 天计算，不同可用性对应的年度允许不可用时长大致是：

• 99.9%：约 8.76 小时；
• 99.95%：约 4.38 小时；
• 99.99%：约 52.6 分钟；
• 99.999%：约 5.3 分钟。

看着都是「三个 9、四个 9」，实际差了一整个工作日。多一个 9，价格往往上一个大台阶，这个钱值不值得花，要看业务能不能停。

二、SLA 是承诺，不是保证

这一点必须说清楚：SLA 不承诺「不会出故障」，它承诺的是「如果没达到可用性，我会给你补偿」。

补偿的形态通常是服务代金券、时长延长，很少是现金。也就是说，业务停了三个小时，客户跑了、订单丢了，你拿到的可能只是下个月账单的一点抵扣。

而且多数 SLA 设有赔付上限，比如不超过当期费用的 10%、30% 或 100%。服务费本身不高的业务，赔付款几乎可以忽略。

三、赔付条款里的除外责任，要认真读

常见的除外情形包括：

• 不可抗力：自然灾害、大规模电力中断、政策调整；
• 客户自身原因：配置错误、代码问题、未按建议做冗余；
• 免费额度与试用资源：很多 SLA 不覆盖；
• 单可用区部署：只在一个可用区买实例，该可用区故障可能被认定为不在保障范围；
• 未在规定时限内报障：有的协议要求你在故障发生后若干小时内提交工单，过期不受理。

「未及时报障就不赔」这一条，很多企业吃过亏。故障当天忙着救火，没人想起来提交工单，事后追偿时才发现已经超时。

四、云厂商的可靠性，要靠架构来兜

把业务全部压在一个可用区、一台实例上，SLA 写得再高也没用。真正管用的是这几层：

• 跨可用区部署：至少两台实例分布在不同的可用区，前面挂负载均衡；
• 数据库做主从或集群，并确认切换是自动的、切换时间可接受；
• 静态资源与备份放到独立位置，不要和源实例同账号同区域；
• 关键依赖准备降级方案：短信发不出时改用邮件，支付通道故障时引导到备用通道；
• 把域名 TTL 提前调低，故障时能快速切到备用环境。

云的责任是「机房不出事」，你的责任是「机房出事了业务还能转」。这两件事不能互相替代。

五、故障当天该按什么顺序做

• 先确认范围：是自己配置的问题，还是云厂商的区域性故障。看厂商状态页、看监控、看同区域其他业务；
• 再保核心：优先恢复下单、支付、登录这三条链路，其余功能可以先降级；
• 同步对外：官网、公众号、客服话术准备好，别让客户以为公司跑路了；
• 事后复盘：不是追责，而是找出「下次还会不会再停」的那个点。

六、选云时该问的问题

不要只问「可用性多少」，再问四句：赔付是代金券还是现金？上限是多少？哪些情况不赔？跨可用区部署要不要额外付费？这四个答案，比那个百分比更能反映真实保障。

写在最后

SLA 是一份合同条款，不是一颗定心丸。能扛住故障的，从来不是协议上的数字，而是提前做好的冗余和演练。名牌商务网提供企业上云的架构咨询与迁移支持，可以帮你把单点、备份和切换预案一起理清。