阿里云-云小站(无限量代金券发放中)
【腾讯云】云服务器、云数据库、COS、CDN、短信等热卖云产品特惠抢购

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

160次阅读
没有评论

共计 2561 个字符,预计需要花费 7 分钟才能阅读完成。

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

首先来回顾一下 10 天前的 aws 事故。

AWS 事故简介

此次事件始于 10 月 19 日 PDT23:48,结束于 10 月 20 日 PDT14:20。在此过程中,客户应用的影响大致可分为三个不同阶段:

首先,10 月 19 日 23:48 至 10 月 20 日 02:40,Amazon DynamoDB 在美国东部(弗吉尼亚北部,us-east-1)区域的 API 错误率显著升高。

其次,10 月 20 日 05:30 至 14:09,网络负载均衡器(Network Load Balancer,NLB)在该区域出现部分负载均衡实例连接错误率上升的情况(源于 NLB 集群的健康检查失败)。

第三,10 月 20 日 02:25 至 10:36,新的 EC2 实例启动均告失败;尽管从 10:37 开始实例启动逐步恢复成功,但部分新启动实例出现了网络连接问题,直到 13:50 才完全解决。

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

事故原因:此次事件是由该服务的自动域名系统 (DNS) 管理系统中一个潜在缺陷引发的,该缺陷导致 DynamoDB 的终端节点解析失败。

官方事故报告:https://aws.amazon.com/cn/message/101925/

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

AWS 事故影响

这场持续 15 小时的故障,在全球数字经济中掀起了一场 ” 赛博地震 ”。Catchpoint CEO 受 CNN 采访时表示:这次故障的预估经济损失达 ” 数十亿甚至数千亿美元 ”。

金融服务业

Robinhood 在美东交易时段完全离线,数百万散户投资者被锁在账户之外;

Coinbase 的宕机让加密货币交易者在市场波动中束手无策;

Venmo 收到 8000 份故障报告,用户的数字钱包瞬间 ” 消失 ”。在现代无现金社会,这相当于所有人同时失去了钱包。

游戏行业

Roblox 7000 万日活用户被迫下线,虚拟经济瞬间停摆;

Epic Games 的 Fortnite、任天堂的 Pokémon GO、育碧的彩虹六号集体失声。

对这些依赖用户粘性的平台而言,每小时的宕机都可能意味着永久的用户流失。

政府

英国的政府网站,税务,海关,银行系统受到影响,多家航空公司内部系统受损导致部分航班运营混乱。

更讽刺的是,Amazon 自家产品全线翻车 —— 购物网站、Alexa、Ring 门铃、Prime Video,甚至 AWS 自己的工单系统都未能幸免。这充分说明:即使是 AWS 的创造者,也无法避免对 us-east-1 的单点依赖。

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

微软云 Azure 事故

2025 年 10 月 29 日,微软 Azure 在全球范围内发生大规模宕机,持续近 9 小时。受影响的不仅包括微软自家核心服务(Office 365、Xbox Live、Copilot 等),还波及航空、医疗、零售等多个行业。

Downdetector 的统计显示,短时间内全球上千起用户报告,堪称一次“互联网半边天的停摆”。

更具戏剧性的是,这一事故发生在微软发布 2026 财年 Q1 财报的前夕,而财报中 Azure 云业务收入同比增长 40%,形成了鲜明反差。

亚马逊云崩完,微软云崩!当全球第二大云“摔了一跤”:Azure 宕机背后的配置风险与警示

根本原因

根据微软初步调查报告:

  • 触发点 :Azure Front Door(全球内容分发与应用加速服务)中一次 意外的租户配置更改

  • 问题机制:该更改引入了无效 / 不一致的配置状态,导致大量 AFD 节点无法正常加载。

  • 连锁反应:异常节点退出全局池,健康节点流量骤增,进一步放大了宕机范围。

  • 防护缺陷:原本应阻止错误部署的保护机制因软件缺陷失效,未能拦截。

微软随后采取措施:冻结所有新的配置更改、回滚至“上一次已知良好配置”,并逐步恢复流量分配。

事件起因是一次无意的租户配置变更,该变更在 Azure Front Door 内部触发了大范围服务中断,影响了依赖 AFD 进行全球内容分发的微软服务和客户应用。

该变更引入了无效或不一致的配置状态,导致大量 AFD 节点无法正确加载,进而引发下游服务的延迟、超时和连接错误。

随着不健康节点退出全局节点池,流量分布在健康节点间变得不平衡,放大了影响,导致即使部分地区仍健康也出现间歇性可用性问题。

我们立即阻止所有新的配置更改以防止错误状态进一步传播,并开始在全球范围内部署“上一次已知的良好配置”。

恢复过程需要在大量节点上重新加载配置,并逐步重新平衡流量,以避免节点恢复时过载。

这种分阶段恢复是为了在确保系统稳定的前提下恢复规模并避免问题复发。

触发根因追溯到租户配置部署流程中的缺陷。

本应阻止错误部署的防护机制因一个软件缺陷而失效,使该部署绕过了安全验证。

我们已审查并立即加强验证与回滚控制机制,以防止未来出现类似问题。

影响范围

受影响的 Azure 服务清单几乎覆盖其生态半壁江山,包括:

  • PaaS 层:App Service、Azure SQL Database、Databricks

  • 安全与身份:Entra ID、Defender EASM、Sentinel

  • 开发与数据:Container Registry、Media Services、Video Indexer

  • 终端体验:Virtual Desktop、Azure Maps、Healthcare APIs

此外,Alaska Airlines、夏威夷航空等航空公司无法在线办理登机手续,加拿大医疗机构 Santé Québec 报告部分系统停运,甚至开源社区的 Helm 官网也一度无法访问。

行业警示

这不是孤立事件。仅仅不到 10 天前,AWS 因 DNS 自动化管理系统的罕见软件 bug,引发了持续 15 小时的全球性故障。两大云巨头占据全球超 55% 的市场份额,它们的接连 ” 掉链子 ”,让 云服务集中化风险 再次成为焦点。

  1. 集中化风险:少数巨头掌控互联网神经中枢,一次配置错误即可波及全球。

  2. 韧性不足:即便是顶级基础设施,仍存在防护机制失效的可能。

  3. 多云与冗余:企业在追求云的便利与弹性时,是否也该考虑多云部署与自主可控?

星哥观点

AWS 事故的起因:此次事件是由该服务的自动域名系统 (DNS) 管理系统中一个潜在缺陷引发的,该缺陷导致 DynamoDB 的终端节点解析失败。

Azure 事故的起因:无意的租户配置变更?又想到了某位伟人说的:这个世界是个巨大的草台班子。。。

给整个云计算行业敲响了警钟。

云计算的魅力在于规模化与自动化,但这也意味着“一处失误,全球震荡”。对于企业用户而言,不能只依赖 SLA 和厂商承诺,更要在架构层面设计冗余与容灾。对于云厂商而言,如何在快速迭代与稳定性之间找到平衡,将是未来十年的核心挑战。

正文完
星哥玩云-微信公众号
post-qrcode
 0
星锅
版权声明:本站原创文章,由 星锅 于2025-10-30发表,共计2561字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
【腾讯云】推广者专属福利,新客户无门槛领取总价值高达2860元代金券,每种代金券限量500张,先到先得。
阿里云-最新活动爆款每日限量供应
评论(没有评论)
验证码
【腾讯云】云服务器、云数据库、COS、CDN、短信等云产品特惠热卖中