Dentro de la Ingeniería del Caos

Ingeniería del Caos[note]Nota: este artículo está… profundamente anotado y está destinado a aquellos usuarios/lectores que ni son ingenieros de sistemas ni desarrolladores de software pero que están interesados en este tipo de materias. Por lo tanto, solo he arañado brevemente la superficie y he intentado hacer todo esto comprensible, así que solicito vuestra paciencia y comprensión[/note] no es más que un movimiento que seguramente va a crecer a lo largo de los años diseñado para aumentar dramáticamente la calidad de los servicios. Piensa que el software, como tal, ya no es lo que era, una serie de líneas de código para un propósito muy determinado que se ejecutaba de forma independiente en un dispositivo y cuyo fallo afectaba solo a ese dispositivo. Ahora, cualquier desarrollador de software sabe que las aplicaciones que crea se comunican con el exterior y se han convertido en servicios[note]Y deben ser tratadas como servicios[/note] con una menor o mayor estructura. No tienes que irte muy lejos: es impensable que una aplicación, hoy en día, no sea capaz de sincronizar sus contenidos o preferencias y ajustes con la misma aplicación en otros dispositivos, pero este es solo un ejemplo muy básico. Como tal, el software de ejecución única se convierte en un servicio y el fallo de este servicio, o mejor, la infraestructura del servicio, genera problemas que pueden escalarse a millones de usuarios del mismo.

Uno de los evangelistas de este movimiento es Kolton Andrus, fundador y CEO de una empresa llamada Gremlin[note]Un gremlin es una criatura mitológica de naturaleza malévola, popular en la tradición de países de habla inglesa y surgida probablemente a comienzos del siglo XV. La historia popular describe a los gremlins como capaces de sabotear todo tipo de maquinaria. Esta percepción de las criaturas dio origen, por ejemplo, a que los pilotos ingleses de la Royal Air Force (RAF) de servicio en Oriente Medio durante la Segunda Guerra Mundial narraran un cuento que intentaba atribuir los accidentes frecuentes que sucedían en sus vuelos a la acción de estos seres fantásticos. El nombre, pues, tiene todo el sentido. ?[/note] que ha trabajado durante años en Amazon y Netflix y donde ha implementado los principios de esta metodología en los equipos de software.[note]Kolton es entrevistado aquí[/note]

Necesitamos identificar las debilidades antes de que se manifiesten en comportamientos aberrantes a nivel de todo el sistema.Principios de la Ingeniería del Caos

Hay una notable diferencia entre Devops[note]Con frecuencia a lo largo de este artículo hay definiciones extraídas de la Wikipedia [/note] e Ingeniería del Caos. DevOps (acrónimo inglés de development -desarrollo- y operations -operaciones-) es una práctica de ingeniería de software que tiene como objetivo unificar el desarrollo de software (Dev) y la operación del software (Ops). La principal característica del movimiento DevOps es defender enérgicamente la automatización y la monitorización en todos los pasos de la construcción del software, desde la integración, las pruebas, la liberación hasta la implementación y la administración de la infraestructura. DevOps apunta a ciclos de desarrollo más cortos, mayor frecuencia de implementación, lanzamientos más confiables, en estrecha alineación con los objetivos comerciales.

Devops es el orden en la construcción, pero su funcionalidad como tal termina donde empieza la Ingeniería del Caos: mientras que con esta práctica[note]Devops[/note] se pueden construir servicios muy ágiles y con una respuesta muy rápida ante problemas, la Ingeniería del Caos se limita a “estirar de los cables y a ver que pasa”[note]Bueno, no es solo eso, pero es una definición gráfica y sencilla[/note], para luego definir metodologías que permitan protocolos de corrección inmediata y automática ante la degradación de un servicio. 

Esto es importante porque hay que definir dónde están los puntos clave, aquellos más dañinos para nuestro servicio y que pueden causar una mayor degradación en cascada desde la infraestructura al usuario, aunque no siempre un punto clave es el culpable de esa degradación o simplemente esos puntos clave no están al alcance ni del ingeniero de sistemas o del desarrollador de software. No se trata solo de ejecutar Unit Test[note]En programación, una prueba unitaria es una forma de comprobar el correcto funcionamiento de una unidad de código. Por ejemplo en diseño estructurado o en diseño funcional una función o un procedimiento, en diseño orientado a objetos una clase. Esto sirve para asegurar que cada unidad funcione correctamente y eficientemente por separado. Además de verificar que el código hace lo que tiene que hacer, verificamos que sea correcto el nombre, los nombres y tipos de los parámetros, el tipo de lo que se devuelve, que si el estado inicial es válido entonces el estado final es válido. La idea es escribir casos de prueba para cada función no trivial o método en el módulo, de forma que cada caso sea independiente del resto. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión[/note] para el código o ejecutar las correspondientes pruebas de integración: simplemente hay gran cantidad de variables que quedan fuera del entorno del desarrollador y que pueden alterar el estado estable de un servicio: desde un vicio oculto  en el firmware de un dispositivo sobre el que se va a ejecutar su código pasando por cambios que un desarrollador no puede anticipar, puesto que en muchos casos, son inaccesibles, y que dependen por ejemplo de los proveedores de pasarela del servicio en cuestión[note]Un caso claro de este ejemplo es cómo Telefónica “boicotea” a Netflix en una situación no esperada y de la que no es culpable el desarrollador del código, el del servicio y el de su arquitectura/estructura ni los departamentos de Q&A. Es aquí donde un Ingeniero del Caos se mueve para tratar de definir cómo superar la degradación del servicio por causas cambiantes y no definidas, pero es solo un caso al azar.[/note].

Es aquí donde entra en juego, en palabras de Kolton Andrus, “la resiliencia como servicio“[note]Realmente Kolton prefiere “Fallo como servicio” pero esto hace difícil vender la empresa – y es bastante comprensible, ? – .[/note]. Así, los ingenieros de su empresa[note]Ingenieros del Caos, que suena desafiante y muy divertido, por cierto[/note] pueden configurar diferentes escenarios, ejecutar simulaciones de esos escenarios, y lo más importante, revertir rápidamente un escenario si un sistema está degradando peor de lo esperado. La idea es ofrecer un control exacto sobre cada paso de la simulación.

La ingeniería del Caos tiene una página[note]Actualizada en abril de 2017 a la publicación de este artículo[/note] en la que se definen los principios de esta forma de trabajo. Vamos a por ella[note]Está traducida del inglés y he preferido dejar el tratamiento de usted planeado en el texto original[/note] y a comentar diferentes aspectos de la misma.

Principios de la Ingeniería del Caos

Los avances en los sistemas de software distribuidos a gran escala están cambiando el juego para la ingeniería de software. Como industria, somos rápidos en adoptar prácticas que aumentan la flexibilidad de desarrollo y la velocidad de despliegue. Después de estas ventajas se plantea una pregunta urgente: ¿cuánta confianza podemos tener en los complejos sistemas que ponemos en producción?

Incluso cuando todos los servicios individuales de un sistema distribuido funcionan correctamente, las interacciones entre ellos pueden causar resultados impredecibles. Los resultados impredecibles, agravados por acontecimientos raros pero perturbadores del mundo real que afectan a los entornos de producción, hacen que estos sistemas distribuidos sean intrínsecamente caóticos.

Necesitamos identificar las debilidades antes de que se manifiesten en comportamientos aberrantes a nivel de todo el sistema. Debemos tratar las debilidades más significativas proactivamente, antes de que afecten a nuestros clientes en la producción. Necesitamos una manera de manejar el caos inherente en estos sistemas, aprovechar la creciente flexibilidad y velocidad, y tener confianza en nuestros despliegues de producción a pesar de la complejidad que representan.

Un enfoque empírico y basado en sistemas aborda el caos de los sistemas distribuidos a escala y crea confianza en la capacidad de esos sistemas para soportar condiciones realistas. Aprendemos sobre el comportamiento de un sistema distribuido observándolo durante un experimento controlado. Llamamos a esto Ingeniería del Caos.

Caos en la práctica

Para abordar específicamente la incertidumbre de los sistemas distribuidos a escala, la ingeniería del Caos puede ser concebida como la facilitación de experimentos para descubrir debilidades sistémicas. Estos experimentos siguen cuatro pasos:

1. Comience por definir el “estado estable” como un resultado mensurable de un sistema que indica un comportamiento normal.[note]Este es el punto de partida: definir un estado estable del servicio y un valor para el mismo y surgen muchas preguntas al respecto ¿A partir de qué punto un estado estable deja de serlo para convertirse en un estado degradado? ¿Cómo se establece ese valor, de forma general para todo el servicio o en segmentos de usuarios afectados por una degradación parcial o total?[/note]
2. Se supone que este estado estable continuará tanto en el grupo de control como en el grupo experimental.
3. Introducir variables que reflejen eventos del mundo real como servidores que se bloquean, discos duros que funcionan mal, conexiones de red que se cortan, etc.
4. Trate de refutar la hipótesis buscando una diferencia en el estado estable entre el grupo de control y el grupo experimental.

Cuanto más difícil es interrumpir el estado estable, más confianza tenemos en el comportamiento del sistema. Si se descubre una debilidad, ahora tenemos un objetivo de mejora antes de que ese comportamiento se manifieste en el sistema en general.

Enfóquese en los resultados mensurables de un sistema, más que en los atributos internos del sistema.Principios avanzados de la Ingeniería del Caos

Principios avanzados

Los siguientes principios describen una aplicación ideal de la Ingeniería del Caos, aplicada a los procesos de experimentación descritos anteriormente. El grado en que se persiguen estos principios se correlaciona fuertemente con la confianza que podemos tener en un sistema distribuido a escala.

Construya una Hipótesis en torno al Comportamiento de Estado Fijo

Enfóquese en los resultados mensurables de un sistema, más que en los atributos internos del sistema. Las mediciones de esa producción durante un corto período de tiempo constituyen una aproximación al estado estable del sistema. El rendimiento total del sistema, las tasas de error, los porcentajes de latencia, etc. pueden ser métricas de interés que representen el comportamiento del estado estable. Al enfocarse en patrones de comportamiento sistémico durante los experimentos, Caos verifica que el sistema funciona, en lugar de intentar validar cómo funciona.

Variar los eventos del mundo real

Las variables de caos reflejan eventos del mundo real. Priorice los eventos ya sea por impacto potencial o frecuencia estimada. Considere los eventos que corresponden a fallas de hardware como la muerte de servidores, fallas de software como respuestas malformadas y eventos no fallidos como picos en el tráfico o eventos de escalamiento. Cualquier evento capaz de alterar el estado estable es una variable potencial en un experimento de Caos.

Ejecutar experimentos en producción

Los sistemas se comportan de forma diferente según el entorno y los patrones de tráfico. Dado que el comportamiento de utilización puede cambiar en cualquier momento, el muestreo del tráfico real es la única manera de capturar de forma fiable la ruta de petición. Para garantizar tanto la autenticidad de la forma en que se ejerce el sistema como la pertinencia del actual sistema desplegado, Caos prefiere fuertemente experimentar directamente sobre el tráfico de producción.[note]Aquí más de un ingeniero de sistemas se muere del susto, pero esta metodología no es para cobardes, claramente, requiere de una preparación previa para recuperar el estado fijo – estable – del sistema tras un test de estrés ante un fallo provocado[/note]

Automatice los experimentos para que se ejecuten continuamente

Realizar experimentos manualmente es laborioso y, en última instancia, insostenible. Automatice los experimentos y ejecútelos continuamente. Chaos Engineering integra la automatización en el sistema para impulsar tanto la orquestación como el análisis.

Minimizar el radio de explosión

Experimentar en la producción tiene el potencial de causar dolor innecesario al cliente. Si bien debe haber un margen para algún impacto negativo a corto plazo, es responsabilidad y obligación del Ingeniero del Caos asegurar que las consecuencias de los experimentos sean minimizadas y contenidas.

La ingeniería del Caos es una práctica poderosa que ya está cambiando la forma en que se diseña y se diseña el software en algunas de las operaciones de mayor escala del mundo. Donde otras prácticas abordan la velocidad y la flexibilidad, La ingeniería del Caos aborda específicamente la incertidumbre sistémica en estos sistemas distribuidos. Los Principios del Caos proporcionan confianza para innovar rápidamente a escalas masivas y ofrecer a los clientes las experiencias de alta calidad que se merecen.

Únase a la discusión en curso sobre los Principios del Caos y su aplicación en el Grupo de Google de la Comunidad del Caos.

Las variables de caos reflejan eventos del mundo real. Priorice los eventos ya sea por impacto potencial o frecuencia estimada. Principios avanzados de la Ingeniería del Caos

Un paso adelante

Los ingenieros del Caos y aquellos que quieren profundizar en esta metodología de trabajo disponen, ademas de la página fundacional, una comunidad[note]Slack[/note] y reuniones a lo largo del mundo. O’Reilly dispone de un libro gratuito sobre este tema escrito por ingenieros de Netflix que están aplicando esta metodología.

Sin embargo, los ingenieros de Q&A[note]El aseguramiento de la calidad (se usa con frecuencia el anglicismo quality assurance) es el conjunto de actividades planificadas y sistemáticas aplicadas en un sistema de gestión de la calidad para que los requisitos de calidad de un producto o servicio sean satisfechos. Entre estas actividades se encuentran la medición sistemática, la comparación con estándares, el seguimiento de los procesos, todas actividades asociadas con bucles de realimentación de información. Estas actividades contribuyen a la prevención de errores, lo cual se puede contrastar con el control de calidad, que se centra en las salidas del proceso. Ambos conceptos suelen utilizarse de manera conjunta.[/note] pueden enarcar una ceja y limitarse a indicar que la Ingeniería del Caos no es más que una variación ostentosa  de algo que se lleva haciendo mucho tiempo.

Hay, sin embargo, alguna diferencia importante. Si el Control de calidad es igual a la medición de la calidad de un producto durante el proceso de prueba, se puede definir que las tareas de aseguramiento de la calidad están interesadas en el proceso de desarrollo del producto, mientras que testing y el control de calidad están interesados en el desarrollo del producto en sí mismo.

La Ingeniería del Caos, sin embargo, está interesada en el propio fallo en sí y en cómo afecta al servicio: los actuales sistema de Q&A prueban el actual desarrollo del software y el servicio y buscan errores en el mismo pero en muchas ocasiones no trabajan con el Qué Pasaría Si…[note]En la mayoría de los casos, aunque no es totalmente aplicable[/note] y por supuesto no se realizan este tipo de test con sistema en producción[note]O si se realizan, con un alcance muy, muy limitado[/note], algo que resulta impensable porque no se puede degradar el servicio para los usuarios.

Por otra parte, la Ingeniería del Caos[note]Que aparentemente lideran los ingenieros de Netflix y por buenas razones, más información en este interesante artículo[/note] no es simplemente un concepto: Chaos Monkey[note]Como parte de una suite de aplicaciones que se utilizan en Netflix para gestionar la Ingeniería del Caos[/note] es una herramienta que desactiva aleatoriamente las instancias en el entorno de producción durante el funcionamiento normal. Cuando se ejecuta en conjunción con una monitorización integral y un equipo de respuesta rápida en espera, ayuda a descubrir debilidades inesperadas en el sistema, lo que a su vez permite al equipo de desarrollo construir mecanismos automáticos de recuperación antes de tiempo, en lugar de tener que luchar para responder a una interrupción del servicio que coge por sorpresa a todo el mundo.