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用户无法登录其帐户。

创作场景

Azure 全球中断三小时：微软回复称 DNS 更新故障