概要
2025 年 10 月 20 日 06:49 至 23:41 UTC 之间，我们收到了 1,308 份客户报告，涉及多个 Zendesk 产品的使用问题。这些服务中断是由于AWS美国东部地区发生严重中断期间应用程序整合失败造成的。
时间线
UTC 时间 | 2025 年 10 月 20 日上午 07:59 2025 年 10 月 20 日上午 12:59（太平洋标准时间）
我们了解到多项 Zendesk 服务都出现了问题。我们的工程团队正在尽力解决此问题。我们将在 30 分钟后提供更新。感谢您的耐心等待。
UTC 时间 | 2025 年 10 月 20 日上午 08:32 2025 年 10 月 20 日上午 01:32（太平洋标准时间）
对于此次服务中断，我们深表歉意。我们的工程师正在积极排除故障。一旦有重要信息需要分享，我们将及时更新。感谢您的理解和耐心等待。
UTC 时间 | 2025 年 10 月 20 日上午 09:49 2025 年 10 月 20 日上午 02:49（太平洋标准时间）
我们的工程师已发现一个来自我们的上游提供商的问题，影响到多个 Zendesk 产品，包括 Chat、 语音、Analytics、SunCo、 Sunshine Platforms、Contact Center 和Support。我们看到了改进，但客户可能会经历一段时间的性能下降。感谢您的耐心等待，我们将及时提供更新。
UTC 时间 | 2025 年 10 月 20 日上午 11:08 2025 年 10 月 20 日上午 04:08（太平洋标准时间）
我们发现，由于我们的上游提供商造成的问题，Zendesk 产品已部分恢复。我们的工程团队将继续努力工作，以恢复所有受影响区域的全面服务。由此带来的不便我们深表歉意，感谢您的耐心等待。更新可用时将予以提供。
UTC 时间 | 2025 年 10 月 20 日下午 2:28 2025 年 10 月 20 日上午 07:28（太平洋标准时间）
根据我们的观察，大多数 Zendesk 产品都实现了显着恢复；但是，美洲和亚太地区的 Explore 客户可能会在实时和历史分析报告中继续遇到过时的数据。此外，通话会话和数据访问方面持续存在问题，与上游提供商问题相关。我们的工程团队正与提供商密切合作以加快修复速度，并积极采取措施在使用高峰期之前完全恢复所有服务。由此造成的任何中断，我们深表歉意。衷心感谢您的耐心等待。如有进一步的更新，我们将及时提供。
UTC 时间 | 2025 年 10 月 20 日下午 03:20 2025 年 10 月 20 日上午 08:20（太平洋标准时间）
我们正在积极处理与云提供商的中断，该中断影响多个 Zendesk 产品和 Pod，主要涉及 Pod 19 和 23。其他影响包括在美国和亚太地区的 Explore，在所有 Pod、人工智能专员和Sunshine Conversations中的 Talk，以及全方位渠道路由和 Chat 中的一些降级。对于之前错过的通知，我们深表歉意。如有新信息，我们将在一小时内或尽快更新。
UTC 时间 | 2025 年 10 月 20 日下午 4:30 2025 年 10 月 20 日上午 09:30（太平洋标准时间）
我们将继续与我们的云提供商合作，解决影响多个 Zendesk 产品的问题。很抱歉，我们没有关于完全恢复的实质性或积极的更新，但我们想让您了解最新信息。感谢您在我们处理此次严重服务中断期间的耐心等待和理解。我们将在有更新可用时发送更新。
UTC 时间 | 2025 年 10 月 20 日晚上 10:05 2025 年 10 月 20 日下午 3:05（太平洋标准时间）
我们的合作伙伴云提供商表示，情况有了显着改善，根据我们的监测和日志记录，Zendesk 产品几乎已完全恢复。虽然我们正从稳定性的角度解决问题，但影响窗口期后仍有大量积压活动尚未处理。Explore 数据和 Talk 通话录音将在接下来的几个小时内逐渐回填，我们将在确认问题已完全解决后进行跟进。感谢您耐心等待我们的调查。
UTC 时间 | 2025 年 10 月 20 日晚上 11:35 2025 年 10 月 20 日下午 4:35（太平洋标准时间）
所有 Zendesk 服务都已恢复，并处于稳定状态。Explore 数据将在未来几个小时内继续更新，因为我们会处理此次事务期间创建的待办工单。客户无需进行任何操作。Explore 报告仍可正常使用，但数据新鲜度可能会延迟，直到待办工单被清除。感谢您耐心等待我们处理此问题。
根本原因分析
此事件的起因是AWS美国东部 (us-east-1) 发生严重中断，导致解析网络地址失败和系统容量不足，从而中断了 Zendesk 的核心基础设施服务。此外，由于AWS可用区的限制，某些 Pod 中出现了资源不平衡的问题。
解决
为解决此问题，工程团队与AWS Support 协调，实施了各种修复程序，包括资源扩展、手动清除，以及重新启动关键数据流程。在响应的整个过程中，我们一直向客户通报最新情况，并确认已确认完全恢复所有核心服务。
修复项目
- 为数据库调用添加超时，以避免延迟，并确保失败的调用不会挂起系统。
- 开发用于抓取应用版本和资产的回退方法，以妥善处理数据库中断。
- 调查由于缺失数据导致的作业失败，并改进验证以避免此类错误；确保相关指标受到监测，且警报处于活跃状态。
- 改进轻松扩展或缩小处理管道以赶上延迟工作的能力。
- 实施功能，使系统在发生故障时可以正常降级，而不是显示错误或空白页面。
- 为集群添加额外的缓存容量，并根据流量高峰时间调整维护日程计划。
- 探索暂时减少非关键服务使用的资源，以优先处理重要的应用程序。
- 创建一个处理工作量故障的清单，以防止 Pod 意外关闭或缩小。
- 设置托管节点组的最小大小限制，以维持足够的资源。
- 研究备份和故障转移选项，以提高服务的可靠性。
- 完成帐户迁移，减少区域故障的风险。
- 研究减少不必要的 API 调用，尽量减少平台故障期间对用户的影响。
- 将事件提取限制在界面可见的范围内，以减少事务期间的数据库负载。
- 查看影响范围，了解受影响区域以外的客户会遇到问题的原因。
- 确认对第三方服务的依赖关系及其故障转移功能。
- 用相关的备份和警报程序更新待命指南。
- 确保在所有事务发生期间，随叫随到的指南都可以访问。
- 改进部署监测工具并冻结政策，以避免发布错误。
- 与云提供商合作，提高警报准确性，减少监测干扰。
- 增加关键代理的内存分配以提高稳定性。
- 将无数据警报与作业处理系统分开，以避免误报。
如需更多信息
有关 Zendesk 的当前系统状态信息以及对您帐户的具体影响，请访问我们的 系统状态页面.请关注此文章，以便在我们的事后分析报告发布时获得通知。如果您对此事务有其他疑问， 联系 Zendesk 客户支持。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。