2022年最重要的网络和服务中断产生了深远的后果。航班接地，切断了虚拟会议，并阻碍了通讯。
根据Cisco拥有的网络情报公司Monloneyes的分析，造成主要基础架构和服务提供商的罪魁祸首也有所不同。与维护相关的错误不止一次引用：加拿大航空公司罗杰斯通讯经历了全国范围内的大规模停电，可追溯到维护更新，并且维护脚本错误给软件制造商Atlassian带来了问题。
BGP的错误配置也出现在最高的中断报告中。边界网关协议告诉互联网流量要采取什么路线，但是如果路由信息不正确，则可以将流量转移到不当的路线上，而Twitter发生了不当的路线。（在我们的每周互联网健康检查）
这是按时间顺序组织的一年中十大中断。
英国航空丢失在线系统：2月25日
2月25日，英国航空公司的在线服务无法访问数小时，导致数百次飞行取消并中断了航空公司的运营。无法预订航班，旅行者无法以电子方式入住航班。据报道，当该航空公司无法访问其在线系统时，该航空公司被迫返回基于纸张的过程，并且在全球范围内感受到了影响。“我们的监视表明，通往航空公司在线服务（和服务器）的网络路径是可以联系的，但服务器和站点的响应已经计时，”千叶中断分析，这指责断电的无反应应用程序服务器（而不是网络问题）。
“该问题的性质以及航空公司对此的反应表明，根本原因可能与多个面向前端服务所依赖的中央后端存储库有关。如果是这种情况，这一事件可能是英国航空公司重新构造或解构其后端以避免单一失败并减少复发的可能性的催化剂。然而，同样可能的是，导致停电的事件链是罕见发生的事件，将来可以大多受到控制。时间会说明。”千眼说。
Twitter被BGP劫持：3月28日
Twitter was unavailable for some users for about 45 minutes on March 28 after JSC RTComm.RU, a Russian Internet and satellite communications provider, improperly announced one of Twitter’s prefixes (104.244.42.0/24) and, as a result, traffic that was destined for Twitter was rerouted for some users and failed. Access to Twitter’s service was restored for impacted users after RTComm’s BGP announcement was withdrawn. ThousandEyes notes that BGP misconfigurations can be used to block traffic in a targeted way – however it’s not always easy to tell when the situation is accidental versus intentional.
“我们知道3月28日的Twitter活动是由RTCOMM宣布自己为Twitter前缀的来源，然后撤回它引起的。While we don’t know what led to the announcement, it’s important to understand that accidental misconfiguration of BGP is not uncommon, and given the ISP’s withdrawal of the route, it’s likely that RTComm did not intend to cause a globally impacting disruption to Twitter’s service. That said, localized manipulation of BGP has been used by ISPs in certain regions to block traffic based on local access policies,” ThousandEyes said in its中断分析。
组织处理路线泄漏和劫持的一种方法是监视使用安全机制（例如资源公共密钥基础架构（RPKI））的快速检测和保护BGP，这是一种用于执行路由 - 原始授权的加密安全机制。RPKI有效地防止BGP劫持和泄漏，但是采用并不广泛。“尽管您的公司可能已经实施了RPKI来抵御BGP威胁，但您的电信公司可能不会。选择ISP时要考虑的事情。
Atlassian夸大了中断影响：4月5日
Atlassian在4月5日上午报道了其几种最大的开发工具，包括Jira，Confluence和Opsgenie。维护脚本错误导致了这些服务的长时间中断 - 但这仅影响了大致影响400个Atlassian客户。
ThousandEyes in its analysis of the outage emphasized the importance of a vendor’s status page when reporting problems: Atlassian’s status page had “a sea of orange and red indicators” suggesting a significant outage, and the company said it would mobilize hundreds of engineers to rectify the incident, but for most customers, there were no problems.
A status page often under-emphasizes the extent of an outage, but it’s also possible for a status page to overstate the impact, ThousandEyes warned: “It’s a really difficult balance to strike: say too little or too late, and customers will be upset at the responsiveness; say too much, be overly transparent, and risk unnecessarily worrying a large number of unaffected customers, as well as stakeholders more broadly.”
罗杰斯在加拿大的停电服务：7月8日
一场易碎的维护更新导致加拿大运营商罗杰斯通信网络的全国范围内停电延长。停电影响了约1200万客户的电话和互联网服务，并阻碍了全国许多关键服务，包括银行交易，政府服务和应急响应能力。
据《千现在》报道，由于内部路由问题，罗杰斯撤回了前缀，这使得I级提供商在互联网上无法到达近24小时。“这一事件似乎是由于撤回了许多罗杰斯的前缀而触发的，从而使他们的网络在全球互联网上无法实现。但是，这段时间大约在其网络中观察到的行为表明，外部BGP路线的撤离可能是由于内部路由问题而引起的。”中断分析。
罗杰斯的停电是重要的提醒，需要对关键服务进行冗余。千鸟认为，有多个网络提供商已经准备就绪或准备就绪，有一个备份计划，并确保具有主动的可见性。“无论多大，任何提供商都无法免疫中断。因此，对于医院和银行业务等关键服务，计划备份网络提供商可以减轻中断的长度和范围。”千眼写道。
电力故障降低美国东部地区：7月8日
7月28日，在Amazon Web服务（AWS）可用性区域1（AZ1）中，电力故障破坏了服务。“停电影响了与该地区的连通性，并降低了亚马逊的EC2实例，该实例影响了Webex，Okta，Splunk，Bamboohr等应用程序，”中断分析。并非所有用户或服务都受到平等影响；例如，位于思科数据中心中的Webex组件仍在运行。2020欧洲杯预赛AWS报告说停电仅持续了大约20分钟，但是其一些客户的服务和应用程序最多需要三个小时才能恢复。
为了设计一定程度的物理冗余，为云传递的应用程序和服务设计一定程度的物理冗余，千落写道：“数据中心停电没有软降落 - 当停止停止时，Reliant Systems很难崩溃。2020欧洲杯预赛无论是电网中断还是一个相关系统的故障，例如UPS电池，在这样的时代，您的数字服务的构建弹性和冗余都是至关重要的。”
Google搜索，Google Maps被淘汰：8月9日
短暂的停电影响了Google搜索和Google地图，这些广泛使用的Google服务在世界各地的用户都无法使用大约一个小时。“尝试达到这些服务的尝试导致来自Google Edge服务器的错误消息，包括通常指示内部服务器或应用程序问题的HTTP 500和502服务器响应。”
据报道，根本原因是软件更新错误。最终用户不仅无法访问Google搜索和Google Maps，而且还取决于Google的软件功能的应用程序在中断期间停止工作。
千眼指出，这对于IT专业人员来说很有趣。“首先，它突出了这样一个事实，即即使是最稳定的服务，例如Google Search，我们很少会遇到问题或中断的服务，仍然受到相同的力量，可以降低任何复杂的数字系统。其次，该事件揭示了如何通过我们每天消费的许多数字服务编织而成的，但却不知道这些软件依赖性。”
缩放中断破坏虚拟会议：9月15日
在9月15日的停电中，用户无法登录或加入缩放会议大约一个小时，这给全球用户带来了坏网关（502）错误。用户无法登录或加入会议，在某些情况下，已经在会议上踢出了会议的用户。
根本原因尚未得到证实，“但它似乎是在Zoom的后端系统中，围绕其解决，路线或重新分配流量的能力，”中断分析。
ZScaler代理遭受100％数据包损失：10月25日
10月25日，交通注定到Zscaler代理端点的一部分，经历了100％的数据包丢失，影响了在其Zscaler Cloud Network 2上使用Zscaler Internet访问（ZIA）服务的客户。最重要的数据包损失持续了大约30分钟，尽管有些损失持续了30分钟，但reachability issues and packet-loss spikes persisted intermittently for some user locations over the next three hours, according to ThousandEyes’中断分析。
ZScaler提到了问题在其状态页面上作为“交通问题”。当代理设备的虚拟IP变得无法到达时，它导致无法转发流量。
ThousandEyes explained how this scenario could have made critical business tools and SaaS apps unreachable for some customers that use Zscaler’s security services: “This may have affected a variety of applications for enterprise customers using Zscaler’s service, as it’s typical in Secure Service Edge (SSE) implementations to proxy not just web traffic but also other critical business tools and SaaS services such as Salesforce, ServiceNow, and Microsoft Office 365. The proxy is therefore in the user’s data path and, when the proxy isn’t reachable, the access to these tools is impacted and remediation often requires manual interventions to route affected users to alternate gateways.”
WhatsApp中断停止消息传递：10月25日
10月25日的两个小时停电使WhatsApp用户无法在平台上发送或接收消息。根据数字情报平台的2022年数据，元拥有的免费软件是世界上最受欢迎的消息传递应用程序 - 31％的全球人口使用WhatsApp。相似的网络。
根据千现在，停电与后端应用程序服务故障有关，而不是网络故障。中断分析。它发生在印度的高峰时段，该应用程序在数亿美元的用户群中。
AWS美国东部地区再次击中：12月5日
亚马逊网络服务（AWS）受苦美国东部2地区的第二次中断在12月初。根据AWS持续了大约75分钟的停电，导致了互联网连接问题与美国2区域。
数千人观察到两个全球位置与AWS的US-2区域之间的数据包损失超过一个小时。该事件影响了通过ISP连接到AWS服务的最终用户。“只有在通过ISP连接的最终用户之间看到损失，并且似乎没有影响该地区内部或区域之间的实例之间的连接，”中断分析。
当天晚些时候AWS发布了一个博客说问题已经解决。“区域内，区域之间和直接连接连接性之间的连接不受此问题的影响。该问题已经解决，连通性已经完全恢复。”