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

在2014年6月的事故（新闻链接）中，也出现过由于资源被滥用致使在处理正常用户请求时出现了DoS。笔者感到惊讶的是，既然已经有先例，为什么此次还会发生同样问题。去年的事故中，由于邮件的后台日志在服务器堆积，而导致了邮件无法投递，似乎影响更大一些，而本月的事故并没有影响到邮件的传输。

众所周知，如果验证方式是基本身份验证或多因子验证，Outlook和ActiveSync在AAD发生故障时依然可以使用缓存的秘钥连接到Exchange Online。根据此次事件报告，仅有1%的Outlook用户和35%的OWA用户在此次故障中受影响。这个比例差异并不奇怪，因为OWA用户是Online模式的Outlook，启动时会要求验证，当验证请求得不到反馈时就无法连接到邮箱。关于不同客户端的不同影响情况会在后续的事件报告中进一步研究。

事件报告发布之后，不少O365的租户管理员通过Twitter等社交媒体抱怨，在故障发生时，服务状态面板（Service Health Dashboard，SHD）上并没有显示出他们租户的健康状况。根据当时的面板显示，O365的功能一切正常，并未告知用户正在经历AAD的频繁验证失败。尽管Azure状态面板上（Azure Status Dashboard）上有显示更多内容，但是租户跟多希望这两块面板可以有集成或者更有关联性。而不幸的是O365的SHD同样依赖于与Web客户端一样的验证方式，因此在故障发生时就没法及时反映Exchange，Sharepoint，Yammer和S4B的即时状态。

事实上，微软预计到O365的SHD会受各种状况的影响，因此在另一套环境里搭建了“紧急通告系统（Emergency Broadcast System，EBS）”，用户可以通过status.office.com的网页形式去访问。EBS的逻辑是，当SHD页面遇到问题时，租户或管理员将被自动转到EBS页，但是微软显然没有考虑到如同本月3号这种SHD的验证层发生问题的情况。

微软的合作伙伴们此次也受到了不小的影响，因为他们没有及时得到微软的支持，甚至在故障发生时根本没法提交支持请求，很可能是由于请求此时也无法进入支持系统。

尽管在事件报告中微软撇清了此次故障并不是O365本身造成的，但是广大客户和媒体依然把矛头指向了Office365。事实上，据不完全统计，此次故障影响了Azure管理门户（Azure Management Portal）, Dynamics CRM, Azure数据目录（Azure Data Catalog）以及运维数据门户（Operational Insight Portal）, 数据流分析（Stream Analytics）, 远程应用（Remote App）, Visual Studio团队服务以及SQL数据库. 几乎可以说微软的整个云组织在那天抛弃了欧洲。

我说句公道话，O365的验证系统是依赖于AAD的，所以并不能说是O365本身的问题。就像当Exchange Online或者内部的Exchange发生问题的时候，不能把责任推给Outlook一样。但是用户往往会看眼前的视图而不去了解背后的故事。

根据木桶理论，一个系统强健与否关键在于他最薄弱的一环。复杂如Office365这样的系统依赖于太多的组件，最重要的一个组件恐怕就是AAD了。整体来说，微软通过大量自动化的管理脚本以及多个数据中心的冗余设计，已经将Office365保持在一个非常高的在线率了。但是一旦有一个组件发生故障，它将影响的是数以万计的公司。

自从2011年6月上线以来，O365的整体体验情况还是不错的，故障率几乎忽略不计，并且也只是区域性的。作为每月六千万活跃用户的一款云服务，这个表现应该说是令人满意的。

毋庸置疑，微软对其Office365产品组会继续提出99.9%在线率的要求，在过去的4年里，都达到了这一指标。事实上在过去的6个季度，SLA已经超过了99.95%，在99.95%和99.99%之间，相信微软的下一个标准会更高。

除去我们今天在讨论的AAD之痛，此次事故中O365的SHD面板没有及时地通知到管理员。这在信息化的今天，在微软这样的企业也是令人心痛的。