Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Ciclo de vida continuo del experimento de ingeniería del caos

Como se ha explicado en la sección anterior, los experimentos de ingeniería del caos se pueden implementar de diferentes maneras. En todos los casos, la clave para crear un experimento de caos significativo es entender la aplicación, los incidentes históricos y las medidas correctivas implementadas, así como comprender claramente las áreas que se deben investigar, como la resiliencia o la seguridad. Sus conocimientos sobre la aplicación le ayudarán a formular una hipótesis sobre los posibles puntos débiles de la aplicación y a comprender cómo detectará, solucionará y recuperará una vez que se produzca el fallo.

El ciclo de vida del experimento del caos incluye los siguientes pasos:

Estos pasos se ilustran en el diagrama y se analizan en las siguientes secciones.

Defina los objetivos y establezca las expectativas

Antes de cada experimento, asegúrate de que tus objetivos y expectativas sean específicos, medibles, alcanzables, relevantes y estén sujetos a un plazo determinado. Defina claramente lo siguiente:

Seleccione la aplicación de destino

La ingeniería del caos es una técnica poderosa, pero requiere una priorización cuidadosa para maximizar el valor. A la hora de decidir dónde centrar los esfuerzos de ingeniería del caos, comience por considerar los servicios fundamentales de su empresa. Pida a sus equipos que repasen las etapas del ciclo de vida del desarrollo del software y comiencen primero a detectar errores en los entornos de prueba. Las aplicaciones esenciales para la empresa están directamente relacionadas con los ingresos, la experiencia del cliente y las operaciones principales. Los experimentos de caos en estos servicios pueden descubrir vulnerabilidades que, si no se abordan, pueden afectar gravemente a la organización (y, potencialmente, a mercados enteros). Por ejemplo, céntrese primero en los servicios orientados al cliente, como los sistemas de negociación o los sistemas de pedidos. La priorización de estos servicios centrales proporciona la mayor protección por inversión de tiempo.

Después de los servicios esenciales, analice los componentes fundamentales, como las bases de datos, las colas de mensajes, las redes y los servicios compartidos. APIs Es posible que se utilicen como componentes o servicios compartidos en toda la organización, por lo que su fallo provocará problemas generalizados. Confirmar la resiliencia de los servicios de infraestructura proporciona la confianza de que no paralizarán las aplicaciones dependientes que están por encima de ellos. Por ejemplo, un experimento de ingeniería del caos en el que se desactiva un clúster de Kafka revela muchos aspectos de la tolerancia a los fallos de las aplicaciones posteriores. Si bien la infraestructura del sistema no está orientada directamente al cliente, es uno de los principales objetivos de la ingeniería del caos.

No olvide trazar un mapa de las brechas mentales de las personas, los procesos, la información de las instalaciones y las dependencias con terceros, ya que estas pueden provocar importantes perturbaciones si no se ajustan a los objetivos de tolerancia al impacto de su organización. Para obtener más información sobre cómo medir el ROI de la ingeniería del caos, lea Cuantificar el ROI de la ingeniería del caos en el documento de estrategia Invertir en la ingeniería del caos como una necesidad estratégica.

En el siguiente diagrama se muestra el retorno de la inversión que se obtiene al realizar experimentos de caos en diferentes niveles de servicios.

Alinee los mapas mentales (descubrimiento de aplicaciones)

Cuando realices experimentos ad hoc o juegues, comenzarás el proceso de descubrimiento de aplicaciones con una sesión de pizarra que se centrará en mapear los detalles de tu aplicación. (Si llevas a cabo los experimentos de forma caótica, ya habrás alineado ese mapa mental al definir la aplicación de destino). Un buen método para entender las carencias mentales consiste en hacer que el miembro más joven del equipo dibuje primero un diagrama de la solicitud y, a continuación, pida a otros miembros del personal superior que vayan añadiendo elementos al diagrama progresivamente. Esto revelará cualquier laguna de comprensión en los distintos niveles de experiencia.

El diagrama debe mostrar las dependencias directas de la aplicación, tanto en sentido ascendente como descendente, así como cualquier integración esencial de terceros. Asegúrese de que el flujo esperado de una solicitud a través de la aplicación esté alineado. Planifique los flujos de trabajo clave y los recorridos de los usuarios para obtener claridad sobre la forma en que los clientes utilizan la aplicación. Considere la posibilidad de utilizar un diagrama de secuencia para capturar esta información.

Tras esta sesión de colaboración, el equipo debería tener un modelo mental compartido de la aplicación, sus dependencias críticas y sus capacidades de supervisión, y comprender los riesgos para poder tomar la decisión fundamentada de continuar con un posible experimento de caos o cancelarlo.

Resuelva los problemas conocidos de su aplicación

Los experimentos de ingeniería del caos están diseñados para detectar de forma proactiva los defectos de una aplicación. Al introducir errores como el aumento de la latencia, los reinicios del servidor o los cortes de energía en las zonas de disponibilidad, puede comprobar la capacidad de su aplicación para tolerar interrupciones realistas. Sin embargo, este proceso supone un nivel subyacente de estabilidad y estado en la aplicación de destino. Al ejecutar experimentos de caos en una aplicación que ya es problemática, se corre el riesgo de enmascarar problemas más profundos.

Antes de emprender una ingeniería de caos, los equipos deben resolver cualquier defecto, error o problema de rendimiento conocido en su aplicación.

Defina la hipótesis y el experimento

Los incidentes pasados que causaron interrupciones en su aplicación o en otras aplicaciones de su organización pueden ser excelentes fuentes de ideas para hacer experimentos caóticos. Por ejemplo, ¿las interrupciones anteriores se debieron a errores de configuración o a la falta de patrones de resiliencia? Revisar los historiales de incidentes y reproducir las causas fundamentales de esos fracasos del mundo real mediante experimentos de caos es una forma eficaz de desarrollar la resiliencia ante problemas similares en el futuro.

Otra fuente valiosa de conceptos experimentales puede provenir directamente de los ingenieros, arquitectos y operadores que estén más familiarizados con una aplicación. Permitir que los miembros del equipo presenten escenarios hipotéticos de fallo que, a su juicio, podrían interrumpir considerablemente la aplicación permite recopilar ideas basadas en información privilegiada. Luego, el equipo de aplicación puede evaluar cuál de estos escenarios propuestos podría tener el mayor impacto potencial o exponer los mayores riesgos desconocidos. Centrarse en experimentos de caos para escenarios de alto riesgo y menos entendidos puede generar importantes aprendizajes y prevenir problemas en el futuro.

Una tercera fuente de ideas proviene de la elaboración de modelos de resiliencia para anticipar las condiciones que provocarían pérdidas empresariales identificadas. Algunos ejercicios de modelado de resiliencia tienen un enfoque basado en componentes para construir un modelo de resiliencia, mientras que otros tienen un enfoque basado en sistemas. Un enfoque basado en componentes plantea la siguiente pregunta: «¿Qué sucede cuando el componente x está sometido a una carga extrema o ha fallado?» El equipo que desarrolla el modelo de resiliencia luego especula sobre el efecto de tal escenario en la aplicación más amplia e identifica los controles de monitoreo y prevención actualmente en vigor para detectar y mitigar los efectos del escenario. Como alternativa, un enfoque basado en sistemas sigue un proceso descendente para resaltar un estado no deseado de la aplicación (por ejemplo, «La tienda web muestra niveles de inventario obsoletos») e invita al equipo de la aplicación a anticipar qué condición o condiciones podrían provocar que la aplicación se comporte de esta manera.

Garantice la preparación operativa para el experimento

Se necesitan indicadores cuantificables para medir el impacto de las condiciones adversas en la aplicación y su comportamiento, tal como se describió anteriormente en la sección sobre observabilidad. La capacidad de medir el comportamiento de la aplicación le permite determinar si las condiciones adversas afectaron a la aplicación y en qué magnitud.

La mejor manera de saber si hay un impacto en su aplicación es medir su estado estable. El estado estable mide el aspecto del funcionamiento normal y, por lo general, se alinea con los indicadores de experiencia empresarial y del cliente de una aplicación determinada. Antes de pasar al siguiente paso, asegúrate de disponer de la capacidad de observación necesaria para entender el impacto y de tener preparados los mecanismos de retroceso en caso de que el experimento no dé los resultados esperados.

Realiza experimentos y escenarios controlados

En AWS, no recomendamos realizar un experimento de caos inicial en una aplicación que esté en producción. El objetivo de un experimento de caos es aprender algo nuevo sobre el comportamiento de la aplicación en condiciones de estrés. El comportamiento de la aplicación puede ser impredecible durante el experimento, por lo que realizar un experimento por primera vez en producción podría tener consecuencias para los clientes. Por lo tanto, siempre debes realizar un experimento de caos inicial en un entorno de nivel inferior que tenga un mínimo potencial de afectar a los usuarios del mundo real y, a continuación, repetir los entornos una vez que compruebes y estés seguro de que tu aplicación puede absorber las acciones introducidas, adaptarse y recuperarse de ellas.

Planifique cada experimento minuciosamente utilizando un documento que recoja los detalles clave, similar al documento de planificación del experimento que se incluye en el apéndice. Algunos de los campos críticos que se deben incluir son la definición del estado estacionario, la hipótesis y el método de inyección de fallas. La planificación, la ejecución y el análisis de un experimento de caos se pueden abarcar en un único artefacto.

Tras finalizar el plan escrito para el experimento, prepare el código necesario para introducir las interrupciones planificadas que se describen en el documento.

Para captar el impacto potencial durante el experimento, asegúrate de que existan mecanismos de observabilidad. Si aún no dispone de una forma automatizada de capturar los resultados del experimento, como los informes del AWS FIS experimento, identifique a los miembros del equipo que tomarán notas durante la ejecución, capture capturas de pantalla de los paneles y guíe al equipo durante el experimento.

Aprenda y ajuste con precisión

Después de cada experimento, reúnanse en equipo para revisar y reflexionar sobre el experimento del caos. Haz un esfuerzo consciente por mantener una mentalidad irreprochable. Su objetivo debe ser tener un diálogo abierto y constructivo que se centre exclusivamente en obtener el máximo aprendizaje, no en culpar a los demás.

Comience por revisar la definición y la hipótesis del estado estacionario para el experimento. ¿Se comportó la aplicación como se esperaba? ¿Hubo alguna sorpresa que invalidara las suposiciones? Comenta las observaciones sobre cómo reaccionó la aplicación durante el experimento, tanto buenas como malas. Los datos recopilados (métricas, registros, capturas de pantalla, etc.) deberían explicar exactamente lo que ocurrió.

Aborde esta revisión de datos con curiosidad y no con criterio, e identifique las áreas en las que se pueden mejorar el diseño, la documentación, la supervisión u otras capacidades de las aplicaciones en función de lo aprendido. Estos elementos de acción se capturan como proyectos de seguimiento para hacer que la aplicación sea más resiliente.

Gracias a este enfoque irreprochable, puede mantener conversaciones sinceras sobre lo que salió mal y cómo solucionarlo. Suponga que todas las personas involucradas tienen intenciones positivas y confíe en que estaban trabajando para lograr buenos resultados. Su objetivo común es el crecimiento y el progreso de la organización a través del aprendizaje y la adaptación continuos. Las revisiones de los experimentos del caos, que se llevan a cabo de manera constructiva e impecable, proporcionan un espacio seguro para que su equipo obtenga información valiosa que haga que sus aplicaciones y su organización sean más confiables y resilientes a largo plazo. La atención se centra en los aprendizajes, no en las personas. Para difundir lo aprendido entre sus equipos, publique el informe de resultados del experimento en un lugar central y publique los resultados para que otros puedan aprender de él.