¿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, sin importar cuánto nos esforcemos en crear un software perfecto que siempre haga lo que fue diseñado para hacer y lo que se supone que debe hacer, el mundo real no parece permitirlo.
Se cuelan errores. Las máquinas interpretan nuestro código de forma diferente a como lo habíamos previsto. Suceden cosas. La ingeniería de calidad existe para intentar encontrar esos problemas no intencionados antes de que lo hagan nuestros clientes.
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
¿Qué es la Ingeniería del Caos?
La Ingeniería del Caos es un enfoque disciplinado para identificar posibles fallos antes de que se conviertan en interrupciones. Con la Ingeniería del Caos se diseñan experimentos de inyección de fallos y se compara lo que uno cree que sucederá con lo que realmente ocurre en los sistemas. Literalmente "rompes 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 proactivamente estos problemas, mucho antes de que el código llegue a producción. Estas pruebas se ejecutan al final de una compilación y antes de que ese código se despliegue públicamente, probando generalmente en un entorno de staging o pruebas frente a probar en producción.
Hasta aquí todo bien, si operamos en 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 un gran nivel de control. Hay una estabilidad inherente en ese control. Esto hace que dichos entornos intermedios y de prueba sean similares a los entornos de producción y permite que las pruebas en ellos tengan éxito.
Los sistemas distribuidos son diferentes. La nube es diferente. No controlamos la infraestructura. Esta cambia constantemente. La infraestructura cambia según nuestro diseño con servicios individuales y microservicios y el balanceo de carga activando nodos de cómputo adicionales o eliminándolos según sea necesario. Los sistemas de failover se ajustan para garantizar la gestión de riesgos. El cambio constante produce comportamientos emergentes e inesperados. Son comportamientos que no siempre podemos predecir, pero que podemos reproducir y provocar usando una forma de pruebas llamada Ingeniería del Caos.
Las pruebas deben adaptarse a medida que cambian los sistemas
No podemos probar efectivamente todo lo que nuestro código en producción y el entorno encontrarán probando en cualquier otro entorno. Podemos probar muchas cosas, cosas que el QA tradicional hace bastante bien y debería seguir haciendo, aunque quizá algunas de ellas puedan realizarse ahora mediante automatización durante el pipeline de construcción. Pero la forma en que hemos hecho QA no puede poner a prueba cómo reaccionará nuestro sistema distribuido cuando, por ejemplo, la red entre un almacenamiento de datos y varios nodos de cómputo esté sobrecargada y aumente la latencia.
Nuestras pruebas automatizadas y manuales no tienen en cuenta este entorno de producción que cambia tan rápidamente, donde los servicios se inician y apagan según la demanda. La única forma de probar si un sistema distribuido seguirá siendo confiable frente a comportamientos emergentes provocados por condiciones cambiantes en producción es hacer lo que todos los paradigmas de pruebas hacen: probarlo y averiguarlo.
Cómo funciona la Ingeniería del Caos: probar y aprender a través del fracaso
Todos tenemos objetivos de tiempo de actividad. Todos queremos mejorar nuestro rendimiento. Para lograrlo, debemos utilizar todos los recursos disponibles para aprender lo máximo posible sobre cómo nuestros sistemas manejan los fallos, ya sea un error del usuario al ingresar datos correctos en un campo de formulario o el fallo de un componente del sistema en la nube que no funciona como se esperaba.
"¿Qué pasa si…?" es una pregunta que todos amamos hacernos. Luego, lo probamos y lo descubrimos.
Debido a que nuestros sistemas y nuestros diseños han evolucionado de manera tan sin precedentes, también debemos evolucionar nuestros métodos de prueba para comprender mejor cómo nuestros sistemas distribuidos manejarán fallos y cómo los fallos de componentes y dependencias impactan en todo el sistema. Las pruebas holísticas de este tipo son la razón de ser de la Ingeniería del Caos, pues permiten probar nuestro sistema completo tal como existe en producción.
Un programa de Ingeniería del Caos comienza de forma pequeña, probando aspectos que ya conocemos o creemos conocer:
- ¿Detectará nuestro sistema de monitoreo activamente la latencia de red por encima de un umbral específico?
- ¿Eso generará una alerta al ingeniero de guardia o quizás una mitigación automática?
- ¿Ha cambiado nuestra configuración con el tiempo, o seguimos lanzando nodos de cómputo según las especificaciones?
¿Cómo resiste cada instancia del servicio bajo pruebas ligeras? ¿Medias? ¿Intensas? Todas deberían comportarse igual y nuestro balanceo de carga debería distribuir la carga entre ellas de manera adecuada. ¿Qué sucede si una instancia comienza a recibir una carga significativamente mayor que las demás porque nuestro servicio de balanceo de carga está teniendo problemas?
Las pruebas sistemáticas de sistemas caóticos aportan beneficios vitales
Hacemos pruebas utilizando el método científico, comenzando de manera pequeña e intencionada. Diseñamos experimentos tempranos para minimizar el radio de impacto, el conjunto de servicios y componentes que creemos que pueden verse afectados, y para reducir al mínimo la magnitud de los parámetros de los experimentos.
Una vez que logramos el éxito aquí, podemos decidir avanzar paso a paso, aumentando nuestra confianza en el sistema o incrementando nuestro backlog priorizado de mejoras por realizar. Cuando implementemos esas mejoras y volvamos a probar usando el mismo experimento de caos y parámetros, el sistema superará la prueba y sabremos que es más confiable que antes.
Esta es la única forma de aprender cómo nuestros sistemas realmente gestionan los fallos en producción, donde nuestros clientes finalmente experimentarán los resultados. Si logramos encontrar los pequeños problemas ahora, antes de que tengan la oportunidad de convertirse en grandes problemas, podremos asegurarnos de que cada vez ocurran menos fallos sistémicos.
Esto convierte a la ingeniería del caos en una herramienta de confiabilidad excepcional. Es una disciplina que nos ayuda a hacer en la nube y a gran escala lo que antes solo podíamos realizar en entornos más pequeños y controlados utilizando QA tradicional.
Esto, en última instancia, se traduce en menos fallos y caídas de producción a gran escala. De hecho, cuando la ingeniería del caos se implementa y utiliza de forma constante, los fallos de servicios y componentes que deberían esperarse 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 en más detalle en el episodio del pódcast The QA Lead con Jonathon Wright.
Nota de la editora:
Puedes mantenerte al día con otros pódcasts y artículos de The QA Lead suscribiéndote al boletín.
También puedes hacerte miembro para acceder al foro de la comunidad de The QA Lead, donde puedes compartir mejores prácticas con otros profesionales de QA e ingenieros de calidad. ¡Espero verte allí!
Lectura relacionada: LAS 10 MEJORES HERRAMIENTAS DE SOFTWARE PARA INGENIERÍA DE CALIDAD: UNA GUÍA COMPLETA
