# OPS 7. Como saber se está tudo pronto para oferecer suporte a uma workload? Avalie a prontidão operacional de sua workload, 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 revisão 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 playbooks 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 Criar planos de suporte para workloads de produção ](ops_ready_to_support_enable_support_plans.md) # OPS07-BP01 Garantir a capacidade da equipe OPS07-BP01 Garantir a capacidade da equipe Adote 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 oferecer suporte à operação da workload e solucionar os incidentes que ocorrerem. Tenha funcionários suficientes para que seja possível fazer uma rotação 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 oferecer suporte à workload quando ela estiver disponível. + Você fornece treinamento para seus funcionários sobre software e serviços que compõem a workload. **Práticas comuns que devem ser evitadas:** + 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 oferecer suporte à rotaçõ\$1es de plantão ou folga de funcionários. **Benefícios de implementar esta prática recomendada:** + Ter membros da equipe qualificados possibilita o suporte eficaz da sua workload. + Com um número suficiente de membros na equipe, é possível dar conta da workload e das rotações de plantão, reduzindo o risco de exaustão. **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto ## Orientação para implementação Orientação para implementação Valide se há um número suficiente de funcionários treinados para oferecer suporte à workload. Verifique se você tem membros da equipe suficientes para cobrir as atividades operacionais normais, incluindo rotações de plantão. **Exemplo de cliente** A AnyCompany Retail garante que as equipes que oferecem suporte à workload estejam completas e treinadas. Há engenheiros suficientes para oferecer suporte a uma rotação 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 à rotação de plantões. ### Etapas de implementação Etapas de implementação 1. Atribua um número adequado de funcionários para operar e fornecer suporte à sua workload, incluindo tarefas de plantão, questões de segurança e eventos de ciclo de vida, como fim do suporte e tarefas de alternância de certificados. 1. Treine seus funcionários referente ao software e às plataformas que compõem a workload. 1. A [AWS Training and Certification](https://aws.amazon.com/training/) oferece uma biblioteca de cursos sobre a AWS. Cursos pagos e gratuitos, online e presenciais, estão disponíveis. 1. A [AWS organiza eventos e webinars](https://aws.amazon.com/events/) nos quais você aprende com especialistas da AWS. 1. Realize o seguinte regularmente: + Avalie 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. + Verifique a habilidade e a capacidade de lidar com [eventos planejados do ciclo de vida](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html), segurança não planejada e notificações operacionais por meio do AWS Health. **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 Recursos **Práticas recomendadas relacionadas:** + [OPS11-BP04 Gerenciar o 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 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 revisão consistente da prontidão operacional OPS07-BP02 Garantir uma revisão consistente da prontidão operacional Use revisões 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ê em dia com 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. **Práticas comuns que devem ser evitadas:** + 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 implementar 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 se esta prática recomendada não for estabelecida:** Alto ## Orientação para implementação 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. Com o tempo, você pode usar serviços como [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) e [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) para criar as práticas recomendadas do ORR em grades de proteção para a detecção automática de práticas recomendadas. **Exemplo de cliente** Depois de vários incidentes na produção, a AnyCompany Retail 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. As novas workloads passam pelo processo de ORR antes do lançamento. Uma ORR é realizada anualmente para cada workload com um subconjunto de práticas recomendadas para incorporar novas práticas recomendadas e requisitos que são adicionados à lista de verificação da ORR. A AnyCompany Retail usava o [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) para detectar algumas das práticas recomendadas, acelerando o processo de ORR. **Etapas de implementação** Para saber mais sobre ORRs, leia o whitepaper [Revisões 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 revisão, 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. + O [Apêndice B: Perguntas de exemplo sobre ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) do whitepaper Revisões 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 [lentes personalizadas](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 entre suas contas e sua organização da AWS. 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 poderão ser aceitáveis 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 Revisões de prontidão operacional](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) a seus gerentes técnicos de conta. O workshop é uma sessão de *trabalho retroativo* interativa que permite 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 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 de ORR. + [OPS01-BP04 Avaliar os requisitos de conformidade](ops_priorities_compliance_reqs.md): os requisitos de conformidade algumas vezes são incluídos em uma lista de verificação de ORR. Em outras, 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 acomodar 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 são excelentes requisitos de ORR. + [REL13-BP01 Definir objetivos de recuperação tempo de inatividade e perda de dados](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html): planos de recuperação de desastres são um bom 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): políticas de gerenciamento de custos podem ser incluídas em sua lista de verificação de ORR. **Documentos relacionados:** + [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: perspectivas personalizadas](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) + [Modelo de revisão de prontidão operacional, por Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79) + [Whitepaper Revisões 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 Criar uma Revisão de prontidão operacional (ORR) eficaz](https://www.youtube.com/watch?v=Keo6zWMQqS8) **Exemplos relacionados:** + [Exemplo da perspectiva da Revisão 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 OPS07-BP03 Usar runbooks para realizar procedimentos Um *runbook* é um processo documentado para alcançar um resultado específico. Os runbooks consistem em uma série de etapas seguidas por alguém para realizar alguma coisa. Os runbooks são usados em operações desde os primórdios da aviação. Nas operações na nuvem, usamos runbooks para reduzir riscos e alcançar os resultados desejados. Simplificando ao máximo, um runbook é uma lista de verificação para concluir uma tarefa. Os 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 quem os usa. Os runbooks devem ser publicados em um local central e 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. Eles 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, você dedicará tempo à automação de runbooks mais complexos. Com o tempo, a maioria dos seus runbooks deverá 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 as permissões necessárias e instruções para tratamento de erros. Eles são armazenados em um local central (sistema de controle de versão) e atualizados com frequência. Por exemplo, seus runbooks fornecem recursos para que suas equipes monitorem, se comuniquem e reajam a eventos do AWS Health para contas críticas durante alarmes de aplicações, problemas operacionais e eventos planejados do ciclo de vida. **Práticas comuns que devem ser evitadas:** + Depender da memória para concluir cada etapa de um processo. + Implantar mudanças manualmente sem uma lista de verificação. + Diferentes membros da equipe realizando o mesmo processo, mas com etapas ou resultados diferentes. + Deixar que os runbooks fiquem desatualizados em relação às alterações no sistema e à automação. **Benefícios de implementar esta 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 as 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 para implementação Orientação para 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. Documente claramente as permissões ou ferramentas especiais necessárias. Forneça orientação detalhada sobre tratamento de erros e encaminhamentos em caso de problema. Liste o proprietário do runbook e publique-o 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. Ao usar serviços como o [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), é possível 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. AWS O Systems Manager Automation também fornece uma [experiência de design visual](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html) com código simples para criar runbooks de automação com mais facilidade. **Exemplo de cliente** A AnyCompany Retail precisa realizar atualizações no esquema de banco de dados durante as 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 alterações. 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. A equipe de operações na nuvem publicou o runbook na wiki interna junto com outros runbooks. Ela planeja automatizar o runbook em um sprint futuro. ### Etapas de implementação Etapas de 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 a biblioteca de runbooks. Você pode criar runbooks usando Markdown. Disponibilizamos um modelo de runbook que pode ser usado para começar a criar runbooks. ``` # Runbook Title ## Runbook Info | Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | ## Steps 1. Step one 2. Step two ``` 1. Se você não tiver um repositório de documentação ou uma wiki, crie um repositório de controle de versão no 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 o Título do runbook e os campos obrigatórios em Informações do runbook. 1. Começando com a primeira etapa, preencha a parte Etapas do runbook. 1. Dê o runbook para um membro da equipe. Peça que ele use o runbook 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 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 Recursos **Práticas recomendadas relacionadas:** + [OPS02-BP02 Processos e procedimentos com proprietários identificados](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html) + [OPS07-BP04 Usar playbooks para investigar problemas](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) + [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) + [OPS10-BP02 Adotar um processo por alerta](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html) + [OPS11-BP04 Gerenciar o conhecimento](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html) **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 de migração 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: Guia de faça você mesmo para runbooks, relatórios de incidentes e resposta a incidentes](https://www.youtube.com/watch?v=E1NaYN_fJUo) + [Como automatizar as operações de TI na AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug) + [Integrar scripts ao AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE) **Exemplos relacionados:** + [Laboratórios do Well-Architected: Automatização de operações com playbooks e runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) + [AWS Publicação no blog da : Criar uma prática de automação de nuvem para excelência operacional: práticas recomendadas do AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/) + [AWS Systems Manager: orientações sobre automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) + [AWS Systems Manager: runbook para restauração de 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 o 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) + [Usar o Document Builder para criar um runbook personalizado](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) **Serviços relacionados:** + [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) # OPS07-BP04 Usar playbooks para investigar problemas OPS07-BP04 Usar playbooks para investigar problemas Os *playbooks* são guias detalhados usados para investigar incidentes. Quando incidentes ocorrem, os playbooks são usados para investigar, definir o escopo do impacto e identificar a causa-raiz. Os playbooks são usados em diversos cenários, desde falhas em implantações até incidentes de segurança. Em muitos casos, os playbooks identificam a causa-raiz que um runbook costuma mitigar. Os playbooks são essenciais aos planos de resposta a incidentes de sua organização. Um bom playbook abrange vários aspectos importantes. 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 playbook se ferramentas especiais ou permissões elevadas são necessárias. 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 playbook deve ter um plano de escalação. Se a causa-raiz tiver sido identificada, o playbook deverá indicar um runbook que descreva como resolvê-la. Os playbooks devem ser armazenados em um local central e atualizados com frequência. Caso os playbooks sejam usados para alertas específicos, forneça às equipes indicadores para o playbook no alerta. À medida que sua organização continuar amadurecendo, automatize seus playbooks. Comece com playbooks para abordar incidentes de baixo risco. Use scripts para automatizar as etapas de descoberta. Tenha runbooks complementares para mitigar as causas-raiz comuns. **Resultado desejado:** sua organização tem playbooks para incidentes comuns. Os playbooks são armazenados em um local central e estão disponíveis para os membros da equipe. Os playbooks são atualizados com frequência. Runbooks complementares são criados para todas as causas-raiz conhecidas. **Práticas comuns que devem ser evitadas:** + 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 implementar esta prática recomendada:** + Os playbooks impulsionam seus esforços para mitigar os incidentes. + Diferentes membros da equipe podem usar o mesmo playbook para identificar uma causa-raiz de maneira consistente. + As causas-raiz conhecidas podem ter runbooks desenvolvidos para elas, diminuindo o tempo de recuperação. + Os playbooks permitem que os membros da equipe comecem a contribuir o quanto antes. + As equipes podem escalar seus processos com playbooks repetíveis. **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio ## Orientação para implementação Orientação para implementação A maneira que você cria e usa os playbooks depende da maturidade da sua organização. Se você é iniciante na nuvem, crie playbooks no formato de texto em um repositório central de documentos. À medida que sua organização amadurecer, os playbooks 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 playbooks totalmente automatizados para problemas comuns que são corrigidos automaticamente com runbooks. Comece a criar seus playbooks listando incidentes comuns que ocorrem com sua workload. Para começar, escolha playbooks para incidentes com baixo risco e nos quais a causa-raiz tenha sido restrita a poucos problemas. Quando já tiver playbooks para os cenários mais simples, passe para cenários de alto risco ou cenários em que a causa-raiz não é bem conhecida. Seus playbooks 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), o texto simples pode ser transformado em automações. Essas automações podem ser executadas na 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 interessadas durante a descoberta e a mitigação e permitir a colaboração durante todo o incidente. Ele usa o AWS Automations para acelerar a detecção e a recuperação. **Exemplo de cliente** Um incidente na produção afetou a AnyCompany Retail. O engenheiro de plantão usou um playbook para investigar o problema. À medida que foi avançando pelas etapas, ele manteve as principais partes interessadas informadas, as quais estão identificadas no playbook. O engenheiro identificou a causa-raiz como uma condição de corrida em um serviço de backend. Usando um runbook, o engenheiro reiniciou o serviço, colocando a AnyCompany Retail online novamente. ### Etapas de implementação Etapas de 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 de playbooks. É possível criar os playbooks usando o Markdown, que é compatível com a maioria dos sistemas de automação de playbooks. Se você estiver iniciando do zero, use o modelo de exemplo de playbook a seguir. ``` # Playbook Title ## Playbook Info | Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? | ## Steps 1. Step one 2. Step two ``` 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 playbooks 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 está limitada a poucos problemas e a resolução é de baixo risco. 1. Usando o modelo Markdown, preencha a seção Nome do playbook e os campos em Informações do playbook. 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 playbook 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 playbook. 1. Publique o playbook no repositório de documentos e informe sua equipe e as partes interessadas. 1. Essa biblioteca de playbooks crescerá à medida que você adicionar outros playbooks. Quando tiver vários playbooks, comece a automatizá-los usando ferramentas como o AWS Systems Manager Automations a fim de manter a automação e os playbooks sincronizados. **Nível de esforço do plano de implementação:** Baixo. Os playbooks devem ser documentos de texto armazenados em um local central. Organizações mais consolidadas passarão a automatizar os respectivos playbooks. ## Recursos Recursos **Práticas recomendadas relacionadas:** + [OPS02-BP02 Processos e procedimentos com proprietários identificados](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html) + [OPS07-BP03 Usar runbooks para realizar procedimentos](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) + [OPS10-BP01 Usar um processo para gerenciamento de eventos, incidentes e problemas](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) + [OPS10-BP02 Adotar um processo por alerta](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html) + [OPS11-BP04 Gerenciar o conhecimento](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html) **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) + [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: Guia de faça você mesmo para runbooks, relatórios de incidentes e resposta a incidentes (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo) + [AWS Systems Manager Incident Manager: workshops virtuais da AWS](https://www.youtube.com/watch?v=KNOc0DxuBSY) + [Integrar scripts ao AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE) **Exemplos relacionados:** + [AWS Framework do playbook do cliente da](https://github.com/aws-samples/aws-customer-playbook-framework) + [AWS Systems Manager: orientações sobre automação](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) + [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: uma biblioteca Python para criação de runbooks em cadernos Jupyter](https://github.com/Nurtch/rubix) + [Usar o Document Builder para criar um runbook personalizado](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) **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 OPS07-BP05 Tomar decisões embasadas para implantar sistemas e alterações Adote processos para lidar com as 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. **Práticas comuns que devem ser evitadas:** + 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 de implementar esta 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 risco exposto se esta prática recomendada não for estabelecida:** Baixo ## Orientação para implementação Orientação para implementação Use estratégias pre-mortem para desenvolver processos para lidar com 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 cliente** A AnyCompany Retail 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 de 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 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 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/) + [Governança na Nuvem AWS: o equilíbrio certo entre agilidade e segurança](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/) # OPS07-BP06 Criar planos de suporte para workloads de produção OPS07-BP06 Criar planos de suporte para workloads de produção Habilite 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. **Práticas comuns que devem ser evitadas:** + 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. + Uma interrupção ocorre na produção relacionada a um fornecedor de software. Não há nenhuma documentação sobre como abrir um caso de suporte. **Benefícios de implementar esta prática recomendada:** + Com o nível de suporte apropriado, você é capaz de obter uma resposta no espaço de tempo requerido para atender às 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 risco exposto se esta prática recomendada não for estabelecida:** Baixo ## Orientação para implementação Orientação para implementação Habilite 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 cliente** Na AnyCompany Retail, todas dependências de software e serviços comerciais contam com planos de suporte. Por exemplo, eles têm o AWS Enterprise Support ativado 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 de 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 Supportoferece ferramentas e tecnologias, pessoas e programas projetados para ajudar você de forma proativa a otimizar o desempenho, reduzir os custos e inovar mais depressa. Além disso, o AWS Business Support oferece benefícios adicionais, como acesso à API para o AWS Trusted Advisor e o AWS Health para integração programática com seus sistemas, além de outros métodos de acesso, como o Console de gerenciamento da AWS e os canais do Amazon EventBridge. 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 Recursos **Práticas recomendadas relacionadas:** + [OPS02-BP02 Processos e procedimentos com proprietários identificados](ops_ops_model_def_proc_owners.md) **Documentos relacionados:** + [Planos do AWS Support](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/)