Con el auge de los microservicios y las arquitecturas distribuidas en la nube, la web se ha vuelto cada vez más compleja. Todos dependemos de estos sistemas más que nunca, pero las fallas se han vuelto mucho más difíciles de predecir.
Estas fallas provocan costosos cortes de energía para las empresas. Las interrupciones perjudican a los clientes que intentan comprar, realizar transacciones comerciales y trabajar. Incluso las interrupciones breves pueden afectar los resultados de una empresa, por lo que el coste del tiempo de inactividad se está convirtiendo en un KPI para muchos equipos de ingeniería. Una interrupción puede costar millones de dólares a una sola empresa.
Las empresas necesitan una solución para este desafío; esperar la próxima interrupción costosa no es una opción. Para enfrentar el desafío de frente, cada vez más empresas recurren a Chaos Engineering.
La ingeniería del caos es medicina preventiva.
Chaos Engineering es un enfoque disciplinado para identificar fallas antes de que se conviertan en interrupciones. Al probar proactivamente cómo responde un sistema bajo estrés, puede identificar y corregir fallas antes de que terminen en las noticias.
Chaos Engineering te permite comparar lo que crees que sucederá con lo que realmente sucede en tus sistemas. Literalmente, «rompe cosas a propósito» para aprender a construir sistemas más resistentes.
Indice
¿Qué es la ingeniería del caos?
La ingeniería del caos es la ciencia detrás de inyectar fallas intencionalmente en los sistemas para medir la capacidad de recuperación. Como cualquier método científico, Chaos Engineering se enfoca en experimentos / hipótesis y luego compara los resultados con un control. El ejemplo por excelencia de Chaos Engineering en un sistema distribuido es eliminar servicios aleatorios para ver cómo responden los elementos y qué detrimento se manifiesta en el viaje del usuario.
Si tomas una sección transversal de lo que una aplicación necesita para ejecutarse (computación, almacenamiento, redes e infraestructura de aplicaciones), inyectar una falla o condiciones turbulentas en cualquier parte de esa pila son experimentos válidos de Ingeniería del Caos.
La saturación de la red o el almacenamiento que repentinamente se vuelve volátil son fallas conocidas en la industria de la tecnología, pero Chaos Engineering permite pruebas mucho más controladas de estas fallas. Debido a la amplia franja de infraestructura que puede verse afectada, los usuarios y profesionales de Chaos Engineering pueden ser casi cualquier persona que apoye la pila de aplicaciones / infraestructura.
Historia
Chaos Engineering se hizo relevante por primera vez en las empresas de Internet que eran pioneras en sistemas distribuidos a gran escala. Estos sistemas eran tan complejos que requerían un nuevo enfoque para probar si fallaban.
2010
El equipo de Netflix Eng Tools creó Chaos Monkey. Chaos Monkey se creó en respuesta al cambio de Netflix de la infraestructura física a la infraestructura en la nube proporcionada por Amazon Web Services, y la necesidad de estar seguro de que la pérdida de una instancia de Amazon no afectaría la experiencia de transmisión de Netflix.
2011
Nació el Ejército Simio. El Ejército Simio agregó modos de inyección de falla adicionales además de Chaos Monkey que permitirían probar un conjunto más completo de estados de falla y, por lo tanto, desarrollar la resistencia a ellos también. “La nube tiene que ver con la redundancia y la tolerancia a fallas. Dado que ningún componente puede garantizar el 100% de tiempo de actividad (e incluso el hardware más caro eventualmente falla), tenemos que diseñar una arquitectura en la nube donde los componentes individuales puedan fallar sin afectar la disponibilidad de todo el sistema”.
2012
Netflix compartió el código fuente de Chaos Monkey en Github, diciendo que “han descubierto que la mejor defensa contra fallas inesperadas importantes es fallar a menudo. Al causar fallas con frecuencia, obligamos a que nuestros servicios se construyan de una manera que sea más resistente”.
2014
Netflix decidió que crearían un nuevo rol: el ingeniero del caos. Bruce Wong acuñó el término y Dan Woods lo compartió con la gran comunidad de ingenieros a través de Twitter.
En octubre de 2014, Netflix anunció Failure Injection Testing (FIT), una nueva herramienta que se basó en los conceptos del Simian Army, pero que dio a los desarrolladores un control más granular sobre el «radio de explosión” de su inyección fallida. Las herramientas de Simian Army habían sido tan efectivas que, en algunos casos, creaban interrupciones dolorosas, lo que hizo que muchos desarrolladores de Netflix desconfiaran de ellas. FIT les dio a los desarrolladores el control sobre el alcance de su falla para que pudieran darse cuenta de los conocimientos de Chaos Engineering, pero mitigando los posibles inconvenientes.
2016
Kolton Andrus y Matthew Fornaciari fundaron Gremlin, la primera solución de ingeniería del caos empresarial gestionada del mundo. Gremlin estaría disponible públicamente a fines de 2017 y se lanzaría con una docena de vectores de ataque diferentes, un botón de detención incorporado para detener y deshacer los ataques y seguridad integral.
2018
Gremlin lanza Chaos Conf, la primera conferencia a gran escala dedicada a la Ingeniería del Caos. En solo dos años, el número de asistentes aumentaría casi 10 veces e incluiría expertos de software, comercio minorista, finanzas, entrega y muchas otras industrias.
2020
AWS agrega Chaos Engineering al pilar de confiabilidad del AWS Well-Architected Framework (WAF). A finales de este año, AWS también anuncia Fault Injection Simulator (FIS), un servicio totalmente administrado para ejecutar de forma nativa experimentos de caos en los servicios de AWS.
2021
Gremlin publica el primer informe de ingeniería del estado del caos . El informe muestra cómo ha crecido la práctica de la Ingeniería del Caos entre las organizaciones, los beneficios clave de la Ingeniería del Caos, la frecuencia con la que los equipos de alto rendimiento realizan experimentos del caos y más.
Principios
Los Principios de la Ingeniería del Caos es un excelente manifiesto que describe los principales objetivos y principios de la Ingeniería del Caos. Los Principios de la Ingeniería del Caos desglosan además cuatro prácticas que son similares al método científico. Sin embargo, a diferencia del método científico, la suposición es que el sistema es estable y luego busca la varianza. Cuanto más difícil es interrumpir el estado estable, más confianza y solidez hay en el sistema.
Definir la línea de base (Estado Estable)
Saber qué es normal / estable es fundamental para detectar desviaciones / regresiones. Dependiendo de lo que estés probando, tener una buena métrica, como el tiempo de respuesta o objetivos de nivel superior, como la capacidad de completar el recorrido del usuario en un tiempo determinado, son buenas medidas de normalidad. El estado estable en un experimento es el grupo de control.
Hipotetizar que el Estado Estable perdurará
Yendo en contra del método científico, asumir que una hipótesis es cierta todo el tiempo no deja mucho margen de maniobra. Chaos Engineering está diseñado para ejecutarse contra sistemas robustos y estables, tratando de encontrar fallas de aplicaciones o de infraestructura. Ejecutar Chaos Engineering contra sistemas inestables no proporciona mucho valor, ya que esos sistemas ya no son confiables y se conoce la inestabilidad.
Introducir variables / experimentos
Como cualquier experimento científico, Chaos Engineering introduce variables en el experimento para ver cómo responde el sistema. Estos experimentos representan escenarios de fallas del mundo real que afectan a uno o más de los cuatro pilares de una aplicación: computación, redes, almacenamiento e infraestructura de aplicaciones. Una falla, por ejemplo, podría ser una falla de hardware o una interrupción de la red.
Intentar refutar la hipótesis
Si la hipótesis es para un estado estable, cualquier variación o interrupción del estado estable (diferencias entre el grupo de control y el grupo experimental) refuta la hipótesis de estabilidad. Al tener ahora un área en la que enfocarse, se pueden hacer arreglos o cambios de diseño para hacer un sistema más robusto y estable.
La implementación de los principios de la Ingeniería del Caos conduce a algunas consideraciones de diseño y las mejores prácticas al implementar experimentos de Ingeniería del Caos.
Empieza por formular una hipótesis sobre cómo debería comportarse un sistema cuando algo sale mal.
Luego, diseña el experimento más pequeño posible para probarlo en tu sistema.
Finalmente, mide el impacto del fracaso en cada paso, buscando señales de éxito o fracaso. Cuando finaliza el experimento, comprendes mejor el comportamiento de tu sistema en el mundo real.
¿Qué empresas practican la Ingeniería del Caos?
Muchas empresas de tecnología más grandes practican la Ingeniería del Caos para comprender mejor sus sistemas distribuidos y arquitecturas de microservicios. La lista incluye Netflix, LinkedIn, Facebook, Google, Microsoft, Amazon y muchos otros. La lista siempre está creciendo.
Pero las industrias más tradicionales, como la banca y las finanzas, también se han dado cuenta de Chaos Engineering. Por ejemplo, en 2014, el National Australia Bank migró de la infraestructura física a Amazon Web Services y utilizó Chaos Engineering para reducir drásticamente el recuento de incidentes.
La Comunidad Slack de Chaos Engineering ha creado un diagrama que rastrea las herramientas conocidas de Chaos Engineering y los ingenieros conocidos que trabajan en Chaos Engineering.
¿Por qué romperías cosas a propósito?
Piensa en una vacuna contra la gripe, en la que se inyecta una pequeña cantidad de un cuerpo extraño potencialmente dañino para desarrollar resistencia y prevenir enfermedades. Chaos Engineering es una herramienta que utilizamos para construir tal inmunidad en nuestros sistemas técnicos inyectando daño (como latencia, falla de CPU o agujeros negros de red) para encontrar y mitigar posibles debilidades.
Estos experimentos tienen el beneficio adicional de ayudar a los equipos a desarrollar la memoria muscular para resolver interrupciones, similar a un simulacro de incendio. Al romper cosas a propósito, sacamos a la luz problemas desconocidos que podrían afectar a nuestros sistemas y clientes.
Según el informe de 2021, los resultados más comunes de Chaos Engineering son una mayor disponibilidad, menor tiempo medio de resolución (MTTR), menor tiempo medio de detección (MTTD), menos errores enviados al producto y menos interrupciones. Los equipos que ejecutan experimentos de ingeniería del caos con frecuencia tienen más probabilidades de tener una disponibilidad superior al 99,9%.
Papel de la ingeniería del caos en los sistemas distribuidos
Los sistemas distribuidos son intrínsecamente más complejos que los sistemas monolíticos, por lo que es difícil predecir todas las formas en que podrían fallar. Las ocho falacias de los sistemas distribuidos describen suposiciones falsas que los programadores nuevos en las aplicaciones distribuidas hacen invariablemente.
Falacias de los sistemas distribuidos:
- La red es confiable
- La latencia es cero
- El ancho de banda es infinito
- La red es segura
- La topología no cambia
- Hay un administrador
- El coste de transporte es cero
- La red es homogénea
Muchas de estas falacias impulsan el diseño de experimentos de ingeniería del caos, como los «ataques de pérdida de paquetes» y los «ataques de latencia». Por ejemplo, las interrupciones de la red pueden provocar una serie de fallas en las aplicaciones que afectan gravemente a los clientes. Las aplicaciones pueden paralizarse mientras esperan interminablemente un paquete. Las aplicaciones pueden consumir memoria u otros recursos del sistema Linux de forma permanente. E incluso después de que haya pasado una interrupción de la red, es posible que las aplicaciones no vuelvan a intentar las operaciones detenidas o que lo vuelvan a intentar de forma demasiado agresiva. Las aplicaciones pueden incluso requerir un reinicio manual. Cada uno de estos ejemplos debe ser probado y preparado.
Beneficios
Los principales beneficios de Chaos Engineering son:
- Cliente: la mayor disponibilidad y durabilidad del servicio significa que ninguna interrupción interrumpe su vida diaria.
- Negocios: Chaos Engineering puede ayudar a prevenir pérdidas extremadamente grandes en ingresos y costes de mantenimiento, crear ingenieros más felices y comprometidos, mejorar la capacitación de guardia para los equipos de ingeniería y mejorar el Programa de administración de SEV (incidentes) para toda la empresa.
- Técnico: los conocimientos de los experimentos de caos pueden significar una reducción de incidentes, reducción de la carga de guardia, mayor comprensión de los modos de falla del sistema, diseño mejorado del sistema, tiempo medio más rápido para la detección de SEV y reducción de SEV repetidos.
¿Qué experimentos de Ingeniería del Caos realizas primero?
Argumentamos que debes realizar tus experimentos en el siguiente orden:
- Conocimientos conocidos: cosas que conoces y comprendes.
- Desconocidas conocidas: cosas de las que eres consciente pero que no comprendes por completo.
- Conocimientos desconocidos: cosas que comprendes pero de las que no eres consciente.
- Desconocidas desconocidas: cosas de las que no eres consciente ni comprendes completamente.
Para ilustrar esto en la práctica con ejemplos, demostraremos cómo seleccionar experimentos basados en una base de datos MySQL fragmentada. En este ejemplo, tenemos un clúster de 100 hosts MySQL con varios fragmentos por host.
En una región, tenemos un host de base de datos principal con dos réplicas y usamos replicación semi-sincronizada. También tenemos una pseudoprimaria y dos pseudo réplicas en una región diferente.
- Conocidos conocidos: Sabemos que cuando una réplica se apaga, se eliminará del clúster. Sabemos que luego se clonará una nueva réplica del primario y se agregará nuevamente al clúster.
- Desconocidas conocidas: Sabemos que se producirá la clonación, ya que tenemos registros que confirman si tiene éxito o falla, pero no conocemos el promedio semanal del tiempo medio que toma desde experimentar una falla hasta agregar una clonación al clúster de manera efectiva. Sabemos que recibiremos una alerta de que el clúster tiene solo una réplica después de 5 minutos, pero no sabemos si nuestro umbral de alerta debe ajustarse para prevenir incidentes de manera más efectiva.
- Desconocido-Conocido: Si apagamos las dos réplicas de un clúster al mismo tiempo, no sabemos exactamente el tiempo medio durante un lunes por la mañana que nos llevaría clonar dos nuevas réplicas del primario existente. Pero sabemos que tenemos un pseudoprimario y dos réplicas que también tendrán las transacciones.
- Desconocido-Desconocido: No sabemos exactamente qué sucedería si cerramos un clúster completo en nuestra región principal, y no sabemos si la pseudo región podría realizar la conmutación por error de manera efectiva porque aún no hemos ejecutado este escenario.
Creamos los siguientes experimentos de caos, trabajándolos en orden:
- Conocidos conocidos: apaga una réplica y mide el tiempo que tarda en detectarse el apagado, eliminar la réplica, iniciar el clon, completar el clon y volver a agregar el clon al clúster. Antes de comenzar este experimento, aumenta las réplicas de dos a tres. Ejecuta el experimento de apagado con una frecuencia regular, pero intenta evitar que el experimento resulte en 0 réplicas en cualquier momento. Informa sobre el tiempo total medio de recuperación para una falla de apagado de réplica y desglosa por día y hora para tener en cuenta las horas pico.
- Desconocidas conocidas: utiliza los resultados y los datos del experimento conocido-conocido para responder preguntas que actualmente serían «incógnitas conocidas». Ahora podrás conocer el impacto del promedio semanal del tiempo medio que tarda desde experimentar una falla hasta agregar un clon de nuevo al clúster de manera efectiva. También sabrás si 5 minutos es un umbral de alerta apropiado para prevenir SEV.
- Desconocido conocido: aumenta el número de réplicas a cuatro antes de realizar este experimento. Apaga dos réplicas de un clúster al mismo tiempo, recopila el tiempo medio durante un lunes por la mañana durante varios meses para determinar cuánto tiempo nos llevaría clonar dos nuevas réplicas del principal existente. Este experimento puede identificar problemas desconocidos, por ejemplo, el principal no puede manejar la carga de la clonación y las copias de seguridad al mismo tiempo y necesitas hacer un mejor uso de las réplicas.
- Desconocido-Desconocido: el cierre de un clúster completo (principal y dos réplicas) requeriría trabajo de ingeniería para que esto sea posible. Esta falla puede ocurrir inesperadamente en la naturaleza, pero aún no estás listo para manejarla. Prioriza el trabajo de ingeniería para manejar este escenario de falla antes de realizar experimentos de caos.
¿Cómo planeas tus primeros experimentos de caos?
Planificación de tu primer experimento
Una de las preguntas más poderosas en la Ingeniería del Caos es «¿Qué podría salir mal?». Al hacer esta pregunta sobre nuestros servicios y entornos, podemos revisar las posibles debilidades y discutir los resultados esperados.
De manera similar a una evaluación de riesgos, esto informa las prioridades sobre qué escenarios son más probables (o más aterradores) y deben probarse primero. Al sentarse como un equipo y poner en pizarra tus servicios, dependencias (tanto internas como externas) y almacenes de datos, puedes formular una imagen de «¿Qué podría salir mal?». En caso de duda, inyectar una falla o un retraso en cada una de tus dependencias es un excelente lugar para comenzar.
Crear una hipótesis
Tienes una idea de lo que puede salir mal. Has elegido la falla exacta para inyectar. ¿Qué pasa después? Este es un excelente ejercicio de pensamiento para trabajar en equipo. Al discutir el escenario, puedes formular hipótesis sobre el resultado esperado antes de ejecutarlo en vivo. ¿Cuál será el impacto para los clientes, tu servicio o tus dependencias?
Midiendo el impacto
Para comprender cómo se comporta tu sistema bajo estrés, debes medir la disponibilidad y durabilidad de tu sistema. Es bueno tener una métrica de rendimiento clave que se correlacione con el éxito del cliente (como pedidos por minuto o inicios de transmisión por segundo ).
Como regla general, si alguna vez ves un impacto en estas métricas, debes detener el experimento de inmediato. Lo siguiente es medir la falla en sí donde deseas verificar (o refutar) su hipótesis. Este podría ser el impacto en la latencia, las solicitudes por segundo o los recursos del sistema. Por último, debes examinar tus paneles y alarmas para detectar efectos secundarios no deseados.
Ten un plan de reversión
Ten siempre un plan de respaldo en caso de que las cosas salgan mal, pero acepta que a veces incluso el plan de respaldo puede fallar. Habla sobre cómo vas a revertir el impacto. Si estás ejecutando comandos a mano, ten cuidado de no interrumpir ssh o controlar el acceso al plano de tus instancias.
Ve a arreglarlo
Después de ejecutar tu primer experimento, con suerte, hay uno de dos resultados: o has verificado que tu sistema es resistente a la falla que has introducido, o has encontrado un problema que necesitas solucionar. Ambos son buenos resultados. Por un lado, ha aumentado tu confianza en el sistema y su comportamiento y, por otro, has encontrado un problema antes de que provocara una interrupción.
Facilitar el trabajo
Chaos Engineering es una herramienta para facilitar tu trabajo. Al probar y validar proactivamente los modos de falla de tu sistema, reducirás su carga operativa, aumentarás su disponibilidad y dormirás mejor por la noche.
Diferencia entre la ingeniería del caos y las pruebas de carga
Ciertamente, la carga puede provocar el caos per se. Por lo general, diseñamos nuestros sistemas para que sean elásticos en varias piezas (activando nodos adicionales de computación, redes, persistencia y / o aplicación para hacer frente a la carga). Eso es asumiendo que todo surge en el mismo momento o en el momento apropiado, para que podamos adelantarnos a la carga.
En el mundo de la informática, el problema de Thundering Herd no es nuevo, pero se manifiesta más comúnmente a medida que avanzamos hacia una arquitectura más distribuida. Un problema de Thundering Herd, por ejemplo, podría estar en el nivel de la máquina, ya que se inicia una gran cantidad de procesos y otro proceso se convierte en el cuello de botella (la capacidad de manejar uno y solo uno de los nuevos procesos).
En una arquitectura distribuida, un Thundering Herd podría ser que tu sistema de mensajería pueda ingerir una gran cantidad de mensajes / eventos a la vez, pero procesar / persistir esos mensajes podría convertirse en un cuello de botella.
Una prueba de carga ciertamente nos ayudaría a prepararnos para un Thundering Herd como un tipo de estrés, pero ¿qué pasa si parte del sistema ni siquiera estaba allí, o llegaba tarde al juego? Ahí es donde entra en juego la Ingeniería del Caos. Un elemento muy difícil de probar sería una falla en cascada sin la Ingeniería del Caos.
Históricamente más equiparado con la red eléctrica, una falla en cascada es una falla de una parte que puede desencadenar fallas en otras partes. En la tierra de los sistemas distribuidos, estamos tratando de encontrar un solo punto de falla y asegurándonos de que nuestra aplicación / infraestructura sea lo suficientemente robusta para manejar las fallas.
Hoy en día, no hay escasez de herramientas y plataformas para ayudarte a promover tus objetivos de Ingeniería del Caos.