La importancia de un proceso de análisis retrospectivo de los incidentes

Las ventajas de un análisis retrospectivo del incidente

Tal vez sientas la tentación de saltarte una reunión formal de análisis retrospectivo y la consiguiente redacción, sobre todo si sabes con certeza qué fue lo que causó el incidente y tienes el convencimiento de haber solucionado la incidencia.

Todo eso podría ser cierto... en tu caso, pero en tu equipo podría haber personas que no hubieran interiorizado la causa del incidente y que podrían beneficiarse de la nitidez de tu percepción, así como mejorar el servicio que prestan al equipo y a tus clientes.

Juntar al personal para participar en un proceso colaborativo y estructurado permite a todo el mundo contribuir con lo que aprendió y, además, puede generar confianza y resiliencia dentro de tu equipo. Asimismo, documentar el incidente y la solución que dio el equipo puede fundamentar la gestión de los incidentes en el futuro.

Otra opción sería poner a disposición de tus clientes o del resto de la organización las conclusiones del análisis retrospectivo del incidente, lo cual puede ayudar muchísimo a recuperar la confianza de las personas que tal vez no hubieran estado muy involucradas cuando se produjo el incidente. Además, podría darse el caso de que otros equipos de tu organización, sobre todo los de liderazgo, necesiten ver los detalles del problema y las medidas que se han tomado para resolverlo, a fin de atajar en el futuro cualquier crítica a toro pasado hacia tu equipo.

Los partners, los clientes y los usuarios finales también podrían querer saber qué ha sucedido y qué pasos has dado para mejorar su experiencia. Poner el análisis retrospectivo del incidente a disposición pública en el sitio web en el que te presentas ante el público podría no resultar apropiado en todos los casos, pero tu equipo de marketing o de relaciones públicas puede ayudarte a formularlo para que se reciba la información de una manera instructiva que genere confianza en tus servicios.

Prácticas recomendadas para el análisis retrospectivo de un incidente

La forma de abordar el análisis retrospectivo del incidente es igual de importante que la checklist de medidas que tomes. Inmediatamente después de un incidente, las tensiones pueden estar a flor de piel. La clave para lograr que el personal participe en el proceso con compromiso y disposición para abordar un problema difícil es transmitirle una sensación de seguridad psicológica.

Establece una política corporativa en la que no se busquen culpables

John Allspaw, el anterior director tecnológico de Etsy, escribió un inspirador artículo sobre los "análisis retrospectivos sin reproches". Su estrategia para abordar la investigación de un incidente permite al personal implicado en un incidente dar cuenta de todas sus acciones y de las consecuencias de estas, así como de lo que sabían y cuándo lo sabían, sin miedo a castigos ni represalias.

Este enfoque es clave para asegurarse de que tus equipos compartan información abiertamente y lleguen al origen de un incidente. Si alguien tiene miedo de llevarse una reprimenda, podría guardarse información o intentar culpar a otra persona. Y, cuando esto sucede, se pierde la confianza mutua y la organización pierde la oportunidad de generar resiliencia en sus equipos y sistemas. Muchos equipos, incluidos los de Atlassian y los de Google, han adoptado los principios del análisis retrospectivo sin reproches para evitar estos peligros.

Evita señalar con el dedo: las críticas deben ser siempre constructivas

Tanto en la reunión de análisis retrospectivo como en la posterior redacción de los hallazgos, debes evitar que tus palabras atribuyan a nadie la responsabilidad personal por el incidente. En lugar de ello, céntrate en las acciones, los resultados y la repercusión.

Aunque es importante preservar la seguridad y objetividad de la conversación, es fundamental llegar al origen del incidente para resolverlo. En la reunión puedes usar una técnica llamada "los 5 porqués". Para empezar, comprueba que todos los presentes estén de acuerdo en cuál es el problema. Acto seguido, pregúntales por qué se produjo este, y luego pregúntales "por qué" a la respuesta que te den. Repite este proceso al menos cinco veces para asegurarte de detectar todos los factores profundos que contribuyen al problema. Procura que los participantes no intenten alejarse de una verdad incómoda o traten de alcanzar un simple consenso de mínimos. Encontrarás más información sobre el enfoque de "los 5 porqués" en esta estrategia de nuestro manual de estrategias aquí.

Revisa todos los análisis retrospectivos y asienta esto en el proceso

Dejar sin revisar el informe de análisis retrospectivo de un incidente equivale a no haberlo redactado nunca. En cuanto se elabora el borrador del informe de análisis retrospectivo de un incidente, es importante revisarlo para cerrar todas las incidencias por resolver, plasmar las ideas que hay que tener en cuenta en el futuro y finalizar el informe. Podría decirse incluso que el incidente no se resuelve de verdad hasta que se hace esta revisión.

¿Cómo se consigue esto? Programa una reunión periódica con los ingenieros (y con cualquier otra persona que pueda estar interesada, como los profesionales de atención al cliente o los gestores de cuentas), al menos una vez al mes, para revisar los informes de los análisis retrospectivos de los incidentes. Puedes optar por revisar los informes recientes o tal vez revisar informes más antiguos y poner en común lecciones que sigan siendo pertinentes en la actualidad.

Un plan de análisis retrospectivo de incidentes eficaz

Para que los análisis retrospectivos sean eficaces (y te permitan desarrollar una política corporativa de mejora continua), te interesa implementar un proceso sencillo y reproducible en el que todo el mundo pueda participar. La forma de conseguirlo dependerá de la política corporativa y del equipo. En Atlassian, hemos desarrollado un método que nos funciona. Puedes informarte en mayor profundidad al respecto en nuestro manual de gestión de incidentes.

Aquí tienes unos cuantos consejos para ponerte manos a la obra:

Consejo 1: Establece un umbral

Tu organización debería tener niveles de gravedad claros y mensurables para los incidentes. Estos niveles de gravedad se pueden usar para desencadenar el proceso de análisis retrospectivo. Por ejemplo, cualquier incidente de gravedad 1 o superior desencadena el proceso de análisis retrospectivo, mientras que el análisis retrospectivo puede ser opcional para los incidentes menos graves. Plantéate darles a los líderes del equipo o a la dirección la oportunidad de solicitar un análisis retrospectivo para cualquier incidente que no supere el umbral.

Consejo 2: No procrastines

Es importante hacer una pausa y descansar un poco después de un incidente. Ahora bien, no postergues demasiado la redacción del análisis retrospectivo del incidente. Si esperas demasiado, podrían perderse u olvidarse detalles importantes. Lo ideal es hacer el borrador inmediatamente después de una reunión de revisión posincidente, la cual debe tener lugar en un plazo de entre 24 y 48 horas tras la resolución del incidente, y no demorarse más de cinco días hábiles.

Consejo 3: Asigna funciones y propietarios

Una reunión de revisión posincidente es donde se concretarán los detalles que se registrarán en el análisis retrospectivo del incidente. Viene bien delegar el borrador del análisis retrospectivo en una persona específica, idealmente alguien que conozca bien el incidente y que tenga el nivel necesario de conocimientos técnicos y organizativos para entender las causas y las mitigaciones.

Consejo 4: Trabaja a partir de una plantilla

Una plantilla puede conseguir que no se te olviden detalles clave. Además, es una forma excelente de generar homogeneidad en todos tus análisis retrospectivos.

Consejo 5: Incluye una cronología

Un cronograma ayuda mucho a documentar los incidentes. Con frecuencia, es el primer lugar al que acuden los ojos de los lectores para intentar hacerse una idea rápida de lo que ha sucedido. Intenta hacerlo con la máxima claridad y especificidad posible. Por ejemplo, "a las 11:14 PST", no "sobre las 11". La concreción en las marcas de tiempo te permite trazar una cadena de acontecimientos de alta fidelidad, lo cual resulta útil para identificar áreas de mejora. Por ejemplo, podrías identificar que el intervalo de tiempo transcurrido entre el inicio del impacto y el momento en el que se notificó a los clientes fue demasiado largo.

Momentos importantes que se deben incluir.

• El primer ticket o la primera alerta
• El anuncio de los primeros comunicados (internos y/o externos)
• Las horas de actualización de la página de estado
• La hora de los intentos de corrección (reversiones del código, etc.)
• La hora de la resolución

Consejo 6: Detalles, detalles y más detalles

Escatimar en detalles es un atajo que solo conduce a redactar análisis retrospectivos inútiles y poco claros. Aporta tantos detalles como puedas sobre lo que sucedió y lo que se hizo durante el incidente. En lugar de decir "entonces se lanzaron los comunicados", di "enviamos los comunicados públicos iniciales, mediante los cuales anunciamos el incidente en nuestra página de estado pública y en nuestra cuenta de Twitter".

Siempre que puedas, incluye enlaces y nombres, enlaces a los tickets y a las actualizaciones del estado, enlaces a documentos sobre el estado del incidente y gráficos de supervisión. Tampoco tengas miedo de añadir capturas de pantalla de los gráficos o paneles pertinentes. Un gráfico de tu sistema de supervisión que muestre claramente las horas de inicio y de finalización del incidente (por ejemplo, una caída en la tasa de solicitudes seguida de una vuelta a la normalidad) es muy valioso porque es inequívoco. Su eficacia aumenta aún más cuando se combina con gráficos que muestran lo que estaba sucediendo en segundo plano en ese momento como, por ejemplo, las conexiones con la base de datos, el estado del enlace de red, o el consumo de CPU/memoria/io/ancho de banda durante el mismo periodo.

Consejo 7: Plasma las métricas del incidente

Cuando plasmas las métricas en el análisis retrospectivo del incidente, aplicas datos demostrables a las incidencias y su repercusión. Contar con estos datos puntuales te ayuda a determinar si tu equipo va en la dirección correcta y a reducir el número de incidentes, su gravedad y el tiempo de inactividad. Al obtener métricas coherentes, puedes dar un paso atrás y observar las tendencias del incidente a lo largo del tiempo.

A continuación, te explicamos algunas métricas que se deben tener en cuenta en el seguimiento del análisis retrospectivo:

• El número de minutos de tiempo de inactividad, para que puedas controlar si este número aumenta o disminuye.
• La gravedad del incidente, de forma que puedas determinar la fiabilidad relativa de tus sistemas.
• El tiempo medio de resolución (MTTR), que mide el tiempo que se tarda de media en resolver un incidente, desde el momento en que se notificó inicialmente.

¿Cuál es el consejo más importante? No te saltes ningún paso. La clave para realizar análisis retrospectivos de incidentes que te ayuden a mejorar tu equipo y tus sistemas es disponer de un proceso y cumplirlo a rajatabla.

Usa una plantilla de análisis retrospectivo de incidentes para optimizar el proceso

A fin de garantizar que tu equipo desarrolle una política corporativa en torno a las revisiones de análisis retrospectivos de incidentes, pónselo fácil para recabar información, programar reuniones y publicar el informe final con checklists y plantillas reutilizables. Un proceso reproducible aporta homogeneidad y ayuda al personal a saber qué esperar, y luego a llegar al proceso con una mentalidad productiva.

Elementos habituales de la checklist para un proceso de análisis retrospectivo de los incidentes:

Reuniones que se deben celebrar:

• Reunión de recopilación de información
• Revisión del informe
• Presentación del informe

Información que se debe recopilar con antelación:

• Programas estándar de cada reunión
• Participantes, partes interesadas, revisores
• Escritura estandarizada del informe de análisis retrospectivo de incidentes con una plantilla