Información general

Comparación de las pruebas de resiliencia con la ingeniería del caos

Las pruebas de resiliencia son deterministas. Es decir, validan las características conocidas sobre los mecanismos de resiliencia, como los disyuntores, los reintentos, las conmutaciones por error o las alternativas, que se han implementado en la aplicación. Confirma la forma en que estos componentes de la aplicación absorben las interrupciones controladas con un impacto mínimo o nulo para el usuario. Por lo tanto, las pruebas de resiliencia se centran en la validación de los modos de fallo conocidos que se incorporan a los componentes de la aplicación con el objetivo de producir pass/fail resultados. Debe realizar pruebas de resiliencia de forma continua como parte de su proceso para asegurarse de no introducir regresiones en su postura de resiliencia. En las pruebas de resiliencia, a menudo no se realizan pruebas con componentes reales, sino simulaciones APIs que simulan un componente determinado. Este enfoque permite realizar pruebas consistentes y reproducibles de los escenarios de falla en un entorno controlado, lo que lo hace adecuado para la integración automática de canalizaciones y las pruebas de regresión.

Por el contrario, la ingeniería del caos no es determinista. Es decir, se basa en hipótesis y verifica tu modelo mental sobre la forma en que la aplicación y sus dependencias (personas, procesos y tecnología) absorben los modos de fallo imprevistos, se adaptan a ellos y, finalmente, se recuperan de ellos. Por lo tanto, la ingeniería del caos se centra en la end-to-end verificación de los modos de fallo desconocidos, con el objetivo de detectar los defectos a tiempo y subsanarlos antes de que se conviertan en eventos a gran escala. La ingeniería del caos fomenta el aprendizaje continuo y debe practicarse mediante un proceso de creación de caos independiente o mediante experimentos ad hoc que permitan ejecutar varios experimentos en cualquier momento sin bloquear la productividad del desarrollador a la hora de implementar el código.

El proceso de ingeniería del caos suele comenzar con un día de juego caótico, que es un evento específico en el que los equipos introducen intencionadamente fallos o fallos controlados en su aplicación. El día de juego es progresivo: comienza en entornos de nivel inferior (como el desarrollo o las pruebas) y, poco a poco, avanza hacia entornos de nivel superior (como la puesta en escena y la preproducción) a medida que aumenta la confianza. Al moverse sistemáticamente por estos entornos, los equipos pueden comprobar que sus sistemas toleran adecuadamente los fallos inyectados antes de que lleguen a la fase de producción. Esta progresión metódica garantiza que, cuando se lleven a cabo experimentos de caos en entornos de producción, los equipos hayan adquirido una confianza sustancial en las capacidades de resiliencia de sus sistemas. El proceso del día del partido es un enfoque proactivo para identificar las debilidades y vulnerabilidades en la arquitectura y las prácticas operativas de una aplicación y, al mismo tiempo, eliminar el stress de aprender durante una interrupción inesperada de la producción.

El valor de la ingeniería del caos

Los sistemas complejos son omnipresentes en el mundo actual. Desempeñan un papel fundamental en muchos aspectos de nuestras vidas, desde los mercados financieros hasta la sanidad. Esperamos que estos sistemas estén siempre operativos. Sin embargo, los sistemas complejos suelen ser vulnerables a eventos y comportamientos inesperados que pueden tener consecuencias importantes. Las organizaciones deben planificar para la disrupción en lugar de preguntarse si ocurrirá. Para ello, pueden aplicar pruebas de escenarios en todos sus servicios empresariales críticos o de misión crítica. Aquí es donde entra en juego la ingeniería del caos.

La ingeniería del caos ofrece un enfoque para gestionar sistemas complejos que puede ayudar a mitigar los riesgos y mejorar la resiliencia. El proceso de preparación para los experimentos de caos requiere que los equipos desarrollen hipótesis sobre el comportamiento de sus sistemas, lo que les permite comprender mejor cómo se construyen los sistemas y cómo funcionan. Esta preparación suele revelar lagunas mentales, ideas arquitectónicas y conocimientos operativos que, de otro modo, podrían quedar sin descubrir. Al comprender mejor cómo reaccionan los sistemas complejos ante las fallas, la ingeniería del caos promueve una mayor transparencia y responsabilidad en el diseño y la administración de los sistemas. Cuanto más a menudo su organización practique la ingeniería del caos, mejor preparada estará desde el punto de vista operativo. La ingeniería del caos le ayuda a establecer las mejores prácticas para diseñar aplicaciones resilientes que puedan sobrevivir a los fallos de los componentes con un impacto mínimo o nulo en los usuarios. Esto garantiza que las aplicaciones críticas funcionen dentro de los niveles de servicio y la tolerancia a los impactos esperados, al tiempo que mejora continuamente el conocimiento del equipo sobre sus propios sistemas.

Prepararse para condiciones adversas

Al desarrollar AWS, utilizas diferentes tipos de servicios, incluidos servicios zonales como Amazon Elastic Compute Cloud (Amazon EC2), servicios regionales como Amazon Simple Storage Service (Amazon S3), servicios globales como (IAM), servicios de software AWS Identity and Access Management como servicio (SaaS) de terceros y servicios locales. Cada tipo de servicio expone distintos dominios de error que hay que tener en cuenta. ¿Cómo se prepara para los eventos autoinfligidos o los eventos causados por terceros sobre los que su organización no tiene control?

Para ayudarte a entender cómo podría responder tu aplicación a condiciones adversas, puedes usar AWS Fault Injection Service ()AWS FIS. AWS FIS es un servicio totalmente gestionado para ejecutar experimentos de inyección de fallos de forma controlada. Puede utilizar este servicio para detectar situaciones AWS predeterminadas, como interrupciones del suministro eléctrico en la zona de disponibilidad o problemas de conectividad entre regiones, o bien crear sus propios experimentos combinando una amplia variedad de errores que ofrece el servicio. AWS FIS permite a sus equipos practicar y aprender continuamente cómo reaccionaría su aplicación ante los fallos más comunes y cómo remediaría los defectos a medida que los detecten.

Practicando la ingeniería del caos controlada

Los principios clave de los experimentos de caos controlado son:

Para escalar con éxito la ingeniería del caos, debe implementar experimentos de caos de forma controlada. Cuando lo usas AWS FIS, puedes crear condiciones de parada mediante las CloudWatchalarmas de Amazon. Puede incorporar estas condiciones en una plantilla de experimento para asegurarse de que los experimentos se detengan si se sobrepasan los límites y se devuelven a su último estado conocido. AWS FIS también proporciona palancas de seguridad. Al activar estas palancas, AWS FIS se detienen y anulan todos los experimentos que se estén realizando en la cuenta Región de AWS, incluidos los experimentos con varias cuentas, e impide que se inicien nuevos experimentos. Esto evita que se produzcan errores durante determinados períodos de tiempo, como el horario de negociación, los eventos de rebajas o el lanzamiento de productos, o en respuesta a las alarmas de estado de las aplicaciones. La palanca de seguridad permanece activada hasta que se desactiva manualmente.

Cuando lleves a cabo un experimento caótico, debes definir medidas de seguridad para evitar efectos secundarios no deseados en el medio ambiente, especialmente si existe la posibilidad de que el experimento afecte a las aplicaciones que están en producción. Cuando planifique el experimento, prevea cualquier efecto adverso que pueda tener en otras aplicaciones del entorno. Por ejemplo, otras aplicaciones podrían recibir mensajes erróneos de la aplicación que forma parte del experimento, recibir un gran volumen de solicitudes o encontrarse con problemas de recursos si comparten la infraestructura. Documente estos riesgos y aborde cualquier problema conocido o inaceptable antes de ejecutar el experimento.