Actividades posteriores a la implementación
La resiliencia es un proceso continuo y la evaluación de la resiliencia de la aplicación debe continuar después de implementar la aplicación. Los resultados de las actividades posteriores a la implementación, como las evaluaciones de resiliencia continuas, pueden requerir que vuelva a evaluar y actualizar algunas de las actividades en materia de resiliencia que realizó al principio del ciclo de vida de la resiliencia.
Realización de evaluaciones de la resiliencia
La evaluación de la resiliencia no termina después de implementar la aplicación en producción. Incluso si tiene canalizaciones de implementación automatizadas y bien definidas, a veces pueden producirse cambios directamente en un entorno de producción. Además, es posible que haya factores que aún no haya tenido en cuenta en la verificación de la resiliencia previa a la implementación. AWS Resilience Hub proporciona una ubicación central en la que puede evaluar si la arquitectura implementada cumple con las necesidades de RPO y RTO que ha definido. Puede utilizar este servicio para realizar evaluaciones bajo demanda de la resiliencia de su aplicación, automatizar las evaluaciones e incluso integrarlas en sus herramientas de CI/CD, tal y como se explica en la entrada en el blog de AWS Continually assessing application resilience with AWS Resilience Hub and AWS CodePipeline
pruebas de DR
En la etapa 2: diseño e implementación, desarrolló estrategias de recuperación ante desastres (DR) como parte de su sistema. Durante la etapa 4, debe probar sus procedimientos de recuperación ante desastres para asegurarse de que el equipo esté totalmente preparado para cualquier incidente y de que los procedimientos funcionen según lo previsto. Debe probar todos sus procedimientos de recuperación ante desastres, incluidas la conmutación por error y la conmutación por recuperación, de forma periódica y revisar los resultados de cada ejercicio para determinar si debe actualizar los procedimientos del sistema y de qué manera para obtener los mejores resultados posibles. Cuando prepare inicialmente su prueba de recuperación ante desastres, prográmela con suficiente antelación y asegúrese de que todo el equipo sepa qué esperar, cómo se medirán los resultados y qué mecanismo para enviar comentarios se utilizará para actualizar los procedimientos en función de los resultados. Una vez que domine las pruebas de recuperación ante desastres programadas, considere la posibilidad de realizarlas sin previo aviso. Los desastres reales no se producen según una programación, por lo que debe estar preparado para poner en práctica su plan en cualquier momento. Sin embargo, “sin previo aviso” no significa que no se haya planificado. Las partes interesadas clave aún deben planificar el evento para garantizar que se cuente con una supervisión adecuada y que los clientes y las aplicaciones esenciales no se vean afectados negativamente.
Detección de desviaciones
Pueden producirse cambios imprevistos en la configuración de las aplicaciones de producción incluso cuando se cuenta con procedimientos de automatización bien definidos. Para detectar cambios en la configuración de la aplicación, debe contar con mecanismos para detectar las derivas; es decir, las derivas con respecto a una configuración de referencia. Para obtener información sobre cómo detectar derivas en las pilas de AWS CloudFormation, consulte Detectar cambios de configuración no administrados en pilas y recursos en la documentación de AWS CloudFormation. Para detectar derivas en el entorno de AWS de la aplicación, consulte Detect and resolve drift in AWS Control Tower en la documentación de AWS Control Tower.
Pruebas sintéticas
Las pruebas sintéticas son el proceso mediante el cual se crea software configurable que se ejecute en producción, de forma programada, para probar las API de la aplicación de manera que se simule la experiencia del usuario final. Estas pruebas a veces se denominan canarios, en referencia al uso original del término en la minería del carbón. Las pruebas sintéticas suelen proporcionar alertas tempranas cuando una aplicación sufre una interrupción, incluso si la avería es parcial o intermitente, como suele ser el caso de los errores grises.
Ingeniería del caos
La ingeniería del caos es un proceso sistemático que implica someter deliberadamente una aplicación a eventos disruptivos de manera que se mitigue el riesgo, supervisar de cerca su respuesta e implementar las mejoras necesarias. Su objetivo es validar o cuestionar las suposiciones sobre la capacidad de la aplicación para gestionar estas interrupciones. En lugar de dejar estos eventos al azar, la ingeniería del caos permite que los ingenieros orquesten experimentos en un entorno controlado, normalmente durante los periodos de poco tráfico y con el apoyo de la ingeniería disponible, para mitigarlos de manera efectiva.
La ingeniería del caos comienza con la comprensión de las condiciones normales de funcionamiento (conocidas como estado estable) de la aplicación en cuestión. A partir de ahí, formula una hipótesis que detalla el comportamiento correcto de la aplicación cuando se produce una interrupción. Lleva a cabo el experimento, que implica la introducción deliberada de interrupciones, como, por ejemplo, la latencia de la red, los errores del servidor, los errores del disco duro y las averías en las dependencias externas. A continuación, analiza los resultados del experimento y mejora la resiliencia de la aplicación en función de lo aprendido. El experimento sirve como una herramienta valiosa para mejorar varios aspectos de la aplicación, como el rendimiento, y detecta problemas latentes que, de otro modo, podrían haber permanecido ocultos. Además, la ingeniería del caos ayuda a revelar las deficiencias en la observabilidad y las herramientas para las alarmas, y ayuda a refinarlas. También contribuye a reducir el tiempo de recuperación y a mejorar las habilidades operativas. La ingeniería del caos acelera la adopción de las prácticas recomendadas y fomenta una mentalidad de mejora continua. En última instancia, permite que los equipos desarrollen y perfeccionen sus habilidades operativas mediante la práctica y la repetición regulares.
AWS recomienda que comience sus esfuerzos para la ingeniería del caos en un entorno que no sea de producción. Puede usar AWS Fault Injection Service (AWS FIS)
