Justin H

RESUMEN

El 5 de marzo de 2024 desde las 19:50 UTC hasta las 22:06 UTC, algunos clientes de Talk podrían haber experimentado problemas de conectividad, como la imposibilidad de hacer, recibir o transferir llamadas. 

 

Cronograma

21:36 UTC | 13:36 PT

Estamos investigando informes de problemas de conectividad de Talk, incluida la imposibilidad de hacer, recibir o transferir llamadas. Próxima actualización en 15 minutos o cuando tengamos más información.

22:06 UTC | 14:06 PT

Nuestros ingenieros continúan investigando los informes de problemas de conectividad de Talk, incluida la imposibilidad de hacer, recibir o transferir llamadas. Próxima actualización en 30 minutos o cuando tengamos más información.

22:32 UTC | 14:32 PT

Nuestra investigación continúa sobre los problemas relacionados con Talk que resultaron en la imposibilidad de hacer, recibir o transferir llamadas. Próxima actualización en 1 hora o cuando tengamos nueva información para compartir.

23:31 UTC | 15:31 PT

Nuestros ingenieros han revertido un cambio y estamos viendo cierta recuperación de nuestra parte. Continuaremos monitoreando el rendimiento durante las próximas 24 horas y proporcionaremos una actualización en ese momento.

6 de marzo - 10:59 UTC | 02:59 PT

La funcionalidad de Talk se restableció por completo y se confirmó que funciona normalmente tanto por los comentarios de los clientes como por nuestro monitoreo interno. Agradecemos su paciencia durante este tiempo. Este incidente ya está resuelto.

 

POST-MORTEM

Análisis de causa raíz

Este incidente parece haber sido causado por un problema de ISP local para algunos clientes en los EE. UU.

Resolución

Para solucionar este problema, inicialmente revertimos un cambio reciente de Talk; sin embargo, nuestra investigación apunta a una interrupción del ISP que se alinea con mayor precisión con la ventana de impacto.

Elementos de corrección

1. Mejore el monitoreo y las alertas en caso de fallas en las llamadas salientes.
2. Trabaje con nuestro proveedor para ajustar los umbrales de alerta para que podamos recibir notificaciones más rápido en situaciones similares.
3. Mejorar los runbooks de resolución de problemas para evaluar el alcance con mayor precisión.

 

PARA MÁS INFORMACIÓN

Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, registre un ticket con nosotros a través de la mensajería de ZBot dentro del widget.

RESUMEN

El 5 de marzo de 2024 de 15:30 UTC a 18:25 UTC, los clientes de Sunshine Conversations en todos los pods que usan los canales de mensajería por redes sociales podrían haber experimentado una interrupción significativa en el servicio debido a una interrupción en Meta. Esta interrupción afectó principalmente a WhatsApp, con impactos considerables también en Facebook Messenger e Instagram, lo que provocó una interrupción parcial en el tráfico saliente a través de estos canales.

Cronograma

16:30 UTC | 08:30 PT
Hemos confirmado un problema que afecta a todos los canales de mensajería por redes sociales con tecnología Meta, incluidos Facebook, Messenger, WhatsApp e Instagram. Proporcionaremos otra actualización cuando nuestro proveedor asociado haya resuelto el comportamiento.

17:51 UTC | 09:51 PT
Estamos comenzando a ver una recuperación del problema que afecta el uso de todos los canales de mensajería por redes sociales con tecnología Meta. Continuaremos trabajando con nuestro proveedor asociado y monitorearemos la situación hasta que se resuelva por completo.

19:15 UTC | 11:15 PT
Nos complace informar que el problema que causaba retrasos en los mensajes entrantes y salientes en todos los canales de mensajería por redes sociales con tecnología Meta se ha resuelto, y estos canales están procesando los mensajes como se esperaba en este momento. Gracias por su paciencia mientras trabajábamos con nuestro proveedor asociado.

 

POST-MORTEM

Análisis de causa raíz

Este incidente fue causado por un problema con los servicios de Meta, que afectó específicamente a la API de WhatsApp Cloud. Meta no reveló la causa raíz exacta, pero reconoció la interrupción y trabajó para restaurar los servicios. Durante este tiempo, los sistemas de monitoreo de Sunshine Conversations detectaron una gran cantidad de errores al intentar enviar mensajes a través de los canales afectados.

Resolución

La resolución de la interrupción dependió completamente de los esfuerzos de recuperación de Meta. Sunshine Conversations supervisó la situación de cerca y proporcionó actualizaciones a los clientes a medida que estaban disponibles. Una vez que Meta anunció que los servicios habían sido restaurados, Sunshine Conversations verificó que el tráfico saliente volviera a los niveles normales y que los mensajes se estuvieran entregando correctamente a través de los canales de mensajería por redes sociales.

Elementos de corrección

1. Mejore el monitoreo del estado del tráfico saliente.
2. Revisar y actualizar el plan de respuesta a incidentes para incluir canales de comunicación alternativos con Meta en caso de que su portal de soporte principal no esté disponible.

 

PARA MÁS INFORMACIÓN

Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, registre un ticket con nosotros a través de la mensajería de ZBot dentro del widget.

RESUMEN

POST-MORTEM

Análisis de causa raíz

Este incidente fue causado por un defecto de escape, donde el servicio de procesamiento de eventos generó errores al intentar analizar los eventos de webhook con un valor nulo dentro de sus metadatos.

Resolución

Para solucionar este problema, se actualizó la lógica del código para que se aceptaran los valores nulos en los objetos de metadatos.  Continuamos monitoreando la situación y confirmamos en los registros que los errores en el pod 26 ya no ocurrían después de este cambio.

Elementos de corrección

1. Actualizar la documentación pública de Sunshine Conversation para aceptar valores nulos en los objetos de metadatos [Programado]
2. Adición de alertas de monitoreo adicionales para tales errores [Terminado]

PARA MÁS INFORMACIÓN

Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, registre un ticket con nosotros a través de la mensajería de ZBot dentro del widget.

RESUMEN

El 28 de noviembre de 2023, de 13:14 UTC a 17:14 UTC, los clientes de Zendesk Talk en varios pods experimentaron la desaparición del icono de Talk/teléfono, y algunos clientes vieron informes de Explore que mostraban un alto número de llamadas perdidas. 

Cronograma

POST-MORTEM

Análisis de causa raíz

Este incidente fue causado por una corrección de software que contenía un defecto escapado que no fue visible durante el proceso de prueba.  Esta corrección involucraba una variable que no siempre estaba disponible durante la carga de la actividad de voz, lo que hacía que la carga fallara y que el icono de llamada no apareciera en escenarios donde los agentes tenían aplicaciones de terceros instaladas.

Resolución

Para solucionar este problema, hicimos una reversión a la versión anterior del software y obtuvimos la confirmación de la recuperación.

Elementos de corrección

1. Agregar un escenario de prueba para verificar la carga del icono de llamada cuando hay aplicaciones de terceros presentes. [Programada]
2. Agregar monitores y alertas cuando falla la actividad de voz. [Programada]

PARA MÁS INFORMACIÓN

Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, registre un ticket con nosotros a través de la mensajería de ZBot dentro del widget.

RESUMEN

El 16 de noviembre de 2023, de 18:02 UTC a 20:00 UTC, algunos clientes de Support en los pods 13, 17, 19, 23, 28 y 29 sufrieron demoras o una interrupción total en la recepción de correo electrónico entrante. La duración de las demoras varió de 15 a 60 minutos entre el envío de correos electrónicos y la creación de tickets en Zendesk a través de los servicios administrados por Google.

Cronograma

18:53 UTC | 10:53 PT
Estamos investigando informes de correos electrónicos entrantes que no se procesan para los clientes de los pods 28 y 29. En breve proporcionaremos información adicional.

18:57 UTC | 10:57 PT
Hemos confirmado un problema que está causando retrasos en el procesamiento del correo electrónico entrante para los clientes en los pods 13, 19, 23, 28 y 29. Nuestro equipo está investigando y proporcionaremos más actualizaciones tan pronto como estén disponibles.

19:33 UTC | 11:33 PT
Nuestro equipo continúa investigando el problema que causa los retrasos en el procesamiento del correo electrónico entrante en los pods 13, 17, 19, 23, 28 y 29. Estamos trabajando diligentemente para mitigar el impacto, y nos aseguraremos de compartir nueva información tan pronto como podamos.

19:54 UTC | 11:54 PT
Estamos comenzando a ver una mejora en el problema que causa retrasos en el procesamiento del correo electrónico entrante en los pods 13, 17, 19, 23, 28 y 29. Nuestro equipo continuará monitoreando para garantizar una recuperación completa. 

21:14 UTC | 13:14 PT
Hemos resuelto el problema que causaba retrasos en el correo electrónico entrante para los clientes en los pods 13, 17, 19, 23, 28 y 29, y los correos electrónicos entrantes se están procesando como se esperaba en este momento. Gracias por su paciencia durante nuestra investigación.

 

POST-MORTEM

Análisis de causa raíz

Este incidente fue causado por problemas de conectividad del servicio Mail Fetcher con Gmail, lo que interrumpió el procesamiento del correo entrante en Support, donde las respuestas 302 Moved de Gmail fueron interpretadas como fallas por la sonda de actividad, lo que indica al organizador del contenedor que los pods no estaban en buen estado. Esto hizo que el orquestador reemplazara los pods y detuviera el procesamiento de correo en los contenedores asociados, lo que provocó demoras o interrupciones del correo entrante.

Resolución

Para solucionar este problema, el tráfico de correo entrante se restauró después de que Gmail dejó de bloquear esas verificaciones de estado, lo que permitió que el correo electrónico entrante de Support terminara de crear sus pods y comenzara a procesar el correo nuevamente. Poco después, las colas de correo entrante se pusieron al día y el tráfico comenzó a fluir normalmente.

Elementos de corrección

1. Mejorar las herramientas de implementación existentes para las verificaciones de estado del correo electrónico. 
2. Cree alertas adicionales. 
3. Agregue líneas de código de corrección en aplicaciones específicas.

 

PARA MÁS INFORMACIÓN

Si desea información sobre el estado actual del sistema de su cuenta de Zendesk, consulte nuestra página de estado del sistema. El resumen de la investigación post-mortem se suele publicar aquí unos días después de que finaliza el incidente. Si tiene más preguntas sobre este incidente, registre un ticket con nosotros a través de la mensajería de ZBot dentro del widget.

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?