因拼写错误,17个数据库被删除,微软罢工十小时

发表于:2023-6-06 08:52

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:小王斯基    来源:FreeBuf

#
微软
分享:
  The register 网站披露,巴西南部地区部署的 Microsoft Azure DevOps 服务”罢工“了约十个小时。随后,微软首席软件工程经理 Eric Mattingly 为本次中断事件公开道歉,并透露中断原因是一个简单拼写错误致使 17 个生产数据库被删除。
  Mattingly 表示 Azure DevOps  工程师会定期对生产数据库进行快照(Snapshot)处理,以便及时调查报告上来的问题或测试性能是否改进,这些举动都依赖一个每天运行的后台系统,该系统会在特定时间删除旧的快照。
  在 Azure DevOps 工程师近期进行的一次代码升级中,用支持的 Azure.ResourceManager.*NuGet 包取代了弃用的 Microsoft.Azure.Management.*包,此举引起一个大型的拉取请求,其中更换了旧包和新包中的 API 调用。
  然而拉取请求中却出现了拼写错误,误将删除快照数据库的调用改成了删除托管数据库的 Azure SQL Server 的调用,导致后台快照删除作业删除了整个服务器。
  事故原因
  Mattingly 指出 Azure DevOps 有专门的测试来捕捉此类问题,但是错误的代码只在某些特定条件下才得以运行,因此在现有的测试中没有很好的覆盖到。(据推测,这些条件需要存在于一个足够“老”的数据库快照,以便被删除脚本所捕获。)
  Mattingly 进一步指出由于没有任何快照数据库,Sprint 222 的内部部署(第0环)没有发生任何意外,几天后,软件变更被部署到客户环境(第1环)被用于南巴西规模单位(一个特定角色的服务器集群)。该环境中有一个快照数据库,其年龄“老”到足以触发该错误,最终导致后台工作删除了该规模单位的“整个 Azure SQL 服务器和所有 17 个生产数据库”。
  经过十多个小时的努力,微软方面已经全部恢复了数据库,为防止此类问题再次发生,微软已经采取各种修复和重新配置措施。花费如此长时间的原因如下:
  第一:由于客户自己无法恢复 Azure SQL Server, 必须由 Azure 工程师来处理这一问题,这一过程大约需要一个小时:
  第二:数据库具有不同的备份配置,一些数据库被配置为区域冗余备份,另一些数据库被设置为最近的地理区域冗余备份,协调这种不匹配的冗余备份,需要花费几个小时;
  最后一个原因:在数据库开始恢复在线后,由于自身网络服务器存在一系列复杂问题,使用这些数据库的客户也无法立刻访问整个规模单元。
  据悉,这些问题由服务器预热任务引起,该任务通过测试调用在可用数据库列表中反复进行,恢复过程中的数据库出现了一个错误,就会触发预热测试 执行指数回退重试,导致预热平均需要 90 分钟,在正常情况下此操作只需要几秒钟。
  更为复杂的是,整个恢复过程交错进行,一旦有一两台服务器开始接受客户流量,就会出现过载现象,然后停机。因此,恢复服务需要阻断所有到巴西南部规模单位的流量,直到一切都充分准备好后,才重新加入负载平衡器并处理流量。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号