Introducción a chaos engineering.

Desde hace varios años, la digitalización de las compañías ha provocado que los sistemas de TI hayan pasado de ser un complemento del Negocio a ser “EL NEGOCIO”.

Son múltiples los ejemplos que podemos encontrarnos y que nos ayudan a ponernos en perspectiva sobre la magnitud de las consecuencias cuando se producen pérdidas de servicio:

• En marzo de 2015 un corte de servicio de 11h en el Apple Store les supuso pérdidas por valor de $25 millones.
• En marzo de 2019 un corte de servicio de 14h en Facebook causó pérdidas estimadas en $90 millones.
• En agosto de 2016 un corte de energía en el centro de control de Delta Airlines originó la cancelación de más de 2.000 vuelos y un impacto de $150 millones.

¿Por qué ahora?

Los problemas asociados a los fallos en los sistemas TI no son nuevos, han sucedido desde que los propios sistemas existen. Entonces, ¿por qué darles tanta importancia en este momento?

En los últimos años estamos siendo partícipes de una auténtica revolución en la forma en la que se diseñan, se desarrollan y se operan las plataformas digitales. Conceptos como las Arquitecturas distribuidas basadas en Microservicios, Cloud Computing, NoOps, Continuous Delivery, GitOps, Infraestructura como Código, Micro-frontends, entre otras, son disrupciones tecnológicas que aportan múltiples beneficios pero que, a su vez, traen consigo ciertos retos que se deben tener muy en cuenta.

Uno de los grandes retos de estas arquitecturas es la resiliencia de los sistemas de información. A medida que la plataforma crece, la complejidad en la gestión de la estabilidad del sistema a nivel global aumenta de manera exponencial.

Predecir el comportamiento de la plataforma ante eventuales fallos en este entorno se torna crítico.

¿Qué es chaos engineering?

En este post os vamos a contar qué es Chaos engineering y por qué esta disciplina está tan de moda. Si estás interesado en conocer más a fondo esta ingeniera del caos te recomendamos estas lecturas:

• Aprende a planificar una estrategia de chaos engineering aplicada a una organización.
• Conoce las herramientas y frameworks más extendidos.
• Y analiza una pequeña infraestructura para ver cómo dividir en fases la implantación de las hipótesis.

Chaos engineering es una disciplina que nos permite identificar fallos antes de que se conviertan en pérdidas de servicio. Al probar de manera proactiva cómo responde una plataforma, podemos identificar y corregir fallos antes de que sea demasiado tarde.

Tradicionalmente las organizaciones suelen trabajar con el término “Disaster Recovery” donde se generan planes de actuación que permiten mitigar las consecuencias de una situación de emergencia y volver a una estabilidad.

Chaos Engineering, sin embargo, busca generar un sistema que pueda sobrevivir a esas emergencias, en base a tratar de comparar lo que creemos que sucederá con lo que realmente sucede en nuestra plataforma ante estas circunstancias. Literalmente, "romperemos cosas a propósito" para aprender a construir sistemas y aplicaciones más resilientes.

Para ello, utilizaremos un método científico basado en construir una hipótesis que define cuál es el comportamiento que esperamos de nuestra plataforma, para poder ejecutar un experimento que provoque fallos en ella y comprobar si nuestra hipótesis se cumple.

Comenzaremos ejecutando estos experimentos en partes pequeñas de nuestra aplicación o de nuestra infraestructura, empezando por entornos no productivos y, a medida que vayamos ganando confianza y mejorando la disponibilidad de estas pequeñas piezas, extenderemos nuestro radio de acción (conocido como blast radius) para abarcar chaos en partes más grandes de nuestra plataforma, extendiendo esta práctica hasta nuestro entorno de producción.

¿Cómo se origina?

Esta disciplina comienza de la mano de Netflix, la plataforma más grande de contenidos en streaming. Como parte de un post en su blog donde explican sus lecciones aprendidas durante la migración de sus sistemas de On Premise hacia AWS, en 2010 dieron a luz una aplicación llamada Chaos Monkey, cuyo código publicaron en 2012.

Durante esta migración, se dieron cuenta de que la mejor forma de evitar fallos era provocarlos constantemente. Entonces, implementaron una utilidad cuyo objetivo era atacar activamente la infraestructura, en este caso matando instancias u otros servicios de AWS de forma aleatoria, de forma que se asegurasen de que Netflix pudiera seguir dando servicio cuando estas circunstancias se producían.

En 2011 publicaron también el proyecto Simian Army, que completaba la funcionalidad proporcionada por Chaos Monkey.

¿Qué beneficios se obtienen de aplicar ingeniería del caos?

Tradicionalmente nos hemos preocupado de evitar que los fallos ocurran, creando muchos tests para asegurarnos de que nuestras aplicaciones funcionan correctamente, definiendo arquitecturas de sistemas en alta disponibilidad para poder dar servicio cuando los problemas ocurren, etc.

Esta disciplina busca justo lo contrario, queremos pasar a convivir con el fallo. Provocando fallos de forma aleatoria y aprendiendo de ellos haremos que nuestras aplicaciones, que van a dar vida a nuestro negocio, sean mucho más resilientes.

Chaos engineering puede ayudar a prevenir pérdidas económicas importantes a nivel de negocio, hacer que las personas técnicas tengan mayor confianza en sus aplicaciones y sistemas, e incluso reducir los costes operacionales reduciendo el número de incidencias que afecten a nuestra producción.

Para que esta disciplina tenga éxito es imprescindible contar con un potente sistema de observabilidad, que nos facilite la visualización de los datos necesarios para entender que la ejecución de los experimentos están teniendo en nuestra plataforma, siendo capaces de entender el comportamiento que producen para poder implementar las mejoras necesarias y poder así aumentar la disponibilidad.

¿Qué conocimientos son necesarios? ¿Existe un nuevo rol asociado? ¿Quiénes deben involucrarse?

En muchas compañías, normalmente de tamaño considerable, existe el rol de “Chaos Engineer” e, incluso, equipos completos con varias personas que tienen este mismo rol.

Quizás en el caso de compañías de menor tamaño, y desde la irrupción del concepto de equipos SRE (Site Reliability Engineering), lo más común suele ser integrar en estos equipos la responsabilidad de llevar a cabo esta disciplina. El objetivo de estas personas y equipos es el de ser “los propietarios” de esta disciplina, pero también de inculcarla dentro de la organización.

Poder responder a preguntas como “¿Qué ocurre en nuestros sistemas cuando se produce una indisponibilidad de la base de datos?”, “¿Cómo se comportan las aplicaciones en este caso?”, “¿Y si en lugar de indisponibilidad se producen latencias importantes entre los distintos sistemas o microservicios que componen nuestra aplicación?” o “¿Podemos seguir vendiendo nuestro producto o servicio bajo estas condiciones?”, requieren conocimientos específicos en función de las herramientas de chaos que se vayan a utilizar.

Y, aún más importante, es que deben ser capaces de involucrar a todos los equipos que dan vida a la plataforma dentro de la compañía:

• Negocio
• Aplicación
• Middleware
• Networking
• Infraestructura
• Seguridad
• Operaciones...

Todos deben estar implicados con esta disciplina y, sumando el conocimiento que aportan, deben ser capaces de dar respuesta a las preguntas señaladas anteriormente, establecer un comportamiento base de las aplicaciones para que nuestro negocio siga funcionando correctamente, y apoyarse en la ejecución de experimentos de chaos hasta mejorar los resultados tratando de alcanzar ese comportamiento base que hemos definido bajo condiciones difíciles de la plataforma.

¿Cuándo aplicar esta disciplina?

Los sistemas distribuidos son infinitamente más complejos que los sistemas monolíticos, por lo que es difícil predecir todas las formas en que podrían fallar. Deberíamos considerar la aplicación de esta disciplina si las aplicaciones que dan vida a nuestro negocio son Cloud Native.

¿Cómo empezar a aplicar esta disciplina?

Chaos engineering no es solamente “romper cosas en producción”, es un viaje.

En este viaje aprenderemos a romper cosas en un entorno controlado (cualquier entorno) mediante experimentos bien planificados para construir una aplicación que soportará condiciones turbulentas.

La ingeniería del caos es un proceso que debe ser iterativo e incremental. Los procesos más críticos, desde el punto de vista de negocio o del soporte a negocio, deben ser los primeros en analizar y estudiar para posteriormente ir cubriendo otros procesos en función de su criticidad.

Comenzaremos ejecutando experimentos actuando sobre una parte pequeña y controlada de nuestra infraestructura o aplicación, lo que se denomina como blast-radius pequeño en este caso, para ir ganando confianza durante este camino, e iremos escalando nuestros experimentos para aumentar el blast-radius poco a poco.

Conclusión

Chaos engineering nos proporciona una herramienta para hacer nuestro trabajo más sencillo. Provocando fallos de manera intencionada conseguiremos innumerables beneficios que aumentarán la resiliencia de nuestro negocio, haciendo que las personas que lo conforman respiren más tranquilas, sabiendo que el riesgo de que se produzcan problemas en producción será mucho menor y pudiendo desempeñar su trabajo con más tranquilidad, dedicando el tiempo a tareas de mucho más valor en su día a día.

¿Te has quedado con ganas de más?

¡No te pierdas nuestro podcast!