¿Qué es la Ingeniería del Caos y por qué es importante?
¿Por qué es importante la ingeniería del caos? Veamos por qué existe la Garantía de Calidad (QA) en primer lugar.
En pocas palabras, QA existe porque, por mucho que intentemos crear software perfecto que siempre haga lo que está diseñado y se supone que debe hacer, el mundo real no parece permitirlo.
Los errores se cuelan. Las máquinas interpretan nuestro código de manera diferente a como lo planeamos. Suceden cosas. La ingeniería de calidad existe para intentar encontrar esos problemas no intencionados antes de que lo hagan nuestros clientes.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
¿Qué es la ingeniería del caos?
La ingeniería del caos es un enfoque disciplinado para identificar fallos potenciales antes de que se conviertan en interrupciones del servicio. Con la ingeniería del caos se diseñan experimentos para inyectar fallos y se compara lo que se espera que ocurra con lo que realmente ocurre en tus sistemas. Literalmente, “rompes las cosas a propósito” para aprender a construir sistemas más resilientes.
¿Por qué es importante la ingeniería del caos?
Porque los sistemas están cambiando. Tradicionalmente, QA ejecuta una variedad de pruebas y tipos de pruebas para buscar de forma proactiva estos problemas, mucho antes de que el código llegue a producción. Estas pruebas se realizan al final de una compilación y antes de que ese código sea desplegado públicamente, normalmente probando en un entorno de pruebas o staging en vez de probar en producción.
Hasta aquí todo bien, si estamos operando bajo un modelo tradicional de desarrollo y despliegue de software. Los diseños monolíticos y los despliegues en máquinas propiedad de la empresa otorgan una gran cantidad de control. Hay una estabilidad inherente a este control. Esto hace que estos entornos de staging y pruebas sean similares a los entornos de producción y permite que las pruebas en ellos sean exitosas.
Los sistemas distribuidos son diferentes. La nube es diferente. No controlamos la infraestructura. Está cambiando constantemente. La infraestructura cambia según nuestro diseño con servicios individuales, microservicios, y balanceadores de carga que inician o eliminan nodos de cómputo según sea necesario. Los sistemas de conmutación por error se ajustan a sí mismos para garantizar la gestión de riesgos. El cambio constante provoca comportamientos inesperados, emergentes. Estos son comportamientos que no siempre podemos predecir, pero que sí podemos reproducir y provocar utilizando una forma de pruebas llamada ingeniería del caos.
Las pruebas deben adaptarse a medida que los sistemas cambian
No podemos probar eficazmente todo lo que nuestro código en producción y el entorno se encontrarán probando en cualquier otro entorno. Podemos probar muchas cosas, cosas que la QA tradicional hace bastante bien y debería seguir haciéndolo, aunque quizás parte de ello ahora puede hacerse de forma automatizada en la etapa de construcción del software. Pero la manera en que hemos hecho QA no puede probar cómo reaccionará nuestro sistema distribuido cuando, por ejemplo, la red entre un almacén de datos y varios nodos de cómputo se vea saturada y aumente la latencia.
Nuestras pruebas automatizadas y manuales no contemplan este entorno de producción de cambio rápido donde los servicios se inician y detienen según la demanda. La única manera de comprobar si un sistema distribuido seguirá siendo confiable cuando se enfrente a comportamientos emergentes causados por condiciones cambiantes es hacer lo que todos los paradigmas de pruebas hacen: probar y ver qué sucede.
¿Cómo funciona la ingeniería del caos?: probar y aprender a través del fracaso
Todos tenemos objetivos de tiempo activo. Todos queremos mejorar nuestro rendimiento. Para lograrlo, debemos usar todos los recursos disponibles para aprender tanto como sea posible sobre cómo manejan nuestros sistemas los fallos, ya sea la falta de un usuario al rellenar un campo adecuadamente o cuando un componente del sistema en la nube falla en funcionar como se espera.
"¿Qué pasa si...?" es una pregunta que todos amamos hacer. Luego, lo probamos y descubrimos la respuesta.
Debido a que nuestros sistemas y sus diseños han evolucionado de manera sin precedentes, también debemos evolucionar nuestros métodos de pruebas para entender mejor cómo nuestros sistemas distribuidos gestionarán los fallos y cómo los fallos de componentes y dependencias impactan al sistema completo. Las pruebas holísticas de este tipo son el propósito de la ingeniería del caos, porque permite probar todo nuestro sistema tal y como existe en producción.
Un programa de ingeniería del caos comienza de forma pequeña, probando cosas que ya sabemos o creemos saber:
- ¿Nuestro sistema de monitoreo detectará activamente la latencia de red por encima de un cierto umbral?
- ¿Eso iniciará una alerta hacia el ingeniero de guardia o tal vez una mitigación automática?
- ¿Nuestra configuración ha cambiado con el tiempo, o seguimos iniciando nodos de cómputo según las especificaciones?
¿Cómo resiste cada instancia de servicio durante pruebas ligeras? ¿Medias? ¿Intensas? Todas deberían funcionar igual y nuestro balanceador de carga debería distribuir la carga entre ellas adecuadamente. ¿Qué pasa si una instancia comienza a recibir una carga significativamente mayor que las otras debido a problemas en nuestro servicio de balanceo?
Las pruebas sistemáticas de sistemas caóticos aportan beneficios vitales
Realizamos pruebas utilizando el método científico, empezando de a poco y siendo intencionales. Diseñamos experimentos tempranos para minimizar el radio de impacto, es decir, el conjunto de servicios y componentes que creemos que pueden verse afectados, y para minimizar la magnitud de los parámetros del experimento.
Una vez que tenemos éxito aquí, podemos decidir avanzar paso a paso, aumentando nuestra confianza en el sistema o desarrollando nuestro backlog priorizado de mejoras a implementar. Cuando realizamos esas mejoras y volvemos a probar utilizando el mismo experimento de caos y parámetros, el sistema pasará la prueba y sabremos que es más confiable que antes.
Esta es la única manera de aprender cómo nuestros sistemas realmente gestionan los fallos en producción, donde nuestros clientes acabarán experimentando los resultados. Si detectamos los pequeños problemas ahora, antes de que tengan la oportunidad de convertirse en problemas mayores, podemos asegurarnos de que cada vez ocurran menos fallos sistémicos.
Esto convierte a la Ingeniería del Caos en una herramienta impresionante para la confiabilidad. Es una disciplina que nos ayuda a hacer en la nube y a escala lo que antes solo podíamos lograr en entornos más pequeños y controlados usando QA tradicional.
En última instancia, esto significa menos fallos en producción y menos caídas a gran escala. De hecho, cuando la Ingeniería del Caos se implementa y se utiliza de forma constante, los fallos de servicios y componentes que normalmente se esperarían en el caos de la nube no tendrán ningún impacto en nuestros clientes. De hecho, nunca sabrán que hubo un fallo, y ese es el verdadero objetivo.
¿Qué sigue?
Hablé sobre ingeniería del caos con más detalle en el episodio del pódcast The QA Lead junto a Jonathon Wright.
Nota del editor:
Puedes mantenerte al día con otros pódcast y artículos de The QA Lead suscribiéndote al boletín.
También puedes convertirte en miembro para acceder al foro de la comunidad The QA Lead, donde puedes compartir mejores prácticas con otros QAs e ingenieros de calidad. ¡Espero verte allí!
Lectura relacionada: LOS 10 MEJORES SOFTWARE DE INGENIERÍA DE CALIDAD: UNA GUÍA COMPLETA
