HubSpot 2025年10月20日事件报告

2025年10月20日，HubSpot经历了一次重大的服务中断，多个产品功能受到影响。此次事件的根源是AWS在us-east-1区域发生的严重故障。尽管我们的基础设施本身保持完好，但此次云服务提供商故障的广泛性，影响了我们的服务以及我们所依赖的关键第三方供应商。我们已经完成了对此次事件的全面分析，并正在实施综合性的改进措施，以增强我们应对未来云服务提供商中断的能力。

事件经过

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

技术影响详情

1. 基础设施层故障

• 计算实例创建：无法调配新的计算实例，阻止了我们的基础设施根据负载自动扩展。
• 凭证轮换：定期刷新的系统凭证开始失效，导致我们基础设施中普遍出现身份验证错误。
• 网络和存储连接：网络接口和存储卷无法连接到实例，导致应用程序无法正常启动。
• IP地址耗尽：在恢复期间，我们的基础设施耗尽了主要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的持续信任。我们致力于通过持续提高平台的可靠性和韧性来维护这种信任。