Esta es la segunda parte de la Descripción general de 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 público de servicio de Zendesk
- Parte 4: Análisis e informes de incidentes posteriores a la resolución
En este artículo, segunda parte, obtendrá una comprensión de cómo los equipos de Zendesk responden 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 raíz hasta el impacto total en los clientes afectados— y comunica el nivel de detalle adecuado.
Este artículo contiene las siguientes secciones:
- Gravedad del incidente
- Estructura del equipo de respuesta a incidentes
- Calendarios de comunicación para incidentes
- Proceso de incidente de baja gravedad
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 utiliza un sistema que agrupa los incidentes de servicio en 5 niveles de gravedad según las características del incidente:
Sistema de calificación de gravedad de Zendesk
Diferentes rutas de derivación y equipos participan para investigar, comunicar y remediar el incidente en función del nivel de gravedad. Esto garantiza el nivel correcto de rigor en cada incidente. El diagrama a continuación describe las actividades clave que ocurren durante y después de que se borra 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 actividades de remediación, cada incidente —independientemente del nivel de gravedad— pasa por un proceso de respuesta e investigación en tiempo real. Eso produce:
- Actualiza a la página de estado cuando el incidente es público
- Análisis de la causa raíz y remedios de incidentes
- Informe de incidente (interno) de Zendesk
Ejemplo de incidente de disponibilidad de servicio de Zendesk
Este es un ejemplo de cómo Zendesk establece la gravedad de los incidentes 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 las solicitudes no podían contactar a los nodos de servicio en el Pod 17. El equipo de ingeniería de redes de Zendesk verificó que los problemas de acceso estaban afectando a los servicios de atención al cliente directamente y rápidamente se dio cuenta de que los servicios de soporte, 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 con soporte. 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 respuesta a incidentes de guardia fue localizado de inmediato. Pocos minutos después de la creación del incidente, un administrador de incidentes recopiló información y reunió recursos de ingeniería adicionales para resolver y corregir el incidente de servicio.
Estructura del equipo de respuesta a incidentes
Zendesk cuenta con un equipo de respuesta a incidentes exclusivo en todo el mundo para garantizar que todos los incidentes se canalicen a través del proceso de administración de incidentes de servicio y se deriven a los niveles apropiados de liderazgo de Zendesk, según se justifique.
Funciones 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 del soporte técnico.
Calendarios de comunicación para incidentes
Zendesk está comprometido en asegurarse de que los incidentes se comuniquen y resuelvan correctamente 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 del incidente de servicio.
| Fase | Tiempos de respuesta |
| Anuncio público | Dentro de los 15 minutos siguientes al incidente llamado |
| Actualizaciones de incidentes | Cada 30 minutos hasta que se restablezca el servicio o cuando haya nueva información disponible |
|
de análisis de eventos (para incidentes de gravedad 0 y 1) |
En las 48 horas siguientes a la resolución del incidente |
| Análisis de causa de fondo | Dentro de las 72 horas de la resolución del incidente |
| Retrospectiva pública de incidentes | Dentro de las 96+ horas de la resolución del incidente |
Los incidentes que tienen una calificación de gravedad de 0 a 2 se consideran incidentes de alta gravedad. Cuando ocurre un incidente de alta gravedad, el equipo global de respuesta a incidentes de guardia está disponible las 24 horas todos los días para responder a estos incidentes. El equipo consta de los siguientes roles:
Roles del equipo de respuesta a incidentes
Ubicaciones globales del equipo 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 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 incidente, se busca a los equipos de ingeniería de guardia en función de los productos y servicios afectados.
Una publicación pública en la página de estado de Zendesk se hace dentro de los 15 minutos posteriores a la creación del incidente para mantener informados a los clientes sobre el incidente conocido. A partir de entonces, las actualizaciones se publican cada 30 minutos hasta que se resuelvan a medida que haya nueva información disponible. Dependiendo del problema y de 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 de estado de Zendesk; ese proceso se describe en la parte 3 de esta guía.
Además de nuestros equipos globales de respuesta a incidentes de guardia, Zendesk ha establecido procesos para la notificación y derivación del liderazgo. Si un incidente de alta gravedad se ajusta a ciertos criterios, activamos el siguiente nivel de respuesta: Gestión de crisis.
Continuó el ejemplo de incidente de disponibilidad del servicio de Zendesk
Sigue usando el incidente de disponibilidad del servicio como ejemplo, así es como progresó 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 creado el incidente en el portal de incidentes de Zendesk, se realizaron una serie de acciones automatizadas:
- Se llamó al equipo de guardia de respuesta al incidente para responder al incidente
- Se creó automáticamente un canal de incidente Slack y se agregó el equipo de respuesta a incidentes al canal exclusivo de Slack
- Se inició automáticamente una llamada de Zoom y se publicó en el canal de Slack para que todos los equipos de respuesta se unieran
- 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 contenedores en el pod 17 no eran accesibles y no podían ser utilizados por servicios dependientes como soporte, Guide y Talk. Un tipo de nodo en particular no tenía réplicas disponibles en otros pods. Esto eventualmente haría que estos productos dejaran de responder a varios clientes.
La ZNOC envió 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 para los clientes. Las pequeñas y medianas empresas de ingeniería Edge también fueron buscadas y se unieron a la llamada. En 5 minutos, se identificó y desplegó una corrección para que los nodos afectados pudieran acceder de nuevo a las llamadas y los servicios de la API.
Soporte 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 incidente Slack para poder agregar rápidamente nuevos informes a medida que iban llegando.
Mientras la investigación continuaba, el administrador de derivación de incidentes creó y publicó la primera actualización pública de 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 estaban vinculados al 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 hicieron notificaciones públicas.
El equipo de ingeniería de redes determinó un cambio en la manera en que se generaron y usaron los certificados como responsables 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 debidamente referenciados
- Verificó que los nuevos nodos de servicio estuvieran accesibles para los servicios y a través de llamadas API
- Monitoreó el tráfico entrante para ver que las solicitudes entrantes ahora 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 comunicación pública junto con la información retrospectiva publicada sobre el incidente se encuentra en la página Notificaciones del servicio.
Como se muestra en el ejemplo, los incidentes de alta gravedad pasan por un proceso riguroso donde se determinan las causas raíz y se crean elementos de remediación para que los equipos de ingeniería de productos corrijan el problema subyacente que causó el incidente. Este análisis ocurre durante la retrospectiva del incidente y se describe con más detalle en la sección Análisis post resolución.
Proceso de incidente de baja gravedad
Los incidentes de servicio de menor gravedad (nivel 3-4) son menos críticos porque afectan a un número más pequeño de clientes y no impiden que esos clientes usen las funciones críticas del negocio de los productos Zendesk. Estos incidentes se abordan 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 prolongan debido al menor impacto empresarial. Aunque el equipo de guardia no recibe una página, estos incidentes se manejan a través de canales específicos de Slack asociados con los equipos de ingeniería de productos de soporte, y los equipos tienden a responder con la misma rapidez que los incidentes de mayor gravedad. La mayoría de los incidentes de gravedad 3 no usan canales de comunicación públicos. En su lugar, los equipos de soporte Reach utilizan notificaciones proactivas si es necesario que un subconjunto de clientes haga algo específico.
Los incidentes de gravedad 4 no afectan directamente el uso de los servicios de Zendesk por parte de los clientes, pero pueden hacerlo si no se atienden. 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
Esto completa la 2da parte, Cómo Zendesk administra los incidentes de servicio, de la Descripción general de 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.