# OPERAÇÕES 7. Como saber se está pronto para oferecer suporte a uma workload?
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-BP06 Viabilizar planos de suporte para workloads de produção](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 Garantir a capacidade da equipe
Tenha um mecanismo para validar que você tem o número adequado de funcionários treinados para fornecer suporte à workload. Eles devem ter treinamento para a plataforma e os serviços que compõem sua workload. Forneça a eles o conhecimento necessário para operar a workload. É necessário ter o número suficiente de funcionários treinados para fornecer suporte à operação da workload e solucionar os incidentes que ocorrerem. Tenha funcionários suficientes para que seja possível alterná-los durante plantões e férias, a fim de evitar a exaustão.
**Resultado desejado:**
+ Há um número suficiente de funcionários treinados para fornecer suporte à workload quando a workload estiver disponível.
+ Você fornece treinamento para seus funcionários sobre software e serviços que compõem a workload.
**Antipadrões comuns:**
+ Implantar uma workload sem membros da equipe treinados para operar a plataforma e os serviços em uso.
+ Não ter funcionários suficientes para fornecer suporte à alternâncias de plantão ou folga de funcionários.
**Benefícios do estabelecimento desta prática recomendada:**
+ Ter membros da equipe qualificados possibilita o suporte eficaz da sua carga de trabalho.
+ Com um número suficiente de membros na equipe, é possível dar conta da workload e das alternâncias de plantão, reduzindo o risco de exaustão.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** alto
## Orientações para a implementação
Valide se há um número suficiente de funcionários treinados para fornecer suporte à workload. Verifique se você tem membros da equipe suficientes para cobrir as atividades operacionais normais, incluindo alternâncias de plantão.
**Exemplo de clientes**
A Loja UmaEmpresa garante que as equipes que fornecem suporte à workload estejam completas e treinadas. Há engenheiros suficientes para fornecer suporte a uma alternância de plantão. Os funcionários têm treinamento referente ao software e à plataforma na qual a workload é criada e são incentivados a obter certificações. Há funcionários suficientes para que as pessoas possam tirar folgas enquanto mantêm o suporte à workload e à alternância de plantões.
**Etapas da implementação**
1. Atribua um número adequado de funcionários para operar e fornecer suporte à workload, incluindo tarefas de plantão.
1. Treine seus funcionários referente ao software e às plataformas que compõem a workload.
1. O [AWS Training and Certification](https://aws.amazon.com/training/) tem uma biblioteca de cursos sobre a AWS. Estão disponíveis cursos pagos e gratuitos, online e presenciais.
1. [A AWS promove eventos e webinars](https://aws.amazon.com/events/) por meio dos quais você aprende com especialistas da AWS.
1. Avalie regularmente o tamanho e as habilidades da equipe à medida que as condições operacionais e a workload mudam. Ajuste o tamanho e as habilidades da equipe para corresponderem aos requisitos operacionais.
**Nível de esforço do plano de implementação:** alto. Contratar e treinar uma equipe para fornecer suporte a uma workload pode exigir um esforço significativo, mas traz benefícios substanciais de longo prazo.
## Recursos
**Práticas recomendadas relacionadas:**
+ [OPS11-BP04 Realizar o gerenciamento de conhecimento](ops_evolve_ops_knowledge_management.md) – Os membros da equipe devem ter as informações necessárias para operar e fornecer suporte à workload. O gerenciamento de conhecimento é fundamental para fornecer isso.
**Documentos relacionados:**
+ [Eventos e webinars da AWS](https://aws.amazon.com/events/)
+ [AWS Training and Certification](https://aws.amazon.com/training/)
# OPS07-BP02 Garantir uma análise consistente da prontidão operacional
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
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
**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 Preparar-se 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 *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
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
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
**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 Realizar 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
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 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
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
**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 Realizar 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
Há processos em vigor para alterações com e sem êxito feitas na workload. Uma estratégia pre-mortem é um exercício em que uma equipe simula uma falha para desenvolver estratégias de mitigação. Use as estratégias pre-mortem para antecipar falhas e criar procedimentos, quando apropriado. Avalie os benefícios e os riscos de implantar alterações na workload. Verifique se todas as alterações estão em conformidade com a governança.
**Resultado desejado:**
+ Você toma decisões embasadas ao implantar alterações na workload.
+ As alterações estão em conformidade com a governança.
**Antipadrões comuns:**
+ Implantar uma alteração em nossa workload sem um processo para lidar com uma implantação com falha.
+ Fazer alterações no ambiente de produção que estão fora da conformidade com os requisitos de governança.
+ Implantar uma nova versão da workload sem estabelecer uma referência para a utilização de recursos.
**Benefícios do estabelecimento desta prática recomendada:**
+ Você está preparado para alterações sem êxito na workload.
+ As alterações na workload estão em conformidade com as políticas de governança.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo
## Orientações para a implementação
Use estratégias pre-mortem no desenvolvimento de processos para alterações sem êxito. Documente os processos de alterações sem êxito. Garanta que todas as alterações estejam em conformidade com a governança. Avalie os benefícios e os riscos de implantar alterações na workload.
**Exemplo de clientes**
A Loja UmaEmpresa realiza estratégias pre-mortem regularmente para validar seus processos de alterações sem êxito. Os processos são documentados em uma Wiki compartilhada e atualizados regularmente. Todas as alterações estão em conformidade com os requisitos de governança.
**Etapas da implementação**
1. Tome decisões embasadas ao implantar alterações na workload. Estabeleça e revise os critérios de uma implantação bem-sucedida. Desenvolva cenários ou critérios que acionariam a reversão de uma alteração. Pondere os benefícios de implantar alterações considerando os riscos de uma alteração sem êxito.
1. Verifique se todas as alterações estão em conformidade com as políticas de governança.
1. Use estratégias pre-mortem para alterações sem êxito e documente as estratégias de migração. Realize um exercício de simulação para modelar uma alteração sem êxito e validar os procedimentos de reversão.
**Nível de esforço do plano de implementação:** moderado. Implementar uma prática de estratégias pre-mortem requer coordenação e esforço das partes interessadas na organização.
## Recursos
**Práticas recomendadas relacionadas:**
+ [OPS01-BP03 Avaliar os requisitos de governança](ops_priorities_governance_reqs.md) – Os requisitos de governança são um fator fundamental para determinar se uma alteração deve ser implementada.
+ [OPS06-BP01 Preparar-se para alterações malsucedidas](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – Estabeleça planos para mitigar uma implantação sem êxito e use estratégias pre-mortem para validá-los.
+ [OPS06-BP02 Testar as implantações](ops_mit_deploy_risks_test_val_chg.md) – Toda alteração de software deve ser testada adequadamente antes da implantação para reduzir os defeitos na produção.
+ [OPS07-BP01 Garantir a capacidade da equipe](ops_ready_to_support_personnel_capability.md) – Ter um número suficiente de funcionários treinados para fornecer suporte à workload é essencial para tomar uma decisão embasada quanto à implantação de uma alteração no sistema.
**Documentos relacionados:**
+ [Amazon Web Services: risco e conformidade](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [Modelo de responsabilidade compartilhada da AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Governance in the Nuvem AWS: The Right Balance Between Agility and Safety ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)(Governança na Nuvem AWS: o equilíbrio certo entre agilidade e segurança)
# OPS07-BP06 Viabilizar planos de suporte para workloads de produção
Viabilize o suporte para qualquer software e quaisquer serviços dos quais sua workload de produção dependa. Selecione um nível de suporte apropriado para atender às necessidades de nível de serviço da produção. Planos de suporte para essas dependências são necessários no caso de interrupção de um serviço ou de um problema de software. Documente os planos de suporte e como solicitar suporte para todos os fornecedores de serviços e software. Implemente mecanismos que verifiquem se os pontos de contato do suporte são mantidos atualizados.
**Resultado desejado:**
+ Implemente planos de suporte para software e serviços dos quais as workloads de produção dependem.
+ Escolha um plano de suporte apropriado com base nas necessidades de nível de serviço.
+ Documente os planos de suporte, os níveis de suporte e como solicitar suporte.
**Antipadrões comuns:**
+ Você não tem nenhum plano de suporte junto a um fornecedor de software essencial. Sua workload é afetada por isso e você não pode fazer nada para agilizar a correção ou obter atualizações em tempo hábil do fornecedor.
+ Um desenvolvedor que era o principal ponto de contato com um fornecedor de software deixou a empresa. Você não consegue entrar em contato com o suporte do fornecedor diretamente. Você precisa despender tempo pesquisando e navegando por sistemas de contato genéricos, aumentando o tempo requerido para responder quando necessário.
+ Ocorre uma interrupção na produção relacionada a um fornecedor de software. Não há nenhuma documentação sobre como abrir um caso de suporte.
**Benefícios do estabelecimento desta prática recomendada:**
+ Com o nível de suporte apropriado, você é capaz de obter uma resposta no espaço de tempo requerido para atender a necessidades de nível de serviço.
+ Como um cliente com suporte, você pode encaminhar a questão se houver problemas na produção.
+ Os fornecedores de software e serviços podem ajudar na resolução de problemas durante um incidente.
**Nível de exposição a riscos quando esta prática recomendada não é estabelecida:** baixo
## Orientações para a implementação
Viabilize planos de suporte para qualquer software e quaisquer serviços dos quais sua workload de produção dependa. Estabeleça planos de suporte apropriados para atender a necessidades de nível de serviço. Para clientes da AWS, isso significa habilitar o AWS Business Support ou superior em quaisquer contas em que você tenha workloads de produção. Entre em contato regularmente com os fornecedores de suporte para obter atualizações sobre ofertas, processos e contatos de suporte. Documente como solicitar suporte de fornecedores de software e serviços e sobre como encaminhar problemas se houver uma interrupção. Implemente mecanismos para manter os contatos de suporte atualizados.
**Exemplo de clientes**
Na Loja UmaEmpresa, todas dependências de software e serviços comerciais contam com planos de suporte. Por exemplo, eles têm o AWS Enterprise Support habilitado em todas as contas com workloads de produção. Qualquer desenvolvedor pode abrir um caso de suporte quando há um problema. Há uma página de wiki com informações sobre como solicitar suporte, a quem notificar e as práticas recomendadas para agilizar um caso.
**Etapas da implementação**
1. Trabalhe com as partes interessadas em sua organização para identificar fornecedores de software e serviços dos quais sua workload dependa. Documente essas dependências.
1. Determine as necessidades de nível de serviço para sua workload. Selecione um plano de suporte alinhado a elas.
1. Para software e serviços comerciais, estabeleça um plano de suporte com os fornecedores.
1. A assinatura do AWS Business Support ou superior para todas as contas de produção fornece um tempo de resposta rápido do AWS Support e é altamente recomendada. Se você não tiver suporte premium, precisará de um plano de ação para lidar com os problemas, o que requer a ajuda do AWS Support. O AWS Support oferece um conjunto de ferramentas e tecnologia, pessoas e programas projetados para ajudar você de forma proativa a otimizar a performance, reduzir custos e inovar com maior rapidez. O AWS Business Support oferece benefícios adicionais, incluindo acesso ao AWS Trusted Advisor e ao AWS Personal Health Dashboard e tempos de resposta mais rápidos.
1. Documente o plano de suporte em sua ferramenta de gerenciamentos de conhecimentos. Inclua como solicitar suporte, a quem notificar se for aberto um caso de suporte e como encaminhar o problema durante um incidente. Uma wiki é um bom mecanismo para possibilitar que todos façam as atualizações necessárias na documentação quando forem informados sobre alterações em processos ou contatos de suporte.
**Nível de esforço do plano de implementação:** baixo. A maioria dos fornecedores de software e serviços oferece planos de suporte que requerem adesão. Documentar e compartilhar práticas recomendadas no sistema de gerenciamento de conhecimentos garante que sua equipe saiba o que fazer quando houver um problema na produção.
## Recursos
**Práticas recomendadas relacionadas:**
+ [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md)
**Documentos relacionados:**
+ [AWS Support Plans ](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**Serviços relacionados:**
+ [AWS Business Support ](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support ](https://aws.amazon.com/premiumsupport/plans/enterprise/)