Ingeniería del caos

Introducción: El nacimiento del caos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Ingeniería del Caos sigue siendo una disciplina relativamente nueva dentro del desarrollo de software. Esta introducción expone la historia, desde los humildes comienzos de la práctica hasta la época actual, en la que todas las grandes industrias la adoptan de alguna forma. En los últimos tres años, la pregunta ha pasado de "¿Deberíamos hacer Ingeniería del Caos?" a "¿Cuál es la mejor manera de empezar a hacer Ingeniería del Caos?".

La historia de nuestra naciente disciplina explica cómo pasamos de la primera a la segunda cuestión que acabamos de plantear. No queremos limitarnos a contar una historia de fechas y movimientos para que los hechos queden claros. Queremos contar la historia de cómo surgió, para que entiendas por qué surgió del modo en que lo hizo, y cómo puedes aprender de ese camino para sacar el máximo partido a la práctica.

La historia comienza en Netflix, donde los autores de este libro, Casey Rosenthal y Nora Jones, trabajaban cuando el Equipo del Caos definió y evangelizó la Ingeniería del Caos.¹ Netflix encontró un valor empresarial real en esta práctica, y cuando otros lo vieron, surgió una comunidad en torno a esta disciplina para difundirla por toda la tecnología.

Principios de gestión como código

A partir de en 2008, Netflix hizo un despliegue muy público² de pasar del centro de datos a la nube. En agosto de ese año, un grave problema de corrupción de la base de datos del centro de datos impidió a Netflix enviar DVD durante tres días. Esto fue antes de que el streaming de vídeo fuera omnipresente; la entrega de DVD era la mayor parte de su negocio.

La idea en aquel momento era que el centro de datos les encerraba en una arquitectura de puntos únicos de fallo, como grandes bases de datos, y componentes escalados verticalmente. El paso a la nube requeriría componentes escalados horizontalmente, lo que reduciría los puntos únicos de fallo.

Las cosas no salieron exactamente como estaba previsto. Por un lado, tardaron ocho años en salir por completo del centro de datos. Y lo que es más relevante para nuestros intereses, el cambio a prácticas de implementación en la nube a escala horizontal no coincidió con el aumento del tiempo de actividad del servicio de streaming que esperaban.³

Para explicar esto, tenemos que recordar que en 2008, Amazon Web Services (AWS) estaba considerablemente menos maduro de lo que está ahora. La computación en nube aún no era un producto básico, y ni mucho menos la opción de implementación por defecto y sin complicaciones que tenemos hoy en día. Por aquel entonces, el servicio en la nube prometía mucho, y una de esas promesas era que las instancias ⁴ ocasionalmente dejarían de existir sin previo aviso. Esta forma concreta de fallo era poco frecuente en un centro de datos, donde las grandes y potentes máquinas estaban bien cuidadas y a menudo se conocían bien las idiosincrasias de máquinas concretas. En un entorno de nube, donde esa misma cantidad de potencia la proporcionaban muchas máquinas más pequeñas que funcionaban con hardware básico, era un suceso desgraciadamente habitual .

Los métodos para construir sistemas resistentes a esta forma de fallo eran bien conocidos. Quizá se podrían haber enumerado media docena de prácticas comunes que ayudan a un sistema a sobrevivir automáticamente al fallo inesperado de uno de sus componentes constituyentes: nodos redundantes en un clúster, limitación del dominio de fallo aumentando el número de nodos y reduciendo la potencia relativa de cada uno, despliegue de redundancias en distintas geografías, autoescalado y automatización del descubrimiento de servicios, etc. El medio concreto para hacer que un sistema sea lo suficientemente robusto como para hacer frente a la desaparición de instancias no era importante. Incluso podría ser diferente según el contexto del sistema. Lo importante era que había que hacerlo, porque el servicio de streaming se enfrentaba a déficits de disponibilidad debido a la alta frecuencia de eventos de inestabilidad de instancias. En cierto modo, Netflix simplemente había multiplicado el efecto de punto único de fallo.

Netflix no era como otras empresas de software. Promovía de forma proactiva principios culturales derivados de una filosofía de gestión única, esbozada en una cubierta cultural. Esto se manifestó en varias prácticas que influyeron mucho en la forma en que Netflix resolvió el déficit de disponibilidad. Por ejemplo

• Netflix sólo contrataba a ingenieros superiores que tuvieran experiencia previa en la función para la que habían sido contratados.

• Dieron a todos los ingenieros plena libertad para hacer todo lo necesario para satisfacer el trabajo, concomitantemente con la responsabilidad de cualquier consecuencia asociada a esas decisiones.

• Fundamentalmente, Netflix confiaba en las personas que hacían el trabajo para decidir cómo se hacía el trabajo.

• La dirección no decía a los colaboradores individuales (CI) lo que tenían que hacer, sino que se aseguraba de que los CI comprendieran los problemas que había que resolver. Los CI decían entonces a la dirección cómo pensaban resolver esos problemas, y luego trabajaban para resolverlos.

• Los equipos de alto rendimiento están muy alineados y poco acoplados. Esto significa que hay que esforzarse menos en el proceso, la comunicación formal o la gestión de tareas si todos comparten el mismo objetivo en todos los equipos.

Esta interesante dinámica es parte de lo que contribuyó a la cultura de alto rendimiento de Netflix, y tuvo una interesante consecuencia en el desarrollo de la Ingeniería del Caos. Dado que el trabajo de la dirección no consistía en decir a los CI lo que tenían que hacer, en Netflix no existía esencialmente ningún mecanismo para que una persona, equipo o grupo dijera al resto de los ingenieros cómo escribir su código. Aunque se podrían haber escrito media docena de patrones comunes para escribir servicios lo bastante robustos como para manejar instancias que desaparecen, no había forma de enviar un edicto a toda la organización de ingenieros exigiendo que todos siguieran esas instrucciones.

Netflix tuvo que encontrar otra forma.

Nace el Mono del Caos

Se probaron muchas cosas de, pero una funcionó y se quedó: Chaos Monkey. Esta sencillísima aplicación recorría una lista de clusters, elegía una instancia al azar de cada cluster y, en algún momento del horario laboral, la apagaba sin previo aviso. Lo hacía todos los días laborables.

Suena cruel, pero el propósito no era molestar a nadie. Los operadores sabían que este tipo de fallo -la desaparición de instancias- iba a ocurrir a todos los clusters en algún momento. El Mono del Caos les proporcionó una forma de probar proactivamente la resistencia de todos al fallo, y hacerlo durante el horario laboral para que la gente pudiera responder a cualquier caída potencial cuando tuvieran los recursos para hacerlo, en lugar de a las 3 de la madrugada, cuando suelen sonar los buscapersonas. Aumentar la frecuencia a una vez al día actuaría como una prueba de regresión, asegurándose de que no se produjera una deriva hacia este modo de fallo más adelante.

El lore de Netflix dice que esto no fue popular al instante. Hubo un breve periodo de tiempo en el que los CI se quejaron del Mono del Caos. Pero parecía funcionar, así que cada vez más equipos acabaron adoptándolo.

Una de las formas en que podemos considerar esta aplicación es que tomó el dolor del problema en cuestión -la desaparición de instancias afectaba a la disponibilidad del servicio- y puso ese dolor en primer plano para todos los ingenieros. Una vez que tuvieron el problema delante, los ingenieros hicieron lo que mejor saben hacer: resolver el problema.

De hecho, si el Mono del Caos les caía el servicio todos los días, no podrían trabajar hasta que resolvieran el problema. No importaba cómo lo resolvieran. Quizá añadieran redundancia, quizá automatización de escalado, quizá patrones de diseño arquitectónico. Eso no importaba. Lo que importaba era que el problema se resolviera de algún modo, rápidamente y con resultados apreciables de inmediato.

Este refuerza el principio "altamente alineado, débilmente acoplado" de la cultura de Netflix. Chaos Monkey obligó a todo el mundo a estar muy alineado con el objetivo de ser lo suficientemente robusto como para gestionar instancias que desaparecen, pero poco acoplado en cuanto a cómo resolver este problema concreto, ya que no sugiere la solución.

Chaos Monkey es un principio de gestión instanciado en código en ejecución. El concepto en el que se basa parecía único y un poco raro, así que Netflix lo publicó en un blog. Chaos Monkey se convirtió en un popular proyecto de código abierto, e incluso en una herramienta de contratación que presentaba Netflix a posibles candidatos como una cultura creativa de ingeniería de software, no sólo como una empresa de entretenimiento. En resumen, Chaos Monkey fue designado un éxito. Esto sentó un precedente y ayudó a establecer esta forma de asumir riesgos y buscar soluciones creativas como parte de la identidad cultural de Netflix.

Avance rápido hasta el 24 de diciembre de 2012, víspera de Navidad.⁵ AWS sufrió una interrupción de los equilibradores de carga elásticos (ELB). Estos componentes conectan las solicitudes y dirigen el tráfico a las instancias informáticas donde se implementan los servicios. Al caerse los ELB, no se pudieron servir más solicitudes. Como el plano de control de Netflix se ejecutaba en AWS, los clientes no podían elegir vídeos y empezar a transmitirlos.

El momento era terrible. En Nochebuena, Netflix debería haber sido el centro de atención, ya que los primeros en adoptarlo mostraron a sus familiares lo fácil que era transmitir películas reales por Internet. En lugar de eso, las familias y los parientes se vieron obligados a hablar entre ellos sin la reconfortante distracción de la biblioteca de contenidos de Netflix.

Dentro de Netflix, esto dolió. No sólo fue un golpe para la imagen pública de la empresa y para el orgullo de la ingeniería, sino que a nadie le gustó que le sacaran de las vacaciones de Nochebuena con una alerta de búsqueda para ver cómo AWS daba tumbos en el proceso de reparación .

El Mono del Caos se había implementado con éxito para resolver el problema de la desaparición de instancias. Eso funcionó a pequeña escala. ¿Podría construirse algo similar para resolver el problema de las regiones que desaparecen? ¿Funcionaría a una escala muy, muy grande?

A lo grande

Cada interacción que el dispositivo de un cliente tiene con el servicio de streaming de Netflix se realiza a través del plano de control. Esta es la funcionalidad implementada en AWS. Una vez que un vídeo comienza a transmitirse, los datos del propio vídeo se sirven desde la red privada de Netflix, que es, con diferencia, la mayor red de distribución de contenidos (CDN) del mundo.

La interrupción de Nochebuena renovó internamente la atención sobre la creación de una solución activo-activo para servir el tráfico del plano de control. En teoría, el tráfico de los clientes del hemisferio occidental se dividiría entre dos regiones de AWS, una en cada costa. Si alguna de las regiones fallara, se crearía una infraestructura para escalar la otra región y trasladar allí todas las solicitudes.

Esta capacidad afectaba a todos los aspectos del servicio de streaming. Hay un retraso de propagación entre costas. Algunos servicios tendrían que modificar cosas para permitir la coherencia eventual entre costas, idear nuevas estrategias de compartición de estados, etc. Desde luego, no es una tarea técnica fácil.

Y, de nuevo, debido a la estructura de Netflix, no existe ningún mecanismo que obligue a todos los ingenieros a ajustarse a alguna solución centralizada y verificada que pudiera gestionar de forma certificable un fallo regional. En su lugar, un equipo respaldado por el apoyo de la alta dirección coordinó el esfuerzo entre los distintos equipos afectados.

Para asegurarse de que todos estos equipos tenían sus servicios a la altura de las circunstancias, se creó una actividad para desconectar una región. Bueno, AWS no permitía a Netflix desconectar una región (algo sobre que había otros clientes en la región), así que en su lugar se simuló esto. La actividad se denominó "Caos Kong".

Las primeras veces que se inició Chaos Kong, fue un asunto de nervios de acero, con una "sala de guerra" reunida para monitorear todos los aspectos del servicio de streaming, y duró horas. Durante meses, Chaos Kong se abortó antes de trasladar todo el tráfico fuera de una región, porque se identificaban problemas y se devolvían a los propietarios del servicio para que los solucionaran. Finalmente, la actividad se estabilizó y se formalizó como responsabilidad del Equipo de Ingeniería de Tráfico. Los Chaos Kong se realizaban rutinariamente para verificar que Netflix tenía un plan de acción en caso de que una sola región se cayera.

En muchas ocasiones, bien por problemas de Netflix, bien por problemas de AWS, una sola región sufrió un tiempo de inactividad significativo. En estos casos se puso en marcha el mecanismo de conmutación por error regional utilizado en Chaos Kong. Los beneficios de la inversión fueron evidentes.⁶

El inconveniente del proceso de conmutación por error regional era que, en el mejor de los casos, se tardaba unos 50 minutos en completarlo, debido a la complejidad de la interpretación e intervención manuales. En parte gracias al aumento de la frecuencia de Chaos Kong, que a su vez repercutió en las expectativas internas sobre la conmutación por error regional dentro de la organización de ingeniería, el Equipo de Ingeniería de Tráfico pudo poner en marcha un nuevo proyecto que, en última instancia, redujo el proceso de conmutación por error a sólo seis minutos.⁷

Esto nos lleva aproximadamente a 2015. Netflix tenía a Chaos Monkey y Chaos Kong, trabajando en la pequeña escala de instancias evanescentes y en la gran escala de regiones evanescentes, respectivamente. Ambos contaban con el apoyo de la cultura de ingeniería e hicieron contribuciones demostrables a la disponibilidad del servicio en este punto.

Formalizar la disciplina

Bruce Wong creó un Equipo de Ingeniería del Caos en Netflix a principios de 2015 y dejó la tarea de desarrollar un estatuto y una hoja de ruta a Casey Rosenthal. Sin saber muy bien en qué se había metido (originalmente fue contratado para dirigir el Equipo de Ingeniería del Tráfico, lo que siguió haciendo simultáneamente con el Equipo de Ingeniería del Caos), Casey recorrió Netflix preguntando qué pensaba la gente que era la Ingeniería del Caos.

La respuesta solía ser algo parecido a: "Ingeniería del caos es cuando rompemos cosas en producción a propósito". Sonaba bien, y podría ser un buen complemento para el resumen de un perfil de LinkedIn, pero no era muy útil. Cualquiera en Netflix con acceso a un terminal tenía los medios para romper cosas en producción, y lo más probable es que no aportara ningún valor a la empresa.

Casey se sentó con sus equipos para definir formalmente la Ingeniería del Caos. Concretamente querían claridad sobre

• ¿Cuál es la definición de Ingeniería del Caos?

• ¿Qué sentido tiene?

• ¿Cómo sé cuándo lo estoy haciendo?

• ¿Cómo puedo mejorar mi práctica de la misma?

Tras aproximadamente un mes de trabajo en una especie de manifiesto, elaboraron los Principios de la Ingeniería del Caos. La disciplina quedaba oficialmente formalizada.

La definición superformal de que se acordó fue: "La Ingeniería del Caos es la disciplina que consiste en experimentar en un sistema distribuido para generar confianza en la capacidad del sistema para soportar condiciones turbulentas en la producción". Esto establecía que es una forma de experimentación, que se sitúa al margen de las pruebas.

En primer lugar, el objetivo de hacer Ingeniería del Caos en es crear confianza. Esto es bueno saberlo, de modo que si no necesitas confianza, entonces esto no es para ti. Si tienes otras formas de fomentar la confianza, entonces puedes sopesar qué método es más eficaz.

La definición también menciona "condiciones turbulentas en la producción" para destacar que no se trata de crear el caos. La Ingeniería del Caos consiste en hacer visible el caos inherente al sistema.

Los Principios de describen una plantilla básica para la experimentación, que se inspira en gran medida en el principio de falsabilidad de Karl Popper. En este sentido, la Ingeniería del Caos se modela más como una ciencia que como una técnica.

Por último, los Principios de enumeran cinco prácticas avanzadas que establecen la norma de oro para una práctica de Ingeniería del Caos:

• Construye una hipótesis sobre el comportamiento en estado estacionario

• Variar los acontecimientos del mundo real

• Realiza experimentos en producción

• Automatiza los experimentos para que se ejecuten continuamente

• Minimizar el radio de la explosión

Cada uno de ellos se analiza sucesivamente en los capítulos siguientes.

El equipo de Netflix plantó bandera. Ahora sabían qué era la Ingeniería del Caos, cómo hacerla y qué valor aportaba a la organización en general.

Nace la Comunidad

Como ya se ha dicho, Netflix sólo contrataba a ingenieros experimentados. Esto significaba que si querías contratar ingenieros del caos, necesitabas un grupo de personas experimentadas en ese campo de donde contratar. Por supuesto, como acababan de inventar la disciplina, esto era difícil de hacer. No había Ingenieros del Caos senior para contratar, porque no había junior, porque fuera de Netflix no existían.

En para resolver este problema, Casey Rosenthal decidió evangelizar el campo y crear una comunidad de práctica. Empezó organizando una conferencia a la que sólo se podía asistir por invitación llamada "Día de la Comunidad del Caos" en otoño de 2015. Se celebró en las oficinas de Uber en San Francisco, y asistieron unas 40 personas. Estuvieron representadas las siguientes empresas: Netflix, Google, Amazon, Microsoft, Facebook, DropBox, WalmartLabs, Yahoo!, LinkedIn, Uber, UCSC, Visa, AT&T, NewRelic, HashiCorp, PagerDuty y Basho.

Las presentaciones no se grabaron, para que la gente pudiera hablar libremente de los problemas que tenían para convencer a la dirección de que adoptara la práctica, así como discutir los "fallos" y las interrupciones de forma extraoficial. Los ponentes fueron elegidos de antemano para hablar de cómo abordaban los temas de la resiliencia, la inyección de fallos, las pruebas de fallos, las pruebas de recuperación de desastres y otros temas relacionados con la Ingeniería del Caos.

Uno de los objetivos explícitos de Netflix al lanzar el Día de la Comunidad del Caos era inspirar a otras empresas a contratar específicamente para el puesto de "Ingeniero del Caos". Funcionó. Al año siguiente, el Día de la Comunidad del Caos se celebró en Seattle, en la torre de oficinas Blackfoot de Amazon. Un directivo de Amazon anunció que, tras el primer Día de la Comunidad del Caos, habían vuelto a convencer a la dirección para que creara un equipo de Ingenieros del Caos en Amazon. Ahora otras empresas también estaban adoptando el título de "Ingeniero del Caos".

Ese año, 2016, la asistencia ascendió a 60 personas. Entre las empresas representadas en la conferencia se encontraban Netflix, Amazon, Google, Microsoft, Visa, Uber, Dropbox, Pivotal, GitHub, UCSC, NCSU, Sandia National Labs, Thoughtworks, DevJam, ScyllaDB, C2, HERE, SendGrid, Cake Solutions, Cars.com, New Relic, Jet.com y O'Reilly.

A instancias de O'Reilly, al año siguiente el equipo de Netflix publicó un informe sobre el tema, Chaos Engineering, que coincidió con varias presentaciones y un taller en la conferencia Velocity de San José.

También en 2017, Casey Rosenthal y Nora Jones organizaron el Día de la Comunidad del Caos en San Francisco, en la oficina de Autodesk en 1 Market Street. Casey había conocido a Nora en el anterior Chaos Community Day cuando trabajaba en Jet.com. Desde entonces se ha trasladado a Netflix y se ha unido al Equipo de Ingeniería del Caos. Asistieron más de 150 personas, entre los sospechosos habituales de las grandes empresas de Silicon Valley que operan a gran escala, así como varias empresas emergentes, universidades y todo lo demás. Eso fue en septiembre.

Un par de meses después, Nora pronunció un discurso sobre la Ingeniería del Caos en la conferencia AWS re:Invent de Las Vegas ante 40.000 asistentes en persona y otros 20.000 en streaming. La Ingeniería del Caos había llegado a lo más alto.

Evolución rápida

Como verás en a lo largo de este libro, los conceptos enhebrados en la Ingeniería del Caos evolucionan rápidamente. Eso significa que gran parte del trabajo realizado en este campo se ha desviado de la intención original. Algunos incluso pueden parecer contradictorios. Es importante recordar que la Ingeniería del Caos es un enfoque pragmático iniciado en un entorno de alto rendimiento que se enfrenta a problemas únicos a escala. Este pragmatismo sigue impulsando el campo, incluso cuando parte de su fuerza procede de la ciencia y el mundo académico.

¹ Casey Rosenthal creó y dirigió el Equipo de Ingeniería del Caos durante tres años en Netflix. Nora Jones se incorporó pronto al Equipo de Ingeniería del Caos como ingeniera y líder técnica. Fue responsable de importantes decisiones arquitectónicas sobre las herramientas construidas, así como de su implementación.

² Yury Izrailevsky, Stevan Vlaovic y Ruslan Meshenberg, "Completing the Netflix Cloud Migration", Netflix Media Center, 11 de febrero de 2016, https://oreil.ly/c4YTI.

³ A lo largo de este libro, nos referiremos generalmente a la disponibilidad del sistema como el "tiempo de actividad" percibido.

⁴ En una implementación basada en la nube, una "instancia" es análoga a una máquina virtual o un servidor en la jerga industrial anterior.

⁵ Adrian Cockcroft, "A Closer Look at the Christmas Eve Outage", The Netflix Tech Blog, 31 de diciembre de 2012, https://oreil.ly/wCftX.

⁶ Ali Basiri, Lorin Hochstein, Abhijit Thosar y Casey Rosenthal, "Chaos Engineering Upgraded", The Netflix Technology Blog, 25 de septiembre de 2015, https://oreil.ly/UJ5yM.

⁷ Luke Kosewski y otros, "Proyecto Nimble: Region Evacuation Reimagined", The Netflix Technology Blog, 12 de marzo de 2018, https://oreil.ly/7bafg.