REL12-BP02 Realizar un análisis después del incidente - Pilar de fiabilidad
Guía para la implementaciónRecursos

REL12-BP02 Realizar un análisis después del incidente

Revise los eventos que afectan a los clientes e identifique los factores que contribuyen al evento y las medidas preventivas. Use esta información para desarrollar un plan de mitigación que limite o evite la reaparición del problema. Desarrolle procedimientos para proporcionar respuestas rápidas y eficaces. Comunique los factores que han contribuido al problema y las medidas correctivas según corresponda, adaptados al público de destino. Disponga de un método para comunicar estas causas a otros usuarios según sea necesario.

Evalúe por qué las pruebas existentes no han detectado el problema. Añada pruebas para este caso si no hay pruebas ya establecidas.

Resultado deseado: sus equipos tienen un enfoque uniforme y consensuado para gestionar el análisis posterior a los incidentes. Uno de los mecanismos es el proceso de corrección de errores (COE). El proceso COE ayuda a sus equipos a identificar, comprender y abordar las causas fundamentales de los incidentes, a la vez que crea mecanismos y barreras de protección para limitar la probabilidad de que se repita el mismo incidente.

Antipatrones usuales:

  • Buscar los factores que han contribuido al problema, pero no seguir investigando si existen otros problemas potenciales o enfoques que mitigar

  • Identificar solo los errores humanos y no proporcionar ninguna formación o automatización que pueda evitar estos errores

  • Concentrarse en determinar la culpa en lugar de en conocer la causa raíz, lo que da lugar a una cultura de miedo y obstaculiza la comunicación abierta

  • Falta de intercambio de ideas, lo que hace que los resultados del análisis de incidentes los conozca solo un grupo pequeño e impide que otros se beneficien de las lecciones aprendidas

  • No tener ningún mecanismo para capturar el conocimiento institucional, por lo que se pierde información valiosa al no preservar las lecciones aprendidas en forma de actualizaciones de las prácticas recomendadas y, por lo tanto, se repiten incidentes con la misma causa raíz o una similar

Ventajas de establecer esta práctica recomendada: realizar análisis después de un incidente y compartir los resultados permite que el riesgo se mitigue en otras cargas de trabajo si estas tienen implementados los mismos factores que han contribuido al problema, y permite también implementar la mitigación o la recuperación automatizada antes de que se produzca un incidente.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto

Guía para la implementación

Un buen análisis posterior a un incidente ofrece oportunidades de proponer soluciones comunes para problemas con patrones arquitectónicos que se utilizan en otros lugares de los sistemas.

Una piedra angular del proceso COE es documentar y abordar los problemas. Es recomendable definir una forma estandarizada de documentar las causas raíz críticas y asegurarse de que estas se revisan y solucionan. Asigne una propiedad clara al proceso de análisis posterior al incidente. Designe a un equipo o persona responsable que supervise las investigaciones y el seguimiento de los incidentes.

Fomente una cultura que se centre en el aprendizaje y la mejora en lugar de en la culpa. Haga hincapié en que el objetivo es prevenir futuros incidentes, no penalizar a las personas.

Desarrolle procedimientos bien definidos para realizar análisis posteriores a los incidentes. En estos procedimientos, se deben describir los pasos que se deben seguir, la información que se va a recopilar y las preguntas clave que se abordarán durante el análisis. Investigue los incidentes a fondo y vaya más allá de las causas inmediatas para identificar las causas raíz y los factores que contribuyen a ellos. Use técnicas como los cinco porqués para profundizar en los problemas subyacentes.

Mantenga un repositorio de las lecciones aprendidas de los análisis de incidentes. Este conocimiento institucional puede servir como referencia para futuros incidentes y esfuerzos de prevención. Comparta las conclusiones y los conocimientos de los análisis posteriores a los incidentes y considere la posibilidad de celebrar reuniones de revisión de invitación abierta después de los incidentes para analizar las lecciones aprendidas.

Pasos para la implementación

  • Al realizar un análisis posterior al incidente, asegúrese de que en el proceso no se culpe a nadie. Esto permite que las personas involucradas en el incidente se muestren imparciales con respecto a las medidas correctivas propuestas, además de fomentar una autoevaluación honesta y la colaboración entre los equipos.

  • Defina una forma estandarizada de documentar los problemas críticos. Un ejemplo de estructura para dicho documento es el siguiente:

    • ¿Qué ha ocurrido?

    • ¿Cómo ha afectado a los clientes y a la empresa?

    • ¿Cuál ha sido la causa raíz?

    • ¿Qué datos tiene para corroborarlo?

      • Por ejemplo, métricas y gráficos

    • ¿Qué pilares básicos estuvieron implicados, con especial atención a la seguridad?

      • Al diseñar cargas de trabajo, se hacen concesiones entre pilares según el contexto del negocio. Estas decisiones de negocios pueden impulsar sus prioridades de ingeniería. Podría dar preferencia a reducir el costo a expensas de la fiabilidad en el desarrollo de entornos o, para soluciones de misión crítica, podría optimizar la fiabilidad con costos aumentados. La seguridad siempre es la tarea primordial, ya que sus clientes deben estar protegidos.

    • ¿Qué lecciones aprendió?

    • ¿Qué medidas correctivas está tomando?

      • Medidas

      • Artículos relacionados

  • Cree procedimientos operativos estándar bien definidos para realizar análisis posteriores a los incidentes.

  • Configure un proceso estandarizado de notificación de incidentes. Documente todos los incidentes de manera exhaustiva, incluido el informe inicial del incidente, los registros, las comunicaciones y las medidas tomadas durante el incidente.

  • Recuerde que un incidente no requiere una interrupción. Podría tratarse de un cuasi incidente o de un sistema que funciona de una forma inesperada, pero que cumple su función.

  • Mejore continuamente su proceso de análisis posterior a un incidente en función de los comentarios y las lecciones aprendidas.

  • Registre los resultados clave en un sistema de administración del conocimiento y considere cualquier patrón que deba añadirse a las guías para desarrolladores o a las listas de verificación previas al despliegue.

Recursos

Documentos relacionados:

Vídeos relacionados: