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.
Implementación de la ingeniería del caos en AWS
La ingeniería del caos forma parte de la etapa de evaluación y prueba del ciclo de vida de la AWS resiliencia, como se ilustra en el siguiente diagrama. Las aplicaciones distribuidas no funcionan de forma aislada de otras aplicaciones o clientes, por lo que le recomendamos que revise todo el ciclo de vida de la resiliencia. El cambio es constante en las aplicaciones distribuidas a medida que la red evoluciona, las aplicaciones ascendentes y descendentes sufren cambios y el uso de los clientes cambia con el tiempo.
Para entender cómo estos cambios en su aplicación pueden afectar a su capacidad de recuperación, incorpore la ingeniería del caos a sus day-to-day operaciones. Puede implementar experimentos de caos de diferentes maneras:
-
Ad hoc: puedes realizar experimentos de caos como experimentos únicos para abordar un problema o una pregunta específicos.
-
Días de juego caóticos: se trata de eventos estructurados y recurrentes diseñados para comprobar la fiabilidad y la resiliencia de una aplicación. El objetivo de un día de juego caótico es identificar posibles problemas o deficiencias de resiliencia en las personas, los procesos y las tecnologías, y poner en práctica los procesos y procedimientos para identificar, mitigar y responder a los incidentes.
-
Canalización del caos: integración y entrega continuas (CI/CD) is about building new features and deploying them safely throughout the environments. To implement chaos engineering experiments, create a chaos pipeline that's separate from your CI/CD pipeline. To understand why, let's assume that you want to add a single chaos engineering experiment to your CI/CDcanalización que provoca una pérdida de paquetes cada vez mayor para los componentes posteriores). El experimento se ejecuta 3 veces y tarda 5 minutos en terminarse cada vez. La pérdida de paquetes aumenta del 10 al 20 por ciento al 30 por ciento con cada ejecución, y el experimento tarda 15 minutos en total en completarse. Si tiene 100 despliegues paralelos, tendrá que esperar 1500 minutos para que se complete un solo experimento. Si tiene que ejecutar 10 experimentos, el impacto para sus desarrolladores sería insoportable. A gran escala, la ingeniería del caos necesita su propia canalización que le permita ejecutar experimentos en paralelo al proceso del ciclo de vida de desarrollo de software (SDLC).
-
Implementaciones en Canary: las Islas Canarias proporcionan un entorno de pruebas para realizar experimentos de caos. Al dirigir un pequeño porcentaje del tráfico a un servicio de Canary o al utilizar métodos como la duplicación o la reproducción del tráfico, puede verificar los nuevos cambios en la infraestructura o el código sin afectar a la estabilidad de su sistema de producción. Puede realizar experimentos a prueba de errores e introducir errores según sea necesario, ya que puede limitar el alcance del impacto en el usuario final.
-
Experimentos programados: puede programar experimentos para verificar los mecanismos de recuperación predecibles de su aplicación. Utilice experimentos programados para reproducir eventos conocidos con frecuencia y ver cómo sus sistemas pueden recuperarse de eventos como la finalización de una EC2 instancia detrás de un grupo de escalado automático, la eliminación de un pod de Kubernetes o la eliminación de una tarea de Amazon ECS.
