# REL12-BP02 Realizar un análisis después del incidente
<a name="rel_testing_resiliency_rca_resiliency"></a>

 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. Agregue pruebas para este caso si no hay pruebas ya establecidas. 

 **Patrones de uso no recomendados comunes:** 
+  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 

 **Beneficios 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 implementadas 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
<a name="implementation-guidance"></a>
+  Establezca un estándar para el análisis posterior a un incidente. 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. 
  +  Asegúrese de que los factores que han contribuido al problema son sinceros y están libres de reproches. 
  +  Si no documenta los problemas actuales, no podrá corregirlos. 
    +  Asegúrese de que el análisis después de un incidente se realice sin reproches para que las medidas correctivas propuestas sean imparciales y para fomentar la autoevaluación y colaboración honestas en sus equipos de aplicaciones. 
+  Use un proceso para determinar los factores que han contribuido al problema. Disponga de un proceso para identificar y documentar los factores que han contribuido al problema, de manera que se puedan elaborar medidas de mitigación para limitar o prevenir su repetición y se puedan desarrollar procedimientos para dar respuestas rápidas y eficaces. Comunique los factores que han contribuido al problema según corresponda, adaptados al público de destino. 
  +  [¿Qué es el análisis de registros?](https://aws.amazon.com/log-analytics/) 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [¿Qué es el análisis de registros?](https://aws.amazon.com/log-analytics/) 
+  [Por qué debería desarrollar una corrección de errores (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)