

# OPS 7  Como você sabe que está pronto para oferecer suporte a uma carga de trabalho?
<a name="w2aac19b5b7c11"></a>

 Avalie a prontidão operacional de sua carga de trabalho, processos/procedimentos e pessoal para entender os riscos operacionais relacionados. 

**Topics**
+ [OPS07-BP01 Garantir a capacidade da equipe](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 Garantir uma análise consistente da prontidão operacional](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 Usar manuais para investigar problemas](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 Tomar decisões embasadas para implantar sistemas e alterações](ops_ready_to_support_informed_deploy_decisions.md)

# OPS07-BP01 Garantir a capacidade da equipe
<a name="ops_ready_to_support_personnel_capability"></a>

 Tenha um mecanismo para validar que você tem o número adequado de pessoal treinado para fornecer suporte às necessidades operacionais. Treine e ajuste a capacidade de pessoal conforme necessário para manter o suporte eficiente. 

 Você precisará ter membros da equipe suficientes para cobrir todas as atividades (inclusive em plantão). Garanta que suas equipes tenham as habilidades necessárias para terem êxito no treinamento sobre as workload, as ferramentas das operações e a AWS. 

 A AWS fornece recursos, incluindo o [Centro de recursos de conceitos básicos da AWS](https://aws.amazon.com/getting-started/), [Blogs da AWS](https://aws.amazon.com/blogs/), [AWS Online Tech Talks](https://aws.amazon.com/getting-started/), [Eventos e webinars da AWS](https://aws.amazon.com/events/)e os [Laboratórios do AWS Well-Architected](https://wellarchitectedlabs.com/), que fornecem orientações, exemplos e demonstrações detalhadas para educar suas equipes. Além disso, o [Treinamento da AWS and Certification](https://aws.amazon.com/training/) fornece algum treinamento gratuito por meio de cursos digitais autoguiados sobre os conceitos básicos da AWS. Também é possível inscrever-se em treinamento administrado por instrutor para oferecer suporte adicional ao desenvolvimento das habilidades em AWS de suas equipes. 

 **Antipadrões comuns:** 
+  Implantar uma carga de trabalho sem membros qualificados na equipe para oferecer suporte à plataforma e aos serviços em uso. 
+  Implantar uma carga de trabalho sem membros da equipe disponíveis durante as horas pretendidas de suporte. 
+  Implantar uma carga de trabalho sem membros suficientes da equipe para oferecer suporte se houver membros da equipe em licença ou afastados por doença. 
+  Implantar cargas de trabalho adicionais sem analisar o impacto adicional sobre os membros da equipe que oferecem suporte e outras cargas de trabalho. 

 **Benefícios do estabelecimento desta prática recomendada:** Ter membros da equipe qualificados possibilita o suporte eficaz da sua carga de trabalho. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Capacidade da equipe: valide se a equipe com treinamento é grande o suficiente para oferecer suporte de forma eficaz à workload. 
  +  Tamanho da equipe: verifique se você tem membros da equipe suficientes para cobrir as atividades operacionais, como tarefas de plantão. 
  +  Habilidades da equipe: verifique se os membros da equipe têm treinamento suficiente da AWS, de workload e de ferramentas operacionais para realizarem suas tarefas. 
    +  [Eventos e webinars da AWS](https://aws.amazon.com/about-aws/events/) 
    +  [Nossas boas-vindas ao Treinamento da AWS and Certification](https://aws.amazon.com/training/) 
  +  Analisar os recursos: analise o tamanho e as habilidades da equipe conforme as condições operacionais e as workloads mudam, para garantir que haja capacidade suficiente para manter a excelência operacional. Faça ajustes para garantir que o tamanho e a habilidade da equipe correspondam aos requisitos operacionais para as cargas de trabalho para as quais a equipe fornece suporte. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Blogs da AWS](https://aws.amazon.com/blogs/) 
+  [Eventos e webinars da AWS](https://aws.amazon.com/about-aws/events/) 
+  [Centro de recursos de conceitos básicos da AWS](https://aws.amazon.com/getting-started/) 
+  [AWS Online Tech Talks](https://aws.amazon.com/getting-started/) 
+  [Nossas boas-vindas ao Treinamento da AWS and Certification](https://aws.amazon.com/training/) 

 **Exemplos relacionados:** 
+  [Laboratórios do Well-Architected](https://wellarchitectedlabs.com/) 

# OPS07-BP02 Garantir uma análise consistente da prontidão operacional
<a name="ops_ready_to_support_const_orr"></a>

Use Análises de prontidão operacional (ORRs) para validar que você pode operar sua workload. A ORR é um mecanismo desenvolvido na Amazon para validar que as equipes podem operar as workloads com segurança. Uma ORR é um processo de análise e inspeção que usa uma lista de verificação de requisitos. Uma ORR é uma experiência de autoatendimento que as equipes usam para certificar suas workloads. As ORRs incluem práticas recomendadas de lições aprendidas de nossos anos de experiência na criação de software. 

 Uma lista de verificação de ORR é composta de recomendações de arquitetura, processo operacional, gerenciamento de evento e qualidade de lançamento. Nosso processo de Correção de erros (CoE) é um motivador principal desses itens. Sua própria análise pós-incidente deve impulsionar a evolução de sua própria ORR. Uma ORR não é apenas sobre seguir as práticas recomendadas, mas evitar a recorrência de eventos que você já viu. Por fim, os requisitos de segurança, governança e conformidade também podem ser incluídos em uma ORR. 

 Execute ORRs antes do lançamento de uma workload para disponibilidade geral e por todo o ciclo de vida de desenvolvimento do software. A execução da ORR antes do lançamento aumenta a capacidade de operar a workload com segurança. Execute a ORR periodicamente na workload para identificar qualquer desvio das práticas recomendadas. Você pode ter listas de verificação da ORR para o lançamento de outros serviços e ORRs para avaliações periódicas. Isso ajuda a manter você atualizado sobre as novas práticas recomendadas que surgem e incorporar as lições aprendidas da análise pós-incidente. À medida que seu uso da nuvem amadurece, é possível criar requisitos de ORR em sua arquitetura como padrões. 

 **Resultado desejado:**  você tem uma lista de verificação da ORR com as práticas recomendadas para sua organização. As ORRs são realizadas antes do lançamento das workloads. As ORRs são executadas periodicamente ao longo do ciclo de vida da workload. 

 **Antipadrões comuns:** 
+ Você lança uma workload sem saber se pode operá-la. 
+ Os requisitos de governança e segurança não estão incluídos na certificação de uma workload para o lançamento. 
+ As workloads não são reavaliadas periodicamente. 
+ As workloads são lançadas sem a aplicação dos procedimentos exigidos. 
+ Você vê a repetição das mesmas falhas da causa raiz em várias workloads. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  suas workloads incluem práticas recomendadas de arquitetura, processo e gerenciamento. 
+  As lições aprendidas são incorporadas em seu processo de ORR. 
+  Os procedimentos exigidos estão em vigor no lançamento das workloads. 
+  As ORRs são executadas durante todo o ciclo de vida do software das workloads. 

 **Nível de risco caso essa prática recomendada não seja estabelecida:** alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Uma ORR é composta por dois elementos: um processo e uma lista de verificação. O processo da ORR deve ser adotado pela organização e ter o apoio de um patrocinador executivo. No mínimo, as ORRs devem ser realizadas antes do lançamento da workload para disponibilidade geral. Execute a ORR ao longo de todo o ciclo de vida de desenvolvimento do software para mantê-la atualizada com as práticas recomendadas ou os novos requisitos. A lista de verificação da ORR deve incluir itens de configuração, requisitos de segurança e governança e práticas recomendadas de sua organização. Ao longo do tempo, você pode usar serviços como o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), o [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)e o [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html), para criar práticas recomendadas com base na ORR visando as barreiras de proteção para detecção automáticas das práticas recomendadas. 

 **Exemplo de cliente** 

 Depois de vários incidentes na produção, a Loja UmaEmpresa decidiu implementar um processo de ORR. Ela criou uma lista de verificação composta de práticas recomendadas, requisitos de governança e conformidade e lições aprendidas de interrupções. Novas workloads passam pelo processo de ORR antes do lançamento. É realizada uma ORR anualmente para cada workload com um subconjunto de práticas recomendadas a incorporar novas práticas recomendadas e requisitos que são adicionados à lista de verificação da ORR. Ao longo do tempo, a Loja UmaEmpresa usou o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) para detectar algumas práticas recomendadas, acelerando o processo de ORR. 

 **Etapas da implementação** 

 Para saber mais sobre as ORRs, leia o [whitepaper de Análises de prontidão operacional (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Ele fornece informações detalhadas sobre o histórico do processo de ORR, como criar sua própria prática de ORR e como desenvolver sua lista de verificação da ORR. As etapas a seguir são uma versão resumida desse documento. Para uma compreensão aprofundada do que são as ORRs e de como criar sua própria, recomendamos a leitura desse whitepaper. 

1. Reúna as principais partes interessadas, incluindo os representantes de segurança, operações e desenvolvimento. 

1. Peça para cada parte interessada fornecer pelo menos um requisito. Para a primeira iteração, tente limitar o número de itens para trinta ou menos. 
   +  [Apêndice B: os exemplos de perguntas da ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) do whitepaper de Análises de prontidão operacional (ORR) contém exemplos de perguntas que você pode usar para começar. 

1. Reúna seus requisitos em uma planilha. 
   + Você pode usar o [Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) no [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) para desenvolver sua ORR e compartilhá-la em suas contas e no AWS Organization. 

1. Identifique uma workload na qual realizar a ORR. O ideal seria em uma workload em pré-lançamento ou uma workload interna. 

1. Execute a lista de verificação completa da ORR e anote as descobertas feitas. As descobertas podem não ser corretas caso esteja ocorrendo uma mitigação. Para descobertas que não tenham uma mitigação, acrescente-as à sua lista de pendências e implemente-as antes do lançamento. 

1. Continue a adicionar práticas recomendadas e requisitos à sua lista de verificação de ORR ao longo do tempo. 

 Os clientes do Suporte com Enterprise Support podem solicitar o [workshop de Análises de prontidão operacional](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) com seu gerente de conta técnico. O workshop é uma sessão interativa de *trabalho em retrospecto* para que você consiga desenvolver sua própria lista de verificação de ORR. 

 **Nível de esforço do plano de implementação:** alto. Adotar uma prática de ORR em sua organização exige a adesão de um patrocinador executivo e das partes interessadas. Crie e atualize a lista de verificação com as opiniões de toda a sua organização. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+ [OPS01-BP03 Avaliar os requisitos de governança](ops_priorities_governance_reqs.md) – Os requisitos de governança são uma opção natural para uma lista de verificação da ORR. 
+ [OPS01-BP04 Avaliar os requisitos de conformidade](ops_priorities_compliance_reqs.md) – Os requisitos de conformidade, às vezes são incluídos em uma lista de verificação de ORR. Outras vezes, eles constituem um processo separado. 
+ [OPS03-BP07 Fornecer recursos adequados às equipes](ops_org_culture_team_res_appro.md) – A capacidade da equipe é uma boa candidata para um requisito de ORR. 
+ [OPS06-BP01 Planejar para alterações malsucedidas](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Um plano de reversão ou avanço deve ser estabelecido antes do lançamento da workload. 
+ [OPS07-BP01 Garantir a capacidade da equipe](ops_ready_to_support_personnel_capability.md) – Para comportar uma workload, você deve ter o pessoal necessário. 
+ [SEC01-BP03 Identificar e validar objetivos de controle](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – Os objetivos de controle de segurança compõem excelentes requisitos de ORR. 
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – Os planos de recuperação de desastres são um ótimo requisito de ORR. 
+ [COST02-BP01 Desenvolver políticas com base nos requisitos da sua organização](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – As políticas de gerenciamento de custos são ótimas para incluir em sua lista de verificação de ORR. 

 **Documentos relacionados:** 
+  [AWS Control Tower - Guardrails in AWS Control Tower (AWS Control Tower: barreiras de proteção no AWS Control Tower)](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [AWS Well-Architected Tool - Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) 
+  [Operational Readiness Review Template by Adrian Hornsby (Modelo de Análise de prontidão operacional, por Adrian Hornsby)](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79) 
+  [Whitepaper de Análises de prontidão operacional (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 

 **Vídeos relacionados:** 
+  [AWS Supports You \$1 Building an Effective Operational Readiness Review (ORR) (Apoio do AWS Support: criação de uma Análise de prontidão operacional (ORR) eficaz)](https://www.youtube.com/watch?v=Keo6zWMQqS8) 

 **Exemplos relacionados:** 
+  [Sample Operational Readiness Review (ORR) Lens (Exemplo da perspectiva da Análise de prontidão operacional (ORR))](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens) 

 **Serviços relacionados:** 
+  [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+  [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html) 

# OPS07-BP03 Usar runbooks para realizar procedimentos
<a name="ops_ready_to_support_use_runbooks"></a>

 A *runbook* é um processo documentado para alcançar um resultado específico. Runbooks consistem em uma série de etapas que alguém segue para realizar alguma coisa. Runbooks são usados em operações desde os primórdios da aviação. Nas operações na nuvem, usamos runbooks para reduzir o risco e alcançar os resultados desejados. Em essência, um runbook é uma lista de verificação para concluir uma tarefa. 

 Runbooks são fundamentais para a operação de uma workload. Da integração de um novo membro da equipe à implantação de um lançamento importante, os runbooks são os processos codificados que fornecem resultados consistentes independentemente de que os usa. Os runbooks devem estar publicados em um local central e devem ser atualizados à medida que o processo evolui, uma vez que a atualização dos runbooks é um aspecto fundamental de um processo de gerenciamento de mudanças. Também devem incluir orientação sobre tratamento de erros, ferramentas, permissões, exceções e encaminhamentos em caso de problema. 

 À medida que sua organização amadurece, comece a automatizar os runbooks. Comece com runbooks que sejam curtos e usados com frequência. Use linguagens de scripts para automatizar as etapas ou facilitar a realização delas. À medida que você automatiza os primeiros runbooks, vai dedicar tempo à automação de runbooks mais complexos. Com o tempo, a maioria dos seus runbooks deverão ter algum nível de automação. 

 **Resultado desejado:** sua equipe tem um conjunto de guias detalhados para realizar tarefas de workload. Os runbooks contêm o resultado desejado, as ferramentas e permissões necessárias e as instruções para tratamento de erros. Eles estão armazenados em um local central e são atualizados frequentemente. 

 **Antipadrões comuns:** 
+  Depender da memória para concluir cada etapa de um processo. 
+  Implantar mudanças manualmente sem uma lista de verificação. 
+  Vários membros da equipe realizando o mesmo processo, mas com etapas ou resultados diferentes. 
+  Deixar que os runbooks fiquem desatualizados em relação às mudanças no sistema e à automação. 

 **Benefícios do estabelecimento desta prática recomendada:** 
+  Redução das taxas de erros em tarefas manuais. 
+  Operações realizadas de maneira consistente. 
+  Novos membros da equipe podem começar a realizar tarefas mais cedo. 
+  Os runbooks podem ser automatizados para reduzir o esforço. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação de implementação
<a name="implementation-guidance"></a>

 Os runbooks podem assumir diversos formatos dependendo do nível de maturidade da sua organização. No mínimo, devem consistir em um documento de texto detalhado. O resultado desejado deve estar claramente identificado. Documentar claramente as permissões ou ferramentas especiais necessárias. Fornecer orientação detalhada sobre tratamento de erros e encaminhamentos em caso de problema. Listar o proprietário do runbook e publicá-lo em um local central. Depois que o runbook estiver documentado, valide-o pedindo que outro membro da equipe o execute. À medida que os procedimentos evoluem, atualize os runbooks de acordo com seu processo de gerenciamento de mudanças. 

 Os runbooks em texto devem ser automatizados à medida que a organização amadurece. Usando serviços como as [automações do AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), você pode transformar texto plano em automações que podem ser executadas na workload. Essas automações podem ser executadas em resposta a eventos, reduzindo a sobrecarga operacional de manutenção da workload. 

 **Exemplo de cliente** 

 A AnyCompany Retail precisa realizar atualizações no esquema de banco de dados durante implantações de software. A equipe de operações na nuvem trabalhou com a equipe de administração do banco de dados para criar um runbook para implantação manual dessas mudanças. O runbook lista cada etapa do processo em um formato de lista de verificação. Ele inclui uma seção sobre tratamento de erros em caso de problema. Eles publicaram o runbook na wiki interna junto com outros runbooks. A equipe de operações na nuvem planeja automatizar o runbook em um sprint futuro. 

## Etapas da implementação
<a name="implementation-steps"></a>

 Se você não tem um repositório de documentos, um repositório de controle de versão é um ótimo lugar para começar a criar sua biblioteca de runbooks. Você pode criar runbooks usando Markdown. Disponibilizamos um modelo de runbook que você pode usar para começar a criar runbooks. 

```
# Título do runbook ## Informações do runbook | ID do runbook | Descrição | Ferramentas usadas | Permissões especiais | Criador do runbook | Última atualização | Contato para encaminhamento | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | Para que serve este runbook? Qual é o resultado desejado? | Ferramentas | Permissões | Seu nome | 21-09-2022 | Nome para encaminhamento | ## Etapas 1. Primeira etapa 2. Segunda etapa
```

1.  Se você não tiver um repositório de documentação ou uma wiki, crie um repositório de controle de versão em seu sistema de controle de versão. 

1.  Identifique um processo que não tenha um runbook. Um processo ideal é um que seja realizado quase regularmente, que tenha poucas etapas e que tenha falhas de baixo impacto. 

1.  No repositório de documentos, crie um rascunho de documento em Markdown usando o modelo. Preencha `Título do runbook` e os campos necessários em `Informações do runbook`. 

1.  Começando pela primeira etapa, preencha a seção `Etapas` do runbook. 

1.  Dê o runbook a um membro da equipe. Peça que o use para validar as etapas. Se algo estiver faltando ou não estiver claro, atualize o runbook. 

1.  Disponibilize o runbook em seu armazenamento interno de documentos. Depois, informe a sua equipe e outras partes interessadas. 

1.  Com o passar do tempo, você terá uma biblioteca de runbooks. À medida que essa biblioteca cresce, comece a trabalhar na automatização dos runbooks. 

 **Nível de esforço do plano de implementação:** baixo. O padrão mínimo para um runbook é um guia de texto detalhado. A automatização dos runbooks pode aumentar o esforço de implementação. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md): os runbooks devem ter um proprietário responsável por mantê-los. 
+  [OPS07-BP04 Usar manuais para investigar problemas](ops_ready_to_support_use_playbooks.md): os runbooks e playbooks são semelhantes, com uma diferença importante: um runbook tem um resultado desejado. Em muitos casos, os runbooks são acionados depois que um playbook identifica uma causa raiz. 
+  [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](ops_event_response_event_incident_problem_process.md): os runbooks fazem parte de uma boa prática de gerenciamento de eventos, incidentes e problemas. 
+  [OPS10-BP02 Ter um processo por alerta](ops_event_response_process_per_alert.md): os runbooks e playbooks devem ser usados para responder a alertas. Com o tempo, essas reações devem ser automatizadas. 
+  [OPS11-BP04 Executar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md): a manutenção dos runbooks é essencial para o gerenciamento de conhecimento. 

 **Documentos relacionados:** 
+ [Como alcançar excelência operacional usando playbooks e runbooks automatizados](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/) 
+ [AWS Systems Manager: trabalhar com runbooks](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+ [Playbook para grandes migrações da AWS - Tarefa 4: Como melhorar runbooks de migração](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html) 
+ [Como usar runbooks do AWS Systems Manager Automation para resolver tarefas operacionais](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) 

 **Vídeos relacionados:** 
+  [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1) (Guia DIY para runbooks, relatórios de incidentes e resposta a incidentes)](https://www.youtube.com/watch?v=E1NaYN_fJUo) 
+  [How to automate IT Operations on AWS \$1 Amazon Web Services (Como automatizar operações de TI na AWS \$1 Amazon Web Services)](https://www.youtube.com/watch?v=GuWj_mlyTug) 
+  [Integrate Scripts into AWS Systems Manager (Integração de scripts no AWS Systems Manager)](https://www.youtube.com/watch?v=Seh1RbnF-uE) 

 **Exemplos relacionados:** 
+  [AWS Systems Manager: demonstrações de automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) 
+  [AWS Systems Manager: runbook para restaurar um volume raiz usando o snapshot mais recente](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+  [Criar um runbook de resposta a incidentes da AWS usando cadernos Jupyter e CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) 
+  [Gitlab: runbooks](https://gitlab.com/gitlab-com/runbooks) 
+  [Rubix: uma biblioteca de Python para criação de runbooks em cadernos Jupyter](https://github.com/Nurtch/rubix) 
+  [Como usar o gerador de documentos para criar um runbook personalizado](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) 
+  [Well-Architected Labs: automatização de operações com playbooks e runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

 **Serviços relacionados:** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 

# OPS07-BP04 Usar manuais para investigar problemas
<a name="ops_ready_to_support_use_playbooks"></a>

 Os manuais são guias detalhados usados para investigar incidentes. Quando incidentes ocorrem, os manuais são usados para investigar, definir o escopo do impacto e identificar a causa raiz. Os manuais são usados em diversos cenários, desde falhas em implantações até incidentes de segurança. Em muitos casos, os manuais identificam a causa raiz mitigada por um runbook. Os manuais são essenciais aos planos de resposta a incidentes de sua organização. 

 Um bom manual abrange vários aspectos principais. Ele guia o usuário, detalhadamente, ao longo do processo de descoberta. Considerando várias perspectivas, quais etapas devem ser seguidas para diagnosticar um incidente? Defina claramente no manual se são necessárias ferramentas especiais ou permissões elevadas. Ter um plano de comunicação para atualizar as partes interessadas sobre o status da investigação é essencial. Em situações em que a causa raiz ainda não foi identificada, o manual deve ter um plano de escalação. Se a causa raiz tiver sido identificada, o manual deverá indicar um runbook que descreva como resolvê-la. Os manuais devem ser armazenados em um local central e atualizados com frequência. Caso os manuais sejam usados para alertas específicos, forneça às equipes indicadores para o manual no alerta. 

 À medida que sua organização for amadurecendo, automatize seus manuais. Comece com manuais que abordem incidentes de baixo risco. Use scripts para automatizar as etapas de descoberta. Tenha runbooks complementares para mitigar as causas raízes comuns. 

 **Resultado desejado:** Sua organização tem manuais para incidentes comuns. Os manuais são armazenados em um local central e estão disponíveis para os membros da equipe. Os manuais são atualizados com frequência. São criados runbooks complementares para todas as causas raízes conhecidas. 

 **Antipadrões comuns:** 
+  Não há uma maneira padrão de investigar um incidente. 
+  Os membros da equipe precisam confiar na própria memória ou no conhecimento institucional para solucionar uma falha na implantação. 
+  Os novos membros da equipe aprendem a investigar os problemas por meio de tentativa e erro. 
+  As práticas recomendadas para a investigação dos problemas não são compartilhadas entre as equipes. 

 **Benefícios de estabelecer esta prática recomendada:** 
+  Os manuais impulsionam seus esforços para mitigar os incidentes. 
+  Diferentes membros da equipe podem usar o mesmo manual para identificar uma causa raiz de maneira consistente. 
+  As causas raízes conhecidas podem ter runbooks desenvolvidos para elas, o que acelera o tempo de recuperação. 
+  Os manuais permitem que os membros da equipe comecem a contribuir o quanto antes. 
+  As equipes podem escalar seus processos com manuais repetíveis. 

 **Nível de risco exposto se essa prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A maneira que você cria e usa os manuais depende da maturidade de sua organização. Se você é iniciante na nuvem, crie manuais no formato de texto em um repositório central de documentos. À medida que sua organização amadurecer, os manuais poderão passar a ser semiautomatizados com linguagens de script, como Python. Esses scripts podem ser executados em um caderno Jupyter para acelerar a descoberta. As organizações avançadas têm manuais totalmente automatizados para problemas comuns que são corrigidos automaticamente com runbooks. 

 Comece a criar seus manuais listando incidentes comuns que ocorrem com sua workload. Para começar, escolha manuais para incidentes com baixo risco e nos quais a causa raiz tenha sido restrita a poucos problemas. Quando você tiver manuais para os cenários mais simples, passe para cenários de alto risco ou cenários em que a causa raiz não seja bem conhecida. 

 Seus manuais em texto deverão ser automatizados à medida que sua organização amadurecer. Usando serviços, como o [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), um texto sem formatação pode ser transformado em automações. Essas automações podem ser executadas em sua workload para acelerar as investigações. Elas podem ser ativadas em resposta a eventos, o que reduz o tempo necessário para descobrir e resolver incidentes. 

 Os clientes podem usar o [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) para responder a incidentes. Esse serviço fornece uma interface única para fazer a triagem de incidentes, informar as partes interessas durante a descoberta e a mitigação e colaborar durante todo o incidente. Ele usa o AWS Systems Manager Automations para acelerar a detecção e a recuperação. 

 **Exemplo de cliente** 

 Um incidente na produção afetou a Loja UmaEmpresa. O engenheiro de plantão usou um manual para investigar o problema. À medida que foi avançando pelas etapas, ele manteve atualizadas as principais partes interessadas, identificadas no manual. O engenheiro identificou a causa raiz como uma condição de corrida em um serviço de back-end. Usando um runbook, o engenheiro reiniciou o serviço, colocando a Loja UmaEmpresa online novamente. 

## Etapas da implementação
<a name="implementation-steps"></a>

 Se você não tem um repositório de documentos, sugerimos criar um repositório de controle de versão para a biblioteca do manual. É possível criar os manuais usando o Markdown, que é compatível com a maioria dos sistemas de automação de manuais. Se você estiver iniciando do zero, use o modelo de exemplo de manual a seguir. 

```
# Título do manual ## Informações do manual | ID do manual | Descrição | Ferramentas usadas | Permissões especiais | Autor do manual | Última atualização | Ponto de contato de escalação | Partes interessadas | Plano de comunicação | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | Para que é este manual? Ele é usado para qual incidente? | Ferramentas | Permissões | Seu nome | 21/9/2022 | Nome para escalação | Nome da parte interessada | Como as atualizações serão comunicadas durante a investigação? | ## Etapas 1. Etapa um 2. Etapa dois
```

1.  Se você não tiver um repositório de documentos ou uma wiki, crie um repositório de controle de versão para seus manuais no sistema de controle de versão. 

1.  Identifique um problema comum que requer investigação. Ele deve ser um cenário em que a causa raiz esteja limitada a poucos problemas e a resolução seja de baixo risco. 

1.  Usando o modelo do Markdown, preencha a seção `Nome do manual` e os campos em `Informações do manual`. 

1.  Preencha as etapas de resolução de problemas. Seja o mais claro possível sobre quais ações devem ser executadas ou quais áreas devem ser investigadas. 

1.  Dê o manual a um membro da equipe e peça para essa pessoa analisá-lo a fim de validá-lo. Caso algo esteja faltando ou não esteja claro, atualize o manual. 

1.  Publique o manual no repositório de documentos e informe sua equipe e as partes interessadas. 

1.  Essa biblioteca de manuais crescerá à medida que você adicionar outros manuais. Quando você tiver vários manuais, comece a automatizá-los usando ferramentas como o AWS Systems Manager Automations a fim de manter a automação e os manuais sincronizados. 

 **Nível de esforço do plano de implementação:** Baixo. Os manuais devem ser documentos de texto armazenados em um local central. Organizações mais consolidadas passarão a automatizar os respectivos manuais. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md): os manuais devem ter um proprietário responsável por mantê-los. 
+  [OPS07-BP03 Usar runbooks para realizar procedimentos](ops_ready_to_support_use_runbooks.md): os runbooks e os manuais são semelhantes, com uma diferença importante: um runbook tem um resultado desejado. Em muitos casos, os runbooks são usados quando um manual identifica uma causa raiz. 
+  [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](ops_event_response_event_incident_problem_process.md): os manuais fazem parte de uma boa prática de gerenciamento de eventos, incidentes e problemas. 
+  [OPS10-BP02 Ter um processo por alerta](ops_event_response_process_per_alert.md): os runbooks e manuais devem ser usados para responder a alertas. Com o tempo, essas reações devem ser automatizadas. 
+  [OPS11-BP04 Executar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md): a manutenção dos manuais é essencial para o gerenciamento de conhecimento. 

 **Documentos relacionados:** 
+ [ Achieving Operational Excellence using automated playbook and runbook (Como alcançar excelência operacional usando manuais e runbooks automatizados) ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+  [AWS Systems Manager: Working with runbooks ( AWS Systems Manager: trabalho com runbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+ [ Use AWS Systems Manager Automation runbooks to resolve operational tasks (Usar runbooks do AWS Systems Manager Automation para resolver tarefas operacionais) ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)

 **Vídeos relacionados:** 
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1) (Guia DIY para runbooks, relatórios de incidentes e resposta a incidentes) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS Virtual Workshops (AWS Systems Manager Incident Manager - workshops virtuais da AWS) ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ Integrate Scripts into AWS Systems Manager (Integração de scripts no AWS Systems Manager) ](https://www.youtube.com/watch?v=Seh1RbnF-uE)

 **Exemplos relacionados:** 
+ [AWS Customer Playbook Framework (Framework do manual do cliente daAWS) ](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: Automation walkthroughs (AWS Systems Manager: demonstrações de automação) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake (Criar um runbook de resposta a incidentes da AWS usando cadernos Jupyter e o CloudTrail Lake) ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix – A Python library for building runbooks in Jupyter Notebooks (Rubix: uma biblioteca de Python para criação de runbooks em cadernos Jupyter) ](https://github.com/Nurtch/rubix)
+ [ Using Document Builder to create a custom runbook (Como usar o gerador de documentos para criar um runbook personalizado) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected Labs: Automating operations with Playbooks and Runbooks (Well-Architected Labs: automatização de operações com manuais e runbooks) ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected Labs: Incident response playbook with Jupyter (Well-Architected Labs: manual de resposta a incidentes com o Jupyter) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)

 **Serviços relacionados:** 
+ [AWS Systems Manager Automation ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)

# OPS07-BP05 Tomar decisões embasadas para implantar sistemas e alterações
<a name="ops_ready_to_support_informed_deploy_decisions"></a>

 Avalie os recursos da equipe para oferecer suporte à carga de trabalho e à conformidade da carga de trabalho com a governança. Avalie isso em relação aos benefícios da implantação ao determinar se deseja fazer a transição para um sistema ou mudar para produção. Compreenda os benefícios e riscos para tomar decisões informadas. 

 Uma estratégia pre-mortem é um exercício em que uma equipe simula uma falha para desenvolver estratégias de mitigação. Use estratégias pre-mortem para prever falhas e criar procedimentos, quando apropriado. Ao fazer alterações nas listas de verificação usadas para avaliar suas cargas de trabalho, planeje o que você fará com sistemas ativos que não estejam mais em conformidade. 

 **Antipadrões comuns:** 
+  Decidir implantar uma carga de trabalho sem entender os riscos de segurança presentes na carga de trabalho. 
+  Decidir implantar uma carga de trabalho sem entender se ela está em conformidade com sua governança e seus padrões. 
+  Decidir implantar uma carga de trabalho sem entender se sua equipe pode oferecer suporte a ela. 
+  Decidir implantar uma carga de trabalho sem entender como ela beneficia a organização. 

 **Benefícios do estabelecimento desta prática recomendada:** Ter membros da equipe qualificados possibilita o suporte eficaz da sua carga de trabalho. 

 **Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Baixo 

## Orientações para a implementação
<a name="implementation-guidance"></a>
+  Tomar decisões embasadas para implantar workloads e alterações: avalie os recursos da equipe para apoiar a workload e a conformidade da workload com a governança. Avalie isso em relação aos benefícios da implantação ao determinar se deseja fazer a transição para um sistema ou mudar para produção. Compreenda os benefícios e riscos e tome decisões informadas. 