5 月 2 日 19:29 到 22:35 UTC 之间，微软 Azure 发生了三小时左右中断，导致 Azure、Microsoft 365、Dynamics 和 DevOps 等多项服务出现连接问题。
根据最新消息，本次事故发生在 DNS 迁移期间，具体时间为 5 月 2 日 19:29 到 22:35 UTC 之间，大多数服务在 UTC 时间 21:40 恢复，其余服务在 22:35 UTC 恢复。根据微软方面的回复，造成该事故的根本原因如下：
作为计划维护活动的一部分，微软工程师执行了配置更改，以更新用于访问多个微软服务（包括 Azure 存储和 Azure SQL 数据库）的 DNS 区域名称服务器（name server）之一。更改过程失败导致这些区域的四个名称服务器（name server）之一指向没有数据的 DNS 服务器并返回否定响应。结果是，这些服务使用的域（例如 database.windows.net ）中大约 25％的查询产生了错误结果，并且这些服务的可访问性降低。因此，依赖于这些核心服务的多个其他 Azure 和 Microsoft 服务受到不同程度的影响。
该事件对 Azure 计算、存储、App Service、Azure AD 身份服务和 SQL 数据库产生了连锁反应。根据外媒 The Register 此前的报道，本次受影响的服务包括 SharePoint Online，OneDrive for Business，Microsoft Teams，Stream，Power BI，Planner，Forms，PowerApps，Dynamics 365，Intune 和 Office Licensing。
微软方面表示，此事件源于两个独立的错误和一些巧合，这两个错误本身其实不会产生影响：
1、微软工程师执行了名称服务器（name server）委派更改以更新多个区域的名称服务器，包括 Azure 存储和 Azure SQL 数据库。其中，每个区域有四个名称服务器用于冗余，并且在此维护期间仅对一个名称服务器进行更新。用于进行更改的自动化参数配置错误导致名称服务器委派错误。
2、作为先前自动化工作的一部分，空区域文件存在于非指定委托的预期目标服务器上。这本身并不是问题，因为名称服务器没有为相关区域提供服务。
但是，由于此实例中更改自动化出现配置错误，被委派的目标名称服务器是空副本。因此，此名称服务器对区域中所有查询给出了否定（nxdomain）答案。由于该区域的四个名称服务器记录中只有一个是不正确的，因此受影响区域大约四分之一的查询收到不正确的否定响应。
为解决此问题，微软工程师通过将名称服务器值还原为先前的设置来更正委派问题。工程师验证所有响应都是正确的，DNS 解析器开始在 5 分钟内返回正确结果。某些访问错误值并缓存结果的应用程序和服务可能需要更长的恢复时间，直到错误的缓存信息到期为止。在事件发生期间，微软多次更新页面，并逐渐恢复服务。该公司向客户保证，DNS 记录在活动期间没有受到影响，并且 Azure DNS 本身仍然存在。
对此，微软方面建议用户可以执行以下操作（包括但不限于）：
- 执行名称服务器更新代码中的附加检查，以防止意外更改（正在进行）。
- 预执行建模，以准确预测变更结果，并在执行 [正在进行] 之前检测潜在问题。
- 改进每个区域，每个名称服务器监视器，立即检测导致一个名称服务器偏离其他名称服务器（正在进行）的更改。
- 改进 DNS 命名空间设计，以更好地允许分阶段推出更改，同时降低增量影响（进行中）。
根据了解，这不是微软 Azure 第一次发生服务中断。 1 月份，全球 Azure 中断影响了 Office 365，Azure 和 Dynamics 365 服务，原因也与 DNS 有关，微软方面表示是 Level 3 托管 DNS 服务出现问题。去年底，Azure AD 多因素身份验证中断使全球的 Office 365 用户无法登录其帐户。
最新评论