微软Azure大约持续10.5小时,经历了一个重大停机影响Azure DevOps服务在巴西南部地区(SBR)。

故障发生由于错误错误在快照删除工作,无意删除了Azure SQL Server的目的而不是SQL Azure数据库。

这导致了删除所有17个生产数据库规模的单位,导致无法处理客户流量。

有数据丢失?

幸运的是,停机期间没有经验数据丢失。这个问题被发现在20分钟内,随叫随到工程师及时解决问题。然而,有几个因素促成了恢复时间延长。

首先,由于客户无法恢复AzureSQL服务器本身,SQL Azure团队必须参与修复过程。

这个过程包括确定需要SQL Azure待命的工程师和恢复服务器,历时大约一个小时,据埃里克•Mattingly主要软件Eng经理在微软Azure。

其次,恢复数据库添加额外的时间由于备份配置。虽然一些数据库配置Geo-zone-redundant备份,其他人之前创建这个功能可用,只有Zone-redundant备份。

因此,恢复过程包括将数据复制到配对地区,增加恢复时间取决于数据库的大小。

前进,微软Azure表示,将确保所有数据库备份被配置为在所有规模Geo-zone-redundant单位。

最后,即使在数据库恢复,整个规模单位由于并发症仍然无法访问与web服务器。回收在w3wp进程在服务器上引发周期性的热身任务,遇到错误,导致延长预热时间。

这影响了web服务器的健康调查,导致中断客户的流量负载均衡器。为了解决这个问题,微软Azure实现措施逐步开启用户和允许web服务器正确热身。

“末停机窗口,我们封锁了所有交通规模单位资源利用特性允许所有web服务器热身并成功进入负载均衡器,”马丁利说声明。

“这导致用户接收速率限制和使用错误。一旦所有数据库都是健康的,我们逐渐畅通用户增加客户流量正常水平。”

读也:据说微软Azure宇宙DB数据库漏洞暴露3300公司严重的黑客

防止类似事件

微软Azure已经采取措施防止类似事件和改善他们的服务的弹性。他们有固定的bug快照删除工作,创建全面测试,Azure实现资源管理器锁来防止意外删除。

此外,他们确保所有SQL Azure数据库备份配置Geo-zone冗余和隔离快照数据库从生产数据库。

Mattingly向所有的顾客道歉受中断影响,保证他们正在采取措施防止未来出现。

相关文章:现在微软的服务器停机影响Azure, Xbox Live Again-Issues指向DNS,影响其他应用程序