Microsoft 发布了本周重大 Microsoft 365 登录问题的根本原因分析

本周，我们有近 5 小时的 Microsoft 365 停机时间， 用户无法登录多个服务，包括 OneDrive 和 Microsoft Teams。

的旅程 微软发布了该问题的根本原因分析，微软称这是由于服务更新，该服务更新旨在针对内部验证测试环，但由于 Azure AD 后端服务安全部署过程 (SDP) 系统中的潜在代码缺陷，它被直接部署到微软的生产环境中。

微软表示，在 21 年 25 月 28 日 2020:00 UTC 和 23 年 29 月 2020 日 2:25 UTC 之间，客户在为所有依赖于 Azure Active Directory (Azure AD) 的微软和第三方应用程序和服务执行身份验证操作时遇到了错误。 ) 进行身份验证。 到第二天 XNUMX 点 XNUMX 分，这个问题才完全缓解。

美国和澳大利亚受到的打击最为严重，美国只有 17% 的用户能够成功登录。

由于 SDP 系统中的潜在缺陷破坏了部署元数据，微软无法回滚更新，这使得该问题更加复杂，这意味着必须手动回滚更新。

微软向受影响的客户道歉，并表示他们将继续采取措施改进微软 Azure 平台及其流程，以帮助确保未来不会发生此类事件。 计划的步骤之一包括对 Azure AD 服务后端 SDP 系统应用额外的保护，以防止发现的问题类别。

阅读下面的完整分析：

RCA – 跨多个 Microsoft 服务和 Azure Active Directory 集成应用程序的身份验证错误（跟踪 ID SM79-F88）

影响总结： 在 21 年 25 月 28 日 2020:00 UTC 和 23 年 29 月 2020 日 2:XNUMX UTC 之间，客户可能在为依赖于 Azure Active Directory (Azure AD) 的所有 Microsoft 和第三方应用程序和服务执行身份验证操作时遇到错误用于身份验证。 使用 Azure AD BXNUMXC 进行身份验证的应用程序也受到影响。

尚未使用 Azure AD 对云服务进行身份验证的用户更有可能遇到问题，并且可能已经看到与下面显示的平均可用性数字相对应的多个身份验证请求失败。 这些已在不同的客户和工作负载中汇总。

• 欧洲：事件期间的成功率为 81%。
• 美洲：事件期间的成功率为 17%，在缓解之前提高到 37%。
• 亚洲：事件前 72 分钟的成功率为 120%。 随着营业时间高峰流量的开始，可用性降至最低的 32%。
• 澳大利亚：事件期间的成功率为 37%。

到 00 年 23 月 29 日 2020:02 UTC，大多数客户的服务已恢复到正常的运营可用性，但是，我们观察到身份验证请求失败的频率很低，这可能会在 UTC 时间 25:XNUMX 之前影响客户。

在影响开始时间之前进行身份验证的用户不太可能遇到问题，具体取决于他们正在访问的应用程序或服务。

恢复措施到位，保护虚拟机、虚拟机规模集和 Azure Kubernetes 服务的托管身份服务，在整个事件期间平均可用性为 99.8%。

根本原因： 28 月 21 日 25:XNUMX UTC，部署了针对内部验证测试环的服务更新，导致 Azure AD 后端服务在启动时崩溃。 Azure AD 后端服务安全部署过程 (SDP) 系统中的潜在代码缺陷导致它绕过我们的正常验证过程直接部署到我们的生产环境中。

Azure AD 旨在成为一种以主动-主动配置部署的地理分布式服务，该配置具有跨全球多个数据中心的多个分区，并使用隔离边界构建。 通常，更改最初针对不包含客户数据的验证环，然后是仅包含 Microsoft 用户的内环，最后是我们的生产环境。 这些更改将在几天内跨五个环分阶段部署。

在这种情况下，由于潜在缺陷影响了系统解释部署元数据的能力，SDP 系统未能正确定位验证测试环。 因此，所有环都同时成为目标。 不正确的部署导致服务可用性下降。

在影响的几分钟内，我们采取措施使用自动回滚系统恢复更改，这通常会限制影响的持续时间和严重程度。 然而，我们的 SDP 系统中的潜在缺陷破坏了部署元数据，我们不得不求助于手动回滚过程。 这大大延长了缓解问题的时间。

减轻： 我们的监控在最初影响的几分钟内检测到服务降级，我们立即开始进行故障排除。 开展了以下缓解活动：

• 影响始于世界标准时间 21:25，在 5 分钟内，我们的监测检测到了不健康的状况，并立即启动了工程。
• 在接下来的 30 分钟内，在对问题进行故障排除的同时，我们采取了一系列步骤来尝试尽量减少对客户的影响并加快缓解速度。 这包括在应用缓解措施后主动扩展一些 Azure AD 服务以处理预期负载，并将某些工作负载故障转移到备份 Azure AD 身份验证系统。
• 在 22:02 UTC，我们确定了根本原因，开始补救，并启动了我们的自动回滚机制。
• 由于 SDP 元数据损坏，自动回滚失败。 在 22:47 UTC 我们启动了手动更新服务配置的过程，绕过了 SDP 系统，整个操作在 23:59 UTC 完成。
• 到 00:23 UTC 足够的后端服务实例返回到健康状态以达到正常的服务操作参数。
• 在 UTC 时间 02:25 之前，所有具有残留影响的服务实例均已恢复。

接下来的步骤： 对于受影响客户的影响，我们深表歉意。 我们正在不断采取措施改进 Microsoft Azure 平台和我们的流程，以帮助确保未来不会发生此类事件。 在这种情况下，这包括（但不限于）以下内容：

我们已经完成了

• 修复了 Azure AD 后端 SDP 系统中的潜在代码缺陷。
• 修复了现有的回滚系统，以允许恢复最后一个已知良好的元数据以防止损坏。
• 扩大回滚操作演练的范围和频率。

其余步骤包括

• 对 Azure AD 服务后端 SDP 系统应用额外的保护，以防止此处确定的问题类别。
• 加快向所有关键服务推出 Azure AD 备份身份验证系统作为首要任务，以显着减少未来类似类型问题的影响。
• 将 Azure AD 场景载入自动化通信管道，该管道在 15 分钟内向受影响的客户发布初始通信。

提供反馈信息： 请参加我们的调查，帮助我们改善 Azure 客户沟通体验： https://aka.ms/AzurePIRSurvey

通过 网易科技