说说云架构下SLA那些事儿，别光看条款其实还挺复杂的

说说云架构下SLA那些事儿，别光看条款其实还挺复杂的

很多人觉得云服务的SLA（服务等级协议）就是合同里那几个百分比数字，99.9%可用性”，真用起来才发现，这玩意儿水深得很，根本不是看一眼条款就能明白的，它就像一座冰山，条款是水面上的十分之一,水下的部分才是真正决定你业务会不会翻船的关键。

云的环境让SLA变得“立体”了，以前自己管机房，SLA可能只管到服务器硬件通电不断电，但在云里，你的服务是个“连环套”，比如你的应用跑在云上，你依赖云厂商的虚拟机（计算）、数据库（存储）、网络（连接）。《凤凰项目》这本讲IT运维的小说里有个比喻，说IT系统就像一套复杂的流水线，云架构把这条流水线搬到了别人的工厂里，而且每个环节都由不同的车间负责，云厂商的SLA往往是分层的：计算有计算的SLA，存储有存储的，网络有网络的，你的应用整体能达到几个9，得看这一串“链条”里最弱的那一环，更麻烦的是，这些SLA之间经常是“乘法关系”，而不是独立的，比如计算服务中断时，存储服务可能虽然本身正常，但你完全访问不了,对你来说效果就是服务全挂。

SLA的“时间”算法是个大学问，条款里写的“月度可用性99.9%”，听着很清晰，但“宕机时间”怎么算？是从你发现并正式报修开始算，还是从故障实际发生开始算？很多云厂商的条款规定，故障时间从他们确认后开始计算，这中间你感知到的故障时间、你排查问题的时间，可能都不算数，一次持续4小时的严重中断，和24次每次10分钟的零星中断，对用户体验的伤害天差地别，但在SLA的计算公式里，它们可能只是“总不可用分钟数”的区别，赔给你的服务抵扣券可能一模一样。亚马逊AWS在其SLA文档中就有对“排除条款”的详细列举，比如因你配置错误、或例行维护提前通知过的中断，都不计入宕机时间,这些细节才是真正影响你权益的地方。

云架构的“共享责任模型”让SLA的边界极其模糊，云厂商保证“云平台本身”的可用性，但你自己在云上搭建的架构设计合不合理、代码健不健壮、配置安不安全，人家可不管，如果你的应用因为一个糟糕的数据库查询设计导致崩溃，这可不属于云厂商SLA的覆盖范围。业内常说的“云厂商负责云的安全，你负责云里的安全”，就是这个道理，你的架构是否做了多可用区部署？是否设计了良好的故障转移和弹性伸缩？这些你自己该做的事如果没做，那么云平台基础SLA再高，你的业务照样一碰就倒，Netflix之所以大力推行“混沌工程”，主动在自己的云环境中“搞破坏”，就是为了验证自己架构的韧性,弥补单纯依赖云厂商SLA所带来的巨大盲区。

赔偿条款几乎是“象征性”的，绝大多数云SLA的赔偿，都只是返还服务中断期间对应服务的费用的一部分（通常是10%到100%不等），而且是以“服务抵扣券”形式返还，这和你业务中断造成的真实损失（客户流失、品牌受损、订单丢失）相比，简直是九牛一毛。微软Azure的SLA条款中就明确写道：“这是您就任何未能满足SLA的情况所能获得的唯一且全部的救济。” 这句话翻译过来就是：赔你点代金券就算了，别想告我，SLA的真正价值，与其说是“经济保障”，不如说是一个“压力测试指标”和“架构设计指南”，它倒逼着你去思考：我的业务能承受哪个级别的中断？为了达到想要的可用性,我需要在架构上投入多少成本和设计精力？

所以说，云架构下的SLA，绝不是一个简单的数字承诺，它是一个需要你从自身业务连续性要求出发，倒推回去审视云服务选型、架构设计、运维监控和故障预案的完整体系，光盯着合同里那个“99.95%”，就觉得高枕无忧，那很可能在问题真正发生时，才发现自己签的只是一份“心理安慰剂”，真正的SLA，是你自己用良好的架构和实践，在云这个复杂生态中,为自己构建出来的。