Gestión de incidentes para equipos de alta velocidad
Análisis retrospectivos públicos o privados de incidentes
Cómo saber cuál es el momento adecuado para dar una explicación pública posincidente
Hubo una época en la que casi todos los incidentes de TI quedaban confinados a las cuatro paredes de la organización en la que se producían. Sin embargo, en la actualidad, con los servicios web y la infraestructura en la nube, eso rara vez pasa. Los incidentes tecnológicos son un verdadero problema que, cuando se producen, salpican a muchas personas, lo cual ha supuesto un cambio considerable en la forma en que los equipos responden a los incidentes, se enteran de ellos y se comunican al respecto.
Piensa en el análisis retrospectivo de los incidentes (al que también se le suele llamar "revisión posincidente").
El análisis retrospectivo de un incidente reúne al personal para comentar los pormenores de un incidente: el motivo por el que produjo, sus consecuencias, las medidas que se tomaron para mitigarlo y resolverlo, y qué habría que hacer para impedir que vuelva a suceder.
El análisis retrospectivo de un incidente se puede dividir en dos actividades distintas: la reunión en la que se examina el incidente y el correspondiente informe de análisis retrospectivo generado como consecuencia de dicha reunión.
Se suele decir "análisis retrospectivo" para referirse indistintamente a la reunión o al informe. Con este término, el personal podría estar hablando de una de estas actividades o de ambas.
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.
Cuándo hacer un análisis retrospectivo de un incidente
En Atlassian, siempre hacemos análisis retrospectivos internos de los incidentes de gravedad 1 y 2 (los "más importantes"). En el caso de los incidentes de menor importancia, son opcionales. Animamos a utilizar el proceso de análisis retrospectivo en cualquier situación en la que pueda resultar útil.
¿Quién lleva a cabo un análisis a toro pasado?
Normalmente, la responsabilidad de realizar el análisis retrospectivo de un incidente recae sobre el equipo que lo causó. Se nombra a alguien para que se haga cargo de efectuar el análisis retrospectivo y se le asigna la incidencia. Esta persona es la "propietaria del análisis retrospectivo", y es quien va sacando adelante los borradores y la sucesiva aprobación hasta que se publica. Los incidentes a escala de la infraestructura y la plataforma suelen afectar a la empresa transversalmente, por lo que los análisis retrospectivos correspondientes suelen ser más complejos y llevar más trabajo. Por este motivo, a veces asignamos a un gestor de programas exclusivo para que se haga cargo de los análisis retrospectivos a nivel de la infraestructura o la plataforma, ya que este tipo de profesional está mejor capacitado para trabajar con distintos grupos y se puede comprometer con el nivel de esfuerzo requerido.
Comunicación de un informe interno de un análisis retrospectivo
Una vez aprobado el análisis retrospectivo, consideramos que podemos multiplicar sus beneficios si comunicamos lo aprendido a toda la empresa. Para ello, en Atlassian contamos con una acción de automatización que crea un borrador de una entrada de blog en Confluence en cuanto se aprueba el ticket del análisis retrospectivo.
Creación de un informe público del análisis retrospectivo de un incidente
Aunque es menos habitual, suele ser aconsejable publicar una versión pública de un análisis retrospectivo después de un incidente.
Esto sucede sobre todo en los servicios de consumo a gran escala con interrupciones que afectan a muchos usuarios. Lo más normal es que estos equipos publiquen una versión abreviada del informe interno, en vez del informe interno al completo. Es importante que borren toda la información privada o confidencial.
Divulgación de un informe público de análisis retrospectivo de un incidente
Saber cuál es el canal adecuado para publicar un análisis retrospectivo público puede resultar un asunto delicado. En el caso de algunos equipos, se podría publicar directamente en el blog de tu empresa o en tu sitio web. Otros equipos tienen un blog de ingeniería aparte en el que podría encajar un análisis retrospectivo.
En nuestro producto Statuspage, los usuarios pueden publicar análisis retrospectivos públicos directamente en su página de estado tras la resolución de un incidente.
Descubre la comunicación de incidentes con Statuspage
En este tutorial, te mostraremos cómo utilizar plantillas de incidentes para comunicarte eficazmente durante las interrupciones. Puedes aplicarlo a muchos tipos de interrupciones del servicio.
Leer el tutorialLa importancia de un proceso de análisis retrospectivo de los incidentes
El análisis retrospectivo de un incidente, también conocido como "revisión posincidente", es la mejor manera de repasar lo sucedido durante un incidente y plasmar las lecciones aprendidas.
Leer el artículo