As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Documento de planejamento de experimentos
## Estado estacionário
| Nome do processo | Site de adoção de animais de estimação |
| --- | --- |
| Arquitetura física | (Link para o diagrama de arquitetura.) |
| Arquitetura lógica | (Link para o diagrama lógico.) |
| Definir estado estacionário | O tempo médio de carregamento da página, medido usando o Largest Contentful Paint (LCP), para o site de adoção de animais de estimação é de 2,5 segundos ou menos com uma latência de 99 percentis (P99) de 4,0 segundos ou menos com uma linha de base de 5.000 usuários simultâneos. |
| Métricas de estado estacionário | Métrica LCP capturada em toda a base de usuários e métricas douradas (latência, taxa de transferência, taxas de erro, saturação). |
| Observabilidade em estado estacionário | O LCP será capturado pelo navegador do usuário, enviado para a Amazon CloudWatch e inspecionado com CloudWatch RUM. Em um período de 60 segundos, a média e o tempo de LCP do P99 serão agregados para todas as solicitações nesse período. As métricas douradas de alto nível são capturadas usando CloudWatch. |
| Processo para atingir o estado estacionário | O Grafana K6 será usado para criar uma carga que simula os níveis normais de tráfego de produção de aproximadamente 5 mil usuários simultâneos. |
## Requisitos de observabilidade
As equipes devem ser capazes de ver o seguinte:
+ **Estado estacionário**: o que será observado para verificar se a aplicação está em condições normais?
+ **Condição de falha**: como a condição de falha aparecerá no painel? Por exemplo:
+ Alarmes que devem ser acionados
+ Registros que devem ser gerados
+ **Impacto da falha**: o que deve ser observado para visualizar os componentes que devem ser afetados (escopo do impacto)?
+ **Recuperação**: Como a recuperação será visualizada e medida para capturar o MTTR?
+ **Depuração**: detalhes da solução de problemas em falhas de experimentos.
A tabela a seguir fornece sugestões e exemplos para um gráfico de requisitos de observabilidade. Você deve definir o que deve ser observado com base em seu experimento específico.
| O que precisa ser observado | Link para a ferramenta de observabilidade | O que está sendo observado |
| --- | --- | --- |
| Fonte de entrada | Painel de controle Grafana K6 | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Integridade geral do aplicativo | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Saúde do fluxo de trabalho | CloudWatch Painel de adoção de animais de estimação | Tempo de LCP, métricas douradas |
| Rastreamentos | Painel X-Ray para adoção de animais de estimação | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Logs | CloudWatch Registros de adoção de animais | Quaisquer erros encontrados pelos pods serão enviados para o CloudWatch Logs. |
## Definição do experimento
| Nome do experimento | Stress de CPU no Amazon EKS PetSite pod |
| --- | --- |
| Código-fonte do experimento | (Link para o repositório de origem do experimento.) |
| Descrição do experimento | Esse experimento explora como um aumento no uso da CPU do pod de PetSite aplicativos afetaria a experiência geral do cliente. Ao injetar estresse da CPU em cada PetSite pod em execução, poderemos entender se há impacto nos clientes e a extensão desse impacto. |
| Requisitos ou parâmetros do experimento | Carga de aplicação: média de produção
Seletor de etiquetas para pods: `app=petsite` |
| Duração do experimento | 10 minutos |
| Ambiente | Ambiente de teste Alpha |
| Recursos alvo do experimento | PetSite cápsulas de aplicação |
| Linha de base do experimento que é introduzida por meio da ferramenta de geração de carga | [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html) |
| Condição de recuo | Nenhum |
## Hipótese
| E se | Impacto | Recuperação |
| --- | --- | --- |
| O que aconteceria com o estado estável se os pods de PetSite aplicativos experimentassem ou causassem mais de 60% de utilização da CPU por 10 minutos sob o tráfego normal em nível de produção?
** ** | Os tempos de LCP permanecerão abaixo de 2,5 segundos para P50 de usuários com P99 de 4,0 segundos ou menos. O consumidor deve ser capaz de carregar a página de PetSite destino. | Detecção:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)
Autocura:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-planning.html)
Recuperação:
Quando a utilização da CPU voltar ao normal, o LCP deverá se recuperar automaticamente. |
## Processo experimental
Adapte o seguinte exemplo de step-by-step processo ao seu experimento específico:
1. Valide o acesso e a funcionalidade de todos os AWS X-Ray painéis CloudWatch, Amazon e CloudWatch RUM.
1. Valide a integridade do ambiente de aplicativos:
1. Confirme se o cluster EKS está íntegro usando o CloudWatch painel.
1. Visite a implantação do aplicativo do site de teste de adoção de animais de estimação no URL de exemplo.
1. Inicie uma carga para atingir o estado estável:
1. Confirme se o gerador de carga está funcionando e enviando 5000 solicitações por segundo.
1. Aguarde 5 minutos para que o aplicativo atinja seu estado estável.
1. Confirme o estado estável do aplicativo usando o painel do CloudWatch RUM.
1. Iniciar uma falha (experimento):
1. Abra o AWS FIS console.
1. Execute o pet-adoption-pod-stress experimento.
1. Confirme se o experimento está sendo executado no console.
1. Observe o impacto da falha em seu aplicativo:
1. Capture capturas de tela do CloudWatch RUM e dos CloudWatch painéis e anote quaisquer pontos de dados anômalos.
1. Depois que o experimento for concluído AWS FIS, capture capturas de tela adicionais para registrar se o aplicativo retorna ao estado estacionário na ausência de estresse e observe quaisquer anomalias nos pontos de dados.
1. Se o estado estacionário não for retomado, tome medidas para recuperar o aplicativo e registre as etapas realizadas.
1. Valide se o ambiente voltou ao normal:
+ Analise todas as métricas de negócios, experiência do usuário, aplicativos e infraestrutura para verificar se o sistema voltou a um estado conhecido. Capture capturas de tela do painel, se for útil.
## Cronograma do experimento
Certifique-se de capturar o cronograma do end-to-end experimento, começando com a geração de carga, a injeção da falha, a observação do impacto e a recuperação do aplicativo, e terminando quando você interrompe a geração de carga. Isso é ilustrado no exemplo a seguir.
## Resultados do experimento
| ID de execução do experimento | Resultados do experimento |
| --- | --- |
| `PET-ADOPT-EXP-23` | (Link para os resultados do experimento.) |
## Defeitos identificados
+ O cluster Kubernetes não detectou o comprometimento da CPU dos PetSite pods, por isso não agendou implantações adicionais.
+ Não houve aumento nas taxas de erro 4XX ou 5XX como resultado desse experimento.
+ Precisamos ajustar a verificação de integridade do pod para considerar o impacto no LCP quando há restrições de recursos.