Justin H

概要

在 2024 年 3 月 5 日 19:50 UTC 至 22:06 UTC 之间，部分 Talk 客户可能遇到了连接问题，包括无法拨打、接听或转接电话。 

 

时间线

21:36 UTC | 13:36 PT

我们正在调查有关 Talk 连接问题的报告，包括无法拨打、接听或转接电话。下次更新将于 15 分钟后，或当我们有更多信息时。

UTC 时间 | 22:06 14:06 PT

我们的工程师将继续调查 Talk 连接问题报告，包括无法拨打、接听或转接电话。下次更新将于 30 分钟后，或当我们有更多信息时。

UTC 时间 | 22:32 14:32（太平洋时间）

我们正在继续调查导致无法拨打、接听或转接电话的 Talk 相关问题。下次更新于 1 小时后，或当我们有新信息可分享时。

UTC 时间 | 23:31 15:31（太平洋时间）

我们的工程师已回滚了一个更改，我们看到部分已恢复。我们将继续监测未来 24 小时内的性能，届时提供最新进展。

UTC | 3 月 6 日 - 10:59 02:59 太平洋时间

客户反馈和我们的内部监测均确认 Talk 功能已完全恢复并可正常运行。感谢您的耐心等待！此事务现已解决。

 

事后分析

根本原因分析

对于某些美国客户，此事件似乎是由本地 运营商问题引起的。

解决方案

要解决此问题，我们最初回滚了最近的 Talk 更改；然而，根据我们的调查，更准确的说法是存在一起 IIS 服务中断。

修复项目

1. 改进呼出电话失败的监测和警报。
2. 与我们的提供商合作调整警报阈值，以便我们在遇到类似情况时可以更快地收到通知。
3. 改进故障排除 Runbook，以更准确地评估范围。

 

如需更多信息

如需了解您 Zendesk 当前的系统状态信息，请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问， 请通过小组件中的 ZBot Messaging 向我们提交工单。

概要

在 2024 年 3 月 5 日 15:30 UTC 至 18:25 UTC 之间，使用社交消息传送渠道的所有 Pod 中的 Sunshine Conversations 客户可能会因为 Meta 的服务中断而遇到严重的服务中断。此次中断主要影响了 WhatsApp，对 Facebook Messenger 和 Instagram 也产生了重大影响，导致通过这些渠道的出站流量部分中断。

时间线

16:30 UTC | 08:30 太平洋时间
我们已确认一个问题，影响到所有由 Meta 提供技术支持的社交消息传送渠道，包括 Facebook、Messenger、WhatsApp 和 Instagram。当我们的合作伙伴解决了此问题后，我们将再次提供最新进展。

17:51 UTC | 09:51 太平洋时间
影响由 Meta 提供技术支持的所有社交消息传送渠道使用的问题已开始逐步解决。我们将继续与提供商合作伙伴合作并监测情况，直至完全解决。

19:15 UTC | 11:15 PT
我们很高兴地报告，在所有由 Meta 提供技术支持的社交消息传送渠道中，导致收到和发出消息延迟的问题都已解决，这些渠道目前正在如期处理消息。感谢您的耐心等待，我们正在与提供商合作伙伴联系。

 

事后分析

根本原因分析

此事件是由 Meta 服务的问题引起的，具体涉及到 WhatsApp Cloud API。Meta 没有透露确切的根本原因，但他们承认出现了中断，并正在努力恢复服务。在此期间，Sunshine Conversations 的监测系统在尝试通过受影响的渠道发送消息时大量检测到错误。

解决方案

中断的解决完全取决于 Meta 的恢复工作。Sunshine Conversations 密切关注事态发展，并及时向客户提供最新进展。在 Meta 宣布服务已恢复后，Sunshine Conversations 已验证出站流量是否已恢复到正常水平，以及消息是否已通过社交消息传送渠道成功送达。

修复项目

1. 改进对出站流量运行状况的监测。
2. 审查并更新事务响应计划，添加 Meta 的替代沟通渠道，以防主要支持门户不可用。

 

如需更多信息

如需了解您 Zendesk 当前的系统状态信息，请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问， 请通过小组件中的 ZBot Messaging 向我们提交工单。

概要

事后分析

根本原因分析

此事件是由一个转义缺陷引起的，即事件处理服务在尝试解析元数据中带有空值的 Webhook 事件时生成了错误。

解决方案

为了解决此问题，代码逻辑已更新，可以接受元数据对象中的空值。  我们继续监测事态发展，并在日志中确认，在此更改后，Pod 26 已不再出错。

修复项目

1. 更新 Sunshine Conversation 公开文档，使其接受元数据对象中的空值[已计划]
2. 针对此类错误添加其他监测警报[已完成]

如需更多信息

如需了解您 Zendesk 当前的系统状态信息，请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问， 请通过小组件中的 ZBot Messaging 向我们提交工单。

概要

2023 年 11 月 28 日 13:14 UTC 至 17:14 UTC 之间，使用多个 Pod 的 Zendesk Talk 客户遇到 Talk/电话图标缺失的问题，且部分客户发现 Explore 报告显示大量未接来电。 

时间线

事后分析

根本原因分析

此事件是由一个软件修复程序引起的，该修复程序包含一个在测试过程中不可见的转义缺陷。  此修复涉及一个在语音活动加载期间并不总是可用的变量，导致加载崩溃，以及在专员已安装第三方应用的场景中，通话图标不显示。

解决方案

为解决此问题，我们回滚到了以前的软件版本，并确认了恢复。

修复项目

1. 添加测试场景以检查存在第三方应用时的通话图标加载情况。 [已计划]
2. 添加语音活动失败时的监测和警报。 [已计划]

如需更多信息

如需了解您 Zendesk 当前的系统状态信息，请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问， 请通过小组件中的 ZBot Messaging 向我们提交工单。

概要

2023 年 11 月 16 日 18:02 UTC 至 20:00 UTC，Pod 13、17、19、23、28 和 29 中的一些 Support 客户在接收入站电邮时遇到了延迟或完全停止。从发送电邮到通过 Google 托管服务在 Zendesk 中创建工单，延迟时间为 15 到 60 分钟不等。

时间线

18:53 UTC | 10:53 PT
我们正在调查 Pod 28 和 29 上未为客户处理入站电邮的报告。我们将很快提供更多信息。

18:57 UTC | 10:57（太平洋时间）
我们已确认一个导致 Pod 13、19、23、28 和 29 上的客户入站电邮处理延迟的问题。我们的团队正在调查此事。如有最新进展，我们将第一时间提供。

19:33 UTC | 11:33（太平洋时间）
我们的团队正在继续调查导致 Pod 13、17、19、23、28 和 29 入站电邮处理延迟的问题。我们正在努力减轻影响，并确保尽快共享新信息。

19:54 UTC | 11:54（太平洋时间）
我们开始看到导致 Pod 13、17、19、23、28 和 29 入站电邮处理延迟的问题有所改善。我们的团队将继续进行监测，以确保其完全恢复。 

21:14 UTC | 13:14 PT
我们已为 Pod 13、17、19、23、28 和 29 的客户解决入站电邮延迟的问题，目前正在如预期处理入站电邮。感谢您耐心等待我们的调查。

 

事后分析

根本原因分析

引发此事件的原因是邮件提取服务与 Gmail 出现连接问题，导致 Support 中的入站邮件处理中断。其中，Gmail 的 302 已移动 响应被活跃度探索解读为失败，向容器协调器表明 Pod 运行状况不佳。这导致协调器替换了 Pod，并停止了关联容器中的邮件处理，从而导致了入站邮件延迟或中断。

解决方案

为了解决此问题，我们在 Gmail 停止阻止这些运行状况检查后恢复了入站邮件流量，以便 Support 入站电邮完成 Pod 创建并重新开始处理邮件。不久之后，入站邮件队列的速度加快了，流量开始正常流动。

修复项目

1. 改进现有的电邮运行状况检查实施工具。 
2. 创建更多警报。 
3. 在特定的应用程序中添加更正代码行。

 

如需更多信息

如需了解您 Zendesk 当前的系统状态信息，请查看我们的 系统状态页面。我们的事后调查概要通常会在事件结束几天后发布在这里。如果您对此事件有其他疑问， 请通过小组件中的 ZBot Messaging 向我们提交工单。

Hey shelley,

I suspect that this could be achieved using a custom attribute to filter out tickets with singular engagements. 

Hello Oanh Chau, 

You should be able to make a report like this in the Support: Tickets Dataset. The screenshot below is a bare bones idea of what metrics and attributes you would need to use: 

The Test Tag Inclusion metric I have here uses the following formula to display only solved tickets with the tags you specify: 

IF (([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")) 
AND (INCLUDES_ANY([Ticket tags], "your_tag_here"))
THEN [Ticket ID]
ENDIF

You would need to make two custom metrics for your Large and Super Large tags, so they will show as separate columns in your report. 

Hey Bobby Koch, 

The backlog snapshots occur at midnight daily. To view the most current totals for outstanding tickets, we recommend using the Tickets dataset. 

Hey Joel Sandi, 

To answer your first question, you should be able to report on ticket information with an Explore Report using the Guide: Knowledge Capture dataset. There is a set of attributes categorized as "ticket" that allow you to look closer at ticket data from the Knowledge Capture App. 

As for your second question, the articles linked per ticket metric, as well as all the metrics under the "Knowledge Capture" Dashboard tab, are meant to gauge performance metrics of the Knowledge Capture application, primarily. From a business value perspective, the articles linked per ticket metric could show pain points for your staff in your Knowledge Base. I would assume that ideally, you would want this number to be as close to 1 as possible (1 article for each ticket). 

Hey Jacqui, 

Are you using bookmarks to capture the desired time range in this dashboard?