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á.
# Etapa 4: operar
Depois de concluir a [Etapa 3: avaliar e testar](stage-3.md), tudo estará pronto para a implantação da aplicação na produção. Na etapa *Operar*, você implanta a aplicação na produção e gerencia a experiência de seus clientes. O design e a implementação da sua aplicação determinam muitos de seus resultados de resiliência, mas essa etapa se concentra nas práticas operacionais que seu sistema usa para manter e melhorar a resiliência. Criar uma cultura de excelência operacional ajuda a criar padrões e consistência nessas práticas.
## Observabilidade
A parte mais importante para entender a experiência do cliente é por meio de monitoramento e alarmes. Você precisa instrumentar sua aplicação para entender seu estado, e precisa de perspectivas diversas, o que significa que você precisa avaliar tanto do lado do servidor quanto do lado do cliente, normalmente com canários. Suas métricas devem incluir dados sobre as interações da sua aplicação com suas dependências e [dimensões que se alinham às delimitações de isolamento contra falhas](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/multi-az-observability.html). Você também deve produzir logs que forneçam detalhes adicionais sobre cada unidade de trabalho realizada pela sua aplicação. Você pode considerar combinar métricas e logs usando uma solução como o [formato métrico incorporado do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html). Você provavelmente descobrirá que sempre quer mais observabilidade, então considere as compensações de custo, esforço e complexidade necessárias para implementar o nível desejado de instrumentação.
Os links a seguir fornecem as práticas recomendadas para instrumentar a aplicação e criar alarmes:
+ [Monitoring production services at Amazon](https://youtu.be/hnPcf_Czbvw) (apresentação do AWS re:Invent 2020)
+ [Amazon Builders' Library: Operational Excellence at Amazon](https://youtu.be/7MrD4VSLC_w) (apresentação do AWS re:Invent 2021)
+ [Observability best practices at Amazon](https://youtu.be/zZPzXEBW4P8) (apresentação do AWS re:Invent 2022)
+ [Como instrumentar sistemas distribuídos para obter visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) (artigo da Amazon Builders' Library)
+ [Building dashboards for operational visibility](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/) (artigo da Amazon Builders' Library)
## Gerenciamento de eventos
Você deve ter um processo de gerenciamento de eventos para lidar com deficiências quando seus alarmes (ou pior, seus clientes) informam que algo está errado. Esse processo deve incluir o acionamento de um operador de plantão, o escalonamento de problemas e o estabelecimento de runbooks para abordagens consistentes de solução de problemas que ajudem a remover erros humanos. No entanto, as deficiências geralmente não ocorrem isoladamente. Uma única aplicação pode afetar várias outras aplicações que dependem dela. Você pode resolver problemas rapidamente entendendo todas as aplicações afetadas e reunindo operadores de várias equipes em uma única teleconferência. No entanto, dependendo do tamanho e da estrutura da sua organização, esse processo pode exigir uma equipe de operações centralizada.
Além de configurar um processo de gerenciamento de eventos, você deve revisar regularmente suas métricas por meio de painéis. As avaliações regulares ajudam você a entender a experiência do cliente e as tendências de longo prazo na performance da sua aplicação. Isso ajuda a identificar problemas e gargalos antes que eles causem um impacto significativo na produção. Analisar as métricas de forma consistente e padronizada oferece benefícios significativos, mas exige uma adesão de cima para baixo e um investimento de tempo.
Os links a seguir fornecem as práticas recomendadas na criação de painéis e análises de métricas operacionais:
+ [Building dashboards for operational visibility](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/) (artigo da Amazon Builders' Library)
+ [Amazon's approach to failing successfully](https://youtu.be/yQiRli2ZPxU) (apresentação do AWS re:Invent 2019)
## Resiliência contínua
Durante a [Etapa 2: projetar e implementar](stage-2.md) e a [Etapa 3: avaliar e testar](stage-3.md), você iniciou as atividades de revisão e teste antes de implantar sua aplicação na produção. Durante a etapa de *operação*, você deve continuar iterando essas atividades na produção. Você deve revisar periodicamente a postura de resiliência da sua aplicação por meio de [análises do AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/), de [análises de prontidão operacional (ORRs)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) e do [framework de análise de resiliência](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html). Isso ajuda a garantir que sua aplicação não se desvie das linhas de base e dos padrões estabelecidos e garante que você esteja a par das orientações novas ou atualizadas. Essas atividades de resiliência contínua ajudam você a descobrir interrupções anteriormente imprevistas e a criar novas mitigações.
Você também pode considerar realizar [dias de jogo](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html) e experimentos de [engenharia do caos](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/) na produção depois de executá-los com êxito em ambientes de pré-produção. Os dias de jogo simulam eventos conhecidos para os quais você criou mecanismos de resiliência a fim de mitigá-los. Por exemplo, um dia de jogo pode simular uma deficiência no serviço regional da AWS e implementar um failover multirregional. Embora a implementação dessas atividades possa exigir um nível significativo de esforço, ambas as práticas ajudam a criar confiança de que seu sistema é resiliente aos modos de falha que você o projetou para suportar.
Ao operar suas aplicações, enfrentar eventos operacionais, revisar métricas e testar sua aplicação, você encontrará inúmeras oportunidades para responder e aprender.