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.
Cómo empezar con la ingeniería del caos
Antes de realizar un experimento, le recomendamos que ponga en práctica algunos elementos esenciales para aprovechar al máximo sus prácticas de ingeniería del caos. Estos elementos esenciales incluyen:
-
Observabilidad (métricas, registro, seguimiento de solicitudes)
-
Una lista de eventos o fallas del mundo real que te gustaría explorar
-
Patrocinio de la resiliencia organizacional mediante la participación de los líderes
-
Priorización de los hallazgos críticos, en función del posible impacto empresarial, por encima de las nuevas características que se descubran al realizar experimentos de caos
Observabilidad para experimentos de caos
La observabilidad, que comprende las métricas, el registro y el seguimiento de las solicitudes, desempeña un papel clave en la ingeniería del caos. Cuando realice un experimento, querrá comprender las métricas empresariales, las métricas del lado del servidor, las métricas de la experiencia del cliente y las métricas de las operaciones. Sin la observabilidad, no podrá definir el comportamiento en estado estacionario ni crear un experimento significativo para verificar si su hipótesis sobre su aplicación es cierta.
Métricas
El siguiente diagrama muestra los tipos de métricas de las que puede hacer un seguimiento para realizar experimentos de caos en distintos tipos de aplicaciones.
-
Métricas empresariales: el estado estable indica el funcionamiento normal del sistema y lo definen las métricas empresariales. Se puede representar mediante transacciones por segundo (TPS), flujos de clics por segundo, pedidos por segundo o una medición similar. La aplicación muestra un estado estable cuando funciona según lo esperado. Por lo tanto, compruebe que la aplicación esté en buen estado antes de ejecutar los experimentos. El estado estable no significa necesariamente que no se produzca ningún impacto en la aplicación cuando se produzca un error, ya que un porcentaje de errores podría estar dentro de los límites aceptables. El estado estacionario es su punto de referencia. Por ejemplo, el estado estable de un sistema de pagos podría definirse como el procesamiento de 300 TPS con una tasa de éxito del 99 por ciento y un tiempo de ida y vuelta de 500 ms. Visualmente, piense en el estado estacionario como un electrocardiograma (ECG). Si el estado estable de su sistema fluctúa repentinamente, sabrá que hay un problema con el servicio.
-
Métricas del lado del servidor: para comprender el rendimiento de sus recursos durante el experimento, necesita información sobre su rendimiento antes, durante y después del experimento. Para medir el impacto de tus recursos en AWS, puedes usar Amazon CloudWatch. CloudWatch es un servicio que monitorea las aplicaciones, responde a los cambios de rendimiento, optimiza el uso de los recursos y proporciona información sobre el estado de las operaciones. Durante sus experimentos, querrá capturar métricas del lado del servidor, como la saturación, los volúmenes de solicitudes, las tasas de error y la latencia.
-
Métricas de experiencia del cliente: sí AWS, puedes capturar métricas de usuarios reales mediante CloudWatchRUM para simular las solicitudes de los usuarios a través de herramientas como Locust, Grafana k6, Selenium o Puppeteer. Las métricas reales de los usuarios son fundamentales para las organizaciones que llevan a cabo experimentos de ingeniería del caos. Al monitorear cómo se ven afectados los usuarios reales durante un experimento, los equipos pueden obtener una imagen precisa de cómo los fallos y las interrupciones afectarán a los clientes en la producción. Los indicadores clave de la experiencia del cliente son el tiempo hasta el primer byte (TTFB), Largest Contentful Paint (LCP), la interacción con el siguiente cuadro (INP) y el tiempo total de bloqueo (TBT).
-
Métricas operativas: las intervenciones miden la eficacia con la que se mitigan los fallos de forma automatizada; por ejemplo, la latencia correcta de las solicitudes de los clientes durante el reinicio de módulos, tareas o instancias de EC2 con mecanismos como el controlador de replicación o el escalado automático. Poder intervenir automáticamente durante una avería está directamente relacionado con una buena experiencia de usuario. Es crucial saber si estos mecanismos de mitigación se ven alterados a lo largo del tiempo. Al definir las métricas para las mitigaciones automatizadas exitosas y fallidas, se crean pautas que ayudan a identificar las posibles regresiones en todo el sistema.
Registro
El registro centralizado es fundamental para comprender los estados de los componentes de la aplicación antes, durante y después de un experimento caótico. Le recomendamos que recopile registros de todos los componentes de la aplicación para crear una vista consolidada de lo que hacía cada componente en el momento en que se introdujo el experimento. Esto proporciona una imagen clara del flujo del end-to-end experimento.
Rastreo de solicitudes
El rastreo de solicitudes le permite observar el flujo de cualquier solicitud individual en los componentes de la aplicación para obtener una comprensión completa del impacto que la falla inyectada tiene en el sistema y sus dependencias. Al rastrear las solicitudes, puede ver cómo se propaga la falla a través de los diferentes servicios y componentes, lo que le permite evaluar mejor el alcance de la interrupción. Para rastrear sus solicitudes AWS, puede utilizar. AWS X-Ray
Escenarios de fracaso para provocar el caos en los experimentos
El objetivo de introducir errores comunes en su aplicación es comprender cómo reacciona la aplicación ante estos eventos inesperados, de modo que pueda crear mecanismos de mitigación y hacer que su sistema sea resistente a dichos errores. Además, debe utilizar la ingeniería del caos para reproducir los escenarios de fallos históricos y comprobar que sus mecanismos de mitigación siguen funcionando según lo previsto y que no se han desviado con el paso del tiempo.
Ten en cuenta los siguientes eventos cuando planifiques tus experimentos de ingeniería del caos.
| Modo de fallo | Description (Descripción) |
|---|---|
Deterioro del servidor |
Reinicie las instancias EC2, elimine los pods de Kubernetes o las tareas de Amazon Elastic Container Service (Amazon ECS) para comprender cómo reacciona su aplicación ante estos bloqueos. |
errores de API |
Introduce errores en tu propio servicio APIs para AWS entender el comportamiento de las aplicaciones. |
Problemas de red |
Introduzca latencia o congestión, o bloquee las conexiones para imitar los problemas de red del mundo real. |
AWS Deterioro de zona de disponibilidad |
Reproduzca el deterioro de una zona de disponibilidad completa para verificar la recuperación en todas las zonas. |
Región de AWS deterioro de la conectividad |
Reproduzca una avería de la red Regiones de AWS para comprobar cómo reaccionan los recursos de la región secundaria ante tal suceso. |
Fallos en la base |
Conmute por error las réplicas de las bases de datos o dañe los datos, o impida el acceso a las instancias de la base de datos, para comprender el impacto en sus estrategias de aplicaciones y recuperación. |
Pausa en la replicación de la base de datos y Amazon S3 |
Detenga la replicación de la base de datos o de Amazon Simple Storage Service (Amazon S3) en todas las zonas de disponibilidad Regiones de AWS o para comprender el impacto en las aplicaciones posteriores. |
Degradación del almacenamiento |
Pausa la E/S, elimina los volúmenes de Amazon Elastic Block Store (Amazon EBS) o elimina archivos para comprobar la durabilidad y la recuperación de los datos. |
Deterioro de dependencia |
Reduzca o degrade el rendimiento de los servicios descendentes o ascendentes de los que depende, incluidos los servicios de terceros, para comprender el end-to-end flujo y el impacto en sus clientes. |
Aumentos repentinos de tráfico |
Genere picos en el tráfico de usuarios para probar las capacidades de escalado automático y compruebe cómo el tiempo de arranque en frío puede afectar al estado general de la aplicación. |
Agotamiento de los recursos |
Aproveche al máximo la CPU, la memoria y el espacio en disco para comprobar la correcta degradación de la aplicación. |
Fallos en cascada |
Provocan los errores principales que repercuten en cascada en las aplicaciones y los componentes posteriores. |
Implementaciones incorrectas |
Implemente cambios o configuraciones problemáticos para verificar los mecanismos de reversión. |
Patrocinio de la resiliencia organizacional
La ingeniería del caos proporciona el mayor valor cuando se aplica en toda la organización. Le recomendamos que trabaje con un patrocinador ejecutivo que pueda ayudarlo a establecer objetivos de resiliencia en toda su organización, eliminar el miedo, la incertidumbre y las dudas sobre el ámbito e iniciar el proceso de transformación para que la resiliencia sea responsabilidad de todos.
Para respaldar el argumento empresarial de crear una práctica de ingeniería basada en el caos, incorpore las iniciativas de ingeniería del caos a sus proyectos empresariales fundamentales. Hacer de la resiliencia un activo y un motor de aceleración le ayudará a medir el éxito a lo largo del tiempo. Comience con un recuento de los incidentes críticos por mes o por trimestre, el tiempo promedio de recuperación y el impacto que estos incidentes causaron a sus clientes y a su organización. Establezca un objetivo con sus equipos para reducir el número de incidentes en un período de 6 a 12 meses, a medida que se vayan introduciendo mejoras en todos sus paquetes de aplicaciones en respuesta a los complicados experimentos de ingeniería.
Mida si los incidentes son muy repetitivos. Por ejemplo, supongamos que un certificado TLS caducado provoca un tiempo de inactividad porque los clientes no pueden establecer una conexión de confianza. Si se producen varios incidentes en un año debido a la caducidad de varios certificados TLS, puedes realizar un experimento sobre la caducidad de un certificado TLS y comprobar que tus equipos reciben alertas o son capaces de mitigar automáticamente dichos problemas. Esto ayudará a garantizar que seas resistente a este tipo de errores.
Para hacer un seguimiento del progreso de la ingeniería del caos a lo largo del tiempo, registre las siguientes métricas para ayudar a resaltar el valor de la ingeniería del caos a lo largo del ciclo de vida de una aplicación:
-
Menor tasa de incidentes: haga un seguimiento del número de incidentes de producción a lo largo del tiempo y correlacione este número con la adopción de la ingeniería del caos. La expectativa es que la tasa de incidentes graves disminuya.
-
Mejora del tiempo medio de resolución (MTTR): calcule el tiempo medio que se tarda en resolver los incidentes y realice un seguimiento de estos datos para comprobar si mejoran con la ingeniería del caos a lo largo del tiempo.
-
Mayor disponibilidad de las aplicaciones: utilice métricas de nivel de servicio para mostrar las mejoras de disponibilidad a medida que aumenta la resiliencia de las aplicaciones debido a los experimentos caóticos.
-
Lanzamiento más rápido del mercado: la ingeniería basada en el caos puede proporcionarle la confianza necesaria para lanzar ofertas innovadoras con mayor rapidez, ya que sabe que sus aplicaciones son resilientes. Realice un seguimiento de los aumentos en la velocidad de lanzamiento de los productos.
-
Reducción de los costos operativos: cuantifique si indicadores como el ruido de las alertas, la carga operativa y el esfuerzo manual para administrar las aplicaciones disminuyen debido a las prácticas caóticas.
-
Aumentar la confianza: encueste a los desarrolladores, los ingenieros de confiabilidad del sitio (SREs) y otro personal técnico para evaluar si la ingeniería del caos aumentó su confianza en la resiliencia de las aplicaciones. Las percepciones importan.
-
Experiencias de cliente mejoradas: Connect la ingeniería del caos con resultados positivos para los clientes, como menos interrupciones del servicio, retrocesos e interrupciones.
Priorizar la remediación
Al realizar experimentos de caos, es probable que identifique áreas de mejora en las que la aplicación no funciona según lo previsto. La solución de estos problemas se convertirá en una tarea pendiente que tendrá que priorizar junto con otras tareas, como el desarrollo de funciones. Le recomendamos que dedique tiempo a estas mejoras para evitar futuros errores. Considere la posibilidad de priorizar estos aprendizajes y tareas de corrección en función del nivel de impacto que puedan causar. Los hallazgos que afecten directamente a la resiliencia o la seguridad de la aplicación deberían tener prioridad sobre las nuevas funciones, a fin de evitar que repercutan en los clientes. Si el equipo se esfuerza por priorizar las tareas de remediación antes que el desarrollo de funciones, considere la posibilidad de ponerse en contacto con su patrocinador ejecutivo para asegurarse de que las prioridades se establezcan en función de la tolerancia al riesgo empresarial.
