La ingeniería del caos es la disciplina que consiste en experimentar en un sistema con el fin de generar confianza en la capacidad del sistema para soportar condiciones turbulentas en la producción. [1]
En el desarrollo de software, la capacidad de un software determinado para tolerar fallos y, al mismo tiempo, garantizar una calidad de servicio adecuada (con frecuencia denominada resiliencia ) suele especificarse como un requisito. Sin embargo, los equipos de desarrollo pueden no cumplir con este requisito debido a factores como plazos cortos o falta de conocimiento del dominio. La ingeniería del caos abarca técnicas destinadas a cumplir con los requisitos de resiliencia.
La ingeniería del caos se puede utilizar para lograr resiliencia ante fallas de infraestructura, fallas de red y fallas de aplicaciones.
Calcular cuánta confianza tenemos en los sistemas complejos interconectados que se ponen en funcionamiento en entornos de producción requiere métricas de preparación operativa. La preparación operativa se puede evaluar mediante simulaciones de ingeniería del caos. Las soluciones para aumentar la resiliencia y la preparación operativa de una plataforma incluyen el fortalecimiento de las capacidades de copia de seguridad, restauración, transferencia de archivos de red, conmutación por error y seguridad general del entorno.
Una evaluación para inducir el caos en un entorno de Kubernetes finalizó los pods aleatorios que recibían datos de dispositivos de borde en centros de datos mientras procesaban análisis en una red de big data. El tiempo de recuperación de los pods fue una métrica de resiliencia que estimó el tiempo de respuesta. [2] [3]
1983 – Manzana
Mientras se desarrollaban MacWrite y MacPaint para el primer ordenador Apple Macintosh , Steve Capps creó "Monkey", un accesorio de escritorio que generaba eventos de interfaz de usuario de forma aleatoria y a gran velocidad, simulando un mono golpeando frenéticamente el teclado y moviendo y haciendo clic con el ratón. Se empezó a utilizar rápidamente para depurar errores , ya que generaba errores que los programadores debían corregir, ya que no era posible realizar pruebas automatizadas ; el primer Macintosh tenía muy poco espacio de memoria libre para algo más sofisticado. [4]
1992 – Prólogo Mientras se desarrollaban ABAL2 y SING para las primeras versiones gráficas del sistema operativo PROLOGUE, Iain James Marshall creó "La Matraque", un accesorio de escritorio que generaba secuencias aleatorias de eventos de interfaz gráfica , tanto legales como no, a alta velocidad, probando así el comportamiento crítico de las bibliotecas gráficas subyacentes. Este programa se ejecutaba antes de la entrega de producción, durante días seguidos, asegurando así el grado requerido de resistencia total. Esta herramienta se amplió posteriormente para incluir la base de datos y otras instrucciones de acceso a archivos del lenguaje ABAL para verificar y garantizar su resistencia posterior. Actualmente se utiliza una variación de esta herramienta para la calificación de la versión moderna conocida como OPENABAL.
2003 – Amazon
Mientras trabajaba para mejorar la fiabilidad de los sitios web de Amazon , Jesse Robbins creó "Game day", [5] una iniciativa que aumenta la fiabilidad creando deliberadamente fallos importantes de forma periódica. Robbins ha dicho que se inspiró en la formación de bomberos y en la investigación en otros campos, lecciones sobre sistemas complejos e ingeniería de fiabilidad. [6]
2006 – Google
Mientras trabajaba en Google , Kripa Krishnan creó un programa similar al Game Day de Amazon (ver arriba) llamado "DiRT". [6] [7] [8] Jason Cahoon, ingeniero de confiabilidad del sitio [9] en Google, contribuyó con un capítulo sobre Google DiRT [10] en el libro "Chaos Engineering" [11] y describió el sistema en la conferencia GOTOpia 2021. [12]
2011 – Netflix
Mientras supervisaban la migración de Netflix a la nube en 2011, Nora Jones, Casey Rosenthal y Greg Orzell [11] [13] [14] ampliaron la disciplina mientras trabajaban juntos en Netflix al configurar una herramienta que provocaría fallas en su entorno de producción, el entorno utilizado por los clientes de Netflix. La intención era pasar de un modelo de desarrollo que suponía que no había fallas a un modelo en el que las fallas se consideraban inevitables, lo que llevó a los desarrolladores a considerar la resiliencia incorporada como una obligación en lugar de una opción:
“En Netflix, nuestra cultura de libertad y responsabilidad nos llevó a no obligar a los ingenieros a diseñar su código de una manera específica. En cambio, descubrimos que podíamos alinear a nuestros equipos en torno a la noción de resiliencia de la infraestructura aislando los problemas creados por la neutralización de servidores y llevándolos al extremo. Hemos creado Chaos Monkey, un programa que elige aleatoriamente un servidor y lo desactiva durante sus horas habituales de actividad. Algunos pensarán que es una locura, pero no podíamos depender de la ocurrencia aleatoria de un evento para probar nuestro comportamiento frente a las consecuencias de ese evento. Saber que esto sucedería con frecuencia ha creado una fuerte alineación entre los ingenieros para construir redundancia y automatización de procesos para sobrevivir a tales incidentes, sin afectar a los millones de usuarios de Netflix. Chaos Monkey es una de nuestras herramientas más efectivas para mejorar la calidad de nuestros servicios”. [15]
Al "matar" periódicamente instancias aleatorias de un servicio de software, fue posible probar una arquitectura redundante para verificar que una falla del servidor no afectara notablemente a los clientes.
El concepto de ingeniería del caos es similar al de los servidores Phoenix, introducido por primera vez por Martin Fowler en 2012. [16]
Chaos Monkey es una herramienta inventada en 2011 por Netflix para probar la resiliencia de su infraestructura de TI. [13] Funciona desactivando intencionalmente las computadoras en la red de producción de Netflix para probar cómo responden los sistemas restantes a la interrupción. Chaos Monkey ahora es parte de un conjunto más grande de herramientas llamadas Simian Army, diseñadas para simular y probar las respuestas a varias fallas del sistema y casos extremos.
El código detrás de Chaos Monkey fue publicado por Netflix en 2012 bajo una licencia Apache 2.0. [17] [18]
El nombre "Mono del Caos" se explica en el libro Monos del Caos de Antonio García Martínez: [19]
Imaginemos a un mono entrando en un «centro de datos», esas «granjas» de servidores que albergan todas las funciones críticas de nuestras actividades online. El mono arranca cables al azar, destruye dispositivos y devuelve todo lo que pasa por su mano [es decir, arroja excrementos]. El reto para los responsables de TI es diseñar el sistema de información del que son responsables de manera que pueda funcionar a pesar de estos monos, que nunca se sabe cuándo llegan ni qué destruirán.
Simian Army [18] es un conjunto de herramientas desarrolladas por Netflix para probar la confiabilidad, seguridad o resiliencia de su infraestructura de Amazon Web Services e incluye las siguientes herramientas: [20]
El "Día del Caos" de 2017 de Voyages-sncf.com [23] gamificó la simulación de fallas de preproducción [24] para presentarla en la conferencia DevOps REX de 2017. [25] Fundada en 2019, Steadybit popularizó el caos de preproducción y la ingeniería de confiabilidad. [26] Su centro de confiabilidad de código abierto extiende Steadybit. [27] [28]
Proofdock puede inyectar fallas de infraestructura, plataforma y aplicaciones en Microsoft Azure DevOps . [26] Gremlin es una plataforma de "falla como servicio". [29] El Proyecto Storm de Facebook simula fallas en centros de datos para brindar resistencia a desastres naturales. [30]