No todos los desafíos a los que se enfrentan el software y los sistemas distribuidos pueden predecirse con absoluta certeza. Pero con el caos, los problemas de ingeniería se pueden probar de manera específica. En caso de emergencia, el resultado es un sistema más confiable.
En el desarrollo de software, se presta gran atención al desarrollo de sistemas seguros y fiables. Los desarrolladores trabajan en la confiabilidad de su software con pruebas unitarias y de integración, pero estos métodos alcanzan sus límites en escenarios reales de sistemas distribuidos.
Los sistemas modernos tienen tantos componentes y complejidades que difícilmente pueden cubrirse con métodos de desarrollo regulares. La ingeniería del caos adopta un enfoque diferente: hay un intento específico de destruir el sistema y provocar errores para determinar cómo reaccionan los sistemas en situaciones inesperadas.
Ingeniería del caos: la teoría del caos digital con el mecenas prominente
La tecnología de la ingeniería del caos ha avanzado en los últimos años principalmente por el servicio de transmisión de EE. UU. Netflix. Incluso si Netflix no está asociado con el progreso digital de la misma manera que Apple o Microsoft, la compañía tiene una infraestructura digital gigantesca y concede gran importancia a garantizar que funcione a la perfección.
Chaos Engineering proporciona un modelo de desarrollo en el que se prueban escenarios inesperados y el software se lleva específicamente a sus límites y más allá. En los sistemas modernos, existe una complejidad creciente para los desarrolladores que es inmanejable y puede causar problemas impredecibles en cualquier momento.
Esto también se basa en un replanteamiento, alejándose del modelo de desarrollo, en el que no hay rupturas son la norma, hacía pensar que un colapso es inevitable. Usando la tecnología de la ingeniería del caos, se pueden crear sistemas redundantes de una manera más específica para que los clientes finales ya no se vean afectados por errores.
Explicado con un ejemplo simple: se ha construido un sistema para un cierto número máximo de solicitudes por segundo. ¿Cómo reacciona este sistema cuando se alcanza y se supera el número máximo? ¿Cómo reacciona qué parte del software en qué puntos? No todos los escenarios probados tienen que estar orientados al día a día, una parte emocionante de la ingeniería del caos es el desarrollo de escenarios hipotéticos.
¿Cómo funciona la ingeniería del caos en la práctica?
En términos generales, el proceso de la ingeniería del caos se basa en experimentar con los límites del software. Para ello, primero se define un estado estable, en el que un sistema funciona según lo definido como normal. Un grupo de control asegura que es el escenario caótico el que influye en el sistema; el grupo de control continúa trabajando fuera de este escenario de prueba.
Ahora se introducen problemas en el escenario de prueba (fallas del servidor, discos duros defectuosos, fallas, escenarios de sobrecarga). El objetivo principal de la ingeniería del caos es probar cómo lidiar con estos problemas. ¿Cómo se pueden ampliar los límites de un sistema? ¿Qué redundancias son necesarias para mantener en funcionamiento el servicio existente? ¿Y cómo se pueden eliminar las debilidades dadas?
Para ganar más confianza en un sistema, es esencial limitar los errores y mantener los estados del sistema estables tanto como sea posible. Precisamente por eso, es fundamental someter los sistemas a pruebas críticas y provocar errores de forma selectiva.
Simian Army: un ejemplo de software de ingeniería del caos
Para llevar a cabo estas pruebas en la práctica, Netflix se basa en el software Simian Army. Esta suite de errores simula una situación en la que los monos utilizan el software y provocan diversos errores. Varias herramientas de prueba tienen nombres correspondientes.
Chaos Gorilla, por ejemplo, desactiva una zona de disponibilidad completa en la infraestructura del servidor, Chaos Kong incluso desactiva una región completa en la infraestructura AWS de Amazon. Byte Monkey prueba las fuentes de error en el código Java de las aplicaciones JVM y Latency Monkey prueba los retrasos en la comunicación, como los que ocurren en caso de fallas en la red.
La complejidad de estos errores causados ya muestra en los extractos mencionados anteriormente cómo pueden ocurrir errores extensos en los sistemas distribuidos. Además de Simian Army, también se utilizan herramientas como SIMOORG (código abierto) o Monkey Ops (software implementado en Go).
Por supuesto, el cliente final no nota nada de la complejidad que subyace incluso en las operaciones más pequeñas y tampoco debería notarlo. Para las empresas, las fallas siempre significan una posible pérdida de ingresos y la ingeniería del caos es solo un método para reducir la probabilidad de fallas.
Chaos Engineering asegura que esto en la práctica ofrece un software más tolerante a fallas y, como resultado, clientes más satisfechos. Para los desarrolladores de TI, Chaos Engineering también ofrece un método atractivo más allá del desarrollo de software para probar escenarios de error a veces realistas y a veces extraños. Esto difumina la línea entre el desarrollo de software y la garantía de calidad para crear más estabilidad y resistencia.