前几天闹的沸沸扬扬的阿里云的故障，今天在群里看到一篇基于故障报告的技术分析，感觉说的挺有道理，解答了一些我的疑惑，也转过来给大家看看。
以下是全文内容：
阿里云前几天的故障详细报告出来了，跟很多网友猜的差不多，但也有很多细节不一样，一起来分析一下。
首先纠正几个错误，之前有很多网友分析是阿里云的AK系统出了问题，但从这份报告来看，AK本身没出故障，是保护AK系统免受“无效AK ID攻击”的白名单过滤机制出了问题。什么叫白名单过滤机制，就像为了防范非法用户拿假钥匙反复插入门锁尝试，门卫首先就会查验用户的合法性，合法后才允许其用钥匙尝试打开大门，这个门卫就是白名单。这本身是个保护AK的机制，这次故障的根因就是这里。
其次，影响时间并不是传闻的3个半小时，实际是1个多小时，从17:39分发现故障到18:35就开始陆续恢复了。从影响面来看，不是所有产品都受到影响了，绝大部分在线业务，例如ECS、RDS、ACK都没受影响，一些“全球性、大面积宕机”的说法太夸张了。部分用户的控制台确实无法登录，但不影响当时他的业务可以正常服务。
特别值得指出的是，尽管网上的声音给人的感觉是所有客户都受到影响，但就故障的影响面而言，实际上总体的宏观比例在10-15%之间，比如某大型电商交易平台、某国内基金会的知名代码托管平台等等都正常运行，很多客户也反映没有受到影响，网上所谓的“1个多小时都不能用，全网不能用”并不可信。
ok，进入正题，先讲下AK 是什么。阿里云的用户要访问云上资源，需要通过AK ID（用户名）和AK Secret（密码）来认证身份。出于AK服务的自身防御机制需要，AK服务每天定时生成一个白名单，ID不在白名单中的AK请求会失败，并被网关拦截。
为何AK服务有白名单机制？为防止海量攻击，AK服务通过数据库对AK ID（用户名）和AK Secret进行认证之前，有两步预处理，第一步，判断ID是否合乎命名规则，符合规则的进入认证环节，不符合规则的进入第二步；第二步，判断ID是否在白名单中，如果在就进入认证环节，如果不在则直接拒绝访问。
本次故障的问题在于：由于AK服务没有校验白名单的完整性，导致白名单不完整，让大量不符合命名规则的ID在第二步直接被拒绝，没能进入认证环节。
在整个修复过程中，阿里云工程师花了22分钟定位了问题，6分钟后制定方案并开始执行，28分钟后杭州等Region恢复正常，之后又花了45分钟全球Region恢复完毕，一共1小时41分钟。
故障基本分析完了，这个锅肯定得阿里云自己背，该道歉道歉，该赔偿赔偿。
从这次故障中，我们提出一些建议，希望阿里云重视。
首先，要降低爆炸半径，核心必须闭环，要做到隔离和收敛，才能做到故障可控。
其次，系统要关注对异常情况的处理，当发现白名单不完整后，应果断丢弃。
最后，从工具和系统机制上改进，要按照“数据、配置、发布”的流程，重点关注一致性和全链路校验，并按Region进行灰度。
