Esta es la segunda parte de la Introducción a la administración de incidentes en Zendesk. Esta guía contiene las siguientes partes:
- 1ra parte: Cómo los problemas de servicio de Zendesk se convierten en incidentes de servicio
- 2da parte: Cómo Zendesk administra los incidentes de servicio (este artículo)
- 3ra parte: Monitorear un incidente de servicio público de Zendesk
- Parte 4: Análisis e informes de incidentes posteriores a la resolución
En la segunda parte de este artículo, comprenderá cómoCómo responden los equipos de Zendesk a los incidentes de servicio dentro de nuestros productos en función de los niveles de gravedad. Zendesk adopta un enfoque integral para comprender un incidente, desde la causa raíz hasta el impacto total en los clientes afectados, y comunica el nivel de detalle apropiado.
Este artículo contiene las siguientes secciones:
- Gravedad del incidente
- Estructura del equipo de respuesta a incidentes
- Plazos de comunicación para incidentes
- Proceso de incidente de gravedad baja
Gravedad del incidente
Una de las decisiones clave que se toman cuando se crea un incidente de servicio es asignar la gravedad del incidente. La gravedad de un incidente determina cómo y qué equipos de Zendesk abordan el problema y cómo se comunica a los clientes afectados.
Zendesk usa un sistema que agrupa los incidentes de servicio en 5 niveles de gravedad según las características del incidente:
Sistema de clasificación de gravedad de Zendesk
Se emplean diferentes rutas de derivación y equipos para investigar, comunicar y remediar el incidente en función del nivel de gravedad. Esto garantiza que se aplique el nivel correcto de rigor a cada incidente. El siguiente diagrama describe las actividades clave que ocurren durante y después de que se resuelve un incidente en función de su nivel de gravedad:
Proceso por nivel de gravedad
Si bien los incidentes de alta gravedad se someten a un análisis riguroso y a actividades de remediación, todos los incidentes, independientemente del nivel de gravedad, pasan por un proceso de respuesta e investigación en tiempo real. Eso produce:
- Actualizaciones a la página de estado de Zendesk cuando el incidente es público
- Análisis de causa raíz y remediación de incidentes
- Informe de incidentes (internos) de Zendesk
Ejemplo de incidente de disponibilidad del servicio de Zendesk
Este es un ejemplo de cómo Zendesk establece Incident Severity y cómo los equipos de Zendesk responden internamente:
Ejemplo de detección y respuesta de incidentes
En el ejemplo, se ve el siguiente flujo de trabajo:
- El Centro de operaciones de red de Zendesk (ZNOC) identificó un problema cuando las alertas del sistema mostraron que los nodos de servicio en el pod 17 no podían ser atendidos por solicitudes. El equipo de ingeniería de redes de Zendesk verificó que los problemas de acceso estaban afectando directamente a los servicios de atención al cliente y rápidamente se dio cuenta de que los servicios de Support, Guide y Talk para varios clientes no estaban funcionando como se esperaba. Se creó un nuevo incidente de servicio de Zendesk.
- Se sabía que este incidente afectaba a dos clientes cuando se creó inicialmente, pero debido a la naturaleza de la interrupción, más clientes estaban experimentando el problema y comenzaron a plantear sus problemas a Atención al cliente de Zendesk. El equipo de ingeniería asignó al incidente una calificación de gravedad de 1: un incidente de alta prioridad que requiere atención inmediata.
- El equipo de guardia de respuesta a incidentes fue llamado de inmediato. A los pocos minutos de la creación del incidente, un administrador de incidentes reunió información y reunió recursos de ingeniería adicionales para resolver el problema y corregir el incidente de servicio.
Estructura del equipo de respuesta a incidentes
Zendesk cuenta con un equipo global dedicado a la respuesta a incidentes que se encarga de garantizar que todos los incidentes pasen por el proceso de administración de incidentes de servicio y se escalen a los niveles apropiados de liderazgo de Zendesk, según corresponda.
Roles y responsabilidades de la administración de incidentes
Esta estructura de equipo permite que Zendesk realice un análisis exhaustivo del incidente con recursos técnicos y se comunique en tiempo real con los clientes a través de Atención al cliente de Zendesk.
Plazos de comunicación para incidentes
Zendesk se esfuerza por asegurarse de que los incidentes se comuniquen correctamente y se resuelvan en los plazos adecuados para el cliente. Hemos establecido plazos internos para la distribución de los detalles del incidente. El cronograma se basa en el nivel de gravedad del incidente y las etapas de administración de incidentes de servicio.
|
Fase |
Plazos de respuesta |
|
Anuncio público |
Dentro de los 15 minutos posteriores al incidente llamado |
|
Actualizaciones de incidentes |
Cada 30 minutos hasta que se restablezca el servicio o a medida que haya nueva información disponible |
|
Análisis de eventos (para incidentes de gravedad 0 y 1) |
Dentro de las 48 horas de la resolución del incidente |
|
Análisis de causa raíz |
Dentro de las 72 horas de la resolución del incidente |
|
Retrospectiva de incidentes públicos |
En un plazo de más de 96 horas desde la resolución del incidente |
Los incidentes que tienen una calificación de gravedad de 0 a 2 se consideran altos incidentes de gravedad. Cuando ocurre un incidente de alta gravedad, el equipo de respuesta a incidentes de guardia está disponible las 24 horas del día, los 7 días de la semana para responder a estos incidentes. El equipo consta de los siguientes roles:
Roles del equipo de respuesta a incidentes
Ubicaciones del equipo global de respuesta a incidentes
A medida que se llama al equipo de guardia, el diagnóstico del incidente comienza minutos después de que se declara el incidente. Se crea un canal de Slack y una llamada de Zoom para permitir la comunicación del equipo de respuesta en tiempo real. A medida que el equipo de respuesta a incidentes clasifica y analiza el alcance del incidente, los equipos de ingeniería de guardia reciben avisos según los productos y servicios afectados.
Una publicación pública en la página de estado de Zendesk se realiza dentro de los 15 minutos posteriores a la creación del incidente para mantener a los clientes informados sobre el incidente conocido. A partir de entonces, las actualizaciones se publican cada 30 minutos hasta que se resuelven a medida que hay nueva información disponible. Según el problema y la cantidad de información nueva que se identifique, esta cadencia puede reducirse o alargarse según sea necesario. Los clientes pueden monitorear los incidentes de servicio activos en la página Estado de Zendesk. Ese proceso se describe en parte 3 de esta guía.
Además de nuestros equipos de respuesta a incidentes de guardia en todo el mundo, Zendesk ha establecido procesos para notificar y derivar a los líderes. Si un incidente de gravedad alta cumple ciertos criterios, activamos el siguiente nivel de respuesta, que es la gestión de crisis.
Ejemplo de incidente de disponibilidad del servicio de Zendesk (continuación)
Continuando con el ejemplo del incidente de disponibilidad del servicio, este es el progreso de la respuesta al incidente a través del proceso de administración de incidentes en Zendesk:
Cronología de respuesta a incidentes de disponibilidad del servicio
Como se puede ver en el ejemplo, una vez que se creó el incidente en el Portal de incidentes de Zendesk, se tomaron una serie de acciones automatizadas:
- El equipo de guardia de respuesta a incidentes fue llamado para responder al incidente
- Se creó automáticamente un canal de Slack para incidentes y se agregó el equipo de guardia de Respuesta a incidentes al canal de Slack dedicado
- Se inició automáticamente una llamada de Zoom y se publicó en el canal de Slack para que todos los que respondieron pudieran unirse
- Se creó automáticamente un documento de resumen del evento para documentar el incidente y compartir el progreso internamente con Zendesk
En la llamada de Zoom, el administrador de incidentes validó la gravedad inicial y confirmó el alcance y el impacto del problema.
Rápidamente se determinó que varios nodos de contenedor en el pod 17 no eran accesibles y no podían ser utilizados por los servicios dependientes, incluidos los productos Support, Guide y Talk. Un tipo de nodo en particular no tenía réplicas disponibles en otros pods. Con el tiempo, estos productos dejarían de responder a varios clientes.
El ZNOC envió un mensaje al equipo de ingeniería de redes correspondiente a la llamada de Zoom para comenzar a investigar cómo resolver el problema inmediato de restaurar el servicio y el acceso a la API a los clientes. Las pymes de ingeniería perimetral también fueron contactadas y se unieron a la llamada. En 5 minutos, se identificó e implementó una solución para que los nodos afectados estuvieran nuevamente accesibles para las llamadas y los servicios de la API.
Atención al cliente de Zendesk creó un ticket de problema para hacer seguimiento de los informes de los clientes. Este ticket se agregó al canal de incidentes de Slack para permitir que se agreguen rápidamente nuevos informes a medida que van llegando.
Mientras continuaba la investigación, el administrador de derivación de incidentes creó y publicó la primera actualización pública en la página de estado de Zendesk 12 minutos después de la creación del incidente.
Primera publicación de incidente de disponibilidad de servicio en la página de estado del sistema de Zendesk
Mientras los equipos investigaban el incidente, los informes de los clientes que llegaban se vinculaban con el ticket de problema principal asociado con el incidente. Esto permitió que el equipo de respuesta a incidentes enviara actualizaciones a todos los clientes afectados cuando hacían notificaciones públicas.
El equipo de ingeniería de redes determinó que un cambio en la forma en que se generaban y usaban los certificados era responsable del incidente y tomó las siguientes medidas para restaurar el servicio a los clientes afectados:
- Nodos inaccesibles desactivados
- Se crearon nuevos nodos de servicio con certificados referenciados correctamente
- Verificó que los nuevos nodos de servicio fueran accesibles para los servicios y a través de llamadas a la API
- Supervisó el tráfico entrante para ver si las solicitudes entrantes se estaban manejando correctamente
A medida que avanzaba el incidente, se hicieron dos actualizaciones públicas más: Uno 14 minutos después de la creación del incidente y otro 63 minutos después de la creación del incidente. El historial de comunicaciones públicas junto con la información retrospectiva de incidentes publicados se puede encontrar en la página Notificaciones de servicio para el incidente.
Como se muestra en el ejemplo, los incidentes de alta gravedad pasan por un proceso riguroso en el que se determinan las causas raíz y se crean elementos de remediación para que los equipos de ingeniería de productos solucionen el problema subyacente que causó el incidente. Este análisis se lleva a cabo durante la retrospectiva de incidentes y se analiza con más detalle en la Sección Análisis de incidentes posteriores a la resolución.
Proceso de incidente de gravedad baja
Los incidentes de servicio de menor gravedad (nivel 3-4) son menos críticos porque afectan a un número menor de clientes y no impiden que esos clientes usen las funciones críticas para el negocio de los productos Zendesk. Estos incidentes se tratan de acuerdo con las pautas anteriores, pero no se publican en los canales públicos.
Los incidentes de gravedad 3 se manejan de la misma manera que los incidentes de gravedad 0-2. Los tiempos de respuesta esperados se amplían debido a la reducción del impacto comercial. Aunque el equipo de guardia no recibe avisos, estos incidentes se manejan a través de canales específicos de Slack para incidentes de Zendesk asociados con los equipos de ingeniería de productos de soporte, y los equipos tienden a responder tan rápido como los incidentes de mayor gravedad. La mayoría de los incidentes de gravedad 3 no usan canales de comunicación públicos. En cambio, los equipos de atención al cliente de Zendesk se comunican con los clientes mediante notificaciones proactivas si se requiere una acción específica de un subconjunto de clientes.
Los incidentes de gravedad 4 no afectan directamente el uso que los clientes hacen de los servicios de Zendesk, pero tienen el potencial de hacerlo si no se abordan. Estos incidentes se crean como respuestas proactivas a problemas potenciales. Los equipos de ingeniería de productos interactúan de la misma manera que lo hacen con el proceso de gravedad 3.
Más información
Con esto finaliza la Parte 2, Cómo Zendesk administra los incidentes de servicio, de la Información general sobre la administración de incidentes en Zendesk.
Si desea más información, puede pasar a la siguiente parte de esta guía: 3ra parte: Monitorear un incidente de servicio público 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.