HubSpot 2025年10月20日事件报告

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

发生了什么

美国东部时间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使用Amazon SQS作为其底层消息队列来可靠地处理这些任务。这种架构使HubSpot面向用户的功能保持响应，同时在后台处理耗时的操作。在AWS中断期间，TQ2经历了显著的处理能力下降，其影响远超出最初的云服务提供商故障本身：

当AWS SQS变得不可用时，TQ2的故障转移机制自动将任务重定向到Kafka（一个备用消息队列系统），成功捕获了传入的任务。
然而，负责在恢复后将任务重新发送到SQS的故障转移消费者遇到了消息大小验证中的一个关键错误，导致某些任务无法被重新处理。
故障转移消费者中的处理限制意味着清除累积的任务积压所需的时间比最初的AWS中断时间要长得多，从而延长了恢复窗口。
这意味着在AWS服务恢复后数小时内，后台作业处理能力仍然处于下降状态。

3. 供应商服务中断

我们的通话提供商的控制平面经历了显著的服务能力下降，因为它位于同一AWS区域。
我们的分析数据库提供商也经历了类似的区域故障，导致数据仓库操作无法进行。
云存储和CDN服务受损，影响了文件的上传和下载。

客户影响

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

通话功能受到影响，呼出和呼入的通话失败率升高。
报告和分析服务（包括自定义报告生成器、旅程分析、数据工作室和列表评估）经历了显著的服务能力下降，许多客户遇到错误信息。
电子邮件发送在多段时间内严重受阻，计划中的电子邮件在服务恢复后才最终发送。
报价单操作出现失败和错误率升高。
数据操作也受到影响，导出作业无法完成，由于文件下载问题，导入处理也经历了显著的服务能力下降。

事件时间线

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

我们的事件响应

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

基础设施稳定：我们的工程师立即禁用了自动扩展和部署系统，以防止AWS API故障造成额外的服务中断。这种手动干预在AWS服务能力下降期间维持了我们现有基础设施的稳定性。
工作负载管理：我们进行了手动干预，使关键应用程序能够在不调用失败的AWS API的情况下继续运行，使部分服务在中断期间保持部分功能。
任务队列故障转移：我们的TQ2系统的自动故障转移机制成功地将数百万个后台任务重定向到我们的Kafka备份系统，在SQS中断期间保留了任务数据，并在AWS服务恢复后实现了恢复。

我们的改进措施

增强事件响应流程：我们正在记录并自动化在此次事件中手动执行的防御性流程。这包括自动化部署冻结、基础设施扩展控制和恢复流程。这些操作手册将确保任何工程师都能在几分钟内执行关键的防御措施，而无需特定专业知识。
供应商多样化：我们正在探索整个技术栈的供应商多样化策略，以减少对任何单一提供商的依赖。这包括评估替代供应商，并构建在供应商经历区域故障时能够实现自动故障转移的抽象层。
高级监控和预警系统：我们正在改进对关键云服务提供商API和依赖项的监控，以便在它们影响生产工作负载之前检测到故障，并尽早发现服务能力下降模式。
改进任务队列恢复：TQ2故障转移消费者正在从同步处理转换为异步处理，以显著提高吞吐量。我们还将把故障转移主题迁移到容量大幅增加的专用基础设施上，以便在恢复场景中实现大规模并行处理。
扩展混沌工程：我们正在扩展现有的混沌工程项目，以纳入更全面的AWS服务故障场景。这些演练将验证我们的操作手册，培训我们的团队，并在问题影响客户之前识别薄弱环节。
改进客户沟通：我们正在改进错误信息，使其在发生服务问题时更加及时和信息丰富。此外，我们正在实施当关键依赖项失败时自动激活的应用内横幅，确保客户对重大服务中断有清晰的可见性。

我们对可靠性的承诺

虽然如此大规模的云服务提供商中断很罕见，但我们认识到我们的客户依赖HubSpot进行关键的业务运营。此次事件催生了一项涵盖基础设施、架构和运营改进的全面可靠性倡议。我们正在投资构建反脆弱系统——这些系统不仅能承受故障，还能从压力测试中改进。通过供应商多样化、架构演进和严格的故障测试，我们致力于确保未来的云服务提供商事件对您的业务运营影响最小。感谢您的耐心以及对HubSpot的持续信任。我们致力于通过不断提高我们平台的可靠性和韧性来维护这种信任。