RESUMEN
En junio de 2024, en particular los días 13 y 25 y algunos días de julio, surgieron varios problemas en el espacio de trabajo de agente de Zendesk Support. Estos incidentes interrumpieron los flujos de trabajo de los agentes y les dificultaron el acceso a los tickets. Los principales problemas que encontraron incluyeron un error "Mensajes no encontrados" y un código de error "A_xxx" al intentar cargar tickets. Estos problemas ocurrieron principalmente en varios pods en varios días. Cada pico de interrupción solía durar un promedio de 2 minutos. Si bien los clientes podían intentar actualizar el sistema como una solución alternativa, corrían el riesgo de perder las conversaciones en curso en el proceso.
Cronograma
25 de junio de 2024 04:05 p.m. UTC | 25 de junio de 2024 09:05 a.m. PT
Estamos al tanto de un aumento de errores que afectó a los clientes en varios pods entre las 15:40 y las 15:47 UTC del 25 de junio de 2024, lo que resultó en respuestas de "Mensajes no encontrados" y mensajes de "Código de error A_xxx" al intentar cargar tickets en Soporte. Nos hemos recuperado de estos errores y el problema debería resolverse volviendo a cargar el navegador y/o borrando la memoria caché y las cookies.
POST-MORTEM
Análisis de causa raíz
La causa principal de estos incidentes fue un aumento inesperado de las solicitudes HTTP al servidor, a menudo en las horas de mayor tráfico. Este aumento provocó un efecto de "rebaño atronador" que desbordó las conexiones del servidor de Agent Graph, lo que provocó que fallaran los sondeos de preparación. Se identificó que Lotus, un componente vital del sistema, desempeñaba un papel importante. Sobrecargó el Administrador de datos de tickets (TDM) con varias solicitudes cada vez que se reconectaba. Este aumento en el tráfico se atribuye principalmente a las suscripciones de estado de conversación que se vuelven a conectar después de desconexiones masivas aparentemente debido a Zorg/Nginx o despliegues de servicios de suscripción.
El TDM es el principal responsable de administrar los datos de los tickets. Organiza y almacena la información cuando se genera un ticket y luego recupera y presenta estos datos cuando un agente o un cliente necesita acceder a ellos, y actúa como el controlador principal de todos los datos relacionados con los tickets, lo que garantiza un funcionamiento impecable dentro del sistema.
Resolución
Se implementaron medidas preventivas en respuesta a estos problemas. Estos incluían el limitador de velocidad de conexión y solicitud, responsable de regular el tráfico entrante. Al mismo tiempo, se tomaron medidas para mejorar la resiliencia de Agent Graph durante las fallas de almacenamiento en caché. Esta estrategia sirvió para evitar interrupciones en todo el sistema por fallas técnicas inevitables, actuando como un generador de respaldo durante un corte de energía. Si bien se implementaron numerosas mitigaciones, la corrección real que concluyó que el incidente del servicio fue un cambio realizado en Lotus. El cambio redujo el número de escenarios en los que se volverían a obtener los datos y luego se pondría fin al efecto de rebaño atronador.
Editado el 25 de julio: Después de hacer algunos ajustes el 10 de julio para evitar que una acumulación de solicitudes causara problemas, no vimos más picos que afectaran la interfaz de usuario del ticket. Seguimos vigilando de cerca las cosas y nos sentimos satisfechos de ver que todo iba bien en los días siguientes.
Además, durante el mes anterior, habíamos notado algunas caídas de rendimiento en pods específicos los viernes; sin embargo, las cosas estaban mejorando el 12 de julio, lo que nos dio más confianza en nuestros cambios. Después de eso, el 15 de julio, no encontramos aumentos ni picos en el rendimiento, lo que nos hace creer que el problema se había resuelto.
Elementos de corrección
Se han planificado estrategias adicionales para mejorar aún más la estabilidad del sistema y evitar futuras interrupciones:
- Alerta de errores de sondeo de preparación: Implemente una prueba de humo para alertar al equipo técnico de inmediato sobre cualquier problema potencial, lo que permite una acción rápida.
- Consideración de los patrones de obtención: Aconseje a los desarrolladores de software que consideren cuidadosamente el volumen y la frecuencia de la recuperación de información para evitar desequilibrios en el sistema.
- Establecimiento de una línea base de solicitudes: Determinar la capacidad del sistema para atender solicitudes simultáneas de información de tickets para evitar fallas en el sistema.
- Espaciar las recapturas: Introducir un jitter para mitigar los efectos de rebaño atronadores.
- Explore más Graceful Subscription Retention: Investigue maneras de mantener las suscripciones de manera más eficaz durante los despliegues.
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, comuníquese con Atención al cliente de Zendesk.
Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.
Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.