HubSpot 2025年10月20日事件报告

事件概述

2025年10月20日，HubSpot因AWS us-east-1区域严重中断而经历了重大的服务中断，影响了多个产品功能。尽管我们的基础设施保持完好，但云提供商故障的广泛性影响了我们的服务以及我们所依赖的关键第三方供应商。

发生了什么

美国东部时间10月20日凌晨2:48，AWS经历了近年来最严重的服务中断之一，影响了HubSpot主要基础设施所在的us-east-1区域的众多服务。中断始于DynamoDB（数据库服务）故障，并级联影响到IAM（身份和访问管理）、SQS（简单队列服务）和EC2（计算实例）。

技术影响详情

1. 基础设施层故障

计算实例创建：无法配置新的计算实例，阻止了我们的基础设施自动扩展以处理负载 凭证轮换：定期刷新的系统凭证开始失败，导致整个基础设施出现身份验证错误 网络和存储连接：网络接口和存储卷无法连接到实例，阻止应用程序正常启动 IP地址耗尽：在恢复期间，我们的基础设施耗尽了主要范围内的可用私有IP地址。我们部署了预先准备的备份IP范围，但AWS基础设施传播这些更改的时间比预期长，暂时影响了应用程序连接性

2. 任务队列系统（TQ2）级联故障

TQ2（任务队列2）是HubSpot的核心分布式任务处理系统，处理我们平台上的异步后台工作。每天处理数百万个任务，TQ2管理从计划电子邮件和工作流执行到报告生成、数据导入/导出和列表处理的所有内容。

当服务需要在后台或将来某个时间执行工作时，它们将任务排入TQ2，TQ2使用Amazon SQS作为其底层消息队列可靠地处理这些任务。这种架构在后台处理耗时操作的同时，保持了HubSpot面向用户功能的响应性。

在AWS中断期间，TQ2经历了显著的处理性能下降，远远超出了最初的云提供商中断：

• 当AWS SQS变得不可用时，TQ2的故障转移机制自动将任务重定向到Kafka（备份消息队列系统），成功捕获了传入任务
• 但是，负责在恢复后将任务重放回SQS的故障转移消费者遇到了消息大小验证中的关键错误，阻止了某些任务被重新处理
• 故障转移消费者中的处理约束意味着清除累积的积压任务所需的时间显著长于最初的AWS中断，延长了恢复窗口
• 这意味着在AWS服务恢复后数小时内，后台作业处理仍然处于降级状态

3. 供应商服务中断

• 我们的呼叫提供商的控制平面经历了显著降级，因为它共享相同的AWS区域
• 我们的分析数据库提供商经历了类似的区域故障，使数据仓库操作无法进行
• 云存储和CDN服务受损，影响了文件上传和下载

客户影响

在此事件期间，客户在多个产品领域经历了性能下降：

• 呼叫功能受到影响，出站和入站呼叫的失败率升高
• 报告和分析服务（包括自定义报告生成器、旅程分析、Data Studio和列表评估）经历了显著降级，许多客户遇到错误消息
• 电子邮件发送在多个时间段严重降级，计划电子邮件在服务恢复后最终送达
• 报价操作经历故障和错误率升高
• 数据操作也受到影响，导出作业无法完成，导入处理因文件下载问题而经历显著降级

事件时间线

• 2:48 AM ET：AWS DynamoDB中断开始，触发IAM和SQS中的级联故障
• 3:00 AM ET：TQ2任务处理经历严重降级；Kafka故障转移激活
• 8:35 AM ET：我们的工程师禁用自动扩展系统以在AWS中断期间保持稳定性
• 9:07 AM ET：执行手动干预以允许应用程序继续运行而不需要AWS API调用
• 12:43 PM ET：检测到IP地址耗尽；启动紧急备份范围部署
• 3:50 PM ET：AWS宣布服务恢复
• 9:11 PM ET：TQ2积压清除完成

我们在事件期间的响应

当AWS服务受损时，我们的工程团队采取了多项防御措施来保护服务稳定性并最小化客户影响：

基础设施稳定：我们的工程师立即禁用自动扩展和部署系统，防止AWS API故障导致额外的服务中断。这种手动干预在AWS服务降级期间保持了现有基础设施的稳定性。

工作负载管理：我们执行手动干预，允许关键应用程序继续运行而不需要调用失败的AWS API，使某些服务在中断期间保持部分功能。

任务队列故障转移：我们的TQ2系统的自动故障转移机制成功将数百万个后台任务重定向到我们的Kafka备份系统，在SQS中断期间保留任务数据，并在AWS服务恢复后实现恢复。

我们正在进行的改进

增强的事件响应程序：我们正在记录和自动化在此事件期间手动执行的防御程序。这包括自动部署冻结、基础设施扩展控制和恢复程序。这些运行手册将确保任何工程师都能在几分钟内执行关键防御措施，而不需要特定专业知识。

供应商多样化：我们正在探索整个技术栈的供应商多样化策略，以减少对任何单个提供商的依赖。这包括评估替代提供商和构建抽象层，使在供应商经历区域故障时能够自动故障转移。

高级监控和早期预警系统：我们正在改进围绕关键云提供商API和依赖项的监控，以在它们影响生产工作负载之前检测故障，并及早识别降级模式。

改进的任务队列恢复：TQ2故障转移消费者正在从同步处理转换为异步处理，以显著提高吞吐量。我们还将故障转移主题迁移到具有大幅增加容量的专用基础设施，以在恢复场景中实现大规模并行处理。

扩展的混沌工程：我们正在扩展现有的混沌工程计划，以包括更全面的AWS服务故障场景。这些练习将验证我们的运行手册，培训我们的团队，并在影响客户之前识别弱点。

客户沟通改进：我们正在改进错误消息，在服务问题发生时提供更及时和信息丰富的内容。此外，我们正在实施当关键依赖项失败时激活的自动应用内横幅，确保客户对重大服务中断有清晰的可见性。

我们对可靠性的承诺

虽然这种规模的云提供商中断很少见，但我们认识到我们的客户依赖HubSpot进行关键业务操作。此事件催化了涵盖基础设施、架构和运营改进的全面可靠性计划。

我们正在投资构建抗脆弱系统——不仅能够承受故障，还能从压力测试中改进的系统。通过供应商多样化、架构演进和严格的故障测试，我们正在努力确保未来的云提供商事件对您的业务运营影响最小。

感谢您对HubSpot的耐心和持续信任。我们致力于通过持续改进我们平台的可靠性和弹性来维护这种信任。