概要
2024 年 12 月 1 日 4:00 UTC 到 12:00 UTC 期间,多个 Pod 中的 Sell 客户在使用智能列表中的数据可见度、创建交易时的潜在客户转化以及呼出电话等功能时都遇到了问题,其中失败。恢复功能后,还需要处理大量请求,一直到 2024 年 12 月 18 日 16:22 UTC 时间才能完成。
时间线
UTC 时间 | 2024 年 12 月 18 日下午 4:22 2024 年 12 月 18 日上午 08:22(太平洋时间)
感谢您的耐心等待,我们正在重新处理影响窗口期错过或受到影响的 Sell 数据。此时所有数据都应该是正确的。如果仍有任何问题,请与 联系。
UTC 时间 | 2024 年 12 月 13 日晚上 11:26 2024 年 12 月 13 日下午 03:26(太平洋时间)
我们的工程团队在回填并重新处理影响窗口期错过或受到影响的 Sell 数据方面取得了重大进展;但仍有一小部分请求需要更多人工参与才能回填。我们正在投入更多时间和精力来确保所有数据都到达适当位置,并下周继续工作以确认完全恢复。感谢您在此期间的耐心等待!
UTC 时间 | 2024 年 12 月 9 日晚上 10:16 2024 年 12 月 6 日下午 2:16(太平洋时间)
我们的团队将继续努力回填影响窗口期期间受影响的 Sell 数据;然而,考虑到数据量以及我们在确保准确包含正确数据方面的谨慎程度,这将需要一些额外的时间来完成。随着回填工作的进行,我们会及时提供最新进展。
UTC 时间 | 2024 年 12 月 6 日下午 02:06 2024 年 12 月 6 日上午 06:06(太平洋时间)
我们想提供关于 2024 年 12 月 3 日影响 Sell 客户的事务的最新情况。我们团队将继续处理此次事务期间出现的数据积压问题,我们将继续尽快提供更新。
UTC 时间 | 2024 年 12 月 4 日上午 10:27 2024 年 12 月 4 日上午 02:27(太平洋时间)
我们的团队正在积极探索最有效的方法,以处理由于昨天影响 Sell 的事务而造成的操作积压。我们将第一时间分享更多更新。
UTC 时间 | 2024 年 12 月 3 日晚上 11:44 2024 年 12 月 3 日下午 03:44(太平洋时间)
我们的工程团队已稳定 Sell 功能,目前正在如期处理新的请求。我们正在研究各种选项,以处理在影响范围内可能已超时的请求,并在明天继续进行调查时提供更多信息。
UTC 时间 | 2024 年 12 月 3 日下午 9:47 2024 年 12 月 3 日下午 01:47(太平洋时间)
我们的团队将继续致力于减少待办工单数量,并恢复预期的 Sell 功能。我们正在努力增加工作量以加快恢复速度,但预计仍会出现一些延迟和延迟。有新信息可分享时,我们将及时提供最新进展。
UTC 时间 | 2024 年 12 月 3 日下午 5:09 2024 年 12 月 3 日上午 09:09(太平洋时间)
我们开始看到影响 Sell 的问题有所改善;但是,我们正在努力解决大量积压问题,因此您可能仍会遇到延迟。我们将继续监测事态发展,确保完全恢复。
UTC 时间 | 2024 年 12 月 3 日下午 03:35 2024 年 12 月 3 日上午 07:35(太平洋时间)
我们的团队将继续致力于解决当前影响 Sell 的问题。其具体体现为智能列表中的数据可见度问题、交易创建时的潜在客户转化问题,以及呼出电话间歇性失败。如有最新更新,我们将及时提供。
UTC 时间 | 2024 年 12 月 3 日下午 02:01 2024 年 12 月 3 日上午 06:01(太平洋时间)
我们希望及时向您通报影响某些功能的持续问题,包括智能列表中的数据可见度、创建交易时的潜在客户转化,以及间歇性呼出电话失败。虽然我们目前没有新的进展可分享,但请注意,我们的团队正在努力尽快解决此问题。
UTC 时间 | 2024 年 12 月 3 日下午 12:14 2024 年 12 月 3 日上午 04:14(太平洋时间)
我们的团队正在积极解决影响特定功能的服务降级问题。目前,智能列表中的数据可见度、交易创建中的潜在客户转化以及呼出电话都会受到影响,后者会出现间歇性失败。虽然大多数核心服务仍然可操作,但某些问题通常可以通过重新加载或重试解决。
UTC 时间 | 2024 年 12 月 3 日上午 11:23 2024 年 12 月 3 日上午 03:23(太平洋时间)
我们团队正在积极解决影响特定功能的服务降级问题,包括智能列表中的数据可见度,以及交易创建中的潜在客户转化。大多数核心服务仍可运行,某些功能的问题通常可以通过重新加载或重试解决。
UTC 时间 | 2024 年 12 月 3 日上午 10:53 2024 年 12 月 3 日 上午 02:53(太平洋时间)
我们目前正在调查一个过时数据可能出现在我们系统中的问题。此外,尝试在此期间更新数据可能会导致错误。我们团队正在努力优先解决这些问题。
事后分析
根本原因分析
此事件是由于请求量突然增加,导致整个 Sell 基础设施内存使用量较高。这导致了警报负载过重,并导致多个队列达到其最大容量。负责管理这些请求流的系统经常重新启动,无法跟上需求,导致积压的工单不断增加,并阻止新请求的处理。
解决方案
为了解决这个问题,我们首先尝试扩容更多的基础设施,但很快就爆满了。然后,我们使用额外资源设置一个新集群,以有效管理实时流量。这使我们能够在处理旧基础设施中积压的请求的同时,稳定运营并恢复正常功能。
修复项目
- 移除过时的通知队列:我们决定取消与客户沟通时不必要的通知队列。这样可减少相关基础设施处理的请求数量。
- 增强消息处理工具:我们对现有工具进行了改进,以提高消息处理效率和处理请求的能力。
- 建立其他警报:创建了新的监测警报,以跟踪系统性能,避免内存使用率过高。
- 设置连接限制:我们对特定应用程序的连接数量实施了限制,以防过载并确保流量管理更加顺利。
如需更多信息
如需了解您 Zendesk 当前的系统状态信息,请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。
0 条评论