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 do resultado do experimento
<a name="sample-result"></a>

## Configuração
<a name="config"></a>

Documente as configurações específicas do experimento. Por exemplo:
+ Conjunto de geração de carga para simular 5 mil usuários emitindo um total de 85 solicitações por segundo.

## Pré-requisitos
<a name="prereqs"></a>
+ Verificou se o site de adoção de animais de estimação estava funcionando no ambiente de teste alfa.
+ Verifiquei se o modelo do experimento foi configurado para aplicar estresse de CPU aos pods de PetSite aplicativos que estão sendo executados no cluster EKS.  Os pods de aplicativos foram identificados pelo rótulo Kubernetes. `app=petsite`
+ Foi confirmado que a carga está sendo executada e gerando 85 solicitações por segundo.

## Estado estacionário
<a name="results-steady-state"></a>

Documente as etapas tomadas para alcançar o estado estável e como você o verificou. Por exemplo:

Para a implantação de teste do local de adoção de animais de estimação, uma carga de 85 RPS está sendo gerada para simular o estado estacionário. O CloudWatch RUM e os CloudWatch painéis foram revisados para verificar se todas as métricas de negócios e aplicativos estavam dentro dos intervalos normais antes da execução do experimento.

Dados de observabilidade:


| Esperados | Observado | 
| --- | --- | 
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-result.html) | ![Relatório de estado estacionário 1 para o experimento do caos.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/images/ss-1.png)![Relatório de estado estacionário 2 para o experimento do caos.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/images/ss-2.png) | 

## Injeção de falhas
<a name="fault-injection"></a>

AWS FIS foi usado para injetar falhas usando o modelo do experimento (forneça o link). O experimento foi configurado para ser executado por 10 minutos, e uma reversão foi configurada se os nós de trabalho sofressem estresse na CPU acima de 60%.

## Observação de falhas
<a name="fault-obs"></a>

O CloudWatch RUM e os CloudWatch painéis foram revisados para rastrear o estado estável do aplicativo (definido usando métricas de LCP).  As capturas de tela foram capturadas na tabela a seguir.

Dados de observabilidade:


| Esperados | Observado | 
| --- | --- | 
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/sample-result.html) | ![Relatório de observação de falhas 1 para experimento de caos.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/images/fs-1.png)![Relatório de observação de falhas 2 para experimento de caos.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/images/fs-2.png) | 

## Recuperação
<a name="recovery"></a>

Depois que o estresse for removido (o AWS FIS experimento foi concluído e o estresse da CPU foi removido dos pods), o aplicativo deve retomar seu estado estável normal.  Nenhuma intervenção manual deve ser necessária.

Dados de observabilidade:


| Esperados | Observado (captura de tela) | 
| --- | --- | 
| O LCP P99 deve estar abaixo de 4 segundos, com a média abaixo de 2,5 segundos. | ![A recuperação de amostras resulta de um experimento de caos.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/chaos-engineering-on-aws/images/rec-1.png) |