Las organizaciones con alta resiliencia, madurez digital y alta observabilidad a través de paneles de control y otras herramientas deberían adoptar la ingeniería del caos, ya que pueden tomar medidas inmediatas sobre los problemas que ocurran a través de experimentos. Las organizaciones que carecen de esta observabilidad⁴ (enlace externo a ibm.com) pueden tardar demasiado en resolver los experimentos que creen a través de la ingeniería del caos.

La ingeniería de caos también es imprescindible para las organizaciones que utilizan la nube, especialmente la nube pública y las aplicaciones nativas de la nube. La nube pública introduce posibles problemas de apagón que requieren coordinación con el proveedor de servicios en la nube, lo que crea un enfoque diferente al de los problemas en las instalaciones. 

Las empresas que utilizan la nube siguen abordando los incidentes de TI sin tener en cuenta cómo afectan la nube y el software como servicio (SaaS) a esos incidentes de forma diferente, según Constellation Research⁵.(enlace externo a ibm.com) 

Además, el aumento del uso de microservicios, que aumenta el número de hosts o contenedores que se ejecutan en un sistema, crea desafíos únicos (enlace externo a ibm.com) que pueden sacarse a la luz y resolverse a través de experimentos de caos. Cambia 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 canales de integración continua y entrega continua (CI/CD). Incorporar la ingeniería del caos en los CI/CD, como hizo Netflix⁶ (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 los socios a través de las API significa que un problema en sus sistemas puede tener un efecto colateral en otras organizaciones.

Implementar la ingeniería del caos ayuda a las organizaciones a comprender los puntos débiles de su arquitectura y a corregirlos, creando en última instancia la capacidad de anticipar futuros fallos. La ingeniería del caos exitosa ayuda a las organizaciones a minimizar los fallos técnicos con cualquier impacto significativo en el cliente, y también apoya la construcción de arquitecturas de sistemas complejas más fuertes y resilientes. Una vez que una organización decide dedicarse a la ingeniería del caos, el próximo 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 de forma intencionada 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 fallos: 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 inyección de fallos son la inducción de fallos de disco, la finalización de procesos, el apagado de un host o la introducción de aumentos de potencia o temperatura. Las inyecciones de fallos pueden ayudar a las organizaciones a identificar cualquier punto único de fallo, lo que puede provocar que todo el sistema falle si algo les sucede.
• Generación de carga: se refiere a estresar intencionalmente el sistema al enviar niveles de tráfico significativos que superan con creces las operaciones normales. Esto ayuda a los ingenieros de fiabilidad del sitio (SRE) a comprender los cuellos de botella del sistema, lo que a su vez les permite crear sistemas más escalables. 
• Pruebas de Canary: implica lanzar un nuevo producto o característica a un grupo pequeño de usuarios. De esa manera, cualquier fallo o error sólo afectará a un porcentaje de los visitantes, dejando que el resto del público acceda 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: al principio parece paradójico que los ingenieros de software permitan que se produzca un incidente cuando están conectados para evitar que ocurra. Sin embargo, las interrupciones siempre se van a producir en los servicios de TI y es mejor experimentarlas en un entorno controlado para identificar la solución de forma preventiva en lugar de hacerlo fuera del horario laboral, cuando el equipo de una organización no trabaja o no ha encontrado ese problema específico antes.
• Establecer un comportamiento en estado estacionario: en primer lugar, el equipo de ingeniería debe definir cómo debe comportarse el sistema cuando se ejecuta correctamente, de modo que pueda comparar cómo afectan los experimentos a ese estado estacionario.
• Identificar incidentes del mundo real: los experimentos de ingeniería del caos deben acercarse lo más posible a lo que podría suceder en un día normal en lugar de crear situaciones improbables. Los fallos de red e infraestructura, el código incorrecto, los problemas de alimentación y la sobrecarga de tráfico son incidentes potenciales.
• Crear un game day: la ingeniería del caos puede estudiar el entorno en un game day, día en el que se produzcan 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 automatizando los experimentos, que requerirían 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 de experimentos, la inyección de errores y el aprovisionamiento de infraestructura son aspectos de la experimentación que las organizaciones pueden automatizar
• Tener en cuenta el alcance de la explosión: un ingeniero del caos debe esforzarse mucho en minimizar el alcance de la explosión para que el daño real a los clientes sea el menor posible. Algunas formas de minimizar el alcance de la explosión son:
  • Dirigir 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 ejecutarse sin control durante mucho tiempo.
  • Ejecutar el experimento lejos de los máximos de tráfico: las organizaciones deben intentar evitar ejecutar experimentos durante las horas punta, a menos que estén intentando evaluar específicamente cómo 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 no haya ninguna interrupción de la experiencia del cliente en el servicio es ejecutarlo en el entorno de preproducción. Sin embargo, eso significa que las condiciones diferirán de las del entorno de producción, lo que podría dar una imagen falsa de lo que está ocurriendo. Para minimizar esto, asegúrese de que sus entornos de preproducción y producción se reflejen entre sí en la medida de lo 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 debe ser probar "todo"; examinar todos los componentes, capas, servicios, y sus dependencias durante todo el proceso.

Las organizaciones que utilizan la ingeniería del caos deben decidir si utilizar 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 a 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 podría no crear una respuesta realista porque carece de los mismos niveles de tráfico que el entorno en vivo. También es posible que no tenga las mismas configuraciones de seguridad que ese entorno. 

Algunas organizaciones temen causar problemas intencionalmente con su sitio activo, por lo que ejecutan sus experimentos en su sitio de preproducción o de desarrollo. Esto garantiza que cualquier problema que se produzca no afecte a la experiencia del cliente en vivo. Para mitigar esto, algunas organizaciones comienzan en entornos de preproducción para controlar 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, la ingeniería del caos tiene como objetivo probar los problemas reales a gran escala, por lo que los entornos de producción proporcionarán la imagen más precisa de lo que sucede y lo que requiere solución.