概要
2024-02-09 20:32 UTC 到 2024-02-09 22:29 UTC 期间，Pod 13 的 Support 客户遇到了一个问题，导致一些工单不显示 SLA 标记。
事后分析
根本原因分析
在此事件中，pod 13 中的 16 个 k8s pod 中有一个意外重启并出现故障。该错误消息表示“连接字符串授权机构”出现了问题，导致我们指标事件服务 (MES) 的关键依赖项“redis”主机中断。这种中断导致工单活动日志的处理复杂化，尤其是导致服务级别协议 (SLA) 活动缺失或延迟。我们怀疑 kpod 由于部署或配置更改而无意中重新启动。发生问题时，我们的首要目标是解决主要服务问题，而这需要快速进行系统重置。此过程没有给我们时间立即记录出现故障的系统单位的详细信息。但后来我们在安全测试环境中引入了一个缺陷，成功重现了该错误，这有助于我们更好地理解问题所在。
解决方案
识别问题后，我们重新部署了 kpod，最终解决了该问题。缺失的 SLA 事件随后将进行回填。
请注意：为解决已开启工单已损坏的 SLA 而运行数据回填/恢复的操作会产生副作用，即会完全移除已关闭工单上的 SLA 数据，从而导致 Explore 中的 SLA 数据为“空”。
修复项目
- 探索更好的方法来组织和传递环境变量，以确保在系统单位重新启动时准备就绪
- 更新我们的“funfiller”，缩短修复已损坏的服务级别协议 (SLA) 的周转时间
- 审阅监测和警报
- 重新研究环境变量的传递方法，确保其在系统重启时可用
如需更多信息
如需了解您 Zendesk 当前的系统状态信息，请查看我们的系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问，请通过小组件中的 ZBot Messaging 向我们提交工单。
翻译免责声明：本文章使用自动翻译软件翻译，以便您了解基本内容。 我们已采取合理措施提供准确翻译，但不保证翻译准确性
如对翻译准确性有任何疑问，请以文章的英语版本为准。