阿里云、滴滴等互联网巨头近期接连发生大规模宕机事件，在国内引发公众热议。不过这类情况在国外并不少见，全球科技巨头和各种规模的供应商在2023年经历了多次云服务中断。本文梳理了2023年规模最大的15起云服务中断事件。

1月微软服务中断

1月17日，北美地区的Microsoft Teams和Microsoft 365用户遭遇服务中断，中断从美国东部标准时间9:17持续到14:18。
服务中断跟踪网站Downdetector显示了大量与Teams相关的问题报告。上午10点左右，累积报告了504个问题；在上午11点前，又报告了503个问题。这些问题中大66%由服务器连接引起，20%由应用程序引起，14%属于登录问题。

1月25日，路透社报道称，网络问题导致美洲、欧洲、亚太、中东和非洲等地Azure、Teams、Outlook和其他服务中断。上午晚些时候，经过全面系统恢复各项务恢复正常。微软将服务中断归咎于微软广域网（WAN）设备之间的网络连接问题。根据Quest Software的Practical 365报告，服务中断事件持续了大约五个小时。问题根源是一条授权WAN路由器发送消息的命令，导致邻接验算和表格转发，阻碍了数据包转发。

1月IT Glue服务中断

太平洋标准时间1月18日上午8点左右，Kaseya旗下云文档软件厂商IT Glue报告称，他们必须进行“紧急数据库维护……以解决一些客户遇到的问题。”

根据事件报告，这家供应商启用了只读模式，直到太平洋标准时间上午9:33才恢复正常。IT Glue在1月20日之前恢复了所有密码和文件。

Reddit用户在1月9日和1月11日发帖报告了IT Glue平台的问题，尽管后者并没有这两天的事件报告。该事件在1月份的多条帖子中引发了超过40条评论。

2月甲骨文、NetSuite服务中断

甲骨文联合创始人兼首席技术官Larry Ellison曾公开表示，旗下甲骨文云基础设施（OCI）“不会崩溃”。但据Network World报道，2月OCI发生了一次持续数日的服务中断。

问题始于美国太平洋标准时间2月13日周一上午大约10:30，并持续到2月15日周三下午大约3:30，主要影响美洲、澳大利亚、亚太、中东、欧洲和亚洲的用户。
事件原因是，支持OCI公共域名系统API接口的后端基础设施出现性能问题，导致无法处理一些传入服务请求。甲骨文使用了实时后端优化和DNS负载管理微调来减轻问题。

根据Network World的报道，中断期间，OCI Vault、API Gateway、Oracle Digital Assistant和使用OpenSearch的OCI Search都出现了问题。
Data Centre Dynamics报道称，甲骨文子公司NetSuite在美国东部标准时间2月14日中午左右发生服务中断，原因是马萨诸塞州沃尔瑟姆的Cyxtera数据中心起火。

据The Register报道，Cyxtera数据中心切断了服务器电源，账户恢复工作大约在美国东部标准时间晚上10:26左右开始。

至少有一位Reddit用户报告称他们的账户因服务中断获得了一些抵扣券。

3月 Datadog服务中断

从3月8日开始，美国云监控和安全工具供应商Datadog持续遭遇服务中断，解决问题花了近两天时间。
       据MarketWatch报道，这家供应商在美国东部夏令时上午1:31通知用户其Web应用出现问题。富国银行分析师甚至发布报告，表示担忧这次中断会影响Datadog收入。

根据该供应商5月季度收益电话会议的一份文字记录，这次事件使Datadog损失约500万美元，需要500到600名工程师三班倒工作才能解决。
       文字记录显示，Datadog联合创始人兼首席执行官Pomel表示他并不“太担心再次发生这样的事情”，Datadog学会了如何“更快地恢复”，以及“更好地帮助我们的客户在发生问题时减轻影响。”
       科技专栏作家Gergely Orosz写道，Datadog“很可能在系统中断期间没有向客户收取数据传输费用”，而“这次损失大约相当于公司一天的收入。”
Orosz说，操作系统更新是中断的一个因素，并称该供应商理应更好地与用户沟通。

4月微软服务中断

4月20日，Microsoft 365在线应用和供应商的Teams协作应用出现问题，持续近6个小时。

微软在太平洋夏令时上午6:56发布推文，表示正在“调查Microsoft 365在线应用和Teams管理中心的访问问题。”

公司在太平洋夏令时下午1:10发布推文称，“经过我们内部遥测和受影响用户的积极确认，服务已恢复。”
Ookla旗下的Downdetector网站当天记录了数千个M365的中断报告，报告数量在太平洋夏令时上午7点左右超过了3000个，在太平洋夏令时上午9点左右达到峰值。

根据The Register的报道，Teams、SharePoint Online和Outlook在4月24日再次出现中断。微软在太平洋夏令时上午4:17和上午7:17分别发布推文，表示“大部分影响”已得到纠正。

Bleeping Computer报道称，4月25日Exchange Online发生另一起中断。微软在太平洋夏令时下午1:21发布了有关问题的推文，大约一个小时后表示问题得到解决。

4月谷歌服务中断

据The New Stack报道，4月25日太平洋夏令时下午5:20左右，法国巴黎一家数据中心发生火灾，导致欧洲地区的谷歌云服务和超过90个云服务受影响。

据IT Pro报道，受影响服务包括谷歌云储存、云密钥管理服务、云身份和访问管理和谷歌Kubernetes引擎。

5月10日，谷歌报告称“位于受影响数据中心部分的一些实例仍然不可用。”

这条新闻在Reddit系统管理员论坛中引发了超过200条评论。

4月甲骨文中心问题

据Federal News Network报道，4月17日，美国退伍军人事务部遭遇甲骨文中心电子健康记录（EHR）系统中断，中断持续五个小时，起因是数据库能力升级和故障转移。

随后，在4月25日，甲骨文中心系统再次遭遇了近四个小时的中断，影响到了美国退伍军人事务部、美国国防部和美国海岸警卫队。

据报道，美国退伍军人事务部决定暂停进一步使用该系统，直到使用该系统的五个部门站点对系统功能性恢复信心为止。

5月思科SD-WAN问题

此次问题属于云服务中断的硬件方面。思科多种vEdge平台的公共根证书过期，导致该供应商在推特公开道歉，并在Reddit论坛的思科板块发布帖子，引发80多条评论。

5月10日，思科在推特发帖表示，“对于造成的问题，我们深感抱歉。” 

思科在网站上发帖表示：“我们发布了软件的升级版本以永久解决这个问题。”

根据思科的说法，vEdge路由器提供了“思科SD-WAN解决方案的广域网、安全和多云能力。思科SD-WAN vEdge路由器以硬件、软件、云或虚拟化组件的形式提供，位于站点的边缘，例如远程办公室、分公司、校园或数据中心。”

6月微软服务中断

微软365服务，如Teams和Outlook，在6月初连续几天经历了广泛的中断，随后几天又发生了重大的OneDrive中断。

次天，数千用户发现微软Azure云平台门户下线。

当月晚些时候，微软确认事件是分布式拒绝服务（DDoS）攻击造成的。

事件细节如下。6月5日上午，上万名微软365用户受中断影响。这家软件巨头表示暂停了某项“更新”计划。

美国东部夏令时上午11:45左右，微软发表推文表示，“我们确定了Microsoft Teams、SharePoint Online和OneDrive for Business的下游影响。”

微软表示，发现有一项“更新存在潜在问题”，该公司已经阻止其在更多服务部分传播，并正在审查已应用该更新的微软基础设施中是否有迅速撤销该更新的选项。

第二天，微软发现服务问题的“再次发生”。美国东部夏令时下午12:03，微软表示“确定了事件影响再次开始”，并正在落实进一步的缓解措施。

微软表示，“遥测数据显示，相对于先前事件，影响已经减少，这要归功于先前采取的缓解措施。” 

美国东部夏令时上午11:22，有3118个Downdetector用户报告了Microsoft 365出现问题。

6月8日，一家名为“匿名苏丹”的黑客组织声称对微软OneDrive中断负责。美国东部夏令时下午3点，微软表示正在“继续分析监控遥测数据并实施负载平衡措施，以缓解事件影响。”

当天稍后的状态页面更新显示，中断仅影响了通过Web浏览器访问OneDrive。微软在更新报告中说，“使用桌面客户端、同步客户端或Office客户端访问OneDrive服务没有受到影响。”

第二天，6月9日，微软用户发现Azure云平台门户经历了一次重大中断。

微软似乎在当天下午解决了问题。美国东部夏令时上午11点后不久，Downdetector上开始出现关于Azure可用性问题的用户报告。在接下来的两个小时内，数千名用户在该网站报告Azure中断。

“匿名苏丹”组织声称对Azure门户进行了DDoS攻击。

6月12日星期一，微软表示“已确定网络流量激增”是造成中断的可能原因。

微软说，“我们发现网络流量的激增，影响了管理到这些站点的流量的能力，并导致用户访问这些站点时出现问题。”

6月AWS问题

根据云巨头AWS在网站发布的一份事件报告，亚马逊网络服务在6月经历了数小时的中断事件。

报告称，“从2023年6月13日太平洋夏令时上午11:49开始，客户在美国东部北弗吉尼亚（US-EAST-1）地区对Lambda函数调用的错误率和延迟增加。由于降级的Lambda函数调用，一些其他AWS服务——包括Amazon STS、AWS管理控制台、Amazon EKS、Amazon Connect和Amazon EventBridge——也出现错误率和延迟增加。Lambda函数调用在平洋夏令时下午1:45开始恢复正常，所有受影响的服务在平洋夏令时下午3:37完全恢复。”

报告称，为了防止再次发生此事件，AWS“立即禁用了触发事件的Lambda前端集群活动的扩展活动，同时我们努力解决导致问题的潜在漏洞；此漏洞已经被解决，解决方案已部署到所有地区。” 

报告称，“此事件还揭示了我们Lambda细胞架构中扩展Lambda前端的一个空白。由于该空白，受影响细胞扩展时，潜在漏洞会产生影响。我们已经对Lambda采取几项行动，解决细胞扩展的直接问题，并计划在今年晚些时候完成更多工作，确保所有细胞大小都得到合理限制，避免未来的意外扩展问题。”

根据Downdetector，在太平洋夏令时中午左右，成千上万用户报告称西雅图AWS中断。佛蒙特州车辆管理部门、《波士顿环球报》和纽约都市交通管理局等组织在推特发帖，表示因AWS遇到服务中断。

7月Slack中断

7月27日，由Salesforce拥有的协作平台Slack经历了持续约一小时的系统范围问题，问题在太平洋夏令时上午3点解决。

Slack公司在一篇在线帖子中表示，中断期间，“用户无法在多个平台上发送或接收消息”。

根据帖子所述，“我们的工程团队在更改管理内部系统通信的服务后发现了一个问题。问题导致了Slack功能下降。变更最终被撤销，为所有用户解决了问题。”
中断引发Reddit用户讨论Slack问题，引发了20多条评论。《纽约时报》和The Verge等媒体报道了这次中断。

7月IT Glue问题

7月发生的IT Glue问题持续了约一小时，导致“502错误网关”，在管理服务提供者（MSP）专注的Reddit论坛帖子中引发了近100条评论。

IT Glue在太平洋夏令时7月18日上午11:54发布帖子称，性能问题“可能会阻止我们的一些合作伙伴访问IT Glue。”该事件在太平洋夏令时12:46解决。

“应该开始发布标题为：ITGlue在线了吗？”一个Reddit用户开玩笑说。

9月微软Teams问题

Microsoft Teams在九月中旬经历了长达两个多小时的问题。

微软在太平洋夏令时9月13日上午7:10发推文说，这家科技巨头正在“调查影响Microsoft Teams的事件。用户可能会遇到消息发送和接收延迟或失败等问题。”

供应商“确定问题仅影响通过受影响基础设施为用户提供服务的某些用户”，并将“受影响的服务流量路由到健康基础设施以减轻影响”。

微软在太平洋夏令时上午9:43发推文说：“我们确认与此问题相关的影响已解决。”

由于这一问题，Reddit上一个系统管理员热议帖子出现了20多条评论。

思科的ThousandEyes网络情报公司发帖表示，“应用程序前端是可访问的，但尝试登录系统和/或与其交互导致500错误和超时。”

根据这篇帖子，这表明“某种后端系统或分发层问题”。

9月Salesforce中断问题

Salesforce发布一份报告称，该供应商于9月20日遭遇服务中断，持续大约两小时，影响了其产品和服务。但MuleSoft和Tableau受到的影响时间长达约四小时。根据公司的审查报告，这次中断是由于一项政策变更而意外引发的，该变更是“我们持续审查和更新安全控制的标准操作流程的一部分”。报告称：“虽然这项变更旨在增强防御深度，但无意中阻止了对其意图范围之外的其他合法和必要资源的访问。最终结果是，访问权限不足导致服务之间通信中断，进而在我们系统内部产生了故障。这导致部分客户无法登录和使用服务。”作为供应商，Salesforce已经修改了其变更审查和批准流程，并修复了Tableau中的启动竞争条件错误，以防止类似问题再次发生。Salesforce还承诺：“启用专门的自动化部署流程，以强制执行分阶段政策部署”，“启用额外的监控和警报功能，以更快地诊断与策略相关的问题”，并“对MuleSoft CloudHub的后端组件进行重新架构……以增强弹性。”

11月Cloudflare、Workday服务中断

Workday和Cloudflare将从11月2日开始的服务中断归因于俄勒冈州的一处设施出现的问题。思科的ThousandEyes推测这两者受到了同一数据中心的影响。Cloudflare首席执行官Matthew Prince在该供应商网站上的一篇文章中表示，对于11月初连续多日的事故感到“抱歉和尴尬”，并将部分责任归咎于俄勒冈州Flexential运营的数据中心。11月2日，Cloudflare面向客户的控制面板界面和分析服务出现中断。该事件持续到11月4日。

Prince表示：“截至协调世界时11月2日17:57，我们已经在灾难恢复设施恢复了大部分控制平面。灾难恢复设施上线后，许多客户不太可能在我们大部分产品中遇到问题。然而，其他服务的恢复时间较长，使用这些服务的客户可能在完全解决事件之前遇到问题。在整个事件期间，我们的原始日志服务对大多数客户不可用。”Prince致歉，表示Cloudflare“相信我们已经建立了高可用性系统，即使我们的核心数据中心提供商发生了灾难性故障，也应该能够阻止这样的中断。”他表示：“尽管许多系统确实按设计保持在线，但一些关键系统存在非明显的依赖关系，导致它们不可用。”
Cloudflare承诺要做出的改变包括：

“消除我们核心数据中心对所有服务控制面板配置的依赖，并在可能的情况下将其转移到我们的分布式网络，优先提供支持。”

“要求所有被指定为普遍可用的产品和功能都具有可靠的、经过测试的灾难恢复计划。”

以及“对所有核心数据中心进行彻底审计，并制定重新审计计划，确保它们符合我们的标准。”

Workday在其关于该事件的报告中表示，这次中断持续了三个小时。报告没有提及Cloudflare或Flexential，但将事件归咎于“我们在俄勒冈州波特兰的数据中心发生了电力中断，导致部分客户服务中断。”

这家供应商表示：“由于备用电源故障以及电力环境不稳定，导致了额外的问题，服务恢复所需的时间比通常情况下要长。”

据KRON4报道，Downdetector曾记录了与Workday中断相关的超过1200起报告。

云中断造成损失越来越大，准备工作愈显重要

考虑到服务中断已经司空见惯，做好准备工作变得尤为重要。云服务巨头AWS在11月的re:Invent大会上宣布提供更多故障注入服务场景，方便客户测试应用程序在极端情况下的表现，比如某个云可用区完全断电或与另一可用区失去连接。

根据Parametrix Insurance今年发布的报告，AWS位于美国东部1区（us-east-1）的关键业务服务如果停机24小时，可能会导致34亿美元的直接收入损失，停机48小时可能会导致78亿美元的损失。该区域是服务《财富》世界500强公司数量最多的AWS区域。

根据报告，东部1区（east-1）和西部2区（west-2）AWS服务停机24小时可能会导致82亿美元的损失，停机48小时可能会导致175亿美元的损失。

Aviatrix预计将于明年1月发布的一份报告，将给担心威胁行为者会造成中断的IT专业人员提供更多数据。报告发现，“在过去一年中，由防火墙导致的云网络中断次数是组织内部遭遇的网络攻击次数的两倍多。”