As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Etapa 2: projetar e implementar
Na etapa anterior, você define seus objetivos de resiliência. Agora, na etapa de projetar e implementar, você tenta antecipar os modos de falha e identificar as opções de projeto, conforme orientado pelos objetivos definidos na etapa anterior. Você também define estratégias para o gerenciamento de alterações e desenvolve código de software e configuração de infraestrutura. As seções a seguir destacam as práticas recomendadas da AWS que você deve considerar ao ponderar compensações como custo, complexidade e sobrecarga operacional.
Framework Well-Architected da AWS
Ao arquitetar sua aplicação com base nos objetivos de resiliência desejados, você precisa avaliar vários fatores e fazer compensações na arquitetura mais ideal. Para criar uma aplicação altamente resiliente, você deve considerar aspectos de design, criação e implantação, segurança e operações. O AWS Well-Architected Framework
Confira abaixo exemplos de como o AWS Well-Architected Framework pode ajudar você a projetar e implementar aplicações que atendam aos seus objetivos de resiliência:
-
O pilar da confiabilidade: o pilar da confiabilidade enfatiza a importância de criar aplicações que possam operar de forma correta e consistente, mesmo durante falhas ou interrupções. Por exemplo, o AWS Well-Architected Framework recomenda que você use uma arquitetura de microsserviços para tornar suas aplicações menores e mais simples, para que você possa diferenciar as necessidades de disponibilidade de diferentes componentes em sua aplicação. Você também pode encontrar descrições detalhadas das práticas recomendadas para criar aplicações usando controle de utilização, repetição com recuo exponencial, antecipação à falha (redução de carga), idempotência, trabalho constante, disjuntores e estabilidade estática.
-
Análise abrangente: o AWS Well-Architected Framework incentiva uma revisão abrangente de sua arquitetura em relação às práticas recomendadas e princípios de design. Ele permite avaliar com consistência as arquiteturas e identificar áreas de melhoria.
-
Gerenciamento de riscos: o AWS Well-Architected Framework ajuda você a identificar e gerenciar riscos que podem afetar a confiabilidade da sua aplicação. Ao abordar cenários de possíveis falhas de forma proativa, você pode reduzir sua probabilidade ou a deficiência resultante.
-
Melhoria contínua: a resiliência é um processo contínuo, e o AWS Well-Architected Framework enfatiza a melhoria contínua. Ao revisar e refinar regularmente sua arquitetura e processos com base na orientação do AWS Well-Architected Framework, você pode garantir que seus sistemas permaneçam resilientes diante dos desafios e requisitos em constante mudança.
Análise das dependências
Compreender as dependências de um sistema é fundamental para a resiliência. As dependências incluem as conexões entre os componentes dentro de uma aplicação e as conexões com componentes fora da aplicação, como APIs de terceiros e serviços compartilhados de propriedade da empresa. Compreender essas conexões ajuda a isolar e gerenciar interrupções, pois uma deficiência em um componente pode afetar outros componentes. Esse conhecimento ajuda os engenheiros a avaliar o impacto das deficiências, a planejar adequadamente e a garantir que os recursos sejam usados de forma eficaz. Compreender as dependências ajuda você a criar estratégias alternativas e coordenar os processos de recuperação. Também ajuda a determinar casos em que você pode substituir uma dependência rígida por uma dependência flexível, para que sua aplicação possa continuar cumprindo sua função comercial quando houver uma deficiência de dependência. As dependências também influenciam as decisões sobre balanceamento de carga e escalabilidade de aplicações. Compreender as dependências é vital quando você faz alterações em sua aplicação, pois pode ajudar a determinar possíveis riscos e impactos. Esse conhecimento ajuda você a criar aplicações estáveis e resilientes, auxiliando no gerenciamento de falhas, na avaliação de impacto, na recuperação de deficiências, no balanceamento de carga, na escalabilidade e no gerenciamento de mudanças. Você pode rastrear as dependências manualmente ou usar ferramentas e serviços como AWS X-Ray
Estratégias de recuperação de desastres
Uma estratégia de recuperação de desastres (DR) desempenha um papel fundamental na criação e operação de aplicações resilientes, principalmente garantindo a continuidade dos negócios. Isso garante que as operações comerciais cruciais possam persistir com o mínimo de prejuízo possível, mesmo durante eventos catastróficos, minimizando assim o tempo de inatividade e a possível perda de receita. As estratégias de DR são essenciais para a proteção de dados porque geralmente incorporam backups e replicação de dados regulares em vários locais, o que ajuda a proteger informações comerciais valiosas e a evitar a perda total durante um desastre. Além disso, muitos setores são regulados por políticas que exigem que as empresas tenham uma estratégia de DR para proteger dados sensíveis e garantir que os serviços permaneçam disponíveis durante um desastre. Ao garantir uma deficiência mínima do serviço, uma estratégia de DR também reforça a confiança e a satisfação do cliente. Uma estratégia de DR bem implementada e praticada com frequência reduz o tempo de recuperação após um desastre e ajuda a garantir que as aplicações sejam rapidamente colocadas novamente on-line. Além disso, os desastres podem gerar custos substanciais, não apenas pela perda de receita devido ao tempo de inatividade, mas também pelas despesas de restauração de aplicações e dados. Uma estratégia de DR bem projetada ajuda a se proteger contra essas perdas financeiras.
A estratégia escolhida depende das necessidades específicas da sua aplicação, do seu RTO e RPO e do seu orçamento. O AWS Elastic Disaster Recovery
Para obter mais informações, consulte Disaster Recovery of Workloads on AWS e AWS Multi-Region Fundamentals no site da AWS.
Definição de estratégias de CI/CD
Uma das causas comuns de deficiências na aplicação é o código ou outras alterações que alteram a aplicação de um estado de funcionamento conhecido anteriormente. Se você não abordar o gerenciamento de alterações com cuidado, isso pode causar deficiências frequentes. A frequência das alterações aumenta a oportunidade de impacto. No entanto, fazer alterações com menos frequência resulta em conjuntos de alterações maiores, que têm muito mais probabilidade de resultar em deficiências devido à sua alta complexidade. As práticas de integração e entrega contínuas (CI/CD) são projetadas para manter as alterações pequenas e frequentes (resultando em maior produtividade), ao mesmo tempo em que submetem cada alteração a um alto nível de inspeção por meio da automação. Algumas das estratégias fundamentais são:
-
Automação total: o conceito fundamental de CI/CD é automatizar os processos de criação e implantação o máximo possível. Isso inclui a criação, os testes, a implantação e até mesmo o monitoramento. Os pipelines automatizados ajudam a reduzir a possibilidade de erro humano, garantem a consistência e tornam o processo mais confiável e eficiente.
-
Desenvolvimento orientado a testes (TDD): escreva testes antes de escrever o código da aplicação. Essa prática garante que todo o código tenha testes associados, o que melhora a confiabilidade do código e a qualidade da inspeção automatizada. Esses testes são executados no pipeline de CI para validar as alterações.
-
Confirmações e integrações frequentes: incentive os desenvolvedores a fazer commit de códigos e a realizar integrações com frequência. Alterações pequenas e frequentes são mais fáceis de testar e depurar, o que reduz o risco de problemas significativos. A automação reduz o custo de cada commit e implantação, possibilitando integrações frequentes.
-
Infraestrutura imutável: trate seus servidores e outros componentes da infraestrutura como entidades estáticas e imutáveis. Substitua a infraestrutura em vez de modificá-la o máximo possível, e crie uma nova infraestrutura por meio de código testado e implantado em seu pipeline.
-
Mecanismo de reversão: sempre tenha uma maneira fácil, confiável e frequentemente testada para reverter as alterações se algo der errado. Ser capaz de retornar rapidamente ao bom estado anterior conhecido é essencial para a segurança da implantação. Isso pode ser um botão simples para reverter ao estado anterior ou pode ser totalmente automatizado e iniciado por alarmes.
-
Controle de versão: mantenha todo o código, a configuração e até mesmo a infraestrutura da aplicação como código em um repositório com controle de versão. Essa prática ajuda a garantir que você possa rastrear facilmente as alterações e revertê-las, se necessário.
-
Implantações canário e azul/verde: implantar primeiro novas versões da sua aplicação em um subconjunto de sua infraestrutura ou manter dois ambientes (azul/verde) permite verificar o comportamento de uma mudança na produção e revertê-la rapidamente, se necessário.
O CI/CD não diz respeito apenas às ferramentas, mas também à cultura. Criar uma cultura que valorize a automação, os testes e o aprendizado com as falhas é tão importante quanto implementar as ferramentas e os processos certos. As reversões, se feitas muito rapidamente com impacto mínimo, não devem ser consideradas uma falha, mas uma experiência de aprendizado.
Realização das ORRs
Uma revisão de prontidão operacional (ORR) ajuda a identificar lacunas operacionais e processuais. Na Amazon, criamos ORRs para compilar os aprendizados de décadas operando serviços de alta escala em perguntas selecionadas com orientação das práticas recomendadas. Uma ORR registra as lições aprendidas anteriormente, e as novas equipes são obrigadas a garantir que essas lições tenham sido consideradas em suas aplicações. As ORRs podem fornecer uma lista de modos de falha ou causas de falha que podem ser incluídos na atividade de modelagem de resiliência descrita na seção de modelagem de resiliência abaixo. Para obter mais informações, consulte Operational Readiness Reviews (ORRs) no site do AWS Well-Architected Framework.
Análise das delimitações de isolamento contra falhas da AWS
A AWS fornece várias delimitações de isolamento contra falhas para ajudar você a atingir seus objetivos de resiliência. Você pode usar essas delimitações para aproveitar o escopo previsível de contenção de impacto que elas fornecem. Você deve estar familiarizado com a forma como os serviços da AWS são projetados usando essas delimitações para poder fazer escolhas intencionais sobre as dependências selecionadas para sua aplicação. Para entender como usar delimitações em sua aplicação, consulte AWS Fault Isolation Boundaries no site da AWS.
Seleção de respostas
Um sistema pode responder de várias maneiras a um alarme. Alguns alarmes podem exigir uma resposta da equipe de operações, enquanto outros podem acionar mecanismos de autorrecuperação dentro da aplicação. Você pode decidir manter respostas que possam ser automatizadas como operações manuais para controlar os custos da automação ou gerenciar restrições de engenharia. É provável que o tipo de resposta a um alarme seja selecionado em função do custo de implementação da resposta, da frequência prevista do alarme, da precisão do alarme e da possível perda comercial de não responder ao alarme.
Por exemplo, quando um processo do servidor falha, o processo pode ser reiniciado pelo sistema operacional, um novo servidor pode ser provisionado e o antigo encerrado, ou um operador pode ser instruído a se conectar remotamente ao servidor e reiniciá-lo. Essas respostas têm o mesmo resultado (reiniciar o processo do servidor da aplicação), mas têm níveis variados de custos de implementação e manutenção.
nota
Você pode selecionar várias respostas para adotar uma abordagem de resiliência aprofundada. Por exemplo, no cenário anterior, a equipe de aplicação pode optar por implementar todas as três respostas com um intervalo de tempo entre cada uma. Se o indicador do processo do servidor com falha ainda estiver em um estado de alarme após 30 segundos, a equipe pode presumir que o sistema operacional falhou ao reiniciar o servidor da aplicação. Portanto, eles podem criar um grupo do Auto Scaling para criar um novo servidor virtual e restaurar o processo do servidor da aplicação. Se o indicador ainda estiver em um estado de alarme após 300 segundos, um alerta poderá ser enviado à equipe operacional para se conectar ao servidor de origem e tentar restaurar o processo.
A resposta selecionada pela equipe de aplicação e pelo setor de negócios deve refletir a disposição da empresa em reduzir a sobrecarga operacional com um investimento inicial em tempo de engenharia. Você deve escolher uma resposta (um padrão de arquitetura, como estabilidade estática, um padrão de software, como um disjuntor, ou um procedimento operacional) considerando cuidadosamente as restrições e a manutenção prevista de cada opção de resposta. Algumas respostas padrão podem existir para orientar as equipes de aplicações, para que você possa usar as bibliotecas e os padrões gerenciados pela função de arquitetura centralizada como uma entrada para essa consideração.
Modelagem de resiliência
A modelagem de resiliência documenta como uma aplicação responderá às diferentes interrupções previstas. Ao antecipar interrupções, sua equipe pode implementar processos de observabilidade, controles automatizados e recuperação para mitigar ou evitar deficiências apesar das interrupções. A AWS criou orientações para o desenvolvimento de um modelo de resiliência usando o framework de análise de resiliência. Esse framework pode ajudar você a antecipar interrupções e seu impacto em sua aplicação. Ao antecipar as interrupções, você pode identificar as mitigações necessárias para criar uma aplicação resiliente e confiável. Recomendamos que você use o framework de análise de resiliência para atualizar seu modelo de resiliência a cada iteração do ciclo de vida da sua aplicação. O uso desse framework em cada iteração ajuda a reduzir incidentes, antecipando interrupções durante a fase de design e testando a aplicação antes e depois da implantação da produção. Desenvolver um modelo de resiliência usando esse framework ajuda a garantir que você atenda aos seus objetivos de resiliência.
Falha com segurança
Se você não conseguir evitar interrupções, falhe com segurança. Considere criar sua aplicação com um modo de operação padrão à prova de falhas, em que nenhuma perda comercial significativa possa ocorrer. Um exemplo de estado à prova de falhas para um banco de dados seria usar como padrão as operações somente para leitura, em que os usuários não têm permissão para criar ou alterar nenhum dado. Dependendo da sensibilidade dos dados, você pode até querer que a aplicação adote como padrão um estado de desligamento, e nem mesmo realize consultas somente leitura. Considere qual deve ser o estado à prova de falhas da sua aplicação e use como padrão esse modo de operação sob condições extremas.
