La ingeniería del caos es la causa intencional y controlada de fallas en el entorno de producción o preproducción para comprender su impacto y planificar una mejor postura de defensa y una mejor estrategia de mantenimiento de incidentes.
Cada día se crea una nueva oportunidad para que la aplicación o infraestructura crítica de una organización falle, amenazando potencialmente su capacidad para prestar servicios a los clientes. Las causas de las fallas pueden variar entre varias cuestiones, como violaciones de seguridad, configuraciones erróneas o interrupciones del servicio. La probabilidad de errores o interrupciones puede aumentar al alojarse más aplicaciones y datos en la nube, lo que puede generar un aumento de los problemas de seguridad.
Una forma de abordar las interrupciones es la ingeniería del caos. No se trata de un proceso aleatorio en el que los ingenieros dan de baja instancias o servicios o provocan fallas en los sistemas sin ningún propósito. Este proceso identifica posibles problemas futuros, lo que permite a los equipos de ingeniería solucionarlos de forma proactiva y evitarlos en el futuro en el entorno real.
La ingeniería del caos es importante porque un error o una interrupción pueden ralentizar el ritmo de una organización, desperdiciando tiempo valioso en encontrar una solución sobre la marcha a medida que aumenta el tiempo de inactividad. Netflix aprendió esto de primera mano cuando cambió de on premises a la nube1 (enlace externo a ibm.com); experimentó un corte que provocó una interrupción de tres días en la prestación del servicio en 2008. Esto es anterior a su transformación en una operación de streaming de video, lo que habría hecho que la interrupción fuera exponencialmente más costosa. Como resultado, Netflix decidió que haría todo lo posible para minimizar las interrupciones y comenzó a introducir la ingeniería del caos en sus flujos de trabajo. Esto le permite identificar los problemas antes de que se produzcan y minimizar los daños en caso de que se produzca una falla inevitable.
Netflix creó chaos monkey2(enlace externo a ibm.com), una herramienta de código abierto que crea incidentes aleatorios en los servicios y la infraestructura de TI con la intención de identificar puntos débiles que puedan solucionarse o abordarse mediante procedimientos de recuperación automáticos cuando se traslade de un centro de datos privado a Amazon Web Services (AWS) en respuesta a la falta de confiabilidad de la nube. Muchas organizaciones ahora usan chaos monkey para ejecutar sus experimentos de ingeniería del caos.
La ingeniería del caos es una defensa importante contra las fallas de infraestructura, las interrupciones o la falta de componentes en el entorno de producción de una organización. Ayuda a los ingenieros de confiabilidad del sitio (SRE) y a otros miembros del equipo DevOps a proporcionar una entrega continua de servicios evitando interrupciones significativas en su servicio, comprendiendo mejor sus vulnerabilidades y sabiendo cómo minimizar el impacto si se produce una interrupción.
Incluso un pequeño problema en el código puede tener un efecto catastrófico en el entorno de producción general dadas las diferentes dependencias del programa. Por ejemplo, un error en el sistema de software de transacciones para una empresa de servicios financieros puede resultar en la pérdida de millones de dólares3 (enlace externo a ibm.com). Es posible que las organizaciones no puedan evitar todos los incidentes de TI, pero pueden minimizar el daño utilizando la gestión del caos para comprender los escenarios probables y sus mejores soluciones posibles.
IBM Instana Observability ofrece a todos los usuarios de la empresa un acceso fácil a los datos que desean, con el contexto que necesitan para prevenir y solucionar problemas rápidamente.
Suscríbase al boletín de IBM
Las organizaciones con alta resiliencia, madurez digital y alta observabilidad a través de paneles y otras herramientas deben adoptar la ingeniería del caos, ya que pueden tomar medidas inmediatas sobre los problemas que ocurren a través de experimentos. Las organizaciones que carecen de esta observabilidad4 (enlace externo a ibm.com) pueden tardar demasiado en resolver los experimentos que crean mediante la ingeniería del caos.
La ingeniería del caos también es imprescindible para las organizaciones que utilizan la nube, en particular la nube pública, y aplicaciones nativas de la nube. La nube pública introduce posibles problemas de interrupción que requieren coordinación con el proveedor de la nube, lo que crea un enfoque diferente al de los problemas on premises.
Las empresas que utilizan la nube suelen abordar los incidentes de TI sin considerar cómo la nube y el software como servicio (SaaS) afectan esos incidentes de manera diferente, según Constellation Research5 (enlace externo a ibm.com).
Además, el auge del uso de microservicios, que aumenta el número de hosts o contenedores que se ejecutan en un sistema, crea retos únicos (enlace externo a ibm.com) que pueden descubrirse y resolverse mediante experimentos de caos. Traslada las complejidades del diseño de código a las operaciones del sistema, lo que no elimina las complejidades, pero permite una mayor automatización.
La ingeniería del caos también puede ayudar a las organizaciones a mejorar la velocidad de sus pipelines de integración continua y entrega continua (CI/CD). Incorporar ingeniería del caos en CI/CD, como Netflix6 (enlace externo a ibm.com), permite a las organizaciones automatizar experimentos continuos mientras controlan su impacto potencial.
Por último, el hecho de que las organizaciones se conecten cada vez más con sus socios a través de API significa que un problema en sus sistemas puede repercutir en otras organizaciones.
Desplegar ingeniería del caos ayuda a las organizaciones a comprender los puntos débiles de su arquitectura y corregirlos, creando finalmente la capacidad de anticipar futuras fallas. El éxito de la ingeniería del caos ayuda a las organizaciones a minimizar las fallas técnicas que puedan tener un impacto significativo en el cliente, y también contribuye a la construcción de arquitecturas de sistemas complejos más sólidas y resilientes. Una vez que una organización decide dedicarse a la ingeniería del caos, el siguiente paso es determinar si ejecutarla en el entorno de preproducción o de producción.
Los equipos de DevOps tienen varias opciones para ejecutar experimentos de ingeniería del caos para probar varios procesos del sistema.
- Inyección de latencia: los equipos de DevOps crean escenarios que emulan una conexión de red lenta o fallida. Esto incluye la introducción de retrasos en la red o tiempos de respuesta más lentos.
- Inyección de fallas: esto implica introducir deliberadamente errores en el sistema para determinar cómo afecta a otros sistemas dependientes y si interrumpe los servicios. Algunos ejemplos de inyecciones de fallas incluyen inducir fallas en el disco, finalizar procesos, apagar un host o introducir aumentos de potencia o temperatura. Las inyecciones de fallas pueden ayudar a las organizaciones a identificar cualquier punto único de falla, lo que puede hacer que todo el sistema falle si algo les sucede.
- Generación de carga: esto se relaciona con forzar intencionalmente el sistema enviando niveles de tráfico significativos mucho más allá de las operaciones normales. Esto ayuda a los ingenieros de confiabilidad del sitio (SRE) a comprender cualesquier cuellos de botella en el sistema, lo que a su vez les permite crear sistemas más escalables.
- Pruebas de Canary: esto implica lanzar un nuevo producto o característica a un pequeño grupo de usuarios. De ese modo, cualquier falla o error solo afectará a un porcentaje de visitantes, dejando el resto de la audiencia para acceder a la experiencia del sitio web existente.
Crear el proceso de ingeniería del caos ideal requiere varios principios para garantizar que una organización pueda tener un sistema distribuido a escala.
- Comprender el sistema: esto implica un conocimiento exhaustivo del sistema holístico, sus propiedades y funciones emergentes y su topología, arquitectura, dependencias, comportamiento en estado estacionario, respuesta de salida y características, como la disponibilidad, la latencia y el rendimiento.
- Aceptar el fracaso: parece paradójico inicialmente que los ingenieros de software permitan que ocurra un incidente cuando están preparados para evitarlo. Sin embargo, las interrupciones siempre ocurrirán en los servicios de TI y es mejor experimentarlas en un entorno controlado para identificar la solución de manera preventiva en lugar de fuera del horario laboral, cuando el equipo de una organización no se ha encontrado antes con ese problema específico.
- Establecer un comportamiento estable: primero, el equipo de ingeniería debe definir cómo debe comportarse el sistema cuando se ejecuta correctamente, de modo que pueda comparar cómo los experimentos afectan ese estado estable.
- Identificar incidentes del mundo real: los experimentos de ingeniería del caos deberían estar lo más cerca posible de lo que podría suceder en un día normal en lugar de crear situaciones improbables. Las fallas de red e infraestructura, el código incorrecto, los problemas de energía y la sobrecarga de tráfico son posibles ocurrencias.
- Crear un día de juego: la ingeniería del caos puede estudiar el entorno en un día de juego, en el que se producen múltiples pruebas durante un día específico para maximizar sus recursos para identificar y resolver tantos problemas como sea posible.
- Utilizar la automatización: las organizaciones de todos los tamaños pueden utilizar la ingeniería del caos mediante la automatización de experimentos, lo que requeriría demasiada mano de obra si las empresas los realizaran manualmente. Esto reduce parte de la carga de los equipos de TI durante el proceso de ingeniería del caos. El diseño del experimento, la inyección de fallas y el aprovisionamiento de la infraestructura son todos aspectos de la experimentación que las organizaciones pueden automatizar
- Tener en cuenta el radio de explosión: un ingeniero del caos debe esforzarse mucho en minimizar el radio de explosión para que el daño real a los clientes sea el menor posible. Algunas formas de minimizar el radio de explosión son:
- Dirigirse a un subconjunto de servicios: la ingeniería del caos, especialmente en un entorno de producción, no debería interrumpir fundamentalmente el servicio de una organización. Centrarse en un subconjunto específico de servicios puede minimizar el impacto de un incidente en caso de que se produzca, garantizando que no derribe todo el sistema.
- Ejecutar el experimento durante un tiempo finito: el experimento debe tener un principio y un final. El objetivo del experimento es crear un incidente y resolverlo en lugar de dejarlo funcionar sin control durante mucho tiempo.
- Ejecutar el experimento fuera del pico de tráfico: las organizaciones deben tratar de evitar realizar experimentos durante las horas pico a menos que estén tratando específicamente de medir qué tanto afecta la alta capacidad al sistema durante un incidente.
- Ejecutar el experimento en el entorno de desarrollo: la forma más fácil de garantizar que los clientes no experimenten interrupciones en el servicio es ejecutarlo en el entorno de preproducción. Sin embargo, eso significa que las condiciones difieren del entorno de producción, lo que potencialmente dará un panorama falso de lo que ocurre. Para minimizar esto, asegúrese de que sus entornos de preproducción y producción se reflejen entre sí tanto como sea posible.
- Experimentar en cada componente: la experimentación del caos nunca termina, ya que el sistema de una organización cambia continuamente. Un objetivo también debería ser probar "todo"; examinar todos los componentes, capas, servicios y sus dependencias a lo largo del proceso.
Las organizaciones que utilizan la ingeniería del caos deben decidir si aplican las pruebas del caos en sus entornos de producción o de preproducción. Hay varias razones por las que la ingeniería del caos es más beneficiosa en entornos de producción. Los entornos en vivo proporcionan el entorno más preciso para comprender cómo afecta un incidente la experiencia del cliente. Otra razón es que el entorno de preproducción puede no tener la misma configuración que el entorno real, lo que introduce cierta variabilidad en los experimentos.
Por ejemplo, un incidente en un entorno de preproducción puede no crear una respuesta realista porque carece de los mismos niveles de tráfico que el entorno en vivo. También puede no tener las mismas configuraciones de seguridad que ese entorno.
Algunas organizaciones temen causar intencionalmente problemas con su sitio en vivo, por lo que ejecutan sus experimentos en su sitio de preproducción o desarrollo. Esto garantiza que cualquier problema que ocurra no afecte la experiencia del cliente en vivo. Para mitigar esto, algunas organizaciones comienzan en entornos de preproducción para manejar el proceso antes de pasar al entorno de producción en vivo.
Las organizaciones elegirán qué entorno utilizar en función de su tolerancia al riesgo. En última instancia, el objetivo de la ingeniería del caos es poner a prueba problemas reales a gran escala, por lo que los entornos de producción ofrecerán el panorama más preciso de lo que está sucediendo y de lo que es necesario arreglar.
La ingeniería del caos ofrece a las organizaciones varios beneficios clave.
Los clientes tienen grandes expectativas sobre la disponibilidad de los servicios que compran a las empresas. Cualquier tiempo de inactividad o incapacidad para acceder a lo que han pagado puede tener un efecto grave en la satisfacción del cliente, lo que genera pérdida de ingresos y daño a la reputación. Probar los sistemas e identificar soluciones significa que hay menos riesgo de que un sistema deje de funcionar durante un periodo significativo.
Las interrupciones pueden provenir de un código incorrecto, problemas del servidor o amenazas externas. Esto último puede ocurrir incluso con excelentes prácticas de seguridad. La ingeniería del caos ayuda a identificar los problemas que pueden ser explotados, por lo que las organizaciones pueden introducir parches y correcciones de errores (enlace externo a ibm.com) para mantener sus servicios seguros.
La ingeniería del caos permite a las organizaciones crear un plan más informado sobre cómo abordar los problemas que se plantearán en el futuro. Las organizaciones que adoptan la ingeniería del caos tendrán planes específicos para muchos incidentes, lo que permitirá una reparación más rápida y menos tiempo de inactividad. La ingeniería del caos puede reducir el tiempo de inactividad7 (enlace externo a ibm.com) hasta en un 20 %.
Los experimentos de ingeniería del caos identifican cómo un sistema asigna recursos. La introducción de experimentos demostrará cómo el sistema gestiona las cargas, mostrando dónde se producen o es probable que se produzcan cuellos de botella.
La ingeniería del caos ayuda a los equipos a desarrollar mayor resiliencia y flexibilidad del sistema en su software. Por lo tanto, las organizaciones pueden abordar la codificación de nuevos software y soluciones de manera más inteligente porque saben cómo maneja el sistema actual.
Obtenga el contexto que necesita para resolver incidentes más rápido con la solución de observabilidad de IBM.
Optimice el uso y el costo del software
Descubra cómo la Inteligencia Artificial para Operaciones de TI (AIOps) utiliza los datos y el aprendizaje automático para mejorar y automatizar la gestión de servicios de TI
Prevea y evite los problemas de rendimiento antes de que afecten a su empresa con la gestión del rendimiento de las aplicaciones
Las operaciones de TI y AIOps supervisan y automatizan la gestión, la entrega y el soporte de los servicios de TI en toda la organización
ITSM es la forma en que una organización garantiza que sus servicios de TI funcionen de la manera en que los usuarios y la empresa los necesitan para trabajar
Automatice las tareas de operaciones de TI, acelere la entrega de software y minimice el riesgo de TI con la ingeniería de confiabilidad del sitio
La automatización inteligente combina IA y tecnologías de automatización, permitiendo la automatización de tareas de bajo nivel dentro de su empresa.
Notas de pie de página
1 Chaos Engineering: System Resiliency in Practice, (enlace externo a ibm.com) Casey Rosenthal, Nora Jones, 2020
2 What is Chaos Monkey? Chaos engineering explained, (enlace externo a ibm.com) InfoWorld, 13 de mayo de 2020
3 Knight Capital Says Trading Glitch Cost It $440 Million, (enlace externo a ibm.com) New York Times, 2012
4 There Is No Resilience without Chaos, The New Stack, (enlace externo a ibm.com) 13 de abril de 2023
5 Incident Management in the Cloud Era, (enlace externo a ibm.com) Constellation Research, 2023
6 ChAP: Chaos Automation Platform(enlace externo a ibm.com) Blog de Netflix, 26 de julio de 2017
7 The I&O Leader’s Guide to Chaos Engineering(enlace externo a ibm.com) Gartner, 28 de octubre de 2021