Realize testes de recuperação de falhas

Last reviewed 2024-12-30 UTC

Este princípio no pilar de fiabilidade da Google Cloud estrutura bem arquitetada fornece recomendações para ajudar a conceber e executar testes de recuperação no caso de falhas.

Este princípio é relevante para a área de foco de aprendizagem da fiabilidade.

Vista geral do princípio

Para se certificar de que o seu sistema consegue recuperar de falhas, tem de executar periodicamente testes que incluam failovers regionais, reversões de lançamentos e restauro de dados a partir de cópias de segurança.

Este teste ajuda a praticar respostas a eventos que representam riscos importantes para a fiabilidade, como a indisponibilidade de uma região inteira. Este teste também ajuda a verificar se o seu sistema se comporta conforme previsto durante uma interrupção.

No caso improvável de uma região inteira ficar inativa, tem de fazer failover de todo o tráfego para outra região. Durante o funcionamento normal da sua carga de trabalho, quando os dados são modificados, têm de ser sincronizados da região principal para a região de alternativa. Tem de validar se os dados replicados são sempre muito recentes, para que os utilizadores não sofram perdas de dados nem interrupções de sessões. O sistema de balanceamento de carga também tem de conseguir transferir o tráfego para a região de alternativa em qualquer altura sem interrupções do serviço. Para minimizar o tempo de inatividade após uma indisponibilidade regional, os engenheiros de operações também têm de conseguir desviar o tráfego de utilizadores de uma região de forma manual e eficiente, no menor tempo possível. Esta operação é por vezes denominada drenar uma região, o que significa que para o tráfego de entrada para a região e move todo o tráfego para outro local.

Recomendações

Quando cria e executa testes para a recuperação de falhas, considere as recomendações nas subsecções seguintes.

Defina os objetivos e o âmbito dos testes

Defina claramente o que quer alcançar com os testes. Por exemplo, os seus objetivos podem incluir o seguinte:

  • Valide o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO). Para ver detalhes, consulte o artigo Noções básicas do planeamento de recuperação de desastres.
  • Avalie a resiliência do sistema e a tolerância a falhas em vários cenários de falhas.
  • Teste a eficácia dos mecanismos de comutação por falha automáticos.

Decida que componentes, serviços ou regiões estão no âmbito dos testes. O âmbito pode incluir camadas de aplicações específicas, como a camada de front-end, de back-end e de base de dados, ou pode incluir recursos específicos, como instâncias do Cloud SQL ou clusters do GKE. Google Cloud O âmbito também tem de especificar quaisquer dependências externas, como APIs de terceiros ou interconexões na nuvem.

Prepare o ambiente para testes

Escolha um ambiente adequado, de preferência um ambiente de preparação ou de teste que replique a sua configuração de produção. Se realizar o teste em produção, certifique-se de que tem medidas de segurança prontas, como a monitorização automática e os procedimentos de reversão manuais.

Crie um plano de cópia de segurança. Tire instantâneos ou faça cópias de segurança de bases de dados e serviços críticos para evitar a perda de dados durante o teste. Certifique-se de que a sua equipa está preparada para fazer intervenções manuais se os mecanismos de comutação por falha automatizados falharem.

Para evitar interrupções nos testes, certifique-se de que as funções, as políticas e as configurações de comutação por falha do IAM estão configuradas corretamente. Verifique se as autorizações necessárias estão em vigor para as ferramentas e os scripts de teste.

Informar as partes interessadas, incluindo as operações, o DevOps e os proprietários de aplicações, acerca do cronograma, do âmbito e do potencial impacto do teste. Forneça às partes interessadas uma cronologia estimada e os comportamentos esperados durante o teste.

Simule cenários de falha

Planeie e execute falhas através de ferramentas como o Chaos Monkey. Pode usar scripts personalizados para simular falhas de serviços críticos, como o encerramento de um nó principal num cluster do GKE de várias zonas ou uma instância do Cloud SQL desativada. Também pode usar scripts para simular uma interrupção de rede em toda a região através de regras de firewall ou restrições de API com base no âmbito do teste. Aumente gradualmente os cenários de falha para observar o comportamento do sistema em várias condições.

Introduza testes de carga juntamente com cenários de falhas para replicar a utilização no mundo real durante interrupções. Teste os impactos de falhas em cascata, como o comportamento dos sistemas de front-end quando os serviços de back-end estão indisponíveis.

Para validar as alterações de configuração e avaliar a resiliência do sistema contra erros humanos, teste cenários que envolvam configurações incorretas. Por exemplo, execute testes com definições de comutação por falha de DNS incorretas ou autorizações de IAM incorretas.

Monitorize o comportamento do sistema

Monitorize a forma como os balanceadores de carga, as verificações de funcionamento e outros mecanismos reencaminham o tráfego. Use Google Cloud ferramentas como o Cloud Monitoring e o Cloud Logging para capturar métricas e eventos durante o teste.

Observe as alterações na latência, nas taxas de erro e no débito durante e após a simulação de falhas, e monitorize o impacto geral no desempenho. Identifique qualquer degradação ou inconsistências na experiência do utilizador.

Certifique-se de que os registos são gerados e os alertas são acionados para eventos principais, como falhas de serviço ou failovers. Use estes dados para validar a eficácia dos seus sistemas de alerta e resposta a incidentes.

Valide a recuperação em função do RTO e do RPO

Meça o tempo que o sistema demora a retomar as operações normais após uma falha e, em seguida, compare estes dados com o RTO definido e documente quaisquer lacunas.

Certifique-se de que a integridade e a disponibilidade dos dados estão alinhadas com o RPO. Para testar a consistência da base de dados, compare as capturas de ecrã ou as cópias de segurança da base de dados antes e depois de uma falha.

Avalie o restauro do serviço e confirme que todos os serviços foram restaurados para um estado funcional com uma interrupção mínima para o utilizador.

Documente e analise os resultados

Documente cada passo de teste, cenário de falha e comportamento do sistema correspondente. Inclua indicações de tempo, registos e métricas para análises detalhadas.

Realce gargalos, pontos únicos de falha ou comportamentos inesperados observados durante o teste. Para ajudar a dar prioridade às correções, categorize os problemas por gravidade e impacto.

Sugerir melhorias à arquitetura do sistema, aos mecanismos de comutação por falha ou às configurações de monitorização. Com base nos resultados dos testes, atualize todas as políticas de alternativa relevantes e guias interativos. Apresentar um relatório post mortem aos intervenientes. O relatório deve resumir os resultados, as lições aprendidas e os passos seguintes. Para mais informações, consulte Realize análises detalhadas de incidentes.

Itere e melhore

Para validar a fiabilidade e a resiliência contínuas, planeie testes periódicos (por exemplo, trimestrais).

Execute testes em diferentes cenários, incluindo alterações à infraestrutura, atualizações de software e aumento das cargas de tráfego.

Automatize os testes de comutação por falha através de pipelines de CI/CD para integrar os testes de fiabilidade no ciclo de vida de desenvolvimento.

Durante a análise post mortem, use o feedback das partes interessadas e dos utilizadores finais para melhorar o processo de teste e a resiliência do sistema.