Chaos

Chaos Engineering o cómo predecir la incertidumbre en TI

Chaos Engineering es un filosofía de trabajo que se basa en experimentar en sistemas en producción para predecir la incertidumbre de las infraestructuras de TI.

«Si algo puede salir mal, va a salir mal”

En la era de los procesos y desarrollos ágiles, los microservicios, contenedores, sistemas distribuidos, la automatización de la infraestructura de TI poder predecir el funcionamiento de un sistema puede ser complejo, más aún porque cada área de estos sistemas distribuidos tiene un dueño, su propia gente y su propio soporte.

La Filosofía Chaos Engineering busca crear confianza en los sistemas basándose en experimentos. Añadir Variables del mundo real en los sistemas para ver cómo estos reaccionan, cuán preparados estamos para estos cambios e incluso entender mejor el sistema y todos los recursos involucrado. Chaos Engineering se basa en el principio: «La Ingeniería del Caos es la disciplina de experimentar en un Sistema distribuido, con la finalidad de generar confianza en la capacidad del Sistema para soportar condiciones turbulentas en producción». 

Los principios del Chaos Engineering: https://principlesofchaos.org/

¿Cuándo fue la última vez que hicimos pruebas en los sistemas con todos los componentes involucrados?

Muchos CIOs aseguran hacer pruebas de disponibilidad en sus sistemas, a lo que apunta Chaos Engineering es a hacer experimentos con los sistemas en producción con todos componentes que interactúan para un servicio, el hacer pruebas separadas de redes, servidores, aplicaciones y bases de datos no necesariamente muestran la fotografía completa, por eso la importancia de que se pruebe en producción y con todos los responsables. 

Hacer este tipo de experimentos permiten a los responsables por un lado entender completamente el flujo que lleva realmente un servicio, estar listos cuando suceda en realidad y estar seguros y confiados de que el sistema es resistente a este tipo de fallos.

Hacer pruebas con variables del mundo real en ambientes en producción hará que cuando ocurra el problema de verdad en la noche de navidad o año nuevo sepas qué hacer, qué pasos dar y cómo actuar.

Esto es realmente importante en sistemas distribuidos, con microservicios y muchos componentes enlazados para prestar un servicio. Iniciar el caos en infraestructuras de este tipo nos obliga a entender el funcionamiento, predecirlo y reaccionar ante estos eventos “en el mundo real”.

Introducir el Caos

  • Iniciar definiendo el “Baseline”, el comportamiento normal, cuando todo esta funcionando.
  • Introducir Hipótesis positiva de qué pruebas se quieren hacer con un objetivo claro y medible (establecer métricas de disponibilidad, de sistema, de usuarios, específica de los servicios y del negocio). 
  • Iniciar experimentos con variables del mundo real, falla de servidores, discos duros, servicios, caídas de red, etc.
  • Analizar los resultados del experimento, descubrir fortalezas y debilidades en base a las métricas establecidas.

La diferencia entre desconectar por desconectar y Chaos Engineering es el establecimiento de objetivos y métricas de cada experimento, el notificar a todos los involucrados y reducir el impacto al mínimo posible.

El establecimiento de métricas y monitores es primordial para el análisis del experimento, conocer el comportamiento del sistema y saber qué ocurre al introducir variables del mundo real.

El Chaos Engineering no es algo nuevo, empresas muy grandes como Netflix o LinkedIn son abanderadas de la filosofía incluyendo además equipos con roles específicos y el juego de roles donde unos generan el caos y otros lo interpretan y resuelven y la automatización del caos cada cierto tiempo.

Todo lo que debe considerar para un Plan de Recuperación de Desastres efectivo http://juancarlossaavedra.me/2017/04/todo-lo-que-debe-considerar-para-un-plan-de-recuperacion-de-desastres-efectivo/