1.前言

昨天（11.12)，网上到处都充满了下边的吐槽。刚开始我还没太留意，后来还发现真是比较严重：

如此看来，阿里云确实受灾面积严重。而这又发生在双11期间，正是大家伙儿热情高涨薅羊毛的时候。见：阿里云的羊毛抓紧薅，五千的云服务器三百拿。

后续：

尊敬的客户：（阿里的公告）

您好！北京时间2023年11月12日 17:44起，阿里云监控发现云产品控制台访问及API调用出现异常，阿里云工程师正在紧急介入排查。非常抱歉给您的使用带来不便，若有任何问题，请随时联系我们。

--进展更新

17:50 阿里云已确认故障原因与某个底层服务组件有关，工程师正在紧急处理中。

18:54 经过工程师处理，杭州、北京等地域控制台及API服务已恢复，其他地域控制台服务逐步恢复中。

19:20 工程师通过分批重启组件服务，绝大部分地域控制台及API服务已恢复。

19:43 异常管控服务组件均已完成重启，除个别云产品（如消息队列MQ、消息服务MNS）仍需处理，其余云产品控制台及API服务已恢复。

20:12 北京、杭州等地域消息队列MQ已完成重启，其余地域逐步恢复中。

21:11 受影响云产品均已恢复，因故障影响部分云产品的数据（如监控、账单等）可能存在延迟推送情况，不影响业务运行。

2、关于SLA

SLA：Service Level Agreement，简称 “SLA”。我们先大致看看SLA，以年为单位，能允许的最长中断时间。

毕竟是出了故障，阿里云有自己相关的SLA合约声明，并且是有法律效应的。仔细查看官方文档：https://help.aliyun.com/document_detail/56773.htm

针对各种云服务，他们声明了各自的SLA相应规格。我们来看看几个有代表性的SLA：

2.1、云服务器 ECS服务等级协议

它分两种情况：单实例和多实例（多地域），两者的SLA起始标准有点不一样。

单实例：

多实例：（你可以简单理解为高可用，Multi-AZ)

从这个来看，阿里的要求还是比较高的。

多实例情况下：99.995%， 折算到年，大概是26.3分钟，平均每个月就是2.2分钟左右。

单实例呢：99.975%, 折算到年，大概：

(1-0.99975) * 365 * 24 = 2.16小时 = 129.6分钟

这样分推到一个月，大概：10.8分钟。

ECS作为最底层的云服务，提供这个等级的SLA，也是合理的。不过，此次，如果按这个算，赔偿面积会相当广。冯老师甚至列出了阿里云的健康状态页当时的结果 ：详见：https://mp.weixin.qq.com/s/cTge3xOlIQCALQc8Mi-P8w

2.2、VMware服务服务等级协议

以单实例为例：

也就是说，承诺的SLA为0.95， 这个等级就很一般了。估计永远也不会碰到。（1 - 0.95) * 365 * 24 /12 = 36.5小时。一个月能允许这么长时间的故障。基本上不叫什么服务了。希望这个不是他们官文的笔误。

2.3、轻量应用服务器服务等级协议

服务周期：一个服务周期为一个自然月。

实例服务周期总分钟数：按照服务周期内的总天数╳24（小时）╳60（分钟）计算。

实例服务不可用分钟数：在一个服务周期内轻量应用服务器实例不可用分钟数之和。

嗯，这个才是体现用户端服务的真正的SLA。

99.95%为起付标准。大概就是99.9%的一半，为8.76 * 0.5 = 4.88小时，分到一个月是：24.4分钟。第2档是不太可能了。时间跨度太大。也就是说10%，是差不多要赔了。

小结：

按实际情况来看，基本上第一档都触发了。也许赔偿还是次要的。及时总结教训并防止下次再犯才是重要的。SLA在云环境下比在非云环境下要求确实要苛刻的多。从底层基础设施的健康运营、软件本身的开发质量、到运维端的强有力的实时监控和维护，都非常的重要。

从阿里的SLA声明来看，越靠底层的服务，就提供越高等级的SLA。三九一五 （99.95%)，好像也是目前比较通行的服务等级。国际上一些大型云厂商或者提供PaaS/SaaS的软件供应商，也都采取这个等级的SLA。偏金融的云服务可能适当会要求高些。要求越高，那么需要的硬软件、人力、资金上的投入也会大幅提高。

由此，进一步联想到云环境下，一些有意思的常态性测试：

• 混沌测试（Chaos Test,  ChaosMonkey), 模拟底层服务出故障，系统的整个运行情况

• MultiAZ测试

• 压力测试

不要以为进了生产环境就高枕无忧了。能出问题的场景千奇百怪。

作为国内云厂商的标杆，还是希望阿里云能快速度过危险期。灾难不可能永远不会发生，只是要将发生的机率降到最低。