AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

公有云故障案例分析——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:144280
用户头像

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

关注

评论

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

多图|一文详解Nacos参数!

王磊

nacos

战略规划和战略解码BLM+BEM

wood

bem 战略制定 300天创作 BLM

AI赋能安全技术总结与展望| 社区征文

herosunly

人工智能 新春征文 2月月更

一文带你了解 Java 的内存区域

宇宙之一粟

Java 内存 2月月更

突然发现,npm里request依赖包已经弃用,怎么办?

华为云开发者联盟

npm HTTP node,js Request request依赖包

了解一下ProtoBuf

蜜糖的代码注释

protobuf 2月月更

基于CC2530(ZigBee)设计的自动照明系统

DS小龙哥

2月月更 自动照明系统设计

福昕鲲鹏加入,龙蜥社区迎来版式文档技术服务新伙伴

OpenAnolis小助手

Linux 开源 社区 福昕

架构训练营 毕业设计

ren

DDD实战(1):从需求到代码实现生鲜电商系统

深清秋

DDD 软件架构 生鲜电商系统

改革开放启示录(14/100)

hackstoic

创新管理

大数据培训:构建Flink SQL流式计算平台

@零度

flink sql 大数据开发

java培训:JVM 内存布局

@零度

JVM JAVA开发

学生管理系统的架构设计

Fingal

#架构实战营

阿里无影云桌面深度测评

乌龟哥哥

无影云电脑 2月月更

2022年每个开发者必知的云原生趋势 | 社区征文

Geek_rze78a

容器 微服务 云原生 新春征文

敏捷研发项目,我们该如何度量?

阿里云云效

阿里云 项目管理 云原生 度量 敏捷研发

Linux系统问题排查

AiDaddy

Linux 负载 系统问题

怎么说服领导,能让我用DDD架构肝项目?

小傅哥

DDD 小傅哥 技术架构 架构实践

外屏和宽屏浪费了?HarmonyOS折叠屏设计规范教你用起来

HarmonyOS开发者

HarmonyOS

DOM 精通了?请问 Node 和 Element 有何区别?

编程三昧

JavaScript 前端 DOM 2月月更

大画 Spark :: 网络(4)-Endpoint注册使用与网络环境的构建

dclar

大数据 spark 源代码 框架原理

深入理解持续测试:DevOps 流程中的重要一环

飞算JavaAI开发助手

注册中心

邱学喆

Eureka 注册中心 原理图

KubeVela v1.2 发布:你要的图形化操作控制台 VelaUX 终于来了!

阿里巴巴云原生

阿里云 开源 云原生 KubeVela

前端培训:Vue3语法糖详解分享

@零度

Vue 前端开发

移动应用中的第三方SDK隐私合规检测,早知道

华为云开发者联盟

移动应用 安全 sdk 隐私 隐私合规

51WORLD赋能数字孪生流域/工程建设,助力智慧水利创新发展

Meta 小元

可视化 数字孪生 智慧水利 元宇宙

“元认知”相关学习总结

panda

思维模型 阅读笔记 元认知

技术盘点:容器技术的演进路线是什么?未来有哪些想象空间?

阿里巴巴云原生

阿里云 容器 云原生

vivo 服务端监控架构设计与实践

vivo互联网技术

服务端 系统监控 构架

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