概要
在此事件中,一些来自多个 Pod 和区域的 Explore 客户遇到了延迟,且 Explore 中的工单数据集中有过时的信息。
时间线
10:38 UTC | 02:38 太平洋时间
回滚后,所有重新处理的同步作业都已完成,Explore 数据同步已恢复正常。至此,此事务已解决。感谢您耐心等待我们的调查。
00:18 UTC | 16:18 PT
我们会继续为受影响的客户手动重新处理同步作业,如有具体最新进展,我们会及时分享。
20:58 UTC | 12:58(太平洋时间)
我们已完成一个 Explore 更新的回滚,该更新导致了工单数据集更新的延迟。我们正在手动重新处理同步作业。有新信息可分享时,我们将另行通知。
20:11 UTC | 12:11(太平洋时间)
在最近发布的更新中,我们已找到一些 Explore 客户的工单数据集中同步延迟和错误的潜在根本原因。我们正在努力回滚该更新,并正在监测结果。如有新发现,我们将及时分享。
19:06 UTC | 11:06 PT
我们仍在调查导致 Explore 中工单数据集跨多个 Pod 和区域同步延迟和出错的问题。我们的团队已取得一些进展,但某些帐户仍遇到延迟问题。我们将继续发布找到的新信息。
18:10 UTC | 10:10 PT
对于跨多个 Pod 的某些 Explore 客户,工单数据集中同步延迟和出错。我们的团队将继续调查此问题。随着调查的进展,我们将提供进一步的更新。
17:40 UTC | 09:40 太平洋时间
我们已确认一个问题,该问题导致跨多个 Pod 和 Explore 的工单数据集同步延迟和出错。我们的团队正在进行调查。了解更多信息后,我们会发布更多信息。
17:29 UTC | 09:29 太平洋时间
我们正在调查关于工单数据集跨多个 Pod 和区域的 Explore 同步延迟的报告。我们将很快提供进一步的更新。
事后分析
根本原因分析
背景信息:我们有一个系统 (Explore ETL),定期为客户收集数据。该系统处理数据收集的实际过程。所收集的数据将被存储,然后进行进一步处理。某个帐户的数据收集时出现问题,且每张工单包含大量数据。如此大量的信息会导致内存饱和,从而产生错误,并减慢数据处理的速度。
此外,最近的一次服务器维护升级更改了内存垃圾回收的执行方式,导致内存消耗增加,从而使问题更加严重。
解决方案
识别问题后,我们尝试通过确定任务优先级和重新启动服务器来控制过载。经进一步调查并在其他团队的协助下,我们确定服务器升级问题是造成此问题的原因,并将此问题回滚到了以前的版本。然后任务处理恢复正常。
修复项目
为了避免今后发生此类事件,我们采取了一系列措施:
1.限制工单数据有效负载的大小。
2.考虑到新的垃圾收集操作会增加内存消耗,重新评估服务器维护升级。
3.增强我们的测试环境,以便更好地模拟生产负载,并准确测试此类场景。
如需更多信息
如需了解您 Zendesk 当前的系统状态信息,请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问, 请通过小组件中的 ZBot Messaging 向我们提交工单。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。