最近搜索


没有最近搜索

Attila Takacs's Avatar

Attila Takacs

已加入2021年4月14日

·

最后活动2025年2月05日

关注

0

关注者

2

活动总数

72

投票

1

订阅

63

活动概览

的最新活动 Attila Takacs

Attila Takacs 创建了一篇文章,

文章服务通知

概要

UTC 时间 | 2025 年 2 月 5 日上午 11:48 2025 年 2 月 5 日上午 03:48(太平洋时间)
我们很高兴地通知您,我们的工程团队已识别并解决了指南服务的登录问题。现在您应该可以毫无问题地访问该服务了。感谢您在此期间的耐心等待和理解!如果仍有任何问题,请联系我们的支持团队。

UTC 时间 | 2025 年 2 月 5 日上午 11:29 2025 年 2 月 5 日上午 03:29(太平洋时间)
从移动浏览器登录 Guide 服务时遇到服务降级问题。如果您在访问帐户时遇到错误,请尝试从桌面登录。我们的团队正在努力解决此问题。

事后分析

待定

如需更多信息

有关 Zendesk 当前系统状态信息以及对您帐户的具体影响,请访问我们的 系统状态页面。请关注此文章,以便在我们的事后分析报告发布时获得通知。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2025年2月05日 编辑 · Attila Takacs

0

关注者

1

投票

0

评论


Attila Takacs 创建了一篇文章,

文章服务通知

概要

2025 年 2 月 1 日 00:13 UTC 至 00:59 UTC 之间,POD 26 的客户在访问已存档工单时遇到了问题。在此期间,由于数据库系统缺陷,多个数据库读取器节点无法打开表格。这导致已存档工单的查询失败。

时间线

UTC 时间 | 2025 年 2 月 1 日上午 01:13 2025 年 1 月 31 日下午 05:13(太平洋时间)
我们很高兴地报告,影响 Support 26 客户组错误的问题现已解决。感谢您耐心等待我们的调查。

UTC 时间 | 2025 年 2 月 1 日上午 12:57 2025 年 1 月 31 日下午 04:57(太平洋时间)
我们的工程师相信他们已经确定了影响 PED 26 一批 Support 客户的错误的根本原因,并正在努力解决问题。

UTC 时间 | 2025 年 2 月 1 日上午 12:57 2025 年 1 月 31 日下午 04:57(太平洋时间)
我们正在调查在 PPD 26 上托管的 Support 客户的潜在错误。


事后分析

根本原因分析

此事件是由数据库系统中的缺陷引起的,该缺陷导致集群读取器节点无法访问已存档的工单表格。此缺陷已由我们的供应商技术支持确认,且特定于当时安装的数据库版本。


解决

为解决此问题,我们的工程师已停止向其他分片的部署,并在受影响的分片上完成正在进行的修改。至此,数据库表格即可访问。随后,该团队计划将我们的数据库系统升级到新版本,其中包括针对已识别缺陷的补丁。


修复项目

  1. 在恢复架构更改之前,升级到已打补丁的版本或更高版本。
  2. 将列的添加和索引的删除拆分为单独的操作,以便将部署期间的风险降到最低。
  3. 更新 Runbook,要求大型迁移一开始仅覆盖一个集群,然后再扩展到其他集群。
  4. 对数据库系统补丁进行定期(至少每年)审查,并确定升级节奏。

如需更多信息

有关 Zendesk 当前系统状态信息以及对您帐户的具体影响,请访问我们的 系统状态页面。请关注此文章,以便在我们的事后分析报告发布时获得通知。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2025年2月06日 编辑 · Attila Takacs

0

关注者

1

投票

0

评论


Attila Takacs 创建了一篇文章,

文章服务通知

概要
2025 年 1 月 13 日 11:07 UTC 至 12:07 UTC 之间,Pod 17 的客户遇到了消息传送触发器无法执行的问题。

时间线

UTC 时间 | 2025 年 1 月 13 日下午 12:24 2025 年 1 月 13 日上午 04:24(太平洋时间)
最近的消息传送问题已完全解决,我们的服务已完全恢复正常运行!感谢您的耐心等待!我们的团队将继续密切监测我们的系统,以确保一切顺利运行。感谢您的支持!如有任何问题或反馈,我们将竭诚为您服务!

UTC 时间 | 2025 年 1 月 13 日上午 11:51 2025 年 1 月 13 日上午 03:51(太平洋时间)
我们正在调查在 PID17 上为客户执行消息传送触发器的问题。


事后分析

根本原因分析

造成此事件的原因是消息传送工单日志活动日志服务使用者过早终止,而该服务仍在运行。因此,使用者无法处理新到的事件,从而导致 Pod 17 上消息传送触发器的评估和执行完全停止。

解决方案

为此,我们已修复将单个批次中可处理的最大记录数设置为 500 条(而不是预期的 250 条)的配置错误。我们旨在通过纠正此拼写错误并减小最大记录值来降低消费者由于超时问题而终止的可能性。

修复项目

  1. 实施运行状况检查以检测使用者是否过早终止。
  2. 创建一个监测功能以跟踪正在运行的使用者的数量。
  3. 建立一个监测功能,以监测工单日志事件使用者的停止分区。
  4. 将使用方延迟状态小组件添加到消息传送触发器服务面板。
  5. 创建一个新指标以衡量处理来自消息传送工单日志活动主题批量消息所需的时间。

这些修复措施旨在加强监测,防止今后类似事件发生,确保消息传送触发器服务的稳定性和可靠性。


如需更多信息

有关 Zendesk 当前系统状态信息以及对您帐户的具体影响,请访问我们的 系统状态页面。请关注此文章,以便在我们的事后分析报告发布时获得通知。如果您对此事件有其他疑问, 请联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2025年1月29日 编辑 · Attila Takacs

0

关注者

1

投票

0

评论


Attila Takacs 创建了一篇文章,

文章服务通知

概要

2024 年 12 月 9 日 8:08 至 13:03 UTC 之间,使用多品牌功能的客户在尝试创建工单或更新工单标题时遇到错误,但更改已保存。

时间线

UTC 时间 | 2024 年 12 月 9 日晚上 10:21下午 02:21(太平洋时间)

我们很高兴地通知您,最近的更改已成功恢复,多品牌工单创建的问题现已解决。
如果仍有问题,请尝试硬刷新 (Ctrl + F5) 或清除浏览器缓存和 Cookie,这样有助于解决任何挥之不去的问题。
如果您继续遇到问题,请随时与我们联系。感谢您的耐心等待!

UTC 时间 | 2024 年 12 月 9 日下午 12:58上午 04:58 太平洋时间
我们目前在创建多品牌工单时遇到了问题。我们的工程团队已注意到此问题,正在积极设法尽快解决。
一旦有更多信息可用,我们将提供更新。感谢您的耐心等待和理解!

 

事后分析

根本原因分析

此事件的根本原因是工单初始化逻辑中存在缺陷。当请求者 ID 未定义时,系统会尝试根据工单键值检索它,从而在工单 UI 中发生任何字段更改时出错。我们引入了从用户个人资料页面读取用户 ID 并将其设置为请求者 ID 的新逻辑,无意中将请求者对象设置为未定义,从而破坏了预期功能。


解决

要解决此问题,有问题的更新已恢复。


修复项目

  1. 修复有缺陷的代码:确保系统在创建工单时正确设置请求者数据,以避免条目空白。
  2. 添加自动测试:创建一个测试,检查工单保存流程是否正确处理请求者信息。
  3. 确认手动测试:要求部署人员在“canary”POD 上手动测试更改,并在部署之前确认一切正常。
  4. 改进监测:设置监测功能,就浏览器错误(例如“出错了”)发出警报,以便快速识别问题。

如需更多信息

有关您 Zendesk 当前的系统状态信息,查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事务有其他疑问, 联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年12月17日 编辑 · Attila Takacs

0

关注者

1

投票

0

评论


Attila Takacs 创建了一篇文章,

文章服务通知

概要

2024 年 12 月 3 日 21:09 UTC 至 3:36 UTC 期间,部分使用移动 SDK 的客户在创建工单时遇到了 400 错误。由于一项更改,为新创建的OAuth密钥分配的默认过期时间为 8 小时。这一更改无意中破坏了旧版移动 SDK,因为如果现有密钥失效,后者将无法检索新密钥,从而影响用户体验。已通过恢复更改解决此问题。


时间线

UTC 时间 | 2024 年 12 月 6 日下午 6:20 2024 年 12 月 6 日上午 10:20(太平洋时间)

我们很高兴地报告,导致某些客户在通过 SDK 创建工单时遇到 400 错误的问题已得到解决。对于由此造成的任何服务中断,我们深表歉意。感谢您耐心等待我们的调查。

UTC 时间 | 2024 年 12 月 6 日下午 12:06 2024 年 12 月 6 日上午 04:06(太平洋时间)
对于使用我们的移动 SDK 通过 API 提交的工单,我们团队会继续进行处理,避免出现 400 错误。就目前而言,如果终端用户遇到此错误,可重新启动应用,工单将照常创建。


UTC 时间 | 2024 年 12 月 6 日上午 09:45 2024 年 12 月 6 日上午 01:45(太平洋时间)

我们注意到一些客户在尝试通过我们的移动 SDK 创建工单时可能会遇到 400 错误。如果遇到此错误,请重新启动应用以解决问题。


事后分析

根本原因分析

此事件起因于,在推出过期时间更改之前,我们未能评估身份验证密钥在不同产品中的使用情况。当现有密钥过期时,旧版 SDK 在设计上就无法获取新的OAuth密钥,但在规划和整合阶段并未充分考虑到这一点。加强协作并对密钥使用情况进行更全面的评估本来有助于避免这种中断。


解决

要解决此问题,身份验证团队首先禁用了会增加现有密钥过期时间的回填流程。随后,他们部署了一个拉取请求,以恢复新密钥的过期设置,并启动回填以消除现有密钥的过期情况。此操作已恢复大多数受影响客户的功能。


修复项目

  1. 在团队之间建立清晰的沟通协议,以确保在实施重大更改之前,正确记录和审查已知缺陷。
  2. 改进现有实施工具,以更好地管理身份验证工作流程,减少与旧版 SDK 相关的技术债务。
  3. 创建更多警报和监测系统,以便将来检测类似问题,特别是OAuth密钥失败。
  4. 对特定应用程序引入连接限制,以防止生成过多的密钥,并缓解数据库大小激增。

如需更多信息

有关您 Zendesk 当前的系统状态信息,查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事务有其他疑问, 联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年12月20日 编辑 · Attila Takacs

0

关注者

1

投票

0

评论


Attila Takacs 创建了一篇文章,

文章服务通知

概要

2024 年 11 月 21 日 21:02 UTC 至 21:56 UTC 之间,一些使用托管在 Pod 17 上的Sunshine Conversations的客户遇到了速度缓慢和性能问题。

 

时间线

UTC 时间 | 2024 年 11 月 24 日晚上 10:23 2024 年 11 月 24 日下午 2:23(太平洋时间)
我们很高兴宣布,影响一些客户在 PID 17 上Sunshine Conversations的延迟问题现已解决。非常感谢您的耐心等待!

UTC 时间 | 2024 年 11 月 24 日晚上 10:09 2024 年 11 月 24 日下午 02:09(太平洋时间)
我们相信我们已经确定了 Pod17 上客户 SunCo 性能问题的根本原因。我们现已看到改进,将继续监测此行为。

UTC 时间 | 2024 年 11 月 24 日下午 09:53 2024 年 11 月 24 日下午 01:53(太平洋时间)
我们将继续调查 Pod 17 中的性能问题。这可能导致Sunshine Conversations运行缓慢。我们将尽快提供进一步的更新。

UTC 时间 | 2024 年 11 月 24 日下午 09:36 2024 年 11 月 24 日下午 1:36(太平洋时间)
我们正在调查 Pod 17 上托管的一些客户的潜在性能问题。我们将很快发布包含更多详情的更新。


事后分析

根本原因分析

此事件是由 Pod17 上的流量意外激增引起的,该流量在过去一周增加了一倍多,在事件发生当天几乎增加了三倍。客户使用的 Unity SDK 过度请求 SunCo API 来检索未读消息计数,导致系统负载增加。资源自动缩放程序已达到最大容量,导致无法添加更多资源以处理增加的流量。因此,过载导致响应时间减慢,并最终触发运行状况检查并重新启动,从而使问题更加复杂。

解决方案

为了解决性能问题,我们增加了 Pod17 上 SunCo API 的最大副本数量。此调整使系统能够更好地处理增加的流量,并使所有客户恢复正常的响应时间。

修复项目

  1. 研究 Unity SDK,了解其向 SunCo 发送过多请求的原因,并实施优化。
  2. 记录 embeddables 中的后端交互模式,以澄清用法并识别潜在的低效情况。
  3. 评估 SunCo 中 SDK API 缓存策略的实施,以减少请求数。
  4. 添加监测功能,以检测特定时段内的异常流量增长,主动解决潜在的过载问题。

 

如需更多信息

如需了解您 Zendesk 当前的系统状态信息,请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问,请 联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年12月04日 编辑 · Attila Takacs

0

关注者

1

投票

0

评论


Attila Takacs 创建了一篇文章,

文章服务通知

概要

在 2024 年 11 月 12 日 23:30 UTC 到 2024 年 11 月 15 日 11:26 UTC 之间,在 Pod 25 和 30 中使用 SLA 的 Support 客户会遇到SLA计算延迟,以及其工单上的SLA标记在适用后不会如预期显示工单更新。

 

时间线

UTC 时间 | 2024 年 11 月 15 日下午 01:00 2024 年 11 月 15 日上午 05:00(太平洋时间)
我们很高兴地报告,影响 Pod 25 和 30 指标SLA性能的问题现已解决。感谢您的耐心等待!

UTC 时间 | 2024 年 11 月 15 日下午 12:16 2024 年 11 月 15 日上午 04:16(太平洋时间)
我们现已看到影响 Pod 25 和 30 指标SLA性能的问题已得到改善。我们将继续关注最新进展,并将尽快提供。

 

事后分析

根本原因分析

此事务是由指标事件服务的密钥配置错误引起的。这意味着,当 Zendesk 部署带有额外验证的更新时,亚太地区部署的服务无法初始化,从而导致处理延迟。

解决方案

要解决此问题,我们已在 2024 年 11 月 15 日为受影响的密钥添加了“默认”值。这样指标事件服务才可以正确初始化,继续正常运行。Zendesk 还识别了 Talk 转录服务的“密钥”,并设置了默认值,以降低未来风险。

修复项目

  1. 对所有密钥进行全面审核,确保其值已针对所有区域(尤其是亚太区域)进行了设置。
  2. 改进现有实施工具,避免今后出现类似配置错误。
  3. 创建更多警报,通知相关团队初始化失败和问题。
  4. 研究失败指标的跟踪,确保此类事件触发警报,以便及时解决。

通过实施这些修复措施,我们旨在提高服务的抵御能力,避免今后类似事件发生。

 

如需更多信息

如需了解您 Zendesk 当前的系统状态信息,请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问,请 联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年12月04日 编辑 · Attila Takacs

0

关注者

1

投票

0

评论


Attila Takacs 创建了一篇文章,

文章服务通知

概要

2024 年 11 月 14 日 14:15 至 23:20 UTC 之间,使用 Explore 的客户在访问报告和面板时遇到了网络错误。 

 

时间线

UTC 时间 | 2024 年 11 月 14 日下午 6:11 2024 年 11 月 14 日上午 10:11(太平洋时间)
我们很高兴地报告,加载 Explore 面板或报告时导致“网络错误”消息的问题已解决。感谢您耐心等待我们的调查。

UTC 时间 | 2024 年 11 月 14 日下午 03:18 2024 年 11 月 14 日上午 07:18(太平洋时间)
部分 Explore 用户在加载面板或报告时可能会看到“网络错误”消息。在这种情况下,清除浏览器的 Cookie 和缓存应可以解决问题。对您的不便我们深表歉意。

事后分析

根本原因分析

此事件是由一次网络更改引起的,该更改导致发送到 Explore 服务的标头数量超出了其配置的限制。这导致服务失败(静默提示),从而导致无法为客户加载面板。

解决方案

为了解决这个问题,我们联系了网络团队来调查这些更改。识别问题后,他们恢复了添加过多标头的更改,从而使 Explore 面板恢复了正常功能。

修复项目

  • 改进现有实施工具:审查并改进用于管理 API 请求中标头限制的工具,以避免类似事件。
  • 创建其他警报:设置监测标头计数和其他关键指标的警报,以便在问题影响客户之前将其检测出来。
  • 添加对特定应用程序的连接限制:对 API 实施连接限制,确保其不会超出操作阈值,从而降低未来发生事件的风险。


如需更多信息

如需了解您 Zendesk 当前的系统状态信息,请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问,请 联系 Zendesk 客户支持。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年12月03日 编辑 · Attila Takacs

1

关注者

1

投票

0

评论