RESUMEN
Desde el 9 de febrero de 2024 a las 20:32 UTC hasta el 9 de febrero de 2024 a las 22:29 UTC, los clientes de Support en el pod 13 experimentaron un problema que provocó que algunos tickets no mostraran las insignias de SLA.
POST-MORTEM
Análisis de causa raíz
Durante este incidente, uno de los dieciséis pods de Kubernetes en el pod 13 tuvo un reinicio no planificado y no funcionó correctamente. El mensaje de error indicaba problemas con la "autoridad de cadena de conexión", lo que interrumpía el host "redis", una dependencia crítica para nuestro Metric Event Service (MES). Esta interrupción provocó complicaciones en el procesamiento de los eventos de los tickets, lo que provocó que los eventos del Acuerdo de nivel de servicio (SLA) no estuvieran presentes o se retrasaran. Sospechamos que el kpod se reinició inadvertidamente debido a un despliegue o un cambio de configuración. Cuando ocurrió el problema, nuestro objetivo inmediato era arreglar el servicio principal, lo que requería un reinicio rápido del sistema. Este proceso no nos dio tiempo para registrar los detalles de la unidad del sistema que funciona mal de inmediato. Sin embargo, más tarde logramos reproducir el error en un entorno de prueba seguro introduciendo deliberadamente una falla, lo que nos ayudó a comprender mejor el problema.
Resolución
Una vez que se identificó el problema, se volvió a implementar el kpod, lo que resolvió el problema. Los eventos de SLA que faltaban se rellenaban.
Tenga en cuenta queel reabastecimiento/restauración de los datos que se ejecutó para resolver los SLA incumplidos en los tickets abiertos tuvo el efecto secundario de eliminar por completo los datos de SLA en los tickets cerrados, lo que da como resultado datos de SLA "Nulos" en Explore.
Elementos de corrección
- Explore mejores maneras de organizar y pasar las variables de entorno para garantizar la disponibilidad cada vez que se reinician las unidades del sistema
- Mejore el tiempo de respuesta para corregir los contratos de nivel de servicio (SLA) incumplidos actualizando nuestro "funfiller"
- Revisar el monitoreo y las alertas
- Volver a investigar el método para pasar variables de entorno para garantizar su disponibilidad cada vez que se reinician las unidades del sistema
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.
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.