Todos los sistemas software fallan, ¿Quiere$ que no te du-€la mucho? Más aún, ¿Quieres evitar la histeria mientras fallan? La respuesta no tiene misterio alguno: entrena duro. En esta línea se mueven los principios de Resilience Engineering o ingeniería tolerante a fallos y en este artículo os contamos cómo lo consiguen proveedores de servicios masivos como Amazon, Google o Netflix.

Resilience Engineering

La ingeniería tolerante a fallos es una disciplina relativamente reciente (año 2001, Erik Hollnagel) que se ha consolidado como la necesaria evolución hacia la seguridad adaptativa («Safety-II») incluso para ambientes tan exigentes como los Sistemas de Gestión del Tráfico Áreo («ATM systems») de EUROCONTROL.

En esencia, esta «ingeniería para lograr un comportamiento resiliente» plantea como perspectiva que la creciente complejidad de los sistemas conlleva efectos de resonancia funcional que pueden provocar que pequeños cambios en el comportamiento de los sistemas produzcan consecuencias desproporcionadas, no lineales e impredecibles. En resumen, es inviable conocer el comportamiento exacto de un sistema complejo frente a una demanda variable.

Por tanto nos enfocamos hacia estabilizar el rendimiento y por ello se considera resiliencia como una capacidad intrínseca de los sistemas para ajustar su funcionamiento antes, durante y/o después de cambios y disfunciones, de modo que puedan mantener las operaciones requeridas tanto frente a condiciones de funcionamiento esperadas como inesperadas (del libro Resilience Engineering in Practice, 2010).

Nuestro mantra:
cuanto más probable sea que algo funcione correctamente,
menos probable será que vaya mal.
Así que, a entrenar duro.

Cultivando la tolerancia a fallos

Esta mentalidad inspiró a Jesse Robbins ex-bombero, responsable de la disponibilidad web y «Master of Disaster» en Amazon.com. Para establecer la cultura de «estar preparado» impulsó en 2001 los GameDays, con mezcla de incidencias reales y simuladas, porque consideraba necesario entrenar para alcanzar una respuesta solvente frente a los problemas.

De forma similar desde 2005 en Google tenemos a Kripa Krishnan con el evento de Disaster Recovery Test (DiRT): ámbito global, varios días de duración, exigente.

«Sin embargo, para obtener el máximo beneficio de este tipo de eventos de recuperación de sistemas,
una organización también necesita invertir en
probar de forma continua sus servicios.»
Kripa Krishnan
——–
(extracto) «However, to benefit the most from such recovery events,
an organization also needs to invest in continuous testing of its services.»
Kripa Krishnan

El caos de la mano como ventaja

El siguiente peldaño lo subieron con fuerza en Netflix empezando por la patente de su «Validating the resilency of networked applications» en 2010, siguiendo con los artículos sobre esta cuestión publicados en el blog técnico de Netflix y culminando con la liberación en 2012 de la plataforma Chaos Monkey para Amazon desde el Netflix Open Source Software Center (OSS), en continua evolución.

Así, partiendo de emular los efectos de soltar a un «mono salvaje con pistolas» en los centros de datos, empezaron por crear el Chaos Monkey, una herramienta que deshabilitaba aleatoriamente instancias en producción pero que les permite provocar fallos cuando están los ingenieros preparados para atenderlos y aprender de ellos.

Objetivo: asegurar que frente a incidencias
Netflix es capaz de seguir ofreciendo
una calidad de servicio suficiente.

El éxito del Chaos Monkey les inspiró para constituir la Simian Army como una colección de primates virtuales especializados:

• Latency Monkey: introduce latencias en la capa de comunicaciones RESTful entre cliente y servidor para simular degradaciones de servicio e, incluso, caídas.
• Conformity Monkey: revisa que se están aplicando las buenas prácticas establecidas.
• Doctor Monkey: chequea la salud de los sistemas y retira los enfermos.
• Security Monkey: busca violaciones de las políticas de seguridad, vulnerabilidades o certificados próximos a caducar, por ejemplo.
• 10-18 Monkey: el nombre hace referencia a la Localización e Internacionalización de las aplicaciones y busca problemas en instancias para diversos lenguajes o juegos de caracteres.
• Janitor Monkey: libera recursos ociosos en los servicios de Amazon (AWS).
• Chaos Gorilla: tiene una filosofía similar al Chaos Monkey pero a nivel de zonas de disponibilidad de Amazon.
• Chaos Kong: te lo puedes imaginar, simula la caída de una región entera de Amazon, que incluye varias zonas de disponibilidad ¿Quién dijo miedo?.

Chaos Monkey y la Simian Army

Lo hemos mencionado someramente, pero todo esto tiene poco sentido si no somos capaces de saber cuándo el sistema falla o si está rindiendo conforme a los parámetros de referencia (Acuerdos de Nivel de Servicio – SLA).

Es decir, hay que estar comprobando continuamente que las aplicaciones en producción funcionan. Nuestra solución de automatización Zahorí puede ayudarte con ello, por descontado.

¿Hacia dónde vamos con tanto Chaos Monkey?

Desde Netflix se está impulsando la consolidación del Chaos Engineering, empezando por sus principios: Principles of Chaos Engineering.

De fondo tenemos las tésis de Nassim Nicholas Taleb que en 2012 publicó «Antifragile: things that gain from disorder» estableciendo los Sistemas Antifrágiles como aquellos que mejoran cuando sufren incidentes.

Este es el siguiente nivel: construir sistemas que no solo son capaces de aguantar frente a los problemas sino que son maleables y mejoran su rendimiento conforme los afrontan.

«Antifragility is beyond resilience or robustness.
The resilient resists shocks and stays the same;
the antifragile gets better»
Nassim Nicholas Taleb

Si te interesa seguir con el tema, te recomendamos:

• Sesión «Haciendo el (Chaos) Monkey» por Alejandro Guirao Rodríguez desde el Centro de Innovación del BBVA. Muy didáctica.
• Visita Netflix Open Source Software Center en Github.
• La visión desde Google: Weathering the Unexpected
• White Paper de Eurocontrol: From Safety-I to Safety-II

 Hay dos tipos de sistemas software:
los que han fallado y
los que van a fallar.
¿Estás preparado?