Data+AI时代,如何打造下一代数智平台? 了解详情
写点什么

公有云故障案例分析——Microsoft Azure 的飞来人祸

  • 2015-04-09
  • 本文字数:1856 字

    阅读完需:约 6 分钟

公有云早已飞入寻常百姓家,除了初创的企业,很多大公司也将自己的服务部署在共有云平台上,因此公有云的稳定性和可靠性是十分重要的。平日里谈起公有云,大家总把注意力放在行业老大 Amazon Web Services 上,不太提及 Microsoft Azure,今天就让我们来看一下去年 11 月 Azure 发生的将近 11 个小时的故障。

首先,来回顾一下故障的经过,根据《Update on Azure Storage Service Interruption》这篇官方博客的介绍,这起编号为 3071402 的故障名为“Microsoft Azure Service Incident : Connectivity to multiple Azure Services – Partial Service Interruption”,影响了 19 种 Azure 服务,涉及 12 个 Region,当时似乎只有澳大利亚数据中心幸免于难。

从 11 月 19 日 00:50 发现该问题后的 5 个小时中,多个主要 Region 的存储服务出现问题,大量客户在此之间受到影响;上午 11 点存储故障恢复,大部分客户服务已经恢复,但少数客户的虚拟机由于此前的故障仍存在问题,自动恢复一直持续到 21 日早晨。

讽刺的是多个微软自己的服务也受到了牵连,Windows Store 和 Xbox Live 都受到不同程度的影响。而 Azure 的 Service Health Dashboard 也受故障影响,在故障发生之初尽然显示一切正常,Azure 也真是“醉”了。

一个月后,Azure 团队在其官方博客上就此次故障发表了详细的说明——《Final Root Cause Analysis and Improvement Areas: Nov 18 Azure Storage Service Interruption》,文中剖析了造成故障的原因。本次变更主要是针对 Azure Storage Table Front-Ends 的,目的是减少 CPU 开销,提升存储服务的性能。在测试和预生产环境中,本次变更顺利地通过了健康检查,同时显著提升了系统性能,还解决了几个已知的问题。但是在后续的增量部署中,不幸发生了,Azure Blob Storage Front-Ends 错误地开启了该功能,触发了一个 Bug,导致系统进入死循环无法再提供服务了。几分钟后,监控发现问题,工程师团队在 30 分钟内回滚了 Azure Blob Storage Front-Ends 的变更,对于已经进入死循环的系统进行了重启。

存储系统的故障还影响了虚拟机服务,主要可以将问题归纳为三类,都发生在存储故障和故障恢复阶段:

  1. 磁盘挂载超时(大部分虚拟机重启即可恢复)
  2. 虚拟机配置失败(仅影响 Windows 虚拟机,Linux 虚拟机没有问题)
  3. 虚拟网络编程错误(几小时后工程师团队打了补丁,受影响的虚拟机无需重启即可恢复)

如果说代码的 Bug 未在测试中被发现尚情有可原,那么在换一个灯泡都需要将近50 个工程师参与,流程极为繁琐苛刻的微软,不遵守流程就是不可原谅的了,《Microsoft confirms Azure outage was human error》一文直接就在标题上将其称为“人祸”。

Azure 的部署遵循名为“flighting”的流程,这个流程大致如下:

  1. 在内部测试环境进行部署,随后测试并验证其功能;
  2. 在预生产环境进行部署,在正常的生产级负载下进行测试;
  3. 经过上两步的验证,就能在生产环境中进行小规模部署,一般会部署多个小集群;
  4. 每个小集群都通过验证后就能进行更大规模的增量部署了,通常这种部署在地理上是隔离的。

负责本次性能优化的工程师认为该变更已经在生产环境的小集群上正常运行几个星期了,应该没有问题,在整个 Azure 上开启该功能没有太大风险。而配置工具也没有强制遵循增量部署变更的策略,导致该变更被部署到了整个系统上。

所谓没有规矩不成方圆,有了规矩不能贯彻执行也没用,在小公司或者初创团队,避免繁琐的流程的确能够带来很多便捷,但是在大型团队或者一些核心系统中,流程还是必须的。同时,必须还要有系统能够保证流程得以正确执行,人是会犯错的,人是会走捷径的,就像造成本次故障的那位同学,所以才要系统来进行约束。

Hacker News 上围绕 Azure 团队的故障分析展开了讨论,大家都对 Azure 团队的公开透明表示赞赏(其实在 Azure 的官网有个页面专门记录故障,相比某些公司出了问题遮遮掩掩,这种做法显然更受欢迎),同时不少人也在关心造成这次故障的那位同学的命运,一位读者引用了 IBM 的 Thomas Watson 的话:

最近有人问我会不会开除那个给公司造成 60 万美元损失的员工,我说不会,我刚花了 60 万美元培训了他,为什么要让别人来坐享他的经验?

曾经在支付宝的运维团队也有位朋友这么告诉我——“对运维操作要有敬畏之心”,这句话一直被我记在心中,相信他一定是在背了重大故障之后才会有此感悟。估计 Azure 的那位同学后续一定在操作时会更加仔细,遵循规范。

不知各位读者在了解了 Azure 的这次故障后,是否也能有所收获,当然,如果您在工作中也有过类似的经验教训,不妨也和大家分享一下吧。

2015-04-09 10:144244
用户头像

发布了 135 篇内容, 共 63.9 次阅读, 收获喜欢 43 次。

关注

评论

发布
暂无评论
发现更多内容

Java 面试题之 Logback 打印日志是如何获取当前方法名称的?

越长大越悲伤

Java spring Spring Boot

笔记的妙用:留过往之痕,期未来之变

少油少糖八分饱

方法论 App 工具 笔记 推荐书籍

设计模式-责任链模式

2023-11-11:用go语言,字符串哈希+二分的例题。 给定长为 n 的源串 s,以及长度为 m 的模式串 p, 要求查找源串中有多少子串与模式串匹配, s‘ 与 s 匹配,当且仅当 s‘ 与 s

福大大架构师每日一题

福大大架构师每日一题

es笔记七之聚合操作之桶聚合和矩阵聚合

Hunter熊

elasticsearch 聚合操作 桶聚合 矩阵聚合

MySQL-MDL

开发者眼中的向量数据库应用领域

三掌柜

亚马逊云科技

架构实战营-模块六作业

王朝阳

ZkSync是不可错的Layer 2 四大龙头之一

币离海

以太坊 layer2 zkSync

亚马逊AI应用科技创新下的Amazon SageMaker使用教程

淼.

业务出海之服务器探秘

天黑黑

亚马逊云 出海企业 海外服务器

萌新入手体验亚马逊云科技轻量应用服务器

花花

亚马逊云科技

VPS:搭建自己的私有云

薛定谔的皮皮虾

Nextcloud

MySQL 数据库查询与数据操作:使用 ORDER BY 排序和 DELETE 删除记录

小万哥

Python 程序员 软件 后端 开发

超越服务器:VPS 在开发领域的崭新前景

E₀=mc²

AWS 虚拟化 亚马逊 Amazon Lightsail

ETH2049 单币质押丨组合币质押项目系统开发技术介绍

l8l259l3365

Oracle的to_date()函数解决sql语句日期格式问题

知识浅谈

Java oracle

写在 Chappyz 即将上所之前:基于 AI 技术对 Web3 营销的重新定义

股市老人

业务负债与身体负债

胖胖

持续夯实国云智算底座,天翼云携手伙伴共铸AI繁荣生态

极客天地

公有云故障案例分析——Microsoft Azure的飞来人祸_微软_丁雪丰_InfoQ精选文章