Estos días he estado leyendo bastante sobre las experiencias de Netflix aplicando el “Chaos Engineering”. La “Ingeniería del Caos”, que vendría a ser “la disciplina de experimentar en un sistema distribuido con el fin de fomentar la confianza en la capacidad del sistema para soportar condiciones turbulentas en producción”. Vamos, simplificadamente, hacer experimentos en producción para aprender y mejorar. Pásate por principlesofchaos.org si tienes curiosidad sobre el tema.
Desde hace años, Netflix, según ellos mismos cuentan, lleva usando el popular “Chaos Monkey”, un software de creación propia, un servicio interno que selecciona al azar instancias de máquinas virtuales en Amazon, donde están sus servicios en producción… y hace que se caigan. Por cierto, el código del Chaos Monkey es libre y te lo puedes bajar aquí y más info del mismo la puedes encontrar en el Tech Blog de Netflix.
Así es, me estoy imaginando la acara de alguno. Sí, cuando a media España tecnológica le aterra el DevOps, le da miedo aligerar los pasos a producción, está preocupada por como encajar ITIL en procesos ágiles, etc., y similares menesteres relacionados con el miedo al “¿y si se cae?”, tienes a otros por ahí que lo del DevOps ya se les quedó corto hace años y no sólo superaron esos miedos… sino que son ellos mismos los que se auto producen fallos en producción.
El “Chaos Monkey” (la traducción vendría a ser algo así como el Mono del Caos, pero suena raro) tiene como objetivo motivar a los ingenieros de Netflix a diseñar servicios que puedan soportar fallos en instancias. Lo activan sólo durante horario laboral, para que los equipos puedan responder rápidamente si un servicio falla debido a la anulación de una instancia.
Al parecer, y no lo dudo, el uso del “Chaos Monkey” ha demostrado su eficacia y ha hecho que todos los equipos de Netflix diseñen sus servicios pensando en la recuperación ante fallos en instancias, de manera rutinaria. Y, de hecho, el éxito del “Chaos Monkey” animó a ampliar el uso del llamado “injecting failures” y dio lugar a la “Simian Army”.
El ejercito Simio
La “Simian Army” incluye el “Chaos Monkey”, para tirar instancias al azar de máquinas virtuales en producción en Amazon, incluye al “Chaos Gorilla” que desactiva toda una zona en AWS, y el Chaos Kong, una herramienta que simula (ojo, simula) un corte en toda una región del Amazon (ellos trabajan con instancias en Virginia, Oregon y Dublín) para desviar el tráfico a las regiones restantes.
La Ingeniería del Caos
Romper cosas en producción, lo cual no tiene nada de novedoso… salvo que lo hagas aposta. “Chaos Engineering” es el nombre que se le está dando a esta disciplina.
La ingeniería del caos implica experimentación con un sistema distribuido para construir con confianza en su capacidad para soportar condiciones turbulentas en producción. Estas condiciones van desde fallos en el hardware, aumento inesperado del tráfico, etc.
Aunque media España tecnológica aún viva en el viejo mundo de intentar especificar todo en requisitos y pdfs, para dejarlos inmutables, cerrar los proyectos y dejar el éxito solo en manos de cumplir esos requisitos, todos sabemos que una especificación funcional describe de manera incompleta como un sistema de software debe comportarse.
La idea del “Chaos Engineering” suena muy ágil, como no puedo prever, especificar y controlarlo todo, pongamos en producción rápido y experimentemos.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
6/6/16 bonita fecha para hablar de «caos y destrucción masiva intencionada».
Le da un toque más «apocalíptico»… 😉
Gracias por el post. Muy «disruptor».
jaja, ni me había dado cuenta
Hola,
me ha interesado mucho y buscando en github hay bastantes repositorios muy variados, desde generar el caos en Azure, pasando por Angular hasta OpenStack.
En http://principlesofchaos.org/, se pueden leer los principios a tener en cuenta para crear el caos (que oscuro suena esto).
Gracias por tus post