Framework Well-Architected: pilar da fiabilidade

Last reviewed 2025-02-14 UTC

O pilar da fiabilidade no Google Cloud Well-Architected Framework fornece princípios e recomendações para ajudar a conceber, implementar e gerir cargas de trabalho fiáveis no Google Cloud.

Este documento destina-se a arquitetos da nuvem, programadores, engenheiros de plataformas, administradores e engenheiros de fiabilidade do site.

A fiabilidade é a capacidade de um sistema executar consistentemente as funções pretendidas nas condições definidas e manter o serviço ininterrupto. As práticas recomendadas para a fiabilidade incluem redundância, design tolerante a falhas, monitorização e processos de recuperação automáticos.

Como parte da fiabilidade, a resiliência é a capacidade do sistema de resistir e recuperar de falhas ou interrupções inesperadas, mantendo o desempenho. AsGoogle Cloud funcionalidades, como as implementações multirregionais, as cópias de segurança automáticas e as soluções de recuperação de desastres, podem ajudar a melhorar a resiliência do seu sistema.

A fiabilidade é importante para a sua estratégia de nuvem por vários motivos, incluindo os seguintes:

  • Tempo de inatividade mínimo: o tempo de inatividade pode levar à perda de receita, à diminuição da produtividade e a danos na reputação. As arquiteturas resilientes podem ajudar a garantir que os sistemas continuam a funcionar durante falhas ou a recuperar de forma eficiente de falhas.
  • Experiência do utilizador melhorada: os utilizadores esperam interações integradas com a tecnologia. Os sistemas resilientes podem ajudar a manter um desempenho e uma disponibilidade consistentes, e oferecem um serviço fiável mesmo durante uma elevada procura ou problemas inesperados.
  • Integridade de dados: as falhas podem causar perda ou corrupção de dados. Os sistemas resilientes implementam mecanismos como cópias de segurança, redundância e replicação para proteger os dados e garantir que permanecem precisos e acessíveis.
  • Continuidade da empresa: a sua empresa depende da tecnologia para operações críticas. As arquiteturas resilientes podem ajudar a garantir a continuidade após uma falha catastrófica, o que permite que as funções empresariais continuem sem interrupções significativas e suporta uma recuperação rápida.
  • Conformidade: muitos setores têm requisitos regulamentares para a disponibilidade do sistema e a proteção de dados. As arquiteturas resilientes podem ajudar a cumprir estes padrões, garantindo que os sistemas permanecem operacionais e seguros.
  • Custos mais baixos a longo prazo: as arquiteturas resilientes requerem investimento inicial, mas a resiliência pode ajudar a reduzir os custos ao longo do tempo, evitando inatividade dispendiosa, evitando correções reativas e permitindo uma utilização mais eficiente dos recursos.

Mentalidade organizacional

Para tornar os seus sistemas fiáveis, precisa de um plano e de uma estratégia estabelecida. Esta estratégia tem de incluir formação e a autoridade para dar prioridade à fiabilidade juntamente com outras iniciativas.

Defina uma expetativa clara de que toda a organização é responsável pela fiabilidade, incluindo o desenvolvimento, a gestão de produtos, as operações, a engenharia de plataformas e a engenharia de fiabilidade de sites (EFS). Mesmo os grupos focados na empresa, como o marketing e as vendas, podem influenciar a fiabilidade.

Todas as equipas têm de compreender os objetivos de fiabilidade e os riscos das respetivas aplicações. As equipas têm de ser responsáveis pelo cumprimento destes requisitos. Os conflitos entre a fiabilidade e o desenvolvimento regular de funcionalidades dos produtos têm de ser priorizados e encaminhados em conformidade.

Planeie e faça a gestão da fiabilidade de forma holística em todas as suas funções e equipas. Considere configurar um centro de excelência em nuvem (CCoE) que inclua um pilar de fiabilidade. Para mais informações, consulte o artigo Otimize o percurso da sua organização na nuvem com um centro de excelência na nuvem.

Principais áreas para a fiabilidade

As atividades que realiza para conceber, implementar e gerir um sistema fiável podem ser categorizadas nas seguintes áreas de foco. Cada um dos princípios e recomendações de fiabilidade neste pilar é relevante para uma destas áreas de foco.

  • Âmbito: para compreender o seu sistema, faça uma análise detalhada da respetiva arquitetura. Tem de compreender os componentes, como funcionam e interagem, como os dados e as ações fluem através do sistema e o que pode correr mal. Identificar potenciais falhas, gargalos e riscos, o que ajuda a tomar medidas para mitigar esses problemas.
  • Observação: para ajudar a evitar falhas do sistema, implemente uma observação e uma monitorização abrangentes e contínuas. Através desta observação, pode compreender as tendências e identificar potenciais problemas de forma proativa.
  • Resposta: para reduzir o impacto das falhas, responda adequadamente e recupere de forma eficiente. As respostas automáticas também podem ajudar a reduzir o impacto das falhas. Mesmo com planeamento e controlos, podem ocorrer falhas.
  • Aprendizagem: para ajudar a evitar a recorrência de falhas, aprenda com cada experiência e tome as medidas adequadas.

Princípios fundamentais

As recomendações no pilar de fiabilidade da framework bem arquitetada são mapeadas para os seguintes princípios essenciais:

Colaboradores

Autores:

Outros colaboradores:

Defina a fiabilidade com base nos objetivos da experiência do utilizador

Este princípio no pilar de fiabilidade da Google Cloud estrutura bem arquitetada ajuda a avaliar a experiência dos utilizadores e, em seguida, a mapear as conclusões para objetivos e métricas de fiabilidade.

Este princípio é relevante para o âmbito área de foco da fiabilidade.

Vista geral do princípio

As ferramentas de observabilidade fornecem grandes quantidades de dados, mas nem todos os dados estão diretamente relacionados com os impactos nos utilizadores. Por exemplo, pode observar uma utilização elevada da CPU, operações lentas do servidor ou até tarefas falhadas. No entanto, se estes problemas não afetarem a experiência do utilizador, não constituem uma indisponibilidade.

Para medir a experiência do utilizador, tem de distinguir entre o comportamento do sistema interno e os problemas que os utilizadores enfrentam. Concentre-se em métricas como o rácio de sucesso dos pedidos dos utilizadores. Não confie apenas em métricas centradas no servidor, como a utilização da CPU, que podem levar a conclusões enganadoras sobre a fiabilidade do seu serviço. A fiabilidade verdadeira significa que os utilizadores podem usar de forma consistente e eficaz a sua aplicação ou serviço.

Recomendações

Para ajudar a medir a experiência do utilizador de forma eficaz, considere as recomendações nas secções seguintes.

Meça a experiência do utilizador

Para compreender verdadeiramente a fiabilidade do seu serviço, dê prioridade às métricas que refletem a experiência real dos seus utilizadores. Por exemplo, meça o rácio de sucesso das consultas dos utilizadores, a latência da aplicação e as taxas de erro.

Idealmente, recolha estes dados diretamente do dispositivo ou navegador do utilizador. Se esta recolha de dados direta não for viável, afaste progressivamente o ponto de medição do utilizador no sistema. Por exemplo, pode usar o serviço de balanceamento de carga ou de front-end como ponto de medição. Esta abordagem ajuda a identificar e resolver problemas antes que estes possam ter um impacto significativo nos seus utilizadores.

Analise os percursos dos utilizadores

Para compreender como os utilizadores interagem com o seu sistema, pode usar ferramentas de rastreio, como o Cloud Trace. Ao acompanhar o percurso de um utilizador na sua aplicação, pode encontrar gargalos e problemas de latência que podem prejudicar a experiência do utilizador. O Cloud Trace captura dados de desempenho detalhados para cada salto na arquitetura do seu serviço. Estes dados ajudam a identificar e resolver problemas de desempenho de forma mais eficiente, o que pode levar a uma experiência do utilizador mais fiável e satisfatória.

Defina alvos realistas para a fiabilidade

Este princípio no pilar de fiabilidade da Google Cloud estrutura bem arquitetada ajuda a definir objetivos de fiabilidade que são tecnicamente viáveis para as suas cargas de trabalho no Google Cloud.

Este princípio é relevante para o âmbito área de foco da fiabilidade.

Vista geral do princípio

Crie os seus sistemas de forma que sejam suficientemente fiáveis para a satisfação dos utilizadores. Pode parecer contraditório, mas um objetivo de 100% de fiabilidade nem sempre é a estratégia mais eficaz. Uma fiabilidade mais elevada pode resultar num custo significativamente mais elevado, tanto em termos de investimento financeiro como de potenciais limitações à inovação. Se os utilizadores já estiverem satisfeitos com o nível de serviço atual, os esforços para aumentar ainda mais a satisfação podem gerar um baixo retorno do investimento. Em alternativa, pode gastar melhor os recursos noutro local.

Tem de determinar o nível de fiabilidade com que os seus utilizadores ficam satisfeitos e determinar o ponto em que o custo das melhorias incrementais começa a superar as vantagens. Quando determina este nível de fiabilidade suficiente, pode atribuir recursos estrategicamente e focar-se em funcionalidades e melhorias que ofereçam maior valor aos seus utilizadores.

Recomendações

Para definir alvos de fiabilidade realistas, considere as recomendações nas subsecções seguintes.

Aceite algumas falhas e priorize os componentes

Procure uma alta disponibilidade, como um tempo de atividade de 99,99%, mas não defina um objetivo de tempo de atividade de 100%. Reconheça que algumas falhas são inevitáveis.

A diferença entre 100% de tempo de atividade e uma meta de 99,99% é a tolerância para falhas. Esta lacuna é frequentemente denominada orçamento de erros. A margem de erro pode ajudar a correr riscos e inovar, o que é fundamental para qualquer empresa se manter competitiva.

Priorizar a fiabilidade dos componentes mais críticos no sistema. Aceite que os componentes menos críticos podem ter uma tolerância mais elevada a falhas.

Equilibre a fiabilidade e o custo

Para determinar o nível de fiabilidade ideal para o seu sistema, faça análises detalhadas de custos-benefícios.

Considere fatores como os requisitos do sistema, as consequências das falhas e a tolerância ao risco da sua organização para a aplicação específica. Não se esqueça de considerar as métricas de recuperação de desastres, como o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO). Decida que nível de fiabilidade é aceitável dentro do orçamento e de outras restrições.

Procure formas de melhorar a eficiência e reduzir os custos sem comprometer as funcionalidades de fiabilidade essenciais.

Crie sistemas altamente disponíveis através da redundância de recursos

Este princípio no pilar de fiabilidade do Google Cloud Well-Architected Framework fornece recomendações para planear, criar e gerir a redundância de recursos, o que pode ajudar a evitar falhas.

Este princípio é relevante para o âmbito área de foco da fiabilidade.

Vista geral do princípio

Depois de decidir o nível de fiabilidade de que precisa, tem de conceber os seus sistemas para evitar pontos únicos de falha. Todos os componentes críticos no sistema têm de ser replicados em várias máquinas, zonas e regiões. Por exemplo, não é possível localizar uma base de dados crítica apenas numa região, e não é possível implementar um servidor de metadados apenas numa única zona ou região. Nestes exemplos, se a única zona ou região tiver uma indisponibilidade, o sistema tem uma indisponibilidade global.

Recomendações

Para criar sistemas redundantes, considere as recomendações nas seguintes subsecções.

Identifique domínios de falhas e replique serviços

Mapeie os domínios de falhas do seu sistema, desde VMs individuais a regiões, e crie a pensar na redundância em vários domínios de falhas.

Para garantir a alta disponibilidade, distribua e replique os seus serviços e aplicações em várias zonas e regiões. Configure o sistema para a comutação por falha automática para garantir que os serviços e as aplicações continuam a estar disponíveis em caso de falhas de zonas ou regiões.

Para ver exemplos de arquiteturas multizona e multirregionais, consulte o artigo Crie uma infraestrutura fiável para as suas cargas de trabalho no Google Cloud.

Detete e resolva problemas rapidamente

Monitorize continuamente o estado dos seus domínios com falhas para detetar e resolver problemas rapidamente.

Pode monitorizar o estado atual dos Google Cloud serviços em todas as regiões através do Google Cloud painel de controlo de estado do serviço. Também pode ver incidentes relevantes para o seu projeto através do Personalized Service Health. Pode usar equilibradores de carga para detetar o estado de funcionamento dos recursos e encaminhar automaticamente o tráfego para back-ends em bom estado. Para mais informações, consulte o artigo Vista geral das verificações de estado.

Testar cenários de comutação por falha

Tal como num simulacro de incêndio, simule regularmente falhas para validar a eficácia das suas estratégias de replicação e ativação pós-falha.

Para mais informações, consulte os artigos Simule uma indisponibilidade de zona para um MIG regional e Simule uma falha de zona em clusters regionais do GKE.

Tire partido da escalabilidade horizontal

Este princípio no pilar de fiabilidade da Google Cloud estrutura bem arquitetada fornece recomendações para ajudar a usar a escalabilidade horizontal. Ao usar a escalabilidade horizontal, pode ajudar a garantir que as suas cargas de trabalho no Google Cloud podem ser dimensionadas de forma eficiente e manter o desempenho.

Este princípio é relevante para o âmbito área de foco da fiabilidade.

Vista geral do princípio

Reconfigure a arquitetura do seu sistema para uma arquitetura horizontal. Para acomodar o crescimento do tráfego ou dos dados, pode adicionar mais recursos. Também pode remover recursos quando não estiverem a ser usados.

Para compreender o valor do escalamento horizontal, considere as limitações do escalamento vertical.

Um cenário comum para o escalamento vertical é usar uma base de dados MySQL como a base de dados principal com dados críticos. À medida que a utilização da base de dados aumenta, é necessária mais RAM e CPU. Eventualmente, a base de dados atinge o limite de memória na máquina anfitriã e tem de ser atualizada. Este processo pode ter de ser repetido várias vezes. O problema é que existem limites máximos para o crescimento de uma base de dados. Os tamanhos das VMs não são ilimitados. A base de dados pode atingir um ponto em que já não é possível adicionar mais recursos.

Mesmo que os recursos fossem ilimitados, uma VM grande pode tornar-se um único ponto de falha. Qualquer problema com a VM da base de dados principal pode causar respostas de erro ou provocar uma indisponibilidade ao nível do sistema que afeta todos os utilizadores. Evite pontos únicos de falha, conforme descrito no artigo Crie sistemas de elevada disponibilidade através da redundância de recursos.

Além destes limites de escalabilidade, a escalabilidade vertical tende a ser mais cara. O custo pode aumentar exponencialmente à medida que são adquiridas máquinas com maiores quantidades de capacidade de computação e memória.

Por outro lado, o escalamento horizontal pode custar menos. O potencial de escalabilidade horizontal é praticamente ilimitado num sistema concebido para ser escalável.

Recomendações

Para fazer a transição de uma arquitetura de VM única para uma arquitetura horizontal de vários computadores, tem de planear cuidadosamente e usar as ferramentas certas. Para ajudar a alcançar o escalamento horizontal, considere as recomendações nas seguintes subsecções.

Use serviços geridos

Os serviços geridos eliminam a necessidade de gerir manualmente o escalamento horizontal. Por exemplo, com os grupos de instâncias geridas (GIGs) do Compute Engine, pode adicionar ou remover VMs para dimensionar a sua aplicação horizontalmente. Para aplicações em contentores, o Cloud Run é uma plataforma sem servidor que pode dimensionar automaticamente os seus contentores sem estado com base no tráfego recebido.

Promova o design modular

Os componentes modulares e as interfaces claras ajudam a dimensionar os componentes individuais conforme necessário, em vez de dimensionar toda a aplicação. Para mais informações, consulte o artigo Promova o design modular no pilar de otimização do desempenho.

Implemente um design sem estado

Conceba aplicações sem estado, o que significa que não têm dados armazenados localmente. Isto permite-lhe adicionar ou remover instâncias sem se preocupar com a consistência dos dados.

Detete potenciais falhas através da observabilidade

Este princípio no pilar de fiabilidade da Google Cloud estrutura bem arquitetada fornece recomendações para ajudar a identificar proativamente áreas onde podem ocorrer erros e falhas.

Este princípio é relevante para a observação área de foco da fiabilidade.

Vista geral do princípio

Para manter e melhorar a fiabilidade das suas cargas de trabalho no Google Cloud, tem de implementar uma observabilidade eficaz através de métricas, registos e rastreios.

  • As métricas são medições numéricas de atividades que quer acompanhar para a sua aplicação em intervalos de tempo específicos. Por exemplo, pode querer acompanhar métricas técnicas, como a taxa de pedidos e a taxa de erros, que podem ser usadas como indicadores do nível de serviço (INSs). Também pode ter de acompanhar métricas empresariais específicas da aplicação, como encomendas feitas e pagamentos recebidos.
  • Os registos são registos com data/hora de eventos discretos que ocorrem numa aplicação ou num sistema. O evento pode ser uma falha, um erro ou uma alteração no estado. Os registos podem incluir métricas e também pode usar registos para SLIs.
  • Um rastreio representa o percurso de um único utilizador ou transação através de várias aplicações separadas ou dos componentes de uma aplicação. Por exemplo, estes componentes podem ser microsserviços. Os rastreios ajudam a acompanhar que componentes foram usados nos percursos, onde existem gargalos e quanto tempo demoraram os percursos.

As métricas, os registos e os rastreios ajudam a monitorizar o seu sistema continuamente. A monitorização abrangente ajuda a descobrir onde e por que motivo ocorreram erros. Também pode detetar potenciais falhas antes de ocorrerem erros.

Recomendações

Para detetar potenciais falhas de forma eficiente, considere as recomendações nas subsecções seguintes.

Aceda a estatísticas abrangentes

Para acompanhar as principais métricas, como os tempos de resposta e as taxas de erro, use o Cloud Monitoring e o Cloud Logging. Estas ferramentas também ajudam a garantir que as métricas cumprem consistentemente as necessidades da sua carga de trabalho.

Para tomar decisões orientadas por dados, analise as métricas de serviço predefinidas para compreender as dependências dos componentes e o respetivo impacto no desempenho geral da carga de trabalho.

Para personalizar a sua estratégia de monitorização, crie e publique as suas próprias métricas através do Google Cloud SDK.

Realize a resolução de problemas proativa

Implemente um processamento de erros robusto e ative o registo em todos os componentes das suas cargas de trabalho no Google Cloud. Ative registos como os registos de acesso ao Cloud Storage e os registos de fluxo de VPC.

Quando configurar o registo, tenha em atenção os custos associados. Para controlar os custos de registo, pode configurar filtros de exclusão nos sinks de registo para excluir determinados registos do armazenamento.

Otimize a utilização de recursos

Monitorize o consumo da CPU, as métricas de E/S de rede e as métricas de E/S de disco para detetar recursos com aprovisionamento insuficiente e excessivo em serviços como o GKE, o Compute Engine e o Dataproc. Para ver uma lista completa dos serviços suportados, consulte o artigo Vista geral do Cloud Monitoring.

Dê prioridade aos alertas

Para alertas, foque-se em métricas críticas, defina limites adequados para minimizar o cansaço de alertas e garanta respostas atempadas a problemas significativos. Esta abordagem segmentada permite-lhe manter proativamente a fiabilidade da carga de trabalho. Para mais informações, consulte a Vista geral dos alertas.

Crie a pensar na degradação suave

Este princípio no pilar de fiabilidade da Google Cloud estrutura bem arquitetada fornece recomendações para ajudar a conceber as suas Google Cloud cargas de trabalho para falharem graciosamente.

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

Vista geral do princípio

A degradação gradual é uma abordagem de design em que um sistema que regista uma carga elevada continua a funcionar, possivelmente com um desempenho ou uma precisão reduzidos. A degradação gradual garante a disponibilidade contínua do sistema e evita a falha completa, mesmo que o trabalho do sistema não seja o ideal. Quando a carga regressa a um nível gerível, o sistema retoma a funcionalidade completa.

Por exemplo, durante períodos de carga elevada, a Pesquisa Google dá prioridade aos resultados de páginas Web com uma classificação mais elevada, o que pode sacrificar alguma precisão. Quando a carga diminui, a Pesquisa Google volta a calcular os resultados da pesquisa.

Recomendações

Para criar os seus sistemas para uma diminuição dos níveis de serviço gradual, considere as recomendações nas seguintes subsecções.

Implemente a limitação

Certifique-se de que as suas réplicas conseguem processar sobrecargas de forma independente e podem limitar os pedidos recebidos durante cenários de tráfego elevado. Esta abordagem ajuda a evitar falhas em cascata causadas por mudanças no excesso de tráfego entre zonas.

Use ferramentas como o Apigee para controlar a taxa de pedidos de API durante períodos de tráfego elevado. Pode configurar regras de políticas para refletir a forma como quer reduzir os pedidos.

Rejeite pedidos excessivos antecipadamente

Configure os seus sistemas para rejeitar pedidos excessivos na camada de front-end para proteger os componentes de back-end. A rejeição de alguns pedidos impede falhas globais e permite que o sistema recupere de forma mais elegante.Com esta abordagem, alguns utilizadores podem ter erros. No entanto, pode minimizar o impacto das indisponibilidades, ao contrário de uma abordagem como a interrupção de circuito, em que todo o tráfego é eliminado durante uma sobrecarga.

Trate erros parciais e novas tentativas

Crie as suas aplicações para processarem erros parciais e novas tentativas sem problemas. Este design ajuda a garantir que o máximo de tráfego possível é publicado durante cenários de carga elevada.

Teste cenários de sobrecarga

Para validar se os mecanismos de limitação e de rejeição de pedidos funcionam eficazmente, simule regularmente condições de sobrecarga no seu sistema. Os testes ajudam a garantir que o seu sistema está preparado para picos de tráfego reais.

Monitorize picos de tráfego

Use ferramentas de estatísticas e monitorização para prever e responder a picos de tráfego antes que se transformem em sobrecargas. A deteção e a resposta antecipadas podem ajudar a manter a disponibilidade do serviço durante períodos de elevada procura.

Realize testes de recuperação de falhas

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.

Realize testes de recuperação de perda de dados

Este princípio no pilar de fiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar a conceber e executar testes de recuperação de perda de dados.

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

Vista geral do princípio

Para garantir que o seu sistema consegue recuperar de situações em que os dados são perdidos ou danificados, tem de executar testes para esses cenários. As instâncias de perda de dados podem ser causadas por um erro de software ou algum tipo de desastre natural. Após estes eventos, tem de restaurar os dados a partir de cópias de segurança e voltar a disponibilizar todos os serviços através dos dados restaurados recentemente.

Recomendamos que use três critérios para avaliar o sucesso ou o fracasso deste tipo de teste de recuperação: integridade dos dados, objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO). Para ver detalhes sobre as métricas RTO e RPO, consulte o artigo Noções básicas do planeamento de recuperação de desastres.

O objetivo dos testes de restauro de dados é verificar periodicamente se a sua organização consegue continuar a cumprir os requisitos de continuidade do negócio. Além de medir o OTR e o OPR, um teste de restauro de dados tem de incluir testes de toda a pilha de aplicações e todos os serviços de infraestrutura críticos com os dados restaurados. Isto é necessário para confirmar que toda a aplicação implementada funciona corretamente no ambiente de teste.

Recomendações

Quando conceber e executar testes para a recuperação de perdas de dados, considere as recomendações nas subsecções seguintes.

Valide a consistência da cópia de segurança e teste os processos de restauro

Tem de validar se as suas cópias de segurança contêm instantâneos consistentes e utilizáveis dos dados que pode restaurar para repor imediatamente as aplicações em serviço. Para validar a integridade dos dados, configure verificações de consistência automáticas para serem executadas após cada cópia de segurança.

Para testar as cópias de segurança, restaure-as num ambiente de não produção. Para garantir que as cópias de segurança podem ser restauradas de forma eficiente e que os dados restaurados cumprem os requisitos da aplicação, simule regularmente cenários de recuperação de dados. Documente os passos para o restauro de dados e forme as suas equipas para executarem os passos de forma eficaz durante uma falha.

Agende cópias de segurança regulares e frequentes

Para minimizar a perda de dados durante o restauro e cumprir os objetivos do RPO, é essencial ter cópias de segurança agendadas regularmente. Estabeleça uma frequência de cópia de segurança que se alinhe com o seu RPO. Por exemplo, se o RPO for de 15 minutos, agende cópias de segurança para serem executadas, pelo menos, a cada 15 minutos. Otimize os intervalos de cópia de segurança para reduzir o risco de perda de dados.

Use Google Cloud ferramentas como o Cloud Storage, as cópias de segurança automáticas do Cloud SQL ou as cópias de segurança do Spanner para agendar e gerir cópias de segurança. Para aplicações críticas, use soluções de cópia de segurança quase contínuas, como a recuperação num determinado momento (PITR) para o Cloud SQL ou cópias de segurança incrementais para grandes conjuntos de dados.

Defina e monitorize o RPO

Defina um RPO claro com base nas necessidades da sua empresa e monitorize a conformidade com o RPO. Se os intervalos de cópia de segurança excederem o RPO definido, use o Cloud Monitoring para configurar alertas.

Monitorize o estado da cópia de segurança

Use o Google Cloud serviço de cópia de segurança e recuperação de desastres ou ferramentas semelhantes para monitorizar o estado das suas cópias de segurança e confirmar que estão armazenadas em localizações seguras e fiáveis. Certifique-se de que as cópias de segurança são replicadas em várias regiões para maior resiliência.

Planeie cenários além da cópia de segurança

Combine as cópias de segurança com estratégias de recuperação de desastres, como configurações de comutação por falha ativa-ativa ou replicação entre regiões, para melhorar o tempo de recuperação em casos extremos. Para mais informações, consulte o Guia de planeamento de recuperação de desastres.

Realize investigações "postmortem" exaustivas

Este princípio no pilar de fiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar a realizar postmortems eficazes após falhas e incidentes.

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

Vista geral do princípio

Uma análise post mortem é um registo escrito de um incidente, do respetivo impacto, das ações tomadas para mitigar ou resolver o incidente, das causas principais e das ações de seguimento para impedir a recorrência do incidente. O objetivo de um post mortem é aprender com os erros e não atribuir culpas.

O diagrama seguinte mostra o fluxo de trabalho de uma análise post mortem:

O fluxo de trabalho de uma análise post mortem.

O fluxo de trabalho de uma análise post mortem inclui os seguintes passos:

  • Crie uma análise post mortem
  • Capture os factos
  • Identificar e analisar as causas principais
  • Planeie o futuro
  • Execute o plano

Realize análises "postmortem" após eventos importantes e eventos não importantes, como os seguintes:

  • Indisponibilidades ou degradações visíveis pelos utilizadores que excedam um determinado limite.
  • Perdas de dados de qualquer tipo.
  • Intervenções de engenheiros de serviço, como uma reversão de lançamento ou o reencaminhamento do tráfego.
  • Tempos de resolução acima de um limite definido.
  • Falhas de monitorização, que normalmente implicam a deteção manual de incidentes.

Recomendações

Defina critérios post mortem antes de ocorrer um incidente para que todos saibam quando é necessário um post mortem.

Para realizar postmortems eficazes, considere as recomendações nas seguintes subsecções.

Realize investigações "postmortem" sem culpa

As postmortems eficazes focam-se em processos, ferramentas e tecnologias, e não culpam indivíduos nem equipas. O objetivo de uma análise post mortem é melhorar a sua tecnologia e futuro, não encontrar o culpado. Todos cometem erros. O objetivo deve ser analisar os erros e aprender com eles.

Os exemplos seguintes mostram a diferença entre feedback que atribui culpas e feedback sem culpas:

  • Feedback que atribui culpas: "Temos de reescrever todo o sistema de back-end complicado! Tem sido interrompido semanalmente nos últimos três trimestres e tenho a certeza de que estamos todos cansados de corrigir as coisas aos poucos. A sério, se receber mais um aviso, vou reescrever o código eu próprio…"
  • Feedback sem culpa: "Um item de ação para reescrever todo o sistema de back-end pode, na verdade, impedir que estas páginas continuem a ocorrer. O manual de manutenção desta versão é bastante longo e é muito difícil receber formação completa sobre o mesmo. Tenho a certeza de que os nossos futuros engenheiros de serviço vão agradecer-nos!"

Tornar o relatório post mortem legível para todos os públicos-alvo pretendidos

Para cada informação que planeia incluir no relatório, avalie se essa informação é importante e necessária para ajudar o público a compreender o que aconteceu. Pode mover dados suplementares e explicações para um anexo do relatório. Os revisores que precisarem de mais informações podem solicitá-las.

Evite soluções complexas ou demasiado elaboradas

Antes de começar a explorar soluções para um problema, avalie a importância do problema e a probabilidade de recorrência. Adicionar complexidade ao sistema para resolver problemas que é improvável que ocorram novamente pode levar a uma maior instabilidade.

Partilhe a análise post mortem o mais amplamente possível

Para garantir que os problemas não permanecem por resolver, publique o resultado da análise post mortem para um público vasto e receba apoio técnico da gestão. O valor de uma análise post mortem é proporcional à aprendizagem que ocorre após a análise post mortem. Quando mais pessoas aprendem com os incidentes, a probabilidade de ocorrência de falhas semelhantes é reduzida.