La ingeniería del caos (Chaos Engineering) es una disciplina que, según entiendo, surge alrededor de las actividades de migración de Netflix a la nube (presumiblemente de AWS)¹ . El equipo de Netflix entiende que un plan de contingencia no sirve de mucho si se espera a que a contingencia se presente para validarlo¹ . Tal vez la idea no sea tan novedosa como se dice, es decir, conceptos como COB y DRP existen desde ya hace tiempo, lo mismo que la noción de planes ante contingencias. Lo cierto es que a partir de dicho instante (aquel en el que los ingenieros de Netflix deciden que las cosas son ya demasiado complicadas como para validarlas en teoría, surge esta visión de experimentar directamente en el entorno de producción), impulsado por la publicación de herramientas usadas para este propósito hicieron que un término fuera acuñado y éste pegara.

Chaos engineering, es una disciplina de experimentación rigurosa y controlada² (al menos hasta cierto punto en el que no se comprometa seriamente la producción o entrega de servicios, supongo). El término «chaos» no debe sugerir una actividad que se realiza de forma desordenada y caótica; el término sólo sugiere que se trata de una actividad que debe vérselas con un nivel de complejidad grande y lo aborda desde un punto de vista «ingenieril».

Se trata sin lugar a dudas de un enfoque diferente a lo que tradicionalmente uno está acostumbrado a ver. En mi caso, el enfoque de COB y DRP no me es desconocido, y no dudo que muchos dirán que éste puede ser un enfoque equivocado a lo que debe ser un COB y un DRP. Sin embargo, eso no es lo que aquí discuto… y tal vez deba recurrir a un ejemplo apara ilustrar mi punto.

Cuando laboré en Banamex, ejercicios de COB y DRP eran planificados anualmente.  El ejercicio consistía en plantear una situación por la que el COB debería activarse. Por ejemplo, la falla de un servidor, la desaparición de un centro de cómputo, fallas de comunicaciones. La falla se simulaba, por supuesto, Por ejemplo, para simular que todo un centro de cómputo desaparecía simplemente se cerraba el tráfico a ellos en los balanceadores de carga, firewalls, proxys o algún elemento de comunicaciones. Ciertamente había algo de artificial en el hecho, pues no había condiciones de error… había algunas pero eran mínimas. Además, la prueba se hacía de noche, muy noche, cuando este tipo de cosas no afectaba (o lo hacía en forma mínima) a la operación diaria. Las «evidencias» de la causa del problema se tomaban apuntando por IP a alguna aplicación en el centro de cómputo desaparecido y registrando el mensaje o condición de no haber recibido respuesta. Luego se tomaban las evidencias de cómo la operación normal de los servicios desaparecidos no mostraba error (digamos invocando la aplicación por URL desde un lugar que por cercanía geográfica debería ser atendido por el centro de cómputo desaparecido. Se documentaba todo y se restablecía todo como antes de la prueba. ¿Resultado? Se informaba que el banco estaba preparado para soportar la desaparición de uno de sis centros de cómputo. Suena simple, pero estos ejercicios llevaban a tomar hasta tres horas. Iniciaban a las 22 o 23 hrs y culminaban a la una o dos de la mañana.

Por supuesto, cuando ocurría una falla, una verdadera falla… el COB era un fiasco. Entonces venían las caras de sorpresa, los regaños de los directivos, la exigencia de justificar el porqué las cosas estaban como estaban si ya habían sido validadas, cosas en las que se gastaba más tiempo, mucho más tiempo.

En enfoque que la ingeniería del caos presenta suena mucho más real, pero dudo mucho que un banco verdaderamente decida adoptarlo. Demasiado riesgo para ellos.

Referencias

1. «Chaos Engineering«, Wikipedia, web. Retrieved: 2018.12.07. URL: https://en.wikipedia.org/wiki/Chaos_engineering
2. Kolton Andrus, answering to «What is chaos engineering?«, Quora, web. Posted:2018.01.12; Consulted: 2018.12.07. URL: https://www.quora.com/What-is-chaos-engineering/answer/Kolton-Andrus