概要
2024 年 8 月 27 日 16:30 UTC 至 22:30 UTC,Pod 19、20 和 27 中的 Support 客户的 Webhook 和触发器触发出现延迟,影响了工单更新以及与终端用户的沟通。
时间线
UTC 时间 | 2024 年 8 月 27 日下午 08:03太平洋时间 2024 年 8 月 27 日下午 01:03
我们正在调查 Support 延迟触发和 Webhook 的报告。下次更新将于 30 分钟后,或当我们有新信息可分享时。
UTC 时间 | 2024 年 8 月 27 日下午 08:27 2024 年 8 月 27 日下午 01:27(太平洋时间)
Webhook 和触发器延迟对 Pod 19、20 和 27 上的 Support 客户产生了影响。我们的工程师目前已介入调查。下次更新将于 30 分钟后,或当我们有新信息可分享时。
UTC 时间 | 2024 年 8 月 27 日下午 08:56 2024 年 8 月 27 日下午 1:56(太平洋时间)
我们的工程师将继续调查对 Pod 19、20 和 27 产生影响的 Support 客户的 Webhook 和触发器延迟问题。下次更新于 1 小时后,或当我们有新信息可分享时。
UTC 时间 | 2024 年 8 月 27 日下午 09:24 2024 年 8 月 27 日下午 2:24(太平洋时间)
我们在 Pod 19 上看到了 Webhook 延迟方面的改进,并在 Pod 20 和 27 上继续处理了 Webhook 待办工单。下次更新于 1 小时后,或当我们有新信息可分享时。
UTC 时间 | 2024 年 8 月 27 日晚上 10:03太平洋时间 2024 年 8 月 27 日下午 03:03
Pod 19 和 20 上 Webhook 的待办工单已完全处理,这些 pod 应该不会再出现任何延迟。我们仍在处理 pod 27 上的 Webhook 待办工单,待其清除后将及时发布最新消息。
UTC 时间 | 2024 年 8 月 27 日晚上 10:40太平洋时间 2024 年 8 月 27 日下午 03:40
pod 19、20 和 27 上 Webhook 的待办工单已完全处理,这些 pod 应该不会再有任何延迟。此问题现已完全解决。
事后分析
根本原因分析
此事件的主要原因是某大客户导入了大规模用户,导致流量突然激增。此激增导致 Webhook 系统达到了其吞吐量限制,从而导致了严重的延迟。此外,在 Pod 27 中,自动扩展机制无法充分处理增加的流量,进一步加剧了延迟。
解决方案
要解决此问题,我们已对 Webhook 分发程序和不受信任的出口区域 (UEZ) 进行了可扩展的升级,以应对激增的流量。此外,还要求特定客户放慢操作速度。进行必要的扩容调整后,待办工单开始减少,所有受影响的 pod 中逐渐恢复了正常服务。
修复项目
- 为 Webhook 服务定义水平自动缩放策略。 [正在进行中]
- 研究增强速率限制逻辑,以考虑到具有多个子域名的单个客户。 [已计划]
- 研究并解决 Pod 27 中的安全出口层自动缩放问题。[已计划]
- 简化部署和配置更改流程,减少紧急解决期间的摩擦。 [正在进行中]
- 为 Webhook 实施特定于子域名的终止开关。 [正在进行中]
- 添加监测警报,以标记 Webhook 待办工单或传递延迟何时过大。 [已计划]
- 公开记录 Webhook 速率限制,以通知客户并预先管理流量。 [已计划]
如需更多信息
如需了解您 Zendesk 当前的系统状态信息,请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问,请 联系 Zendesk 客户支持。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。
0 条评论