微软的官员们最近通过一份事故报告分享了一些幕后的情况，说明了是哪里出现了问题，这份报告可以通过Office 365 Dashboard查看。我首次发现这份报告——PIR IS3496，还要感谢Windows IT Pro网站上Tony Redmond的一篇博客文章。(我在自己的Office 365 Dashboard上没能找到这份事故报告，不知道是什么原因，但是我确实看到了完整报告的副本。)

　　根据这份报告，12月3日的Office 365故障持续了大约四个小时，大约是从(UTC)上午九点开始的。这份报告承认“欧洲地区很多用户都受到了这一问题的影响。”一些来自其他地区的用户，只要是通过欧洲进行身份验证，也有可能在那一天受到了这个问题的影响。

　　报告指出，“大约1%的Outlook和35%的OOTW(Outlook on the Web)请求受到了影响。”

　　这份事故报告表示，“受到影响的用户也无法登录进入Office 365门户。而且，一些用户也无法使用Office 365服务，包括SharePoint Online服务、Power BI、Microsoft Intune、 Yammer和Exchange Online。Exchange Online、Outlook on the web (OOTW)用户受到的影响最为严重，但是对Outlook and Exchange ActiveSync(EAS)移动设备的影响很小。”

　　此外，对Service Health Dashboard的访问也受到波及。即使是微软已经提供了备份“Emergency Broadcast System”(EBS)，欧洲地区的用户由于EBS故障也无法看到该页的更新。

　　归根结底，12月3号的服务中断故障是一个登录/身份认证的问题。这家软件公司表示，原因是双重的：

　　“1.最近的更新暴露了一个在生产和生产前认证基础架构之前的配置问题。这导致了一些请求被错误地路由，并在Azure Active Directory(AAD)前端造成了身份验证请求的积压。

　　2.被错误路由的认证请求积压在AAD引发了连锁反应，从而导致系统资源使用率居高不下，进一步加剧了这一问题，而当时的通信流量随着欧洲地区正常工作时间的到来出现了增长。这就导致欧洲数据中心(European Data Centers)出现了间歇性的身份认证请求失败，并导致AAD身份认证服务失败，从而影响到了Office 365服务。”

　　微软防止类似问题再次出现的下一步举措是什么?

　　这份报告称，该公司计划增加附加的故障注入技术以改善测试程序以及额外回退机制以允许使用旧版本的身份认证服务。

　　该报告补充表示，为了防止由于高CPU使用率可能造成的错误路由请求，微软计划增加更多的过载监测和恢复机制，提高服务终端和过载故障之间的隔离度。

　　由于不正确的内容分发网络(CDN)链接让用户无法看到http://status.office.com上的更新，微软计划在Office 365门户的访问受到影响的时候检查其切换选项。

　　微软的报告列出了所有这些步骤完成的截止日期——“2015年12月”。

　　我问过微软的官员，在12月3日受到影响的用户是否会以某种方式得到补偿，被告知该公司无可奉告。

　　我也很好奇，为什么微软会把这个故障分析报告作为面板报告而不是公开发布在博客中，就像之前 Office 365和Azure出现故障时那样。再一次，该公司表示无可奉告。

　　责任编辑：余芯