Azure 宕机 3 个小时:因人为配置 DNS 失误 – 运维派
可以用TITSUP这个技术术语来形容今天持续了三个小时的宕机,TITSUP的全称是完全无法支持用户的数据包。
至少在过去的一两个小时,由于DNS配置失误,微软Azure云在全球范围内处于不稳定的状态。
这次影响整个平台的故障破坏了全球各地由微软托管的各种系统:从Azure SQL数据库和App Services,到多因子身份验证、Microsoft 365、Teams、Dynamics、SharePoint Online和OneDrive,不一而足。
本文发稿时,这个云巨头在逐渐恢复如初,Azure地区在逐个地恢复正常,不过你遇到的实际情况可能会有所不同。问题似乎是从协调世界时(UTC)19点45分左右开始的。
Azure状态页面在UTC 21点28分显示:“客户在Azure及微软其他服务(包括M365、Dynamics和DevOps等)方面可能遇到间歇性连接问题。”
“工程师正在研究影响网络连接的DNS解析问题。连接问题导致对计算、存储和数据库等下游服务带来了影响,一些客户可能无法提交支持请求。”
“一有更多信息,我们会及时发布。一些客户可能开始看到恢复正常。”
换句话说,微软还没有给出故障消除信号;正如微软所说,在接下来的半小时任何情况都有可能发生。
早些时候的Azure状态页面
在Microsoft 365状态页面上,微软的技术人员声称内部DNS配置错误导致了这次宕机:
用户可能无法访问Microsoft 365服务或功能。
更多信息:受影响的服务包括SharePoint Online、OneDrive for Business、Microsoft Teams、Stream、Power BI、Planner、Forms、PowerApps、Dynamics 365、Intune和Office Licensing。
我们已找到并纠正了阻止用户访问Microsoft 365服务和功能的DNS配置问题。我们观察到成功的连接数量增加,我们的遥测数据表明所有服务正在恢复。我们继续密切关注环境,以验证服务已恢复。
这不会是DNS问题头一回整垮Azure――据估计,上一次发生这种情况时,几个客户的数据库丢失数据,所以自求多福吧。
最新消息:
微软表示它已修复了破损的系统,结束了今天持续了三个小时的宕机,Azure的网络基础设施应该或多或少已恢复正常:“我们已采取了缓解措施;大多数服务已恢复,只有一小部分服务可能仍受到一些影响。”
这个科技巨头补充道:“底层的根本原因是不正确的名称服务器授权问题。”
- 运维日记008 - 配置缓存DNS服务(Cache Only DNS Server)
- 54.为Azure上的虚拟机配置反向DNS解析
- Linux运维笔记----DNS的基本配置
- Linux运维实战之DNS(bind)服务器的安装与配置
- 微软Azure云之企业Exchange 2016部署13—DNS配置
- Linux运维实战之DNS的高级配置(转发器、视图等)
- 运维学习之DNS配置高速缓存
- Linux运维实战之DNS(bind)服务器的安装与配置
- 主域控宕机无法恢复后,如何配置辅助域控继续工作
- Windows server 2003 DNS"子域与委派"管理配置指南
- Redhat DNS Bind配置详解
- dnsmasq配置dns实战
- 运维监控利器Nagios之:nagios配置详解
- 数据库宕机,my.cnf各项配置优化
- OGG运维优化脚本(十七)-信息同步类--配置备份
- Azure 证书配置错误: The service configuration file does not provide the certificate identification
- Linux IP、DNS、Route配置
- Ubuntu 下 IP 地址与DNS配置
- 使用OBS+Azure Media Service+CDN进行直播,配置方法及最佳实践
- Linux系统下智能DNS服务器BIND9.7.2安装配置