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:
- 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
- 3ra parte: Monitorear un incidente público de servicio de Zendesk
- 4ta parte: Análisis e informes de incidentes posteriores a la resolución (este artículo)
En este artículo, 4ta parte, aprenderá cómo el equipo de respuesta a incidentes realiza una retrospectiva que incluye el análisis de la causa raíz y la remediación de incidentes de servicio y luego asigna elementos de remediación a los equipos de ingeniería que tienen la propiedad.
Al realizar estas actividades, el soporte puede compartir los detalles del incidente y los próximos pasos con los clientes afectados.
Este artículo contiene las siguientes secciones:
- Realización de una retrospectiva de incidentes de servicio
- Asignar elementos de corrección
- Cerrar un incidente de servicio
Realización de una retrospectiva de incidentes de servicio
Zendesk realiza un ejercicio de reflexión con todos los integrantes del equipo involucrados en el incidente para examinar y documentar las causas del incidente, el impacto del incidente en los clientes y las acciones tomadas para mitigarlo o resolverlo. El equipo revisa las causas de fondo identificadas y las acciones de seguimiento que evitarán que el incidente vuelva a ocurrir. A esto se le conoce como una retrospectiva interna del incidente de servicio. Las retrospectivas de incidentes se comparten públicamente solo para 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 fundamentales. Los resultados de los incidentes se comparten con todos los equipos de ingeniería y los resultados significativos de los incidentes se resaltan y revisan en la reunión semanal de ingeniería de Zendesk.
Hay cuatro actividades principales que se realizan en una retrospectiva de incidente de servicio:
- Revise los detalles del incidente contenidos en el documento del incidente para anclar y orientar a los participantes hacia el incidente
- Revise y valide las conclusiones del análisis de la causa raíz contenidas en el documento del incidente
- Identifique y clasifique cualquier trabajo de reparación que necesiten los equipos de ingeniería de Zendesk para abordar completamente las causas de fondo que conducen al incidente de servicio. Todos los temas de corrección son acordados por consenso por los asistentes a la retrospectiva
- Asigne trabajo de remediación a los equipos de ingeniería correspondientes con SLA claros y apropiados definidos.
Análisis de incidentes de alta gravedad
Una vez resuelto un incidente de alta gravedad, 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 propiedad o intereses invertidos como:
- Atención al cliente de Zendesk
- Equipos de productos
- Líderes que poseen productos, servicios y áreas de Support afectados
Se hace todo lo posible por celebrar la reunión retrospectiva del incidente dentro de las 72 horas siguientes a su resolución, en el entendimiento de que la fecha de la reunión dependerá de la complejidad de la causa fundamental y de la disponibilidad de integrantes del equipo en todas las regiones geográficas.
Después de programar la retrospectiva del incidente, el dueño de la 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:
- Incidente: información general
- Impacto en el cliente
- Descripción técnica
- Causa de fondo e información de servicio
- Detalles y tiempos del incidente
- Remediaciones
El documento del incidente guía la retroactividad del incidente y captura cualquier trabajo de corrección que se identifique para resolver completamente los problemas subyacentes que causaron el incidente.
Hay una fase de análisis adicional para 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 completamente los problemas. Esta información se captura en el documento del incidente.
Proceso de análisis de la causa raíz del incidente de Zendesk
Análisis de incidentes de baja gravedad
Los incidentes de baja gravedad pasan por una causa de fondo y una fase de informes más leves que los incidentes de alta gravedad. Si bien no se completa una reunión retrospectiva formal de incidentes (a menos que el dueño de la ingeniería de productos lo solicite) para incidentes de baja gravedad, el dueño de la ingeniería de productos crea un documento de incidente.
Las causas de fondo se identifican, clasifican y comparten con los equipos de ingeniería, y los elementos de corrección se agregan a los tickets en proceso 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 investigar a fondo los incidentes de baja gravedad.
Puesto que los incidentes de gravedad 3 tienen un impacto menor en los clientes, el estado del problema y las soluciones identificadas se comparten con los clientes afectados que se comunicaron con el incidente a través del soporte técnico 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 se identifican las causas de fondo y las soluciones se abordan internamente usando los procesos y procedimientos descritos anteriormente.
Asignar elementos de corrección
Para asegurarse de que los elementos de corrección estén completos, el equipo de ingeniería de productos revisa los elementos de corrección validados en la retrospectiva y realiza las siguientes acciones:
-
Clasifique las medidas correctivas como Preventivas o Generales:
- Los elementos preventivos son aquellos que evitarían activamente que se repita el incidente
- Los elementos generales no son solo preventivos, sino que resolverían una parte esencial de las circunstancias del incidente.
- Priorice las correcciones para establecer los SLA de respuesta. Este ejercicio incluye las siguientes actividades:
- Identifique los equipos de ingeniería responsables de trabajar en el elemento de corrección
- Vincule el elemento de corrección con la causa de fondo identificada que aborda
- Agregue el elemento de corrección al trabajo en proceso del equipo de ingeniería responsable
- Agregue el elemento de corrección al informe de SLA de ingeniería para hacer seguimiento del cumplimiento de los 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 corrección para su trabajo.
SLA prioritario de elementos de corrección de Zendesk
El equipo de soporte técnico de Zendesk que asiste a la retrospectiva crea las descripciones de los incidentes, las causas de fondo y los remedios identificados que ven los clientes. Esto se publica en la sección Notificaciones de servicio de nuestro centro de ayuda.
Ejemplo de incidente de disponibilidad de servicio continuado
Así es como se realizó una retrospectiva del incidente para este incidente.
4 días laborales después de ocurrido el incidente, el equipo de respuesta al incidente y los ingenieros se reunieron para revisar el incidente, colaborar en las causas fundamentales y crear o actualizar los elementos de remediación. Todos los temas de corrección se acuerdan por consenso de los asistentes a la reunión.
Cada persona involucrada en el incidente desempeñó un papel en la retrospectiva del incidente:
Los detalles examinados y debatidos en la reunión incluyeron:
| Área | Ejemplo |
| Cronograma |
|
| Causas de fondo |
|
| Factores que influyen |
|
| Remediaciones |
|
Para que el equipo de ingeniería pueda realizar un análisis exhaustivo que genere acciones concretas, todos los integrantes del equipo aportaron información para contar el incidente y desarrollar tareas de reparación. Una vez que el equipo de respuesta a incidentes atendió todas las preguntas o problemas, la retrospectiva del incidente se consideró completa.
Al final de la reunión retrospectiva interna, se preguntó a la responsable de soporte al cliente de Zendesk que se ocupaba del público que se enfrentaba a incidentes retrospectivos si tenía alguna pregunta o si necesitaba información adicional del equipo para crear la documentación pública. No tuvo más preguntas y agregó la información retrospectiva a continuación a la sección Notificaciones de servicio en nuestro centro de ayuda.
Información pública retrospectiva para el incidente de la máquina virtual de disponibilidad de servicio
Tres resultados importantes de esta retrospectiva de incidentes que han mejorado los productos y servicios de Zendesk fueron:
- Se identificaron las causas profundas del incidente y todos los equipos de productos de Zendesk las tendrán en cuenta en el desarrollo futuro.
- Las medidas correctivas se identificaron y asignaron a los equipos de ingeniería con SLA
- La retrospectiva pública fue publicada por el soporte al cliente de Zendesk en el centro de ayuda y 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 un resumen de incidentes de servicio que se comparte ampliamente en toda Zendesk. Las descripciones de incidentes, el impacto en los clientes y las medidas correctivas importantes se incluyen en este informe y también en un informe quincenal de revisión de operaciones que se comparte con el equipo ejecutivo de Zendesk.
Una vez que se publica la información retrospectiva en el centro de ayuda y se actualizan los tickets abiertos con los resultados de la retrospectiva, se considera finalizada la fase de análisis y notificación del incidente de servicio. El soporte técnico 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.