最近搜索


没有最近搜索

Emanuele Sparacca's Avatar

Emanuele Sparacca

已加入2021年10月27日

·

最后活动2025年2月07日

关注

0

关注者

0

活动总数

7

投票

0

订阅

4

活动概览

的最新活动 Emanuele Sparacca

Emanuele Sparacca 创建了一篇文章,

文章服务通知

概要

UTC 时间 | 2025 年 2 月 7 日上午 11:12 2025 年 2 月 7 日上午 03:12(太平洋时间)
我们很高兴地通知您,自 UTC 时间 10:25 起,Explore 面板的问题已解决。感谢您的耐心等待和理解!

UTC 时间 | 2025 年 2 月 7 日上午 10:54 2025 年 2 月 7 日上午 02:54(太平洋时间)
自昨天 20:00 UTC 以来,我们目前遇到了 Explore 面板的延迟。我们的工程团队已识别此问题并进行了修复。我们正在积极监测事态发展,确保您为您提供流畅的体验。感谢您的耐心等待!

事后分析

待定

如需更多信息

有关 Zendesk 当前系统状态信息以及对您帐户的具体影响,请访问我们的 系统状态页面。请关注此文章,以便在我们的事后分析报告发布时获得通知。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2025年2月07日 编辑 · Emanuele Sparacca

0

关注者

1

投票

0

评论


Emanuele Sparacca 创建了一篇文章,

文章服务通知

概要

2025 年 1 月 16 日 9:40 UTC 至 10:47 UTC 之间,Pod 19 上的一些 Chat 客户在查看最近的在线交谈、接收在线交谈导出电邮以及从在线交谈创建工单时遇到问题。

时间线

UTC 时间 | 2025 年 1 月 16 日上午 11:26 2025 年 1 月 16 日上午 03:26(太平洋时间)
我们很高兴地通知您,影响为客户提供在线交谈服务的问题现已解决。衷心感谢您的耐心和理解。

UTC 时间 | 2025 年 1 月 16 日上午 11:00 2025 年 1 月 16 日上午 03:00(太平洋时间)
我们在恢复功能方面取得了重大进展,包括查看最近的在线交谈、接收在线交谈导出电邮以及创建工单的功能。我们将继续密切关注事态发展,并努力提升您的体验。感谢您的耐心等待和理解!

UTC 时间 | 2025 年 1 月 16 日上午 10:39 2025 年 1 月 16 日上午 02:39(太平洋时间)
我们的 Pod 19 上的在线交谈服务目前遇到了问题,您可能无法查看最近的在线交谈、接收在线交谈导出电邮,以及创建工单。我们的团队正在积极努力,以尽快解决这些问题。感谢您的耐心等待!


事后分析

根本原因分析

造成此事件的原因是在线交谈服务已达到内存限制,并导致不断重启。每次重新启动都会在内存数据库中生成额外的元数据,导致内存溢出,最终导致系统内存不足,影响共享同一数据库实例的其他服务。

解决方案

为了解决此问题,团队从数据库中删除了不必要的元数据和未确认的密钥,以释放内存。此外,我们增加了实例类型以适应工作量,至此服务部署已成功完成。

修复项目

  1. 添加警报:在 Chat 服务中实施内存不足 (OOM) 情况的警报。
  2. 调整内存限制:降低了内存限制的阈值,以便在达到关键水平之前进行早期干预。
  3. Runbook 的改进:改进了处理在线交谈服务和数据库密钥管理的文档和操作手册。
  4. 数据库集群:已计划将不同服务的数据库实例分开,以避免将来出现共享内存问题。

如需更多信息

有关 Zendesk 当前系统状态信息以及对您帐户的具体影响,请访问我们的 系统状态页面。请关注此文章,以便在我们的事后分析报告发布时获得通知。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2025年1月29日 编辑 · Emanuele Sparacca

0

关注者

1

投票

0

评论


Emanuele Sparacca 创建了一篇文章,

文章服务通知

概要
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 基础设施内存使用量较高。这导致了警报负载过重,并导致多个队列达到其最大容量。负责管理这些请求流的系统经常重新启动,无法跟上需求,导致积压的工单不断增加,并阻止新请求的处理。

解决方案

为了解决这个问题,我们首先尝试扩容更多的基础设施,但很快就爆满了。然后,我们使用额外资源设置一个新集群,以有效管理实时流量。这使我们能够在处理旧基础设施中积压的请求的同时,稳定运营并恢复正常功能。

修复项目

  1. 移除过时的通知队列:我们决定取消与客户沟通时不必要的通知队列。这样可减少相关基础设施处理的请求数量。
  2. 增强消息处理工具:我们对现有工具进行了改进,以提高消息处理效率和处理请求的能力。
  3. 建立其他警报:创建了新的监测警报,以跟踪系统性能,避免内存使用率过高。
  4. 设置连接限制:我们对特定应用程序的连接数量实施了限制,以防过载并确保流量管理更加顺利。

如需更多信息

如需了解您 Zendesk 当前的系统状态信息,请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2025年1月07日 编辑 · Emanuele Sparacca

0

关注者

1

投票

0

评论