概要
2024 年 6 月，Zendesk Support 专员工作区中出现了一些问题，尤其是在 13 日和 25 日以及 7 月的几天里。这些事务中断了专员的工作流程，使其难以访问工单。他们遇到的主要问题是在尝试加载工单时出现“未找到消息”错误和错误代码“A_xxx”。这些问题主要发生在多天内的各个 Pod 中。每次中断峰值通常平均持续 2 分钟。尽管客户可尝试刷新系统作为解决方法，但他们面临在此过程中失去正在进行的对话的风险。
时间线
UTC 时间 | 2024 年 6 月 25 日下午 4:05 2024 年 6 月 25 日上午 09:05（太平洋时间）
我们注意到，在 2024 年 6 月 25 日 15:40 至 15:47 UTC 之间，多个 Pod 中出现的错误激增，导致用户在尝试在Support。我们已从这些错误中恢复，要解决此问题，请重新加载浏览器和/或清除缓存和 Cookie。
事后分析
根本原因分析
造成这些事件的主要原因是对服务器的 HTTP 请求意外增加，通常在流量高峰时段。数据激增产生了“群体效应”，导致专员图服务器连接不堪重负，导致就绪情况调查失败。Lotus 是该系统的重要组成部分，被认定为发挥着重要作用。每次重新连接时都会产生多个请求，导致工单数据管理器 (TDM) 过载。流量激增的主要原因是对话状态订阅在似乎由于 Zorg/Nginx 和/或订阅服务部署而大规模断开连接后重新连接。
TDM 主要负责管理工单数据。它会在工单生成时组织和存储信息，然后在专员或客户需要访问时检索并显示这些数据，并作为所有工单相关数据的主控制者，确保系统内的无缝操作。
解决
我们已针对这些问题采取了预防措施。其中包括负责调节传入流量的连接和请求速率限制器。同时，我们已采取措施增强专员图表在缓存失败期间的恢复能力。此策略可用作断电期间的备用生成器，防止因技术故障而导致整个系统的中断。尽管已采取多种缓解措施，但导致此服务事件结束的实际修复是在 Lotus 中进行的更改。此更改减少了雷群效应结束后重新抓取数据的场景数量。
编辑于 7 月 25 日：在 7 月 10 日进行一些调整以避免请求累积导致问题后，我们没有看到进一步的峰值影响工单 UI。我们继续密切关注，并对接下来的几天一切进展顺利感到满意。
此外，与上个月相比，我们注意到特定 Pod 在周五的性能会有所下降，但这一情况在 7 月 12 日有所好转，这让我们对自己的更改更有信心了。在那之后，7 月 15 日，我们没有遇到任何性能波动或峰值，这让我们相信该问题已解决。
修复项目
我们已计划采取其他策略，以进一步增强系统稳定性并防止未来出现中断：
- 就绪情况调查失败警报：实施冒烟测试，及时提醒技术团队注意任何潜在问题，以便其迅速采取行动。
- 抓取模式的注意事项：建议软件开发者慎重考虑信息检索的数量和频率，以避免系统失衡。
- 建立请求基准线：确定系统同时处理工单信息请求的能力，以避免系统崩溃。
- 间隔重新抓取：引入抖动以减轻雷击群体效应。
- 探索更优质的订阅保留：研究在部署期间更有效地维护订阅的方法。
如需更多信息
如需了解您 Zendesk 当前的系统状态信息，请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问，请 联系 Zendesk 客户支持。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。