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的验证层发生问题的情况。

status

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

尽管在事件报告中微软撇清了此次故障并不是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面板没有及时地通知到管理员。这在信息化的今天,在微软这样的企业也是令人心痛的。

 

发布于: 浏览:6161 次

还没有评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据