2022 年十大中断

2022 年最严重的网络和服务中断产生了深远的影响。航班停飞，虚拟会议中断，通信受阻。

根据思科拥有的网络情报公司ThousandEyes的分析，导致主要基础设施和服务提供商瘫痪的罪魁祸首也多种多样，该公司是一家跟踪互联网和云流量的网络情报公司。与维护相关的错误不止一次被引用：加拿大运营商罗杰斯通信公司经历了一次大规模的全国性中断，这可以追溯到维护更新，维护脚本错误给软件制造商Atlassian带来了问题。

BGP 配置错误也出现在排名靠前的中断报告中。边界网关协议告诉互联网流量要采用什么路由，但如果路由信息不正确，那么流量可能会被转移到不正确的路由，这发生在Twitter上。（在我们的每周互联网健康检查中阅读有关美国和全球中断的更多信息。

以下是一年中排名前 10 位的中断，按时间顺序排列。

英国航空丢失在线系统：2 月 25 日

2 月 25 日，英国航空公司的在线服务数小时无法访问，导致数百架航班取消并中断航空公司运营。无法预订航班，旅客也无法以电子方式办理登机手续。据报道，当其在线系统无法访问时，该航空公司被迫恢复基于纸张的流程，并且在全球范围内都感受到了影响。“我们的监控显示，航空公司在线服务（和服务器）的网络路径是可以访问的，但服务器和站点响应超时，”ThousandEyes在其中断分析中表示，该分析将故障归咎于无响应的应用程序服务器 - 而不是网络问题 - 中断。

“问题的性质以及航空公司对此的反应表明，根本原因可能是多个前端服务所依赖的中央后端存储库。如果是这种情况，此事件可能会成为英国航空公司重新构建或解构其后端以避免单点故障并降低再次发生的可能性的催化剂。然而，同样可能的是，导致停电的一系列事件很少发生，并且将来可以大部分控制。时间会证明一切，“千眼说。

推特被BGP劫持：3月28日

3月28日，俄罗斯互联网和卫星通信提供商JSC RTComm.RU 不当宣布了Twitter的前缀之一（104.244.42.0/24），导致发往Twitter的流量被重新路由到某些用户并失败后，某些用户无法使用Twitter。在RTComm的BGP公告被撤回后，受影响的用户恢复了对Twitter服务的访问。ThousandEyes指出，BGP错误配置可用于有针对性地阻止流量 - 但是并不总是很容易分辨出情况是意外的还是故意的。

“我们知道，3月28日的推特事件是由RTComm宣布自己是推特前缀的起源，然后撤回它引起的。虽然我们不知道是什么导致了这一宣布，但重要的是要了解BGP的意外配置错误并不少见，并且鉴于ISP撤回了该路由，RTComm很可能无意对Twitter的服务造成全球影响的中断。也就是说，某些地区的ISP已经使用BGP的本地化操纵来根据本地访问策略阻止流量，“ThousandEyes在其中断分析中表示。

组织处理路由泄漏和劫持的一种方法是监视快速检测，并使用资源公钥基础结构 （RPKI）（用于执行路由源授权的加密安全机制）等安全机制来保护 BGP。RPKI 对 BGP 劫持和泄漏有效，但采用并不广泛。“虽然您的公司可能实施了RPKI来抵御BGP威胁，但您的电信公司可能不会。选择ISP时需要考虑的事情，“ThousandEyes说。

Atlassian 夸大了中断影响：4 月 5 日

Atlassian 在 4 月 5 日上午报告了其几个最大的开发工具存在的问题，包括 Jira、Confluence 和 OpsGenie。维护脚本错误导致这些服务中断数天，但仅影响了大约 400 名 Atlassian 客户。

ThousandEyes在分析中断时强调了供应商状态页面在报告问题时的重要性：Atlassian的状态页面有“橙色和红色指示器的海洋”，表明发生了严重的中断，该公司表示将动员数百名工程师来纠正事件，但对于大多数客户来说，没有问题。

状态页面通常低估了中断的程度，但状态页面也可能夸大其影响，ThousandEyes警告说：“这是一个非常困难的平衡：说得太少或太晚，客户会对响应能力感到不安;说得太多，过于透明，冒着不必要地担心大量未受影响的客户以及更广泛的利益相关者的风险。

罗杰斯停电削减了加拿大各地的服务：7月8日

拙劣的维护更新导致加拿大运营商罗杰斯通信公司的网络在全国范围内长期中断。停电影响了约1200万客户的电话和互联网服务，并阻碍了全国的许多关键服务，包括银行交易，政府服务和应急响应能力。

根据ThousandEyes的说法，由于内部路由问题，罗杰斯撤回了其前缀，这使得一级提供商在近24小时内无法通过互联网联系。“这一事件似乎是由大量罗杰斯前缀的撤回引发的，这使得他们的网络无法通过全球互联网访问。然而，在这段时间内在其网络中观察到的行为表明，外部BGP路由的退出可能是由内部路由问题引起的，“ThousandEyes在其中断分析中表示。

罗杰斯停电是一个重要的提醒，提醒人们关键服务需要冗余;ThousandEyes建议，拥有多个网络提供商，为发生中断制定备份计划，并确保具有主动可见性。“任何提供商都无法幸免于中断，无论停电有多大。因此，对于医院和银行等关键服务，计划一个可以减轻中断长度和范围的备份网络提供商，“ThousandEyes写道。

AWS 美国东部区域停电：7 月 8 日

7 月 28 日的电源故障中断了美国东部 2 区域中亚马逊云科技 （AWS） 可用区 1 （AZ1） 内的服务。“中断影响了与该地区的连接，并导致亚马逊的EC2实例瘫痪，这影响了Webex，Okta，Splunk，BambooHR等应用程序，”ThousandEyes在其中断分析中报道。并非所有用户或服务都受到同等影响;例如，位于思科数据中心的 Webex 组件仍可正常运行。AWS报告称，停电仅持续了大约20分钟，但其某些客户的服务和应用程序需要长达三个小时才能恢复。

为云交付的应用程序和服务设计一定程度的物理冗余非常重要，ThousandEyes写道：“数据中心停电没有软着陆 - 当电源停止时，依赖的系统会很难。无论是电网中断还是相关系统（如UPS电池）的故障，在这样的时代，数字服务的架构弹性和冗余至关重要。

谷歌搜索，谷歌地图淘汰：8月9日

短暂的中断影响了谷歌搜索和谷歌地图，这些广泛使用的谷歌服务在大约一个小时内无法提供给世界各地的用户。“尝试访问这些服务会导致来自Google边缘服务器的错误消息，包括HTTP 500和502服务器响应，这些响应通常表明内部服务器或应用程序问题，”ThousandEyes报道。

据报道，根本原因是软件更新出错。不仅最终用户无法访问谷歌搜索和谷歌地图，而且依赖谷歌软件功能的应用程序在中断期间也停止工作。

出于几个原因，IT专业人员对中断感兴趣，ThousandEyes指出。“首先，它强调了这样一个事实，即即使是最稳定的服务，例如Google Search，我们很少遇到问题或听说中断的服务，仍然受到可能破坏任何复杂数字系统的相同力量的影响。其次，该活动揭示了一些软件系统是多么普遍，通过我们每天消费的许多数字服务交织在一起，却没有意识到这些软件依赖关系。

缩放中断破坏虚拟会议：9 月 15 日

在 9 月 15 日的中断期间，用户无法登录或加入 Zoom 会议大约一个小时，这给全球用户带来了错误的网关 （502） 错误。用户无法登录或加入会议，在某些情况下，已经在会议中的用户被踢出会议。

根本原因尚未得到证实，“但它似乎在Zoom的后端系统中，围绕他们解决，路由或重新分配流量的能力，”ThousandEyes在其中断分析中表示。

Zscaler 代理遭受 100% 数据包丢失：10 月 25 日

10 月 25 日，发往 Zscaler 代理端点子集的流量经历了 100% 的数据包丢失，影响了在其 Zscaler 云网络 2 上使用 Zscaler 互联网接入 （ZIA） 服务的客户。根据ThousandEyes的中断分析，最严重的数据包丢失持续了大约30分钟，尽管在接下来的三个小时内，某些用户位置的一些可访问性问题和数据包丢失峰值间歇性地持续存在。

Zscaler在其状态页面上将该问题称为“流量转发问题”。当无法访问代理设备的虚拟 IP 时，会导致无法转发流量。

ThousandEyes解释了这种情况如何使使用Zscaler安全服务的某些客户无法访问关键业务工具和SaaS应用程序：“这可能影响了使用Zscaler服务的企业客户的各种应用程序，因为它在安全服务边缘（SSE）实施中很典型，不仅代理Web流量，还代理其他关键业务工具和SaaS服务，如Salesforce。 ServiceNow和Microsoft Office 365。因此，代理位于用户的数据路径中，当无法访问代理时，对这些工具的访问会受到影响，修复通常需要手动干预才能将受影响的用户路由到备用网关。

WhatsApp中断消息传递：10月25日

10月25日的两小时中断导致WhatsApp用户无法在平台上发送或接收消息。元维基拥有的免费软件是世界上最受欢迎的消息传递应用程序——根据数字智能平台 Similarweb 的 2022 年数据，全球 31% 的人口使用 WhatsApp。

根据ThousandEyes的中断分析，中断与后端应用程序服务故障有关，而不是网络故障。它发生在印度的高峰时段，该应用程序拥有数亿用户群。

AWS 美国东部区域再次命中：12 月 5 日

亚马逊网络服务 （AWS） 在 12 月初在其美国东部 2 区域遭受了第二次中断。据 AWS 称，中断持续了大约 75 分钟，导致往返美国东部 2 区域的互联网连接问题。

ThousandEyes 观察到两个全球位置和 AWS 的 US-East-2 区域之间的数据包丢失了一个多小时。该事件影响了通过 ISP 连接到 AWS 服务的最终用户。“这种损失仅在通过ISP连接的最终用户之间出现，并且似乎不会影响区域内或区域之间的实例之间的连接，”ThousandEyes在其中断分析中表示。

当天晚些时候，AWS发布了一篇博客，称问题已解决。“区域内实例之间、区域之间的连接以及直接连接不受此问题的影响。问题已经解决，连接已经完全恢复，“该帖子说。