Azure活动目录（AAD）是Office 365中最薄弱的一环？（上）

欧洲的O365租户本月3号的时候发现他们的部分员工没法访问邮箱以及Sharepoint站点了。最后发现问题并不在意O365上，而是AAD的配置错误导致了Web协议的验证失败从而导致OWA和O365的控制面板页连接失败。这个问题还影响了其他依赖AAD的微软云服务，直到5个小时之后，微软才修正了错误。尽管到目前为止事件的根本原因还没确定，但基本足见O365对AAD的依赖性，而这个服务并不可靠。

这次的事故让很多人想起了去年6月，美国的Exchange Online用户经历的掉线7小时事件（新闻链接），此次的事件影响了西欧和北欧的用户。虽然故障已经排除，但是此次事件引发了我对以下几点的思考：

第一，事实。根据站点的日志报告显示，此次故障发生在GMT12月3日8时59分，然后用户请求堆积在服务端，直到大概5小时之后的下午13时15分。微软的官方解释用大白话说就是：“配置错误导致访问请求被路由到别的地方去鸟~因此导致基于AAD验证的服务被拒绝访问”。

轻描淡写的“配置错误”掩盖了一系列可能性，小到XML文件的编译错误，大到基础架构的运能调整都能概括为配置，不管是哪种可能，导致的结果是随着客户请求在服务端的堆积，AAD撑不住了，无法通过AAD验证的用户最终无法连接到O365的服务。从故障发生的时间（8时59分）正是欧洲用户上线的高峰，而与此同时亚洲和美洲这边就丝毫不受影响，这足见AAD的抗压能力缺失。

微软随后向用户发布了事件报告（PIR IS34783），但就像所有危机公关辞令一样，许多导致问题发生的内部细节并没有公开，但是这篇报告依然值得一读。

报告称，事情的起因是一个“配置错误”，直接导致生产网络的路由错误。然后随着请求的激增，情况更加恶化最终导致服务中断。3个小时后，微软发现了这个问题，修复了错误的配置从而恢复了服务。报告称，官方修复这个错误的时间是当天11：49，之后故障情况就有所缓解，直到一个半小时后的13:15，服务才完全恢复。

随后微软给出了支持这一结论的两点理由：

第一，O365最近的一次升级暴露了微软生产环境与准生产环境间的配置问题。微软的准生产环境其实就是一个验证变更和新应用的测试环境，通过之后，代码才会同步到生产环境。而此次“配置错误”导致了部分O365用户连到了准生产环境，据称此环境的后台日志显示了大量AAD前端用户的验证信息。

第二，随着后台日志的堆积占用了大量系统资源，进而导致了欧洲数据中心间的验证请求失败。最后导致用户连接O365失败。

在解读事件报告时我发现，一些诸如究竟是什么配置错误，以及它最终是如何影响到微软云体系的核心服务的问题并没有获得明确解答。

很显然，12月3号的故障是AAD管理员人为产生的。诚然，在云端的管理运维团队一定是世界上最好的Windows管理员，但是再聪明的人也会犯错误。事件报告称微软已经解决了这个“配置错误”并且会研发“错误回滚技术”，以保证当最新版本的验证服务发生错误时，系统可以第一时间恢复到原来的版本。同时他们还在考虑将各个服务节点分离开，以防止因一个小问题而引发的蝴蝶效应。