这期“互联网报告”播客将通过 ThousandEyes 互联网和云智能的视角，深入分析近期的互联网中断事件和趋势。本播客隔周更新一次，旨在分享最新的互联网中断统计数据，并着重介绍一些值得关注的互联网中断事件。与往常一样，您可以阅读下方的完整分析报告，也可以收听播客获取第一手评论。
互联网中断及趋势
在互联网中断分析中，我们经常观察到多方同时遇到问题。有时，同一个共享依赖项（如网络互联点、云服务提供商或开源库）会在多条服务交付链中引发单点故障。也有些时候，多个问题似乎存在着某个共同的特征，但实际上这些问题并非直接相关，只是恰好同时发生而已。这种巧合可能会导致责任归属判定错误，以致即使想方设法缓解和解决问题，也收效甚微。
上周，我们就遇到了两起这样的事件。这两起事件看似存在共同点，但实际上并无关联。
第一起事件是，Microsoft Azure 在美国某个地区出现问题，导致一些公司在美国部分地区使用依赖于 Azure Storage 的 Azure 服务时遇到了问题。
第二起事件是，网络安全技术公司 CrowdStrike 进行了一次常规性的内容配置更新，导致一系列全球性大规模 IT 中断，使得航空公司和机场、银行、运输运营商、餐厅、超市等多个行业的大量 Windows 计算机发生蓝屏死机（BSOD，Blue Screen of Death）。
由于 Azure 事件和 CrowdStrike 事件差不多同时发生，并且都涉及到 Microsoft 产品，因此一些人最初认为这两起中断事件是相关的；然而，事实证明这两起事件彼此独立，并无关联。
继续阅读，详细了解这些事件，也可通过下方链接跳转至您感兴趣的部分：
CrowdStrike 传感器更新事件
在澳大利亚和新西兰当地时间 7 月 19 日（星期五）下午，许多组织开始遇到问题。很多行业的知名企业同时声称发生中断事件，其 Windows 计算机出现卡顿，这一影响迅速蔓延到其他地理区域，造成了航空公司预订系统、零售超市以及医院服务等多个行业出现运营中断。而这仅仅只是冰山一角。
有一段视频展示了美国航班活动的延误情况，没有什么比该视频更能说明这次事件的影响。美国联邦航空管理局 (FAA) 根据 FAA | X多家航空公司的请求发布地面停飞指令，这段视频记录了当时的状况。
在这次大规模中断事件中，最初责任被认定在于微软，因为受影响的系统和设备都涉及微软产品，而且当天早些时候，微软在美国中部地区的服务经历了一次中断。此次中断影响了使用 Windows 客户端或 Windows 服务器的系统和服务，包括可能在 Windows 系统上运行的服务，如 Active Directory (AD)。
然而，随着 IT 管理员的分析逐渐通过互联网论坛和社交媒体传播，另一个共同因素浮现了出来：CrowdStrike。这是一项用于保护 Windows 终端免受攻击的托管检测和响应 (MDR) 服务。
CrowdStrike 发布了他们的第一份公开声明，帮助澄清了公众最初对于问题原因的困惑。 在这份初步声明之后，CrowdStrike 发布了针对 IT 管理员的操作指南和解决方法，并发布了一份技术事件报告，将事件归因于一个配置文件的问题，称该文件“触发了一个逻辑错误，导致系统崩溃和蓝屏 (BSOD)”。
CrowdStrike 事件之所以引人注目，有几个原因：
-
首先，这个单一共享依赖项引发的大规模互联网中断对全球数字经济产生了潜在影响。该事件被称为“全球最严重的 IT 中断”。虽然可能存在短期记忆效应，但它确实是近年来影响最显著的中断事件之一：2021 年的一次涉及 DDoS 缓解服务的事件也让人记忆犹新，同样类似的还有 2010 年的一次事件，那次事件导致了启动循环和电脑无法启动。
-
其次，恢复工作并非易事，需要 IT 工作人员亲临现场操作才能使机器恢复正常运行。微软一度报告称每台机器可能需要重启多达 15 次。
值得信赖的可视性至关重要
在大规模互联网中断期间，第一个问题通常不是“是否发生了中断？”，而是“是什么导致了这个问题？”，紧随其后的问题是“谁来负责解决这个问题？”。回答这些问题的速度取决于可用信息的数量、完整性和准确性。长期在缺乏完整信息的情况下运营，可能会导致基于某种表象（如“服务无法访问”）而对故障根源做出想当然的判断。
考虑到受到影响的服务范围以及在终端、服务器和应用中出现的各种故障情况（其中只有一部分是 IT 部门可能有权限访问和了解的），网络被怀疑是造成服务中断的“罪魁祸首”并不令人惊讶。互联网连接问题是导致许多不同应用和服务同时出现中断的常见因素。
ThousandEyes 观察到 CrowdStrike 事件以如下两种方式造成了显著影响：
- 流量丢失：前端应用以及托管在 Microsoft Windows 服务器上的服务流量发生丢失。由于服务器无法正常工作，因此它们不能正常地接收和响应传入的流量，导致流量丢失（见下图 2）。
- 服务器超时以及应用和服务的 HTTP 500 错误，并且托管在 CDN 上的服务或者其他基础设施无法访问在微软 Windows 上运行的后端服务器（见下图 3）。
根据这些信息，IT 用户可以结合 ThousandEyes 的数据及视图来缩小故障域并识别问题的根源。这一过程通常从网络开始，因为网络是最大的域，因此流量会在网络中耗费最多的时间。因此，网络不仅是排查故障的最佳起点，而且一旦确定网络没有问题，就能排除大量潜在根源。
在本例中，网络没有显示出重大问题或性能下降，跨越了多个地区和托管位置，表明网络本身并不是问题。然而，之前观察到的两种情况都与服务器问题高度相关，例如服务器无响应或服务器上的应用代码停止正常运行。
这一事件突显出数字体验涉及人们意想不到的诸多因素。只要一个组件，甚至仅仅是一个功能失效或性能下降，就足以使整个服务交付链停止运作。当发生中断时，重要的是高效地确定问题的来源，而这一过程中的关键步骤是排除误判。保障数字体验不仅仅涉及网络，还需要考虑从设备到应用的所有因素。
进一步加剧混乱的是，Microsoft 在一个美国 Azure 区域也经历了中断问题，而巧合的是，该区域也托管了一些客户的 Windows 服务器。这种巧合进一步增加了事件的复杂性，使得确定问题的根源变得更加困难。
Azure 中断
在 CrowdStrike 事件产生明显影响之前的几小时，微软经历了一次其他原因导致的中断，这次中断影响了用户访问被配置为采用美国中部区域单个区域服务的各种 Azure 服务和客户账户。该中断事件发生在 2024 年 7 月 18 日晚上 9:56 (UTC) 到 7 月 19 日中午 12:15 (UTC) 之间。两起事件的时间非常接近，这可能引起了一些混淆，并导致更大规模的全球 IT 中断被错误地归咎为微软的问题。尽管微软系统在 CrowdStrike 事件期间受到了影响，但这与 Azure 中断完全无关。
根据状态更新，一些客户遇到了多个 Azure 服务的问题，包括服务管理操作失败和服务的连接性或可用性问题。到达美国中部区域的网络路径似乎受到了影响，在受影响区域的入口点观察到了转发丢包。此问题主要影响采用在美国中部区域运行的资源的客户，配置为依赖美国中部区域的单区域可用性的用户遇到了可用性问题，而配置为采用多个读取区域但仅采用美国中部这一个写入区域的用户可能遇到了网络性能下降。受影响的用户包括 Confluent、Elastic Cloud 和 Microsoft 365。
微软的状态更新还确认了一项配置更改是影响后端服务连接性的根本原因，特别是对于存储集群和计算集群。然后，这引发了一些自修复服务反复重启。
由于存储集群影响了部分的 Azure SQL 数据库访问，微软启动了修复流程，包括为客户数据库提供跨地区容灾，协助实施故障恢复。
在这种数字体验受到影响的情况下，必须了解相关因素并排除误判，可以避免浪费时间和资源。在这个场景下，需要了解哪些服务和功能受到了影响，其所获得的服务来自何处，哪些地区正在受到影响，这些信息会为缓解故障或实施后续优化起到至关重要的作用。
Workday 中断
7 月 6 日，ThousandEyes 观察到 Workday 上的 HTTP 连接失败次数增加，而且重定向和页面加载时间延长，这种状况持续了大约三小时。根据 ThousandEyes 的观察，问题似乎与初始身份验证程序有关，而不在于实际的身份验证尝试。ThousandEyes 对页面加载和端到端事务流程的分析显示，系统识别到了问题，并使用了一个临时重定向（以 HTTP 状态代码 302 表示），将用户指向一个静态维护页面，这证实了 Workday 内部存在后端服务问题。
不仅重定向时间延长，而且 SSL 性能也有所下降，这通常是身份验证程序出现问题的迹象。吞吐量很可能也下降了，导致响应时间看似改善，但实际上整个页面并未完全加载。关键是，虽然这些信号在孤立的情况下可能有不同的解读方式，但将它们结合起来，就能够更精确地了解事件的来龙去脉。
Grammarly 事件
Grammarly 在 7 月 13 日、15 日和 18 日经历了几次事件。其中后两个事件被描述为“服务中断”，表现为登录问题和功能问题，例如“无法查看建议或修正”。
在中断期间，ThousandEyes 观察到页面加载时间有所延长。这帮助证实了网络的完整性，表明与应用的连接很可能并不是对数字体验产生负面影响的罪魁祸首。这一点进一步得到了确认，因为在来自不同地理位置的路径上没有出现明显的丢包或延迟增加。页面加载时间延长，加上响应缓慢，充分表明了一些后端服务没有响应。这缩小了故障范围，使得客户能够针对应采取的流程、工作流或措施做出更明智的决策。
7 月 13 日的事件直接将问题根源指向 Azure。Azure 报告称，Azure OpenAI (AOAI) 服务有一个自动化系统，该系统在地区级别实施，但使用全局配置来管理某些后端资源的生命周期。为了更新此配置以删除 AOAI 内部订用中未使用的资源，Azure 进行了一项变更。这个订用具有一定的存储账户数量配额，但未使用，按原计划将被清理以避免存储配额压力。
然而，这个资源组还包含了其他资源，比如用于部署、管理和使用 OpenAI 模型的后端托管实例资源终端。此外，该资源组以及这些关键的后端资源没有正确进行标记以防止自动化系统执行指定的清理操作。当该自动化系统开始运行时，这些关键的后端资源被无意中删除，导致 AOAI 在线终端下线并且无法处理客户请求。
数说互联网中断
最后来看一下 ThousandEyes 在过去两周（7 月 8 日至 7 月 21 日）在全球范围内观察到的一些趋势，其中涉及互联网服务提供商 (ISP)、云服务提供商网络、协作应用网络和边缘网络：
-
与之前的下降趋势相反，这段时间内互联网中断数量出现了逆转，整体呈上升趋势。从 7 月 8 日到 7 月 14 日，互联网中断事件数量相比前一周增加了 21%，从 151 起增加到了 183 起。这种上升趋势接下来持续了一周，从 7 月 15 日到 7 月 21 日，互联网中断数量略有增加，从 183 起增加到 187 起，相比前一周增长了 2%。
-
美国同样呈现出上升趋势，但增幅明显大于全球观察数据。从 7 月 8 日到 7 月 14 日，互联网中断数量增加了 52%，随后从 7 月 15 日到 7 月 21 日又进一步增加了 12%。在这段时间内全球和美国的互联网中断数量上升在某种程度上与预期相符，并且符合 ThousandEyes 对于每年这个时段的典型观察结果。
-
由于美国发生的互联网中断数量显著增加，以美国为中心的互联网中断占所有观察到的全球互联网中断的 40% 以上。在 7 月 8 日至 7 月 21 日的两周时间里，48% 的互联网中断发生在美国，相比之下，在之前的两周（6 月 24 日至 7 月 7 日）这一比例为 34%。
