众所周知，就在刚过去不久的11月12号，阿里云突发了一次大规模故障，影响甚广。
以至于连咱们这里评论区小伙伴学校的洗衣机都崩了（手动doge）。
这么关键的双11节点，这么多热门业务和产品，这么大规模的崩盘故障，不一会儿这个事情便被推上了热搜。
而就在近日，阿里云官网上就该故障也给出了一份故障复盘报告，而报告中则给出了这次事件的问题原因。
细看一下不难发现，说到底，在代码级还是存在逻辑缺陷问题。当然阿里云在报告中也给出了一系列相应的改进措施：
- 增加AK服务白名单生成结果的校验及告警拦截能力。
- 增加AK服务白名单更新的灰度验证逻辑，提前发现异常。
- 增加AK服务白名单的快速恢复能力。
- 加强云产品侧的联动恢复能力。
其实当时发生这个事情时，正好是周日的傍晚，当时自己正在家里吃晚饭，所以对于这波故障的直接感受并不明显。
本来对这个事情都没太注意了，不过就在前几天，突然收到了一条来自于阿里云的赔偿短信。
出于好奇，我也登进阿里云的控制台尝试领取了一下。
果然，50很快就到账了（不过是代金券。。）。
而赔偿对象则为阿里云的对象存储OSS服务。
看到这里我才想起来，因为之前自己用的阿里云对象存储OSS来存东西，所以收到这条赔偿短信也就不奇怪了。
不过，它这条短信里所谓的SLA赔偿到底是按照什么标准来的呢？
同样出于好奇，我也看了一下阿里云SLA定义与详细规则。这次的赔偿也是按照不同产品的服务等级协议来划分的。
比如我这次受影响的的使用产品就是阿里云的对象存储OSS，而其对应产品的服务等级协议里也明确规定有具体的赔偿标准。
后台显示当时对象存储OSS的服务可用性为99.9884%。
按照阿里云承诺的当前产品服务可用性不低于99.99%的标准，很明显这就触发赔偿了。
而具体赔付比例按照上面产品服务等级协议里的描述，则来到了10%这个档。
看到这里，我也不禁想起了前段时间语雀的故障赔付，当时语雀的补偿方案是针对个人用户赠送6个月的会员服务。
对于这样类似的赔偿结果，有的用户表示愿意继续给产品一次机会，当然也有用户会表示无法原谅并弃用之。
其实这种长时间、大规模的故障，对于一些重度依赖云产品的用户或者业务来说打击往往是致命的。而这些事后给出的所谓的SLA内的赔偿和客户实际所承担的业务损失来说往往是杯水车薪，压根就覆盖不住，这还不谈客户为此所额外付出的人力物力成本。
因此对于这些云服务商而言，除了赔偿，更重要的还是多研究研究如何加强故障预防和处理，持续提升服务的稳定性和可靠性才是关键。
注：本文在GitHub开源仓库「编程之路」 https://github.com/rd2coding/Road2Coding 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。