¿Qué es la Ingeniería del Caos?
Sus clientes, clientes, visitantes e incluso empleados internos, confían en que sus sistemas funcionen, estén disponibles y funcionen todo el tiempo. En un mundo perfecto, nunca habría un término para cuando los sistemas, aplicaciones y servicios se derrumban, pero este no es un mundo perfecto, y desafortunadamente, a veces las cosas no salen según lo planeado. Las interrupciones y el tiempo de inactividad pueden costar a las empresas millones de dólares. A veces, el mejor plan es un plan para lo inesperado, que es exactamente lo que la ingeniería del caos busca resolver. La ingeniería del caos, también conocida como prueba de caos, puede considerarse una disciplina, o enfoque, para probar y construir un sistema que pueda soportar fallas o condiciones inesperadas.
Con el advenimiento de las prácticas de DevOps, las organizaciones, desde startups hasta empresas, han adoptado lentamente sus propias prácticas de prueba de caos en sus flujos de trabajo de desarrollo. Ya sea que la ingeniería del caos sea llevada a cabo por equipos específicos o como parte de las responsabilidades de los ingenieros de confiabilidad del sitio (SRE),la práctica de la ingeniería del caos está diseñada para descubrir debilidades ocultas dentro de los sistemas, aplicaciones y servicios, asegurando que pueda hacer frente a las situaciones más extremas para una resiliencia completa.
Ingeniería del caos vs. pruebas de rendimiento
Al igual que las pruebas de estrés o las pruebas de carga, laingeniería del caos ayuda a los equipos a identificar puntos de ruptura o fallas mediante la creación de entornos anormales o inestables. Sin embargo, una de las diferencias clave entre la ingeniería del caos y las pruebas de rendimiento es que la ingeniería del caos no solo se centra en unos pocos componentes clave, sino que puede consistir en un número aparentemente ilimitado de factores, fuera del alcance de las consideraciones de prueba normales y obvias. En entornos de red grandes y distribuidos, los sistemas pueden fallar por una variedad de razones que no son tan fáciles de descubrir en comparación con otros entornos. Descubrir estas vulnerabilidades ayuda a los equipos a comprender dónde se encuentran las debilidades para evitar que ocurran estas posibles fallas.
Nace el caos (ingeniería)
La práctica de la ingeniería del caos se originó con Netflix alrededor de 2008 después de haber lanzado formalmente su servicio de transmisión. Después de un problema de corrupción de la base de datos alrededor de 2011, Netflix planeó hacer la transición de su centro de datos a la nube a través de AWS (Amazon Web Services). De hecho, les tomó ocho años completar finalmente la migración. En 2015, AWS experimentó una interrupción, lo que provocó que Netflix se cayera durante varias horas. Estos fueron los primeros días de la computación en la nube, por lo que no era tan robusta, estable y a prueba de fallas como lo es ahora. Cuando descubrieron que el cambio a la nube no creó algunos de los beneficios que esperaban, como escalabilidad, tiempo de actividad, evitar puntos únicos de falla, Escalado automático, etc., decidieron que necesitaban una forma de probar estos inesperados. problemas para garantizar que sus servicios estén en funcionamiento, y en última instancia, evitando el Impacto en los usuarios y frustración. De esta experiencia nació la ingeniería del caos.
Principios y pasos de la ingeniería del caos
La ingeniería del caos no busca crear caos solo para crear caos. Más bien, basado en un conjunto de principios y pasos precisos , está diseñado para crear cuidadosamente planes y experimentos con el único propósito de aprender cómo mitigar el riesgo dentro de grandes sistemas y redes distribuidos. A continuación se enumeran los pasos para crear una guía general para experimentos de caos.
Paso 1: Crear una hipótesis
Esto consiste en hacer suposiciones generales sobre cómo responderá un sistema a medida que se introduzcan factores y condiciones inestables en comparación con el entorno normal. Aquí también es donde se determina qué métricas, como las tasas de error, la latencia, el rendimiento, etc., se deben medir durante el experimento de caos.
Paso 2: Identificar variables y anticipar efectos
Considere lo que podría suceder cuando estos eventos hipotéticos ocurrieran en situaciones de la vida real. Por ejemplo, si su servidor se bloquea inesperadamente o hay un aumento significativo en el tráfico, ¿cuál será el efecto en su sistema en general?
Paso 3: Iniciar el experimento
Idealmente, desea ejecutar su experimento de caos en un entorno de producción en vivo. Sin embargo, debe haber protecciones para evitar que ocurra un escenario peor. Desea asegurarse de que todavía tiene cierto control sobre el entorno si el experimento va de lado. Esto también se conoce como control del radio de explosión. Estos experimentos se pueden automatizar para un mejor análisis, y son más sostenibles, que ejecutarlos manualmente. Otro método que a veces se usa es utilizar un entorno de prueba completo, sin embargo, nuevamente, esto podría no reflejar lo que sucede en el mundo real.
Paso 4: Medir el impacto
¿Cómo se comparan los resultados con la hipótesis inicial? Sobre la base de las métricas que se establecieron en la hipótesis, ¿fue el experimento demasiado limitado o necesita ser escalado para identificar mejor los errores y fallas? ¿El radio de explosión era demasiado limitado? Tal vez necesite ser escalado para desactivar esas fallas que ocurrirían en un escenario de la vida real. Este experimento también puede descubrir problemas adicionales que deben investigarse.
Herramientas de ingeniería del caos
Volvamos a la introducción de la ingeniería del caos con Netflix. Una vez que tomaron la decisión de pasar a la ofensiva y comenzar el proceso de dedicar recursos para un equipo de ingeniería, necesitaban crear un conjunto formalizado de prácticas y herramientas para ayudar a los equipos de ingeniería a llevar a cabo pruebas de caos. Una de las primeras aplicaciones que introdujo Netflix se llamó Chaos Monkey. Cada día, esta aplicación elegiría aleatoriamente un conjunto de clústeres y apagaría esa instancia en algún momento del día para observar cómo respondían los sistemas restantes. Obviamente, esto crea una experiencia dolorosa para los equipos de ingeniería que tienen suficientes dolores de cabeza de red con los que lidiar a diario, pero al final del día, pone a los equipos en una mejor posición para comprender los efectos de estas interrupciones, no solo con respecto a su red, sino también en términos del impacto en los usuarios.
Si bien puede parecer contradictorio dedicar recursos e individuos para ir por ahí “rompiendo” cosas, llevar a cabo proactivamente estas pruebas de caos ayuda a construir una red más resistente y crear una experiencia de usuario mejor y más confiable. El mundo real no funciona en un entorno de prueba controlado. Desde el inicio de Chaos Monkey, ha pasado por varias actualizaciones y se ha convertido en una popular aplicación de código abierto. Y en un momento, era solo una parte de un conjunto de herramientas de ingeniería del caos llamado ejército simio. La suite Simian Army se disolvió en 2018, pero incluía las siguientes utilidades de ingeniería del caos específicas de la tarea:
Caos Kong
Chaos Kong se diseñó para simular una región completa de AWS que se elimina o se elimina para ver cómo se recupera y responde el sistema moviendo el tráfico a una región diferente sin degradación del rendimiento. Una vez más, esto rara vez sucede, pero dentro del alcance de la ingeniería del caos, nada está fuera de los límites.
Mono de conformidad
Conformity Monkey es un servicio que se ejecuta en AWS con el propósito de identificar instancias que no se ajustaban a reglas predefinidas. Se identificó cualquier instancia que no se ajustara a las reglas, que eran lo suficientemente flexibles como para personalizarse y configurarse para ejecutarse a diferentes frecuencias, y se envía una notificación por correo electrónico al propietario o grupo. Desde entonces, Conformity Monkey se ha trasladado a los servicios de Spinnaker.
Gorila del Caos
Chaos Gorilla es como Chaos Monkey, pero en una escala más grande. En lugar de simular errores en instancias únicas de AWS, Chaos Gorilla simuló un error de toda una zona de AWS. Esta utilidad fue diseñada para mostrar cómo un desastre a gran escala afectó a los usuarios o clientes en una región diferente, lo cual fue perfecto para la configuración de la infraestructura y el modelo de negocio de Netflix. Si la plataforma en la nube puede resistir esta prueba al garantizar adecuadamente que los equilibradores de carga respondan adecuadamente y los servicios permanezcan interrumpidos, entonces puede soportar cualquier cosa que se le arroje.
Mono de latencia
Latency Monkey, como su nombre lo indica, se utiliza para probar los servicios contra retrasos de red, o fallas completas, para ayudar a identificar cómo los servicios, y sus dependencias, respondieron a estos retrasos simulados. Sin embargo, al igual que los servicios web en general, puede haber consecuencias desconocidas dentro de otras aplicaciones que pueden no identificarse fácilmente a primera vista, por lo que una utilidad como Latency Monkey es tan importante para medir la tolerancia a fallas en todos los servicios.
Doctor Mono
La utilidad Doctor Monkey se utilizó para realizar comprobaciones de estado en instancias individuales y supervisar el estado (carga de CPU, memoria, recursos, etc.) del sistema en general. Además, Doctor Monkey puede informar sobre el estado de la instancia y eliminar cualquier instancia del servicio que considere no apta para el sistema general.
10-18 Mono
El nombre de 10-18 Monkey proviene de las abreviaturas de localización e internacionalización y localización, L10n e i18n. Los números representan el número de letras entre la primera y la última letra. Dado que los clientes de Netflix residen en todo el mundo, tener un método para monitorear la confiabilidad de sus servicios de transmisión, en diferentes regiones, era de suma importancia. La ventaja de la utilidad 10-18 Monkey es que puede verificar problemas de configuración y rendimiento en múltiples regiones geográficas que sirven y utilizan diferentes idiomas y conjuntos de caracteres.
Mono conserje
¿Qué pasa con todos esos recursos de AWS no utilizados? Entra Janitor Monkey. El propósito de la utilidad Janitor Monkey es encontrar y eliminar recursos no utilizados. Al igual que Chaos Monkey, también es personalizable y extensible lo suficiente como para ser utilizado con otros proveedores de nube. Los usuarios proporcionan un conjunto de reglas y Janitor Monkey se pone a trabajar, identificando aquellos recursos, grupos y volúmenes no utilizados que son candidatos para la limpieza y eliminación y envía una notificación. Con el tiempo, la funcionalidad fue reemplazada por un nuevo servicio llamado Swabbie.
Conclusión: Ingeniería del Caos – Principios, Ejemplos y Herramientas
Con el tiempo, la ingeniería del caos se ha convertido en su propia industria de pleno derecho. Ahora hay una gran cantidad de herramientas comerciales y de código abierto, como Litmus Chaos, Gremlin, Chaos Mesh y muchas más, que las organizaciones pueden utilizar. La construcción de sistemas resilientes no es solo para las empresas de tecnología. Los sistemas distribuidos se han vuelto más complejos, lo que significa que las fallas son más difíciles de predecir. Además, debido a diversos problemas regulatorios y de cumplimiento, los bancos, las entidades gubernamentales, las compañías farmacéuticas, las instituciones educativas, etc., deben probar regularmente sus sistemas y servicios para garantizar que cumplan con los requisitos comerciales y de misión crítica. Las pruebas de rendimiento y las pruebas de caos son enfoques proactivos para aprender a construir sistemas resistentes a través de la observación de fallas.