概要
2025 年 1 月 31 日 13:15 至 17:41 UTC 客户遇到了一些专员和终端用户在用户界面中被阻止实则被阻止的问题。这些用户实际上并未被阻止,在回滚更新并让客户清除缓存后,所有访问权限都已完全恢复。
时间线
UTC 时间 | 2025 年 1 月 31 日下午 6:15 2025 年 1 月 31 日上午 10:15(太平洋时间)
我们很高兴地报告,我们已解决了导致某些用户被意外阻止的问题。感谢您耐心等待我们的调查。
UTC 时间 | 2025 年 1 月 31 日下午 05:52 2025 年 1 月 31 日上午 09:52(太平洋时间)
我们已回滚了一个我们认为的导致专员和终端用户被阻止的更新。在清除缓存并刷新浏览器后,此时用户访问权限应可恢复。如果您继续遇到任何问题,请与我们联系。
UTC 时间 | 2025 年 1 月 31 日下午 05:48 2025 年 1 月 31 日上午 09:48(太平洋时间)
导致多个 Pod 中的用户意外被阻止的问题仍在调查中。我们将在未来一小时内,或有新信息可分享时提供更多更新。
UTC 时间 | 2025 年 1 月 31 日下午 05:23 2025 年 1 月 31 日上午 09:23(太平洋时间)
我们的团队正在继续调查导致专员和终端用户的多个 Pod 被意外阻止的问题。我们将在接下来的 30 分钟内或在了解更多信息后发布更多更新。
UTC 时间 | 2025 年 1 月 31 日下午 04:59 2025 年 1 月 31 日 上午 08:59(太平洋时间)
我们已确认一个问题,导致多个 Pod 中专员和终端用户被意外阻止,我们的团队正在调查此问题。更多更新将在接下来的 30 分钟内发布。
UTC 时间 | 2025 年 1 月 31 日下午 4:46 2025 年 1 月 31 日上午 08:46(太平洋时间)
我们刚收到关于专员和终端用户被意外阻止的报告,我们的团队正在进行调查。更多信息将很快发布。
事后分析
根本原因分析
此事件是由替换用户设置中实施的部署引起的。新实施无法正确处理 NULL 值,导致系统错误地将用户识别为被阻止。以前的系统将 NULL 转换为空字符串,该字符串会被识别为 false 值,而新实现不会执行此转换,从而导致阻止状态返回应为 false 的 true。
解决
为了解决这一问题,该团队已开始回滚有问题的部署。此操作已恢复正常功能,允许用户重新访问其帐户。此外,我们还刷新了浏览器缓存,以确保修复有效。
修复项目
- 数据迁移:执行迁移以纠正被阻止设置中的 NULL 值,避免今后出现类似问题。
- 部署背景信息:确保将来的部署尝试包含适当的背景信息和从此事务中得到的经验教训。
- 单元测试审阅:添加单元测试以涵盖涉及 NULL 值的场景,确保在未来更改中进行可靠的验证。
- 数据覆盖率检查:审阅数据以确保所有实例值都得到充分覆盖和计算。
如需更多信息
有关 Zendesk 当前系统状态信息以及对您帐户的具体影响,请访问我们的 系统状态页面。请关注此文章,以便在我们的事后分析报告发布时获得通知。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。
0 条评论