# OPERAÇÕES 10. Como gerenciar os eventos de workload e operações?
Prepare e valide procedimentos para responder a eventos, com o objetivo de minimizar a interrupção de sua carga de trabalho.
**Topics**
+ [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 Ter um processo por alerta](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 Priorizar eventos operacionais com base no impacto nos negócios](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 Definir caminhos para escaladas](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 Definir um plano de comunicação com o cliente para interrupções](ops_event_response_push_notify.md)
+ [OPS10-BP06 Comunicar o status por meio de painéis](ops_event_response_dashboards.md)
+ [OPS10-BP07 Automatizar respostas a eventos](ops_event_response_auto_event_response.md)
# OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas
Sua organização tem processos para lidar com eventos, incidentes e problemas. *Eventos* são coisas que ocorrem em sua workload que talvez não precisem de intervenção. *Incidentes* são eventos que requerem intervenção. *Problemas* são eventos recorrentes que exigem intervenção ou que não podem ser resolvidos. São necessários processos para reduzir o impacto desses eventos sobre os negócios e garantir respostas adequadas.
Quando incidentes e problemas acontecem em sua workload, você precisa de processos para lidar com eles. Como você vai comunicar o status do evento às partes interessadas? Quem supervisiona e lidera a resposta? Quais são as ferramentas usadas para mitigar o evento? Esses são alguns exemplos de perguntas que você precisa responder para ter um processo de resposta sólido.
Os processos devem estar documentados em um local central e disponíveis a todos envolvidos com a workload. Se você não tiver uma wiki ou um armazenamento central de documentos, use um repositório de controle de versão. Você vai manter esses planos atualizados à medida que os processos evoluem.
Problemas são candidatos para automação. Esses eventos consomem o tempo que você poderia usar para inovar. Comece criando um processo repetível para mitigar o problema. Com o tempo, concentre-se na automação da mitigação ou correção do problema subjacente. Isso vai liberar tempo que você poderá dedicar ao desenvolvimento de melhorias para a workload.
**Resultado desejado:** sua organização tem processos para lidar com eventos, incidentes e problemas. Esses processos são documentados e armazenados em um local central. Eles são atualizados à medida que os processos mudam.
**Antipadrões comuns:**
+ Um acidente ocorre durante um final de semana e o engenheiro de plantão não sabe o que fazer.
+ Um cliente envia um e-mail informando que a aplicação está fora do ar. Você reinicializa o servidor para corrigir. Isso acontece com frequência.
+ Há um incidente com várias equipes trabalhando de maneira independente para resolvê-lo.
+ As implantações acontecem na workload sem serem registradas.
**Benefícios do estabelecimento desta prática recomendada:**
+ Você tem uma trilha de auditoria de eventos na workload.
+ O tempo para se recuperar de um incidente diminui.
+ Os membros da equipe podem resolver incidentes e problemas de maneira consistente.
+ Há um esforço mais consolidado na hora de investigar um incidente.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação de implementação
Implementar essa prática recomendada significa que você está monitorando os eventos da workload. Você tem processos para lidar com incidentes e problemas. Os processos são documentados, compartilhados e atualizados com frequência. Problemas são identificados, priorizados e corrigidos.
**Exemplo de cliente**
A AnyCompany Retail tem uma parte de sua wiki interna dedicada a processos para gerenciamento de eventos, incidentes e problemas. Todos os eventos são enviados para o [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html). Os problemas são identificados como OpsItems no [OpsCenter do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) e priorizados para correção, reduzindo a mão de obra não diferenciada. À medida que os processos mudam, eles são atualizados na wiki interna. Eles usam o [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para gerenciar incidentes e coordenar os esforços de mitigação.
## Etapas da implementação
1. Eventos
+ Monitore os eventos que acontecem na workload, mesmo que nenhuma intervenção humana seja necessária.
+ Trabalhe com as partes interessadas da workload para desenvolver uma lista de eventos que devem ser monitorados. Alguns exemplos são implantações concluídas ou aplicações de correções bem-sucedidas.
+ Você pode usar serviços como [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) ou [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) para gerar eventos personalizados para monitoramento.
1. Incidentes
+ Comece definindo o plano de comunicação para incidentes. Quais partes interessadas devem ser informadas? Como você vai mantê-las informadas? Quem supervisiona os esforços de coordenação? Recomendamos a configuração de um canal de bate-papo interno para comunicação e coordenação.
+ Defina caminhos de encaminhamento para as equipes que oferecem suporte à workload, principalmente se a equipe não tiver uma rotação de plantão. Com base em seu nível de suporte, você também pode registrar um caso no Suporte.
+ Crie um playbook para investigar o incidente. Isso deve incluir o plano de comunicação e etapas de investigação detalhadas. Inclua a verificação do [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) na investigação.
+ Documente seu plano de resposta a incidentes. Comunique o plano de gerenciamento de incidentes para que clientes internos e externos entendam as regras de engajamento e o que espera-se deles. Treine os membros de sua equipe sobre como usá-lo.
+ Os clientes podem usar o [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para configurar e gerenciar seu respectivo plano de resposta a incidentes.
+ Os clientes Enterprise Support podem solicitar o [Workshop de gerenciamento de incidentes](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) de seu gerente de conta técnico. Esse workshop guiado testa seu plano de resposta a incidentes e ajuda você a identificar áreas para melhoria.
1. Problemas
+ Os problemas devem ser identificados e monitorados em seu sistema de ITSM.
+ Identifique todos os problemas conhecidos e priorize-os em termos de esforço para corrigir e impacto na workload.
![\[Matriz de prioridade de ação para priorizar os problemas.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2023-10-03/framework/images/impact-effort-chart.png)
+ Resolva problemas de alto impacto e pouco esforço primeiro. Com esses resolvidos, passe para os problemas do quadrante de baixo impacto e pouco esforço.
+ Você pode usar o [OpsCenter do Systems Manager](systems-manager/latest/userguide/OpsCenter.html) para identificar esses problemas, anexar runbooks a eles e monitorá-los.
**Nível de esforço do plano de implementação:** médio. Você precisa de um processo e ferramentas para implementar essa prática recomendada. Documente seus processos e disponibilize-os para todos que estão associados à workload. Atualize-os com frequência. Você tem um processo para gerenciar problemas e mitigá-los ou corrigi-los.
## Recursos
**Práticas recomendadas relacionadas:**
+ [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md): problemas conhecidos precisam de um runbook associado para que os esforços de mitigação sejam consistentes.
+ [OPS07-BP04 Usar manuais para investigar problemas](ops_ready_to_support_use_playbooks.md): os incidentes precisam ser investigados usando playbooks.
+ [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md): sempre conduza uma autópsia depois de se recuperar de um incidente.
**Documentos relacionados:**
+ [Atlassian: gerenciamento de incidentes na era de DevOps](https://www.atlassian.com/incident-management/devops)
+ [Guia de resposta a incidentes de segurança da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [Gerenciamento de incidentes na era de DevOps e SRE](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty: o que é gerenciamento de incidentes?](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**Vídeos relacionados:**
+ [AWS re:Invent 2020: Incident management in a distributed organization (AWS re:Invent 2020: gerenciamento de incidentes em uma organização distribuída)](https://www.youtube.com/watch?v=tyS1YDhMVos)
+ [AWS re:Invent 2021 - Building next-gen applications with event-driven architectures (AWS re:Invent 2021 - criando aplicações de última geração com arquiteturas orientadas por eventos)](https://www.youtube.com/watch?v=U5GZNt0iMZY)
+ [AWS Supports You \$1 Exploring the Incident Management Tabletop Exercise (AWS apoia você \$1 Conhecendo a simulação teórica de gerenciamento de incidentes](https://www.youtube.com/watch?v=0m8sGDx-pRM)
+ [AWS Systems Manager Incident Manager - AWS Virtual Workshops (AWS Systems Manager Incident Manager - workshops virtuais da AWS)](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [AWS What's Next ft. Incident Manager \$1 AWS Events (Próximos passos na AWS com Incident Manager \$1 Eventos da AWS)](https://www.youtube.com/watch?v=uZL-z7cII3k)
**Exemplos relacionados:**
+ [workshop de ferramentas de gerenciamento e governança da AWS - OpsCenter](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html)
+ [Serviços proativos da AWS: workshop de gerenciamento de incidentes](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [Como desenvolver uma aplicação orientada por eventos com o Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [Como desenvolver arquiteturas orientadas por eventos na AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/)
**Serviços relacionados:**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [OpsCenter do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS10-BP02 Ter um processo por alerta
Tenha uma resposta bem-definida (runbook ou playbook), com um proprietário especificamente identificado, para qualquer evento para o qual você acione um alerta. Isso garante respostas eficazes e rápidas aos eventos de operações e evita que eventos acionáveis sejam ocultados por notificações menos valiosas.
**Antipadrões comuns:**
+ Seu sistema de monitoramento apresenta um stream de conexões aprovadas junto com outras mensagens. O volume de mensagens é tão grande que você perde mensagens de erro periódicas que exigem sua intervenção.
+ Você recebe um alerta de que o site está inoperante. Não há um processo definido para quando isso acontece. Você é forçado a adotar uma abordagem ad hoc para diagnosticar e resolver o problema. Desenvolver esse processo conforme o uso estende o tempo para recuperação.
**Benefícios do estabelecimento desta prática recomendada:** Ao alertar somente quando uma ação é necessária, você impede que alertas de valor baixo ocultem alertas de valor alto. Ao ter um processo para alertas sempre acionáveis, você permite uma resposta consistente e imediata a eventos em seu ambiente.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Alto
## Orientações para a implementação
+ Processo por alerta: qualquer evento para o qual você dispara um alerta deve ter uma resposta bem-definida (runbook ou manual) com um proprietário identificado especificamente (por exemplo, indivíduo, equipe ou função) responsável pela execução bem-sucedida. O desempenho da resposta pode ser automatizado ou conduzido por outra equipe, mas o proprietário é responsável por garantir que o processo ofereça os resultados esperados. Ao ter esses processos, você garante respostas eficazes e rápidas aos eventos de operações e pode impedir que eventos acionáveis sejam ocultados por notificações menos valiosas. Por exemplo, o auto scaling pode ser aplicado para dimensionar um front-end da web, mas a equipe de operações pode ser responsável por garantir que as regras e os limites de auto scaling sejam adequados para as necessidades de carga de trabalho.
## Recursos
**Documentos relacionados:**
+ [Recursos do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/)
+ [O que é o Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**Vídeos relacionados:**
+ [Build a monitoring plan](https://www.youtube.com/watch?v=OMmiGETJpfU)
# OPS10-BP03 Priorizar eventos operacionais com base no impacto nos negócios
Quando vários eventos demandarem intervenção, aborde primeiro os mais significativos para os negócios. Os impactos podem incluir perda de vida ou ferimentos, perda financeira ou danos à reputação ou confiança.
**Antipadrões comuns:**
+ Você recebe uma solicitação de suporte para adicionar uma configuração de impressora para um usuário. Ao trabalhar no problema, você recebe uma solicitação de suporte informando que o site de varejo está inoperante. Depois de concluir a configuração da impressora para o usuário, você começa a trabalhar no problema do site.
+ Você é notificado de que o site de varejo e o sistema de folha de pagamento estão inoperantes. Você não sabe para qual deve ter prioridade.
**Benefícios do estabelecimento desta prática recomendada:** A priorização de respostas aos incidentes com o maior impacto na empresa permite que você gerencie esse impacto.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Priorizar eventos operacionais com base no impacto empresarial: garanta que, quando vários eventos exigirem intervenção, aqueles que forem mais significativos para a empresa sejam abordados primeiro. Os impactos podem incluir perda de vida ou ferimentos, perda financeira, violações regulatórias ou danos à reputação ou à confiança.
# OPS10-BP04 Definir caminhos para escaladas
Defina caminhos de escalação em seus runbooks e playbooks, incluindo o que aciona a escalação e os procedimentos para escalação. Identifique especificamente os proprietários de cada ação para garantir respostas eficazes e rápidas aos eventos de operações.
Saiba quando é necessária uma decisão humana antes que medidas sejam tomadas. Trabalhe com os tomadores de decisão para que essa decisão seja tomada antecipadamente e a ação seja pré-aprovada, para que a MTTR não seja estendida aguardando uma resposta.
**Antipadrões comuns:**
+ Seu site de varejo está inoperante. Você não compreende o runbook para recuperar o site. Você começa a chamar colegas na expectativa de que alguém possa ajudá-lo.
+ Você recebe um caso de suporte para um aplicativo inacessível. Você não tem permissões para administrar o sistema. Você não sabe quem tem. Você tenta entrar em contato com o proprietário do sistema que abriu o caso e não há resposta. Você não tem contatos do sistema e seus colegas não estão familiarizados com ele.
**Benefícios do estabelecimento desta prática recomendada:** Ao definir escalações, gatilhos para escalação e procedimentos para escalação, você permite a adição sistemática de recursos a um incidente a uma taxa apropriada para o impacto.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Médio
## Orientações para a implementação
+ Definir caminhos para as escaladas: defina caminhos para as escaladas em seus runbooks e manuais, incluindo que é acionado pela escalada e os respectivos procedimentos. Por exemplo, escalação de um problema de engenheiros de suporte para engenheiros de suporte seniores quando a resolução do problema não estiver nos runbooks ou quando um período de tempo predefinido tiver decorrido. Outro exemplo de um caminho de escalação apropriado é dos engenheiros de suporte sênior à equipe de desenvolvimento para uma carga de trabalho quando os playbooks não conseguem identificar um caminho para a correção ou quando um período de tempo predefinido decorre. Identifique especificamente os proprietários de cada ação para garantir respostas eficazes e rápidas aos eventos de operações. Os escalonamentos podem incluir terceiros. Por exemplo, um provedor de conectividade de rede ou um fornecedor de software. Os escalonamentos podem incluir tomadores de decisão autorizados identificados para sistemas impactados.
# OPS10-BP05 Definir um plano de comunicação com o cliente para interrupções
Defina e teste um plano de comunicação para interrupções do sistema que seja confiável para manter os clientes e as partes interessadas informados durante interrupções. Comunique-se diretamente com os usuários tanto quando os serviços que eles usam forem afetados como quando os serviços voltarem ao normal.
**Resultado desejado:**
+ Você tem um plano de comunicação para situações que vão desde manutenção agendada até grandes falhas inesperadas, incluindo invocação de planos de recuperação de desastres.
+ Nas comunicações, você fornece informações claras e transparentes sobre problemas do sistema para ajudar os clientes a evitar dúvidas sobre o desempenho dos sistemas.
+ Você usa mensagens de erro personalizadas e páginas de status para reduzir o pico nas solicitações de suporte técnico e mantém os usuários informados.
+ O plano de comunicação é testado regularmente para verificar se ele ocorrerá como planejado no caso de uma interrupção real.
**Antipadrões comuns:**
+ Ocorre uma interrupção da workload, mas você não tem um plano de comunicação. Os usuários sobrecarregam o sistema de tíquetes com solicitações, pois não têm informações sobre a interrupção.
+ Você envia uma notificação por e-mail aos usuários durante uma interrupção. Ela não contém um prazo para a restauração do serviço, então os usuários não conseguem se planejar em torno da interrupção.
+ Há um plano de comunicação para interrupções, mas ele nunca foi testado. Ocorre uma interrupção e o plano de comunicação falha, pois faltou uma etapa fundamental que poderia ter sido identificada no teste.
+ Durante uma interrupção, você envia uma notificação aos usuários com muitas informações e detalhes técnicos sob o NDA da AWS.
**Benefícios do estabelecimento desta prática recomendada:**
+ Manter a comunicação durante as interrupções garante que os clientes possam ver o andamento da resolução dos problemas e o tempo previsto para que ela ocorra.
+ Desenvolver um plano de comunicação bem-definido garante que os clientes e usuários finais estejam bem-informados para que possam tomar medidas adicionais visando a mitigar o impacto das interrupções.
+ Com uma comunicação adequada e maior ciência acerca de interrupções planejadas e não planejadas, é possível melhorar a satisfação dos clientes, limitar reações não pretendidas e gerar a retenção dos clientes.
+ Uma comunicação transparente e em tempo hábil acerca da interrupção do sistema gera credibilidade e estabelece a confiança necessária para manter seu relacionamento com os clientes.
+ Uma estratégia de comunicação comprovada durante uma interrupção ou crise reduz a especulação e os rumores que poderiam atrapalhar sua capacidade de recuperação.
**Nível de risco exposto se esta prática recomendada não é estabelecida:** médio
## Orientações para a implementação
Os planos de comunicação que mantêm os clientes informados durante interrupções são holísticos e abrangem várias interfaces, incluindo páginas de erro voltadas para o cliente, mensagens de erro de API personalizadas, banners sobre o status do sistema e páginas de status de integridade. Se o sistema incluir usuários registrados, é possível comunicar-se por canais de mensagens, como e-mail, SMS ou notificações por push, para enviar conteúdo com mensagens personalizadas aos clientes.
**Ferramentas de comunicação com o cliente**
Como uma primeira linha de defesa, as aplicações web e móveis devem fornecer mensagens de erro amistosas e informativas durante uma interrupção e devem poder redirecionar o tráfego para uma página de status. O [Amazon CloudFront](https://aws.amazon.com/cloudfront/) é uma rede de entrega de conteúdo (CDN) que inclui recursos para definir e entregar conteúdo de erro personalizado. As páginas de erro personalizadas no CloudFront são uma ótima camada inicial de mensagens para os clientes para interrupções no nível de componentes. O CloudFront também pode simplificar o gerenciamento e a ativação da página de status para interceptar todas as solicitações durante interrupções planejadas e não planejadas.
As mensagens de erro de API personalizadas podem ajudar a detectar e reduzir o impacto quando as interrupções são isoladas a serviços discretos. O [Amazon API Gateway](https://aws.amazon.com/api-gateway/) permite configurar respostas personalizadas para as APIs REST. Isso permite fornecer mensagens claras e significativas para os consumidores da API quando o API Gateway não puder acessar os serviços de back-end. As mensagens personalizadas também podem ser usadas para dar suporte a notificações e conteúdos de banner sobre a interrupção quando um recurso específico do sistema é danificado devido a interrupções no nível do serviço.
As mensagens diretas são o tipo mais personalizado de mensagens para o cliente. O [Amazon Pinpoint](https://aws.amazon.com/pinpoint/) é um serviço gerenciado para comunicações escaláveis de vários canais. O Amazon Pinpoint permite criar campanhas que possam transmitir mensagens amplamente pela base de clientes afetados por SMS, e-mail, mensagem de voz, notificações por push ou canais personalizados definidos por você. Ao gerenciar as mensagens com o Amazon Pinpoint, as campanhas de mensagem são bem-definidas, testáveis e podem ser aplicadas de forma inteligente a segmentos de clientes-alvo. Depois de serem estabelecidas, as campanhas podem ser agendadas ou acionadas por eventos e podem ser facilmente testadas.
**Exemplo de clientes**
Quando a workload é prejudicada, a Loja UmaEmpresa envia uma notificação por e-mail aos usuários. O e-mail descreve qual funcionalidade da empresa foi prejudicada e fornece uma estimativa realista de quando o serviço será restaurado. Além disso, há uma página de status que mostra informações em tempo real sobre a integridade da workload. O plano de comunicação é testado em um ambiente de desenvolvimento duas vezes ao ano para validar sua eficácia.
**Etapas da implementação**
1. Determine os canais de comunicação para sua estratégia de mensagens. Considere os aspectos da arquitetura da aplicação e determine a melhor estratégia para fornecer feedback aos clientes. Isso pode incluir uma ou mais das estratégias de orientação descritas, incluindo páginas de erro e de status, respostas de erro de API personalizadas ou mensagens diretas.
1. Elabore páginas de status para a aplicação. Se você determinou que as páginas de status ou de erro personalizadas são adequadas para os clientes, é necessário elaborar o conteúdo e as mensagens para essas páginas. As páginas de erro explicam aos usuários por que uma aplicação não está disponível, quando ela pode ficar disponível novamente e o que pode ser feito enquanto isso. Se a aplicação usar o Amazon CloudFront, é possível fornecer [respostas de erro personalizadas](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html) ou usar o Lambda no Edge para [traduzir erros](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-update-error-status-examples) e reescrever o conteúdo da página. O CloudFront também permite mudar os destinos do conteúdo da aplicação para uma origem de conteúdo estático do [Amazon S3](https://aws.amazon.com/s3/) que contém sua página de status da interrupção ou de manutenção.
1. Elabore o conjunto de status de erro de API correto para seu serviço. As mensagens de erro produzidas pelo API Gateway quando ele não consegue acessar os serviços de back-end, além das exceções no nível do serviço, podem não conter mensagens amistosas adequadas para exibição aos usuários finais. Sem precisar fazer alterações no código dos serviços de back-end, é possível configurar as [respostas de erro personalizadas](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) do API Gateway para mapear os códigos de resposta HTTP para mensagens de erro de API selecionadas.
1. Elabore mensagens de uma perspectiva empresarial para que elas sejam relevantes aos usuários finais do sistema e não contenham detalhes técnicos. Considere seu público e alinhe suas mensagens. Por exemplo, você pode conduzir os usuários internos para uma solução alternativa ou um processo manual que utiliza sistemas alternativos. Os usuários externos podem ser solicitados a aguardar até que o sistema seja restaurado ou assinar as atualizações para receber uma notificação quando o sistema for restaurado. Defina mensagens aprovadas para vários cenários, incluindo interrupções não planejadas, manutenção planejada e falhas parciais do sistema quando um recurso específico pode estar danificado ou indisponível.
1. Modele e automatize as mensagens para os clientes. Depois de estabelecer o conteúdo das mensagens, é possível usar o [Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html) ou outras ferramentas para automatizar sua campanha de mensagens. Com o Amazon Pinpoint, é possível criar segmentos de destino de clientes para usuários afetados específicos e transformar as mensagens em modelos. Consulte o [Tutorial do Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/tutorials.html) para entender como configurar uma campanha de mensagens.
1. Evite o acoplamento forte de recursos de mensagens ao sistema voltado para o cliente. Sua estratégia de mensagens não deve depender fortemente de serviços ou armazenamentos de dados do sistema para verificar se é possível enviar mensagens quando ocorrerem interrupções. Considere desenvolver a capacidade de enviar mensagens a mais de [uma região ou zona de disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html) para disponibilidade de mensagens. Se você estiver usando os serviços da AWS para enviar mensagens, utilize as operações do plano de dados sobre as [operações do ambiente de gerenciamento](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) para invocar suas mensagens.
**Nível de esforço do plano de implementação:** alto. Desenvolver um plano de comunicação e os mecanismos para enviá-lo pode exigir um esforço significativo.
## Recursos
**Práticas recomendadas relacionadas:**
+ [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md) – Seu plano de comunicação deve ter um runbook associado a ele para que seus funcionários saibam como responder.
+ [OPS11-BP02 Executar análise pós-incidente](ops_evolve_ops_perform_rca_process.md) – Depois de uma interrupção, realize uma análise pós-incidente para identificar mecanismos, a fim de evitar outra interrupção.
**Documentos relacionados:**
+ [ Error Handling Patterns in Amazon API Gateway and AWS Lambda](https://aws.amazon.com/blogs/compute/error-handling-patterns-in-amazon-api-gateway-and-aws-lambda/)(Padrões de tratamento de erros no Amazon API Gateway e no AWS Lambda)
+ [ Amazon API Gateway responses ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#supported-gateway-response-types)(Respostas do Amazon API Gateway)
**Exemplos relacionados:**
+ [AWS Health Dashboard ](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)(Painel do AWS Health)
+ [ Summary of the AWS Service Event in the Northern Virginia (US-EAST-1) Region ](https://aws.amazon.com/message/12721/) (Resumo do evento de serviço da AWS na região Virgínia do Norte (US-EAST-1)
**Serviços relacionados:**
+ [AWS Support](https://aws.amazon.com/premiumsupport/)
+ [ Contrato de Cliente da AWS](https://aws.amazon.com/agreement/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [ Amazon Pinpoint ](https://aws.amazon.com/pinpoint/)
+ [ Amazon S3 ](https://aws.amazon.com/s3/)
# OPS10-BP06 Comunicar o status por meio de painéis
Forneça painéis personalizados para seus públicos-alvo (por exemplo, equipes técnicas internas, liderança e clientes) para comunicar o status operacional atual dos negócios e fornecer métricas de interesse.
Você pode criar painéis usando o [Painéis do Amazon CloudWatch](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) em páginas de início personalizáveis no console do CloudWatch. Ao usar serviços de inteligência de negócios, como o [Quick](https://aws.amazon.com/quicksight/) , você pode criar e publicar painéis interativos da carga de trabalho e da integridade operacional (por exemplo, taxas de pedidos, usuários conectados e tempos de transação). Crie painéis contendo visualizações em nível de sistema e de negócios de suas métricas.
**Antipadrões comuns:**
+ Mediante solicitação, você executa um relatório sobre a utilização atual da aplicação para a gerência.
+ Durante um incidente, você é contatado a cada vinte minutos por um proprietário do sistema preocupado, que deseja saber se ele já foi corrigido.
**Benefícios do estabelecimento desta prática recomendada:** Ao criar painéis, você permite o acesso por autoatendimento às informações, permitindo que os clientes se informem e determinem se precisam executar ações.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Comunicar o status por meio de painéis: forneça painéis personalizados para seus públicos-alvo (por exemplo, equipes técnicas internas, liderança e clientes) para comunicar o status operacional atual dos negócios e fornecer métricas de interesse. Fornecer uma opção de autoatendimento para informações de status reduz a interrupção das solicitações de status de campo pela equipe de operações. Os exemplos incluem os painéis do Amazon CloudWatch e o AWS Health Dashboard.
+ [CloudWatch dashboards create and use customized metrics views (Os painéis do CloudWatch criam e usam visualizações de métricas personalizadas)](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
## Recursos
**Documentos relacionados:**
+ [Quick](https://aws.amazon.com/quicksight/)
+ [CloudWatch dashboards create and use customized metrics views (Os painéis do CloudWatch criam e usam visualizações de métricas personalizadas)](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
# OPS10-BP07 Automatizar respostas a eventos
Automatize as respostas aos eventos para reduzir erros causados por processos manuais e garantir respostas rápidas e consistentes.
Existem várias maneiras de automatizar a execução de ações de runbook e manual na AWS. Para responder a um evento de alteração de estado nos seus recursos da AWS, ou de seus próprios eventos personalizados, você deve criar [regras do CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) para acionar respostas por meio de alvos do CloudWatch (por exemplo, funções do Lambda, tópicos do Amazon Simple Notification Service (Amazon SNS), tarefas do Amazon ECS e automação do AWS Systems Manager).
Para responder a uma métrica que ultrapassa um limite para um recurso (por exemplo, tempo de espera), você deve criar [alarmes do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para executar uma ou mais ações usando as ações do Amazon EC2, as ações do Auto Scaling ou enviar uma notificação para um tópico do Amazon SNS. Se for necessário executar ações personalizadas em resposta a um alarme, chame o Lambda por meio de uma notificação do Amazon SNS. Use o Amazon SNS para publicar notificações de eventos e mensagens de escalação para manter as pessoas informadas.
A AWS também é compatível com sistemas de terceiros por meio das APIs e SDKs de serviço da AWS. Existem várias ferramentas de monitoramento fornecidas por parceiros da AWS e por terceiros que permitem monitoramento, notificações e respostas. Algumas dessas ferramentas são New Relic, Splunk, Loggly, SumoLogic e Datadog.
Mantenha procedimentos manuais críticos disponíveis para uso quando houver falha em procedimentos automatizados.
**Antipadrões comuns:**
+ Um desenvolvedor verifica seu código. Esse evento poderia ter sido usado para iniciar uma compilação e, em seguida, executar testes, mas, em vez disso, nada acontece.
+ Sua aplicação registra um erro específico em log antes de parar de funcionar. O procedimento para reiniciar o aplicativo é bem compreendido e pode ter um script. Você pode usar o evento de log para invocar um script e reiniciar o aplicativo. Em vez disso, quando o erro acontece às 3 da manhã de domingo, você é despertado como o recurso de plantão responsável pela correção do sistema.
**Benefícios do estabelecimento desta prática recomendada:** Ao usar respostas automatizadas a eventos, você reduz o tempo de resposta e limita a introdução de erros oriundos de atividades manuais.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** Baixo
## Orientações para a implementação
+ Automatizar respostas a eventos: automatize respostas a eventos para reduzir erros causados por processos manuais e garantir respostas rápidas e consistentes.
+ [O que é o Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Criação de uma regra do CloudWatch Events que aciona um evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [Criação de uma regra do CloudWatch Events que aciona uma chamada de API da AWS usando o AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [Exemplos de eventos do CloudWatch Events de serviços compatíveis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
## Recursos
**Documentos relacionados:**
+ [Recursos do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/)
+ [Exemplos de eventos do CloudWatch Events de serviços compatíveis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
+ [Criação de uma regra do CloudWatch Events que aciona uma chamada de API da AWS usando o AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [Criação de uma regra do CloudWatch Events que aciona um evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [O que é o Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**Vídeos relacionados:**
+ [Build a monitoring plan](https://www.youtube.com/watch?v=OMmiGETJpfU)
**Exemplos relacionados:**