Administración de incidentes, parte 4: Análisis e informes de incidentes posteriores a la resolución

Esta es la cuarta parte de la descripción general de la administración de incidentes en Zendesk. Esta guía contiene las siguientes partes:

• 1^ra parte: Cómo los problemas de servicio de Zendesk se convierten en incidentes de servicio
• 2^da parte: Cómo administra Zendesk los incidentes de servicio
• 3^ra parte: Monitorear un incidente de servicio público de Zendesk
• 4ta parte: Análisis e informes de incidentes posteriores a la resolución (este artículo)

En la cuarta parte de este artículo, aprenderá cómoel equipo de respuesta a incidentes realiza una retrospectiva que incluye el análisis de la causa raíz y la corrección de los incidentes de servicio y luego asigna los elementos de corrección a los equipos de ingeniería que tienen la propiedad.

Al realizar estas actividades, el equipo de atención al cliente de Zendesk puede compartir los detalles del incidente y los próximos pasos con los clientes afectados.

Este artículo contiene las siguientes secciones:

• Realizar una retrospectiva de incidentes de servicio
• Asignación de elementos de remediación
• Cerrar un incidente de servicio

Realizar una retrospectiva de incidentes de servicio

Zendesk lleva a cabo un ejercicio de reflexión con todos los miembros del equipo involucrados en el incidente para examinar y documentar las causas del incidente, el impacto del incidente en los clientes y las medidas tomadas para mitigarlo o resolverlo.  El equipo revisa las causas raíz identificadas y las acciones de seguimiento que evitarán que el incidente vuelva a ocurrir. Esto se conoce como retrospectiva interna de incidentes de servicio. Las retrospectivas de incidentes se comparten públicamente solo para los incidentes de alta gravedad. 

Para garantizar la transparencia y la inclusión de todos los equipos de Zendesk, hay un calendario retrospectivo interno de Zendesk disponible para que puedan asistir a la reunión retrospectiva interna y obtener más información sobre los incidentes de servicio y las causas raíz.  Los resultados de los incidentes se comparten con todos los equipos de ingeniería y los resultados significativos de los incidentes se destacan y revisan en la reunión semanal de ingeniería de Zendesk.

Hay cuatro actividades principales que se realizan en una retrospectiva de incidentes de servicio:

1. Revise los detalles del incidente contenidos en el documento del incidente para orientar y orientar a los participantes sobre el incidente
2. Revisar y validar los hallazgos del análisis de causa raíz contenidos en el documento del incidente
3. Identifique y clasifique cualquier trabajo de remediación necesario para que los equipos de ingeniería de Zendesk aborden por completo las causas fundamentales que conducen al incidente de servicio. Todos los elementos de corrección se acuerdan con el consenso de los asistentes retrospectivos
4. Asigne el trabajo de remediación a los equipos de ingeniería apropiados con SLA claros y apropiados definidos.

Análisis de incidentes de alta gravedad

Una vez que se resuelve un incidente de gravedad alta, el administrador de incidentes programa una reunión retrospectiva que incluye:

• Todos los integrantes del equipo que participaron en la respuesta al incidente
• Ingenieros de equipos cuyos productos o servicios se vieron afectados por el incidente
• Equipos que tienen la propiedad o un interés invertido como:
• Atención al cliente de Zendesk
• Equipos de productos
• Líderes que son dueños de los productos, servicios y áreas de soporte afectados 

Se hace todo lo posible para celebrar la reunión retrospectiva del incidente dentro de las 72 horas posteriores a la resolución del incidente, entendiendo que el momento de la reunión dependerá de la complejidad de la causa raíz y la disponibilidad de los integrantes del equipo en todas las regiones geográficas. 

Después de programar la retrospectiva del incidente, el responsable de ingeniería documenta el análisis de la causa raíz y crea el documento del incidente en función de las siguientes categorías:

• Información general del incidente
• Impacto en el cliente
• Descripción técnica
• Información sobre la causa raíz y el servicio
• Detalles y tiempos del incidente
• Remediaciones

El documento del incidente guía la retrospectiva del incidente y captura cualquier trabajo de corrección que se identifique para resolver por completo los problemas subyacentes que causaron el incidente. 

Hay una fase de análisis adicional que se lleva a cabo para los incidentes de gravedad 0-3 conocida como análisis de causa raíz. Este análisis le da al equipo de ingeniería la oportunidad de comprender y documentar el incidente y definir el trabajo necesario para solucionar los problemas por completo. Esta información se captura en el documento del incidente.

Proceso de análisis de causa raíz de incidentes de Zendesk

Análisis de incidentes de baja gravedad

Los incidentes de gravedad baja pasan por una fase de causa raíz y de informes más eficiente que los incidentes de gravedad alta. Si bien no se completa una reunión retrospectiva formal de incidentes (a menos que lo solicite el dueño de ingeniería del producto) para los incidentes de gravedad baja, el dueño de ingeniería del producto crea un documento de incidente.  

Las causas raíz se identifican, clasifican y comparten con los equipos de ingeniería, y los elementos de remediación se agregan al backlog del equipo de ingeniería de productos con los SLA.  Al igual que con los incidentes de mayor gravedad, Zendesk busca aprender y mejorar nuestros procesos de ingeniería como resultado de la investigación exhaustiva de los incidentes de baja gravedad.

Dado que los incidentes de gravedad 3 tienen un impacto menor en los clientes, el estado del problema y las correcciones identificadas se comparten con los clientes afectados que se comunicaron sobre el incidente a través de Atención al cliente de Zendesk a través de un ticket de Zendesk. 

Los incidentes de gravedad 4, por definición, no tienen un impacto directo en el cliente. El análisis posterior al incidente no se comunica a los clientes, pero las causas fundamentales se identifican y las soluciones se abordan internamente usando los procesos y procedimientos descritos anteriormente.

Asignación de elementos de remediación

Para asegurarse de que se completen los elementos de remediación, el equipo de ingeniería de productos revisa los elementos de remediación validados en la retrospectiva y realiza las siguientes acciones:

1. Clasifique las remediaciones en Preventivas o Generales:
   

• Los elementos preventivos son aquellos que evitarían activamente que el incidente vuelva a ocurrir
• Los elementos generales no son solo preventivos por sí solos, sino que resolverían una parte fundamental de las circunstancias del incidente
• Priorizar las correcciones para establecer los SLA de respuesta. Este ejercicio incluye las siguientes actividades:

• Identificar los equipos de ingeniería responsables de trabajar en el elemento de remediación
• Vincular el elemento de remediación a la causa raíz identificada que aborda
• Agregar el elemento de corrección al trabajo en proceso del equipo de ingeniería responsable
• Agregue el elemento de remediación al informe de SLA de ingeniería para hacer seguimiento del cumplimiento de SLA

A continuación se muestra un gráfico que los equipos de ingeniería de productos usan para determinar cuándo se prioriza y planifica una remediación para su esfuerzo de trabajo.

SLA de prioridad de elementos de corrección de Zendesk

El equipo de atención al cliente de Zendesk que asiste a la retrospectiva crea las descripciones del incidente, las causas raíz y las soluciones identificadas para los clientes. Esto se publica en el artículo del Centro de ayuda asociado con el incidente.

Ejemplo de incidente de disponibilidad de servicio (continuación)

Así es como se realizó una retrospectiva de este incidente.

4 días hábiles después de ocurrido el incidente, el equipo de respuesta a incidentes y los ingenieros se reunieron para revisar el incidente, colaborar en las causas raíz y crear o actualizar los elementos de remediación. Todos los elementos de corrección se acuerdan por consenso de los asistentes a la reunión. 

Cada persona involucrada en el incidente desempeñó un rol en la retrospectiva del incidente:

Los detalles revisados y discutidos en la reunión incluyeron:

Área	Ejemplo
Cronograma	20:02 UTC - Nuevas versiones de contenedores implementadas en servicios de host con certificados actualizados 20:08 UTC - Comienzan a aparecer advertencias de conectividad del contenedor 20:37 UTC: primera evidencia de que los servicios no pueden conectarse a los nuevos contenedores, lo que provoca demoras o interrupciones del servicio 20:57 UTC - El servicio interno de Zendesk deja de procesar las solicitudes, lo que provoca errores de tiempo de espera en las aplicaciones de Support, Guide y Talk alojadas en el pod 17 21:02 UTC - El escalador automático del clúster comienza a crear nuevos contenedores para los servicios a los que no se puede acceder 21:07 UTC: se completa el aprovisionamiento completo de los contenedores de servicio que funcionarán con las configuraciones de servicio existentes 21:49 UTC - Se completó la limpieza de los contenedores inalcanzables 22:07 UTC - Incidente resuelto por completo
Causas raíz	Después de cambiar el servicio de certificados de seguridad, no todos los contenedores se reconstruyeron para recoger los cambios codificados en el script.  Los contenedores que no se volvieron a desplegar no hacían referencia al proveedor de certificados de seguridad correcto y no eran de confianza para otros servicios y contenedores de Zendesk
Factores que influyen	No actualizamos los scripts de implementación para hacer referencia correctamente al nuevo proveedor de certificados de seguridad al crear nuevos contenedores Desplegó los nuevos contenedores demasiado rápido y de manera demasiado amplia para poder hacer ajustes después de que comenzaron a ocurrir fallas Sin capacidad de reversión automatizada
Remediaciones	Cambiar cómo se evalúa el cumplimiento de los certificados de seguridad cuando se crean e implementan nuevos contenedores Agregar un método diferente y más sólido para verificar los certificados antes de lanzar nuevas instancias Documentar la estrategia de despliegue para la infraestructura de escala horizontal Activar la reversión automática de las implementaciones si se produce alguna alerta Investigar cómo la ingeniería de plataformas puede reconstruir sus componentes de infraestructura con más frecuencia Descubra cómo se puede hacer que la infraestructura crítica sea más distribuida y tolerante a fallas

Para que haya un análisis exhaustivo que genere acciones concretas para el equipo de ingeniería, todos los miembros del equipo proporcionaron información para contar el incidente y desarrollar tareas de remediación. Una vez que el equipo de respuesta a incidentes abordó todas las preguntas o los problemas, la retrospectiva del incidente se consideró completa.

Al final de la reunión de retrospectiva interna, se le preguntó a la líder de atención al cliente de Zendesk responsable de la retrospectiva de incidentes de cara al público si tenía alguna pregunta o si necesitaba información adicional del equipo para crear la documentación pública. No tenía más preguntas y agregó la información retrospectiva a continuación al artículo sobre incidentes de servicio público en la sección Notificaciones de servicio en nuestro centro de ayuda.

Información retrospectiva pública para el incidente de disponibilidad de servicio de la máquina virtual

Tres resultados importantes de esta retrospectiva de incidentes que han mejorado los productos y servicios de Zendesk fueron:

• Se identificaron las causas fundamentales del incidente y todos los equipos de productos de Zendesk las tendrán en cuenta en el desarrollo futuro.

• Las correcciones fueron identificadas y asignadas a equipos de ingeniería con SLA

• La retrospectiva pública fue publicada por Atención al cliente de Zendesk en el Centro de ayuda y fue enviada a los clientes afectados que enviaron tickets 

Cerrar un incidente de servicio

Como mejor práctica, Zendesk cierra los tickets abiertos con los clientes para asegurarse de que todo esté debidamente documentado y comunicado para el incidente.

Todos los incidentes de servicio completados se resumen en un informe semanal de resumen de incidentes de servicio que se comparte ampliamente en Zendesk. Las descripciones de los incidentes, el impacto en los clientes y las correcciones importantes se incluyen en este informe y también en un informe de revisión de operaciones quincenal que se comparte con el equipo ejecutivo de Zendesk.

Una vez que la información de la retrospectiva se publica en el Centro de ayuda y los tickets abiertos se actualizan con los resultados de la retrospectiva, la fase de análisis y generación de informes para el incidente de servicio se considera completada. Atención al cliente de Zendesk vincula esos tickets con el incidente de servicio y se marcan como cerrados. 

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.