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.
# Documento de planificación del experimento
## Estado estacionario
| Process name (Nombre del proceso) | Sitio de adopción de mascotas |
| --- | --- |
| Arquitectura física | (Enlace al diagrama de arquitectura). |
| Arquitectura lógica | (Enlace al diagrama lógico). |
| Defina el estado estacionario | El tiempo medio de carga de la página web de adopción de mascotas, medido con Largest Contentful Paint (LCP), es de 2,5 segundos o menos, con una latencia del 99 por ciento (P99) de 4 segundos o menos, con una base de referencia de 5000 usuarios simultáneos. |
| Métricas de estado estacionario | Métrica de LCP capturada en toda la base de usuarios y métricas doradas (latencia, rendimiento, tasas de error, saturación). |
| Observabilidad en estado estacionario | El navegador del usuario capturará el LCP, lo enviará a Amazon CloudWatch y lo inspeccionará con CloudWatch RUM. Durante un período de 60 segundos, se sumarán la media y el tiempo de LCP de 99 pesos para todas las solicitudes de ese período. Las métricas básicas de nivel superior se capturan mediante el uso de. CloudWatch |
| Proceso para alcanzar un estado estable | Grafana K6 se utilizará para crear una carga que simule los niveles normales de tráfico de producción de aproximadamente 5000 usuarios simultáneos. |
## Requisitos de observabilidad
Los equipos deberían poder ver lo siguiente:
+ **Estado estacionario**: ¿Qué se observará para verificar que la aplicación esté en condiciones normales?
+ **Condición de fallo**: ¿Cómo aparecerá el estado de fallo en el salpicadero? Por ejemplo:
+ Alarmas que deberían activarse
+ Registros que deben generarse
+ **Impacto de la falla**: ¿Qué se debe observar para ver los componentes que se espera que se vean afectados (alcance del impacto)?
+ **Recuperación**: ¿Cómo se visualizará y medirá la recuperación para captar el MTTR?
+ **Depuración**: detalles de solución de problemas relacionados con los errores de los experimentos.
La siguiente tabla proporciona sugerencias y ejemplos para un gráfico de requisitos de observabilidad. Debe definir lo que debe observarse en función de su experimento específico.
| ¿Qué hay que observar | Enlace a la herramienta de observabilidad | ¿Qué se está observando |
| --- | --- | --- |
| Fuente de entrada | Cuadro de mandos Grafana K6 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Estado general de la aplicación | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Estado del flujo de trabajo | CloudWatch Panel de adopción de mascotas | Tiempo de LCP, métricas doradas |
| Rastros | Panel de X-Ray sobre adopción de mascotas | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Registros | CloudWatch Registros de adopción de mascotas | Todos los errores que detecten los pods se enviarán a CloudWatch Logs. |
## Definición de experimento
| Nombre del experimento | Amazon EKS PetSite pod CPU stress |
| --- | --- |
| Experimenta con el código fuente | (Enlace al repositorio de fuentes del experimento). |
| Descripción del experimento | Este experimento explora cómo un aumento en el uso de la CPU del módulo de PetSite aplicaciones afectaría a la experiencia general del cliente. Al inyectar stress de CPU en cada PetSite módulo en ejecución, podremos entender si hay un impacto en los clientes y el alcance de ese impacto. |
| Requisitos o parámetros del experimento | Carga de aplicación: media de producción
Selector de etiquetas para cápsulas: `app=petsite` |
| Duración del experimento | 10 minutos |
| Entorno | Entorno de prueba alfa |
| Experimenta con los recursos objetivo | PetSite pods de aplicaciones |
| Experimente la línea base que se introduce mediante la herramienta de generación de carga | [See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Condición de retroceso | Ninguno |
## Hipótesis
| ¿Qué pasaría si | Impact | Recuperación |
| --- | --- | --- |
| ¿Qué pasaría con el estado estable si los pods de PetSite aplicaciones utilizaran o provocaran un uso de la CPU superior al 60% durante 10 minutos con un tráfico normal a nivel de producción?
** ** | Los tiempos de LCP se mantendrán por debajo de 2,5 segundos para un P50 de los usuarios con un P99 de 4 segundos o menos. El consumidor debería poder cargar la página de destino. PetSite | Detección:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)
Autorreparación:[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)
Recuperación:
Cuando el uso de la CPU vuelva a la normalidad, el LCP debería recuperarse automáticamente. |
## Proceso de experimentación
Adapte el siguiente step-by-step proceso de ejemplo a su experimento específico:
1. Valide el acceso y la funcionalidad de todos los Amazon CloudWatch, CloudWatch RUM y AWS X-Ray paneles de control.
1. Valide el estado del entorno de la aplicación:
1. Confirme que el clúster de EKS está en buen estado mediante el CloudWatch panel de control.
1. Visite la implementación de la aplicación del sitio de prueba de adopción de mascotas en la URL de ejemplo.
1. Inicie una carga para alcanzar un estado estable:
1. Confirme que el generador de carga esté funcionando y enviando 5000 solicitudes por segundo.
1. Espere 5 minutos para que la aplicación alcance su estado estable.
1. Confirme el estado estable de la aplicación mediante el panel de control de CloudWatch RUM.
1. Iniciar una falla (experimento):
1. Abre la AWS FIS consola.
1. Ejecuta el pet-adoption-pod-stress experimento.
1. Confirma que el experimento se está ejecutando en la consola.
1. Observe el impacto de la falla en su aplicación:
1. Realice capturas de pantalla del CloudWatch RUM y de los CloudWatch paneles de control y anote cualquier dato anómalo.
1. Una vez finalizado el experimento AWS FIS, captura capturas de pantalla adicionales para registrar si la aplicación vuelve al estado estable en ausencia de stress y observa cualquier anomalía en los puntos de datos.
1. Si el estado estable no se reanuda, tome medidas para recuperar la aplicación y registre las medidas adoptadas.
1. Valide que el entorno haya vuelto a la normalidad:
+ Revise todas las métricas empresariales, de la experiencia del usuario, de las aplicaciones y de la infraestructura para comprobar que el sistema ha vuelto a un estado conocido. Haga capturas de pantalla del panel de control si resulta útil.
## Cronología del experimento
Asegúrese de capturar la cronología del end-to-end experimento, empezando por la generación de la carga, la inyección de la falla, la observación del impacto y la recuperación de la aplicación, y finalizando cuando detenga la generación de carga. Esto se ilustra en el siguiente ejemplo.
## Resultados del experimento
| ID de ejecución del experimento | Resultados del experimento |
| --- | --- |
| `PET-ADOPT-EXP-23` | (Enlace a los resultados del experimento). |
## Defectos identificados
+ El clúster de Kubernetes no detectó el deterioro de la CPU de los PetSite pods, por lo que no programó despliegues adicionales.
+ Como resultado de este experimento, las tasas de error no aumentaron ni 4XX ni 5XX.
+ Tenemos que ajustar la comprobación del estado del módulo para tener en cuenta el impacto en el LCP cuando hay limitaciones de recursos.