Framework de arquitetura bem estruturada: pilar de confiabilidade

Last reviewed 2025-02-14 UTC

O pilar de confiabilidade no Google Cloud Well-Architected Framework fornece princípios e recomendações para ajudar você a projetar, implantar e gerenciar cargas de trabalho confiáveis no Google Cloud.

Este documento é destinado a arquitetos de nuvem, desenvolvedores, engenheiros de plataforma, administradores e engenheiros de confiabilidade do site.

Confiabilidade é a capacidade de um sistema de executar consistentemente as funções pretendidas dentro das condições definidas e manter o serviço ininterrupto. As práticas recomendadas para confiabilidade incluem redundância, design tolerante a falhas, monitoramento e processos de recuperação automatizados.

Como parte da confiabilidade, a resiliência é a capacidade do sistema de resistir e se recuperar de falhas ou interrupções inesperadas, mantendo o desempenho. Os recursos doGoogle Cloud , como implantações multirregionais, backups automatizados e soluções de recuperação de desastres, podem ajudar a melhorar a resiliência do sistema.

A confiabilidade é importante para 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 à reputação. As arquiteturas resilientes podem ajudar a garantir que os sistemas continuem funcionando durante falhas ou se recuperem com eficiência.
  • Experiência do usuário aprimorada: os usuários esperam interações perfeitas com a tecnologia. Sistemas resilientes podem ajudar a manter o desempenho e a disponibilidade consistentes, além de fornecer um serviço confiável mesmo durante alta demanda ou problemas inesperados.
  • Integridade de dados: as falhas podem causar perda ou corrupção de dados. Sistemas resilientes implementam mecanismos como backups, redundância e replicação para proteger os dados e garantir que eles permaneçam precisos e acessíveis.
  • Continuidade dos negócios: 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 de negócios continuem sem interrupções significativas e ajuda em uma recuperação rápida.
  • Conformidade: muitos setores têm requisitos regulatórios para disponibilidade do sistema e proteção de dados. As arquiteturas resilientes podem ajudar você a atender a esses padrões, garantindo que os sistemas permaneçam operacionais e seguros.
  • Custos mais baixos a longo prazo: arquiteturas resilientes exigem investimento inicial, mas a resiliência pode ajudar a reduzir custos ao longo do tempo, evitando inatividades caras, correções reativas e permitindo um uso mais eficiente de recursos.

Mentalidade organizacional

Para tornar seus sistemas confiáveis, você precisa de um plano e de uma estratégia estabelecida. Essa estratégia precisa incluir educação e autoridade para priorizar a confiabilidade junto com outras iniciativas.

Defina uma expectativa clara de que toda a organização é responsável pela confiabilidade, incluindo desenvolvimento, gerenciamento de produtos, operações, engenharia de plataforma e engenharia de confiabilidade do site (SRE, na sigla em inglês). Até mesmo os grupos focados em negócios, como marketing e vendas, podem influenciar a confiabilidade.

Cada equipe precisa entender as metas de confiabilidade e os riscos dos aplicativos. As equipes precisam ser responsáveis por esses requisitos. Os conflitos entre confiabilidade e desenvolvimento de recursos do produto devem ser priorizados e escalados de acordo.

Planeje e gerencie a confiabilidade de maneira holística em todas as funções e equipes. Considere configurar um Centro de Excelência em Nuvem (CCoE, na sigla em inglês) que inclua um pilar de confiabilidade. Para mais informações, consulte Otimize a jornada na nuvem da sua organização com um Centro de Excelência do Cloud.

Áreas de foco para confiabilidade

As atividades que você realiza para projetar, implantar e gerenciar um sistema confiável podem ser categorizadas nas seguintes áreas de foco. Cada um dos princípios e recomendações de confiabilidade neste pilar é relevante para uma dessas áreas de foco.

  • Escopo: para entender seu sistema, faça uma análise detalhada da arquitetura dele. Você precisa entender os componentes, como eles funcionam e interagem, como os dados e as ações fluem pelo sistema e o que pode dar errado. Identifique possíveis falhas, gargalos e riscos, o que ajuda você a entrar em ação para mitigar esses problemas.
  • Observação: para ajudar a evitar falhas no sistema, implemente observação e monitoramento abrangentes e contínuos. Com essa observação, é possível entender tendências e identificar possíveis problemas de forma proativa.
  • Resposta: para reduzir o impacto das falhas, responda adequadamente e se recupere com eficiência. As respostas automatizadas também podem ajudar a reduzir o impacto das falhas. Mesmo com planejamento e controles, ainda podem ocorrer falhas.
  • Aprendizado: para evitar que as falhas recorrentes, aprenda com cada experiência e tome as medidas adequadas.

Avaliar cargas de trabalho usando uma habilidade de agente

Para permitir que os agentes de IA avaliem suas cargas de trabalho na nuvem de acordo com os princípios e as recomendações deste pilar, use a habilidade google-cloud-waf-reliability, disponível no repositório de habilidades de agentes do Google no GitHub.

Para instalar a habilidade, execute o seguinte comando no cliente ou terminal do agente:

npx skills add google/skills --skill google-cloud-waf-reliability

Quando solicitado, especifique os agentes de IA em que você quer instalar a habilidade e defina o escopo da instalação (projeto ou global).

Se você já instalou a habilidade, atualize-a para a versão mais recente executando o seguinte comando:

npx skills update

Princípios básicos

As recomendações no pilar de confiabilidade do Well-Architected Framework estão mapeadas para os seguintes princípios básicos:

Colaboradores

Autores:

Outros colaboradores:

Definir a confiabilidade com base em metas de experiência do usuário

Esse princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework ajuda a avaliar a experiência dos usuários e, em seguida, mapear as descobertas para metas e métricas de confiabilidade.

Esse princípio é relevante para a área de foco de escopo da confiabilidade.

Visão geral do princípio

As ferramentas de observabilidade fornecem grandes quantidades de dados, mas nem todos eles estão diretamente relacionados aos impactos nos usuários. Por exemplo, você pode observar um alto uso da CPU, operações lentas do servidor ou até mesmo tarefas travadas. No entanto, se esses problemas não afetarem a experiência do usuário, eles não constituem uma interrupção.

Para medir a experiência do usuário, é preciso distinguir entre o comportamento interno do sistema e os problemas voltados ao usuário. Concentre-se em métricas como a proporção de sucesso das solicitações do usuário. Não confie apenas em métricas centradas no servidor, como o uso da CPU, que podem levar a conclusões enganosas sobre a confiabilidade do serviço. A confiabilidade verdadeira significa que os usuários podem usar seu aplicativo ou serviço de forma consistente e eficaz.

Recomendações

Para ajudar você a medir a experiência do usuário de maneira eficaz, considere as recomendações nas seções a seguir.

Medir a experiência do usuário

Para entender de verdade a confiabilidade do seu serviço, priorize métricas que reflitam a experiência real dos usuários. Por exemplo, meça a proporção de consultas bem-sucedidas, a latência do aplicativo e as taxas de erro.

O ideal é coletar esses dados diretamente do dispositivo ou navegador do usuário. Se essa coleta direta de dados não for viável, mude o ponto de medição progressivamente para mais longe do usuário no sistema. Por exemplo, é possível usar o balanceador de carga ou o serviço de front-end como o ponto de medição. Essa abordagem ajuda a identificar e resolver problemas antes que eles afetem significativamente os usuários.

Analisar as jornadas do usuário

Para entender como os usuários interagem com seu sistema, use ferramentas de rastreamento, como o Cloud Trace. Ao acompanhar a jornada de um usuário pelo aplicativo, é possível encontrar gargalos e problemas de latência que podem prejudicar a experiência do usuário. O Cloud Trace captura dados de performance detalhados para cada salto na arquitetura do serviço. Esses dados ajudam a identificar e resolver problemas de desempenho com mais eficiência, o que pode levar a uma experiência do usuário mais confiável e satisfatória.

Definir metas realistas de confiabilidade

Este princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework ajuda a definir metas de confiabilidade que são tecnicamente viáveis para suas cargas de trabalho no Google Cloud.

Esse princípio é relevante para a área de foco de escopo da confiabilidade.

Visão geral do princípio

Projete seus sistemas para serem confiáveis o suficiente para a satisfação do usuário. Pode parecer contraditório, mas uma meta de 100% de confiabilidade geralmente não é a estratégia mais eficaz. Uma confiabilidade maior pode resultar em um custo significativamente maior, tanto em termos de investimento financeiro quanto de possíveis limitações à inovação. Se os usuários 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 vez disso, você pode usar melhor os recursos em outro lugar.

É preciso determinar o nível de confiabilidade em que os usuários ficam satisfeitos e o ponto em que o custo das melhorias incrementais começa a superar os benefícios. Ao determinar esse nível de confiabilidade suficiente, é possível alocar recursos estrategicamente e se concentrar em recursos e melhorias que agregam mais valor aos usuários.

Recomendações

Para definir metas de confiabilidade realistas, considere as recomendações nas subseções a seguir.

Aceitar algumas falhas e priorizar componentes

Busque uma alta disponibilidade, como 99,99% de tempo de atividade, mas não defina uma meta de 100% de tempo de atividade. 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 margem de erro. Essa lacuna é chamada de margem de erro. A margem de erro pode ajudar você a assumir riscos e inovar, o que é fundamental para que qualquer empresa se mantenha competitiva.

Priorize a confiabilidade dos componentes mais críticos do sistema. Aceite que componentes menos críticos podem ter uma tolerância maior a falhas.

Equilibrar confiabilidade e custo

Para determinar o nível de confiabilidade ideal para seu sistema, realize análises completas de custo-benefício.

Considere fatores como requisitos do sistema, as consequências de falhas e a tolerância a riscos da sua organização para o aplicativo específico. Lembre-se de considerar as métricas de recuperação de desastres, como o objetivo do tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO). Decida qual nível de confiabilidade é aceitável dentro do orçamento e de outras restrições.

Procure maneiras de melhorar a eficiência e reduzir custos sem comprometer os recursos essenciais de confiabilidade.

Criar sistemas altamente disponíveis usando a redundância de recursos

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

Esse princípio é relevante para a área de foco de escopo da confiabilidade.

Visão geral do princípio

Depois de decidir o nível de confiabilidade necessário, projete seus sistemas para evitar pontos únicos de falha. Todos os componentes críticos do sistema precisam ser replicados em várias máquinas, zonas e regiões. Por exemplo, um banco de dados crítico não pode estar localizado em apenas uma região, e um servidor de metadados não pode ser implantado em apenas uma zona ou região. Nesses exemplos, se a única zona ou região tiver uma interrupção, o sistema terá uma interrupção global.

Recomendações

Para criar sistemas redundantes, considere as recomendações nas subseções a seguir.

Identificar domínios de falha e replicar serviços

Mapeie os domínios de falha do seu sistema, de VMs individuais a regiões, e projete para redundância entre os domínios de falha.

Para garantir alta disponibilidade, distribua e replique seus serviços e aplicativos em várias zonas e regiões. Configure o sistema para failover automático para garantir que os serviços e aplicativos continuem disponíveis em caso de interrupções na zona ou na região.

Para exemplos de arquiteturas multizona e multirregional, consulte Projetar uma infraestrutura confiável para suas cargas de trabalho no Google Cloud.

Detectar e resolver problemas rapidamente

Monitore continuamente o status dos domínios de falha para detectar e resolver problemas imediatamente.

É possível monitorar o status atual dos serviços do Google Cloud em todas as regiões usando o painel do Service Health doGoogle Cloud . Também é possível visualizar incidentes relevantes para seu projeto usando o Personalized Service Health. É possível usar balanceadores de carga para detectar a integridade dos recursos e rotear automaticamente o tráfego para back-ends íntegros. Para saber mais, consulte Visão geral das verificações de integridade.

Testar cenários de failover

Assim como em um exercício de incêndio, simule falhas regularmente para validar a eficácia das estratégias de replicação e failover.

Para mais informações, consulte Simular uma interrupção de zona em um MIG regional e Simular uma falha de zona em clusters regionais do GKE.

Aproveitar a escalonabilidade horizontal

Este princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar você a usar a escalonabilidade horizontal. Ao usar a escalonabilidade horizontal, você ajuda a garantir que as cargas de trabalho no Google Cloud possam ser escalonadas de maneira eficiente e manter o desempenho.

Esse princípio é relevante para a área de foco de escopo da confiabilidade.

Visão geral do princípio

Reestruturar o sistema para uma arquitetura horizontal. Para acomodar o crescimento no tráfego ou nos dados, é possível adicionar mais recursos. Também é possível remover recursos quando eles não estiverem em uso.

Para entender o valor do escalonamento horizontal, considere as limitações do escalonamento vertical.

Um cenário comum para o escalonamento vertical é usar um banco de dados MySQL como o banco de dados principal com dados críticos. À medida que o uso do banco de dados aumenta, mais RAM e CPU são necessárias. Por fim, o banco de dados atinge o limite de memória na máquina host e precisa ser atualizado. Esse processo precisa ser repetido várias vezes. O problema é que há limites rígidos para o crescimento de um banco de dados. Os tamanhos das VMs não são ilimitados. O banco de dados pode chegar a um ponto em que não é mais possível adicionar mais recursos.

Mesmo que os recursos fossem ilimitados, uma VM grande pode se tornar um ponto único de falha. Qualquer problema com a VM do banco de dados principal pode causar respostas de erro ou uma interrupção em todo o sistema que afeta todos os usuários. Evite pontos únicos de falha, conforme descrito em Criar sistemas altamente disponíveis usando a redundância de recursos.

Além desses limites, o escalonamento vertical costuma ser mais caro. O custo pode aumentar exponencialmente à medida que máquinas com maior capacidade de computação e memória são adquiridas.

Por outro lado, o escalonamento horizontal pode custar menos. O potencial de escalonamento horizontal é praticamente ilimitado em um sistema projetado para escalonamento.

Recomendações

Para fazer a transição de uma arquitetura de VM única para uma arquitetura horizontal de várias máquinas, é preciso planejar com cuidado e usar as ferramentas certas. Para ajudar você a alcançar o escalonamento horizontal, considere as recomendações nas subseções a seguir.

Usar serviços gerenciados

Os serviços gerenciados eliminam a necessidade de gerenciar manualmente o escalonamento horizontal. Por exemplo, com os grupos gerenciados de instâncias (MIGs) do Compute Engine, é possível adicionar ou remover VMs para escalonar o aplicativo horizontalmente. Para aplicativos conteinerizados, o Cloud Run é uma plataforma sem servidor que pode escalonar automaticamente seus contêineres sem estado com base no tráfego de entrada.

Promover o design modular

Componentes modulares e interfaces claras ajudam a escalonar componentes individuais conforme necessário, em vez de escalonar todo o aplicativo. Para mais informações, consulte Promover o design modular no pilar de otimização de desempenho.

Implementar um design sem estado

Projete aplicativos sem estado, ou seja, sem dados armazenados localmente. Isso permite adicionar ou remover instâncias sem se preocupar com a consistência dos dados.

Detectar possíveis falhas usando a observabilidade

Este princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar você a identificar proativamente áreas em que erros e falhas podem ocorrer.

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

Visão geral do princípio

Para manter e melhorar a confiabilidade das cargas de trabalho no Google Cloud, é preciso implementar uma observabilidade eficaz usando métricas, registros e traces.

  • As métricas são medições numéricas de atividades que você quer acompanhar no aplicativo em intervalos de tempo específicos. Por exemplo, talvez você queira acompanhar métricas técnicas, como taxa de solicitação e taxa de erro, que podem ser usadas como indicadores de nível de serviço (SLIs). Também pode ser necessário acompanhar métricas de negócios específicas do aplicativo, como pedidos feitos e pagamentos recebidos.
  • Os registros são registros com carimbo de data/hora de eventos discretos que ocorrem em um aplicativo ou sistema. O evento pode ser uma falha, um erro ou uma mudança de estado. Os registros podem incluir métricas, e você também pode usá-los para SLIs.
  • Um trace representa a jornada de um único usuário ou transação por vários aplicativos separados ou pelos componentes de um aplicativo. Por exemplo, esses componentes podem ser microsserviços. Os traces ajudam a rastrear quais componentes foram usados nas jornadas, onde existem gargalos e quanto tempo as jornadas levaram.

Métricas, registros e traces ajudam a monitorar o sistema continuamente. O monitoramento abrangente ajuda a descobrir onde e por que os erros ocorreram. Também é possível detectar possíveis falhas antes que os erros ocorram.

Recomendações

Para detectar possíveis falhas de maneira eficiente, considere as recomendações nas subseções a seguir.

Receba insights abrangentes

Para acompanhar métricas essenciais, como tempos de resposta e taxas de erros, use o Cloud Monitoring e o Cloud Logging. Essas ferramentas também ajudam a garantir que as métricas atendam de forma consistente às necessidades da sua carga de trabalho.

Para tomar decisões baseadas em dados, analise as métricas de serviço padrão para entender as dependências de componentes e o impacto delas no desempenho geral da carga de trabalho.

Para personalizar sua estratégia de monitoramento, crie e publique suas próprias métricas usando o SDK Google Cloud.

Realizar solução de problemas proativa

Implemente um tratamento de erros robusto e ative a geração de registros em todos os componentes das suas cargas de trabalho no Google Cloud. Ative registros como os registros de acesso do Cloud Storage e os registros de fluxo de VPC.

Ao configurar a geração de registros, considere os custos associados. Para controlar os custos de geração de registros, configure filtros de exclusão nos coletores de registros para impedir que determinados registros sejam armazenados.

Otimizar a utilização de recursos

Monitore o consumo de CPU, as métricas de E/S de rede e as métricas de E/S de disco para detectar recursos subprovisionados e superprovisionados em serviços como GKE, Compute Engine e Serviço Gerenciado para Apache Spark. Para uma lista completa dos serviços compatíveis, consulte Visão geral do Cloud Monitoring.

Priorize alertas

Para alertas, concentre-se em métricas críticas, defina limites adequados para minimizar a sobrecarga de alertas e garanta respostas rápidas a problemas significativos. Essa abordagem direcionada permite manter proativamente a confiabilidade da carga de trabalho. Para mais informações, consulte Visão geral de alertas.

Projetar para degradação suave

Este princípio no pilar de confiabilidade do Google Cloud Framework de arquitetura do Google Cloud fornece recomendações para ajudar você a projetar suas cargas de trabalho do Google Cloud para falhar de maneira controlada.

Esse princípio é relevante para a área de foco de resposta da confiabilidade.

Visão geral do princípio

A degradação gradual é uma abordagem de design em que um sistema que passa por uma carga alta continua funcionando, possivelmente com desempenho ou precisão reduzidos. A degradação gradual garante a disponibilidade contínua do sistema e evita falhas completas, mesmo que o trabalho do sistema não seja ideal. Quando a carga volta a um nível gerenciável, o sistema retoma a funcionalidade completa.

Por exemplo, durante períodos de alta carga, a Pesquisa Google prioriza resultados de páginas da Web com classificação mais alta, o que pode sacrificar um pouco a precisão. Quando a carga diminui, a Pesquisa Google recalcula os resultados da pesquisa.

Recomendações

Para projetar seus sistemas para degradação gradual, considere as recomendações nas subseções a seguir.

Implementar limitação

Verifique se as réplicas podem lidar de forma independente com sobrecargas e limitar as solicitações recebidas durante cenários de alto tráfego. Essa abordagem ajuda a evitar falhas em cascata causadas por mudanças no excesso de tráfego entre zonas.

Use ferramentas como a Apigee para controlar a taxa de solicitações de API durante períodos de tráfego intenso. É possível configurar regras de política para refletir como você quer reduzir as solicitações.

Descartar solicitações em excesso com antecedência

Configure seus sistemas para rejeitar solicitações em excesso na camada de front-end, protegendo os componentes de back-end. A eliminação de algumas solicitações evita falhas globais e permite que o sistema se recupere de maneira mais tranquila.Com essa abordagem, alguns usuários podem enfrentar erros. No entanto, é possível minimizar o impacto das interrupções, ao contrário de uma abordagem como a interrupção de circuito, em que todo o tráfego é descartado durante uma sobrecarga.

Tratar erros parciais e novas tentativas

Crie aplicativos para lidar com erros parciais e novas tentativas de maneira integrada. Esse design ajuda a garantir que o máximo de tráfego possível seja atendido durante cenários de alta carga.

Testar cenários de sobrecarga

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

Monitorar picos de tráfego

Use ferramentas de análise e monitoramento para prever e responder a picos de tráfego antes que eles se transformem em sobrecargas. A detecção e a resposta antecipadas podem ajudar a manter a disponibilidade do serviço durante períodos de alta demanda.

Realização de testes de recuperação de falhas

Este princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar você a projetar e executar testes de recuperação em caso de falhas.

Esse princípio é relevante para a área de foco de aprendizado da confiabilidade.

Visão geral do princípio

Para garantir que o sistema possa se recuperar de falhas, é preciso executar testes periódicos que incluam failovers regionais, reversões de versões e restauração de dados de backups.

Esse teste ajuda você a praticar respostas a eventos que representam grandes riscos à confiabilidade, como a interrupção de uma região inteira. Esse teste também ajuda a verificar se o sistema se comporta como esperado durante uma interrupção.

No caso improvável de uma região inteira ficar inativa, é necessário fazer o failover de todo o tráfego para outra região. Durante a operação normal da carga de trabalho, quando os dados são modificados, eles precisam ser sincronizados da região primária para a região de failover. É preciso verificar se os dados replicados são sempre muito recentes para que os usuários não sofram perda de dados ou interrupção da sessão. O sistema de balanceamento de carga também precisa ser capaz de transferir o tráfego para a região de failover a qualquer momento, sem interrupções de serviço. Para minimizar o tempo de inatividade após uma interrupção regional, os engenheiros de operações também precisam ser capazes de desviar o tráfego de usuários de uma região de forma manual e eficiente, no menor tempo possível. Essa operação às vezes é chamada de drenagem de uma região, o que significa que você interrompe o tráfego de entrada para a região e move todo o tráfego para outro lugar.

Recomendações

Ao projetar e executar testes para recuperação de falhas, considere as recomendações nas subseções a seguir.

Defina os objetivos e o escopo do teste

Defina claramente o que você quer alcançar com o teste. Por exemplo, seus objetivos podem incluir o seguinte:

  • Valide o objetivo do tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO). Para mais detalhes, consulte Noções básicas de planejamento de DR.
  • Avalie a resiliência do sistema e a tolerância a falhas em vários cenários de falha.
  • Testar a eficácia dos mecanismos de failover automatizados.

Decida quais componentes, serviços ou regiões estão no escopo do teste. O escopo pode incluir níveis de aplicativo específicos, como front-end, back-end e banco de dados, ou recursos específicos do Google Cloud , como instâncias do Cloud SQL ou clusters do GKE. O escopo também precisa especificar todas as dependências externas, como APIs de terceiros ou interconexões de nuvem.

Preparar o ambiente para testes

Escolha um ambiente adequado, de preferência um de preparo ou sandbox que replique sua configuração de produção. Se você realizar o teste em produção, garanta que as medidas de segurança estejam prontas, como monitoramento automatizado e procedimentos manuais de reversão.

Criar um plano de backup. Tire snapshots ou faça backups de bancos de dados e serviços críticos para evitar a perda de dados durante o teste. Verifique se a equipe está preparada para fazer intervenções manuais se os mecanismos de failover automatizados falharem.

Para evitar interrupções nos testes, verifique se os papéis do IAM, as políticas e as configurações de failover estão configurados corretamente. Verifique se as permissões necessárias estão em vigor para as ferramentas e os scripts de teste.

Informe as partes interessadas, incluindo operações, DevOps e proprietários de aplicativos, sobre o cronograma, o escopo e o possível impacto do teste. Forneça às partes interessadas um cronograma estimado e os comportamentos esperados durante o teste.

Simular cenários de falha

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

Introduza testes de carga com cenários de falha para replicar o uso 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 mudanças 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 configurações incorretas de failover de DNS ou permissões incorretas do IAM.

Monitorar o comportamento do sistema

Monitore como os balanceadores de carga, as verificações de integridade e outros mecanismos redirecionam 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 mudanças na latência, nas taxas de erro e na capacidade de processamento durante e após a simulação de falha e monitore o impacto geral no desempenho. Identifique qualquer degradação ou inconsistência na experiência do usuário.

Verifique se os registros são gerados e se os alertas são acionados para eventos importantes, como interrupções de serviço ou failovers. Use esses dados para verificar a eficácia dos seus sistemas de alerta e resposta a incidentes.

Verificar a recuperação em relação ao RTO e ao RPO

Meça quanto tempo o sistema leva para retomar as operações normais após uma falha, compare esses dados com o RTO definido e documente as lacunas.

Garantir que a integridade de dados e a disponibilidade estejam alinhadas com o RPO. Para testar a consistência do banco de dados, compare snapshots ou backups do banco de dados antes e depois de uma falha.

Avalie a restauração do serviço e confirme se todos os serviços foram restaurados para um estado funcional com o mínimo de interrupção para o usuário.

Documentar e analisar resultados

Documente cada etapa do teste, cenário de falha e comportamento do sistema correspondente. Inclua carimbos de data/hora, registros e métricas para análises detalhadas.

Destaque gargalos, pontos únicos de falha ou comportamentos inesperados observados durante o teste. Para priorizar as correções, categorize os problemas por gravidade e impacto.

Sugira melhorias na arquitetura do sistema, nos mecanismos de failover ou nas configurações de monitoramento. Com base nas descobertas do teste, atualize as políticas de failover e os playbooks relevantes. Apresentar um relatório de post mortem às partes interessadas. O relatório deve resumir os resultados, as lições aprendidas e as próximas etapas. Para mais informações, consulte Realizar post-mortems completos.

Faça iterações e melhore

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

Execute testes em diferentes cenários, incluindo mudanças na infraestrutura, atualizações de software e aumento de cargas de tráfego.

Automatize os testes de failover usando pipelines de CI/CD para integrar testes de confiabilidade ao ciclo de vida de desenvolvimento.

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

Realização de testes para recuperação em caso de perda de dados

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

Esse princípio é relevante para a área de foco de aprendizado da confiabilidade.

Visão geral do princípio

Para garantir que o sistema possa se recuperar de situações em que os dados são perdidos ou corrompidos, é necessário executar testes para esses cenários. As instâncias de perda de dados podem ser causadas por um bug de software ou algum tipo de desastre natural. Depois desses eventos, é necessário restaurar os dados dos backups e reativar todos os serviços usando os dados recém-restaurados.

Recomendamos que você use três critérios para avaliar o sucesso ou a falha desse tipo de teste de recuperação: integridade de dados, objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO). Para detalhes sobre as métricas de RTO e RPO, consulte Noções básicas do planejamento de DR.

O objetivo do teste de restauração de dados é verificar periodicamente se a organização pode continuar atendendo aos requisitos de continuidade de negócios. Além de medir o RTO e o RPO, um teste de restauração de dados precisa incluir testes de toda a pilha de aplicativos e de todos os serviços de infraestrutura crítica com os dados restaurados. Isso é necessário para confirmar se todo o aplicativo implantado funciona corretamente no ambiente de teste.

Recomendações

Ao projetar e executar testes para recuperação de perda de dados, considere as recomendações nas subseções a seguir.

Verificar a consistência do backup e testar os processos de restauração

É preciso verificar se os backups contêm snapshots consistentes e utilizáveis de dados que podem ser restaurados para colocar os aplicativos de volta em serviço imediatamente. Para validar a integridade de dados, configure verificações de consistência automatizadas para serem executadas após cada backup.

Para testar os backups, restaure-os em um ambiente que não seja de produção. Para garantir que os backups possam ser restaurados de forma eficiente e que os dados restaurados atendam aos requisitos do aplicativo, simule regularmente cenários de recuperação de dados. Documente as etapas para restauração de dados e treine suas equipes para executar as etapas de maneira eficaz durante uma falha.

Programar backups regulares e frequentes

Para minimizar a perda de dados durante a restauração e atingir as metas de RPO, é essencial ter backups programados regularmente. Estabeleça uma frequência de backup que se alinhe ao seu RPO. Por exemplo, se o RPO for de 15 minutos, programe os backups para serem executados pelo menos a cada 15 minutos. Otimize os intervalos de backup para reduzir o risco de perda de dados.

Use Google Cloud ferramentas como o Cloud Storage, os backups automatizados do Cloud SQL ou os backups do Spanner para programar e gerenciar backups. Para aplicativos críticos, use soluções de backup quase contínuas, como a recuperação pontual (PITR) para o Cloud SQL ou backups incrementais para grandes conjuntos de dados.

Definir e monitorar o RPO

Defina um RPO claro com base nas necessidades da sua empresa e monitore a adesão a ele. Se os intervalos de backup excederem o RPO definido, use o Cloud Monitoring para configurar alertas.

Monitorar a integridade do backup

Use o Google Cloud serviço de backup e DR ou ferramentas semelhantes para acompanhar a integridade dos backups e confirmar se eles estão armazenados em locais seguros e confiáveis. Verifique se os backups são replicados em várias regiões para maior resiliência.

Planejar cenários além do backup

Combine backups com estratégias de recuperação de desastres, como configurações de failover ativo-ativo ou replicação entre regiões, para melhorar o tempo de recuperação em casos extremos. Para mais informações, consulte o Guia de planejamento de recuperação de desastres.

Realização de análises posteriores aos incidentes detalhadas

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

Esse princípio é relevante para a área de foco de aprendizado da confiabilidade.

Visão geral do princípio

Uma análise post-mortem é um registro escrito de um incidente, o impacto dele, as ações tomadas para mitigar ou resolver o incidente, as causas raiz e as ações de acompanhamento para evitar que o incidente ocorra novamente. O objetivo de uma análise post-mortem é aprender com os erros, não atribuir culpa.

O diagrama a seguir mostra o fluxo de trabalho de uma análise:

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

O fluxo de trabalho de uma análise inclui as seguintes etapas:

  • Criar post-mortem
  • Capturar os fatos
  • Identificar e analisar as causas raiz
  • Planejar pensando no futuro
  • Execute o plano.

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

  • Inatividades ou degradações visíveis para o usuário além de um determinado limite.
  • Perdas de dados de qualquer tipo.
  • Intervenções de engenheiros de plantão, como uma reversão de versão ou redirecionamento de tráfego.
  • Tempos de resolução acima de um limite definido.
  • Falhas de monitoramento, que geralmente implicam na descoberta manual de incidentes.

Recomendações

Defina os critérios de análise post-mortem antes que um incidente ocorra para que todos saibam quando uma análise post-mortem é necessária.

Para realizar análises post-mortem eficazes, considere as recomendações nas subseções a seguir.

Realizar análises post-mortem sem apontar culpados

As análises post-mortem eficazes se concentram em processos, ferramentas e tecnologias, e não culpam indivíduos ou equipes. O objetivo de uma análise post-mortem é melhorar sua tecnologia e o futuro, não encontrar quem é culpado. Todo mundo comete erros. O objetivo deve ser analisar os erros e aprender com eles.

Os exemplos a seguir mostram a diferença entre o feedback que atribui culpa e o feedback sem culpa:

  • Feedback que atribui culpa: "Precisamos reescrever todo o sistema de back-end complicado! Ele tem quebrado semanalmente nos últimos três trimestres, e tenho certeza de que todos estamos cansados de consertar as coisas aos poucos. Sério, se eu receber mais um alerta, vou reescrever o código…"
  • Feedback sem culpa: "Uma ação necessária para reescrever todo o sistema de back-end pode impedir que essas páginas continuem acontecendo. O manual de manutenção dessa versão é muito longo e é difícil treinar as pessoas para usá-lo. Tenho certeza de que nossos futuros engenheiros de plantão vão nos agradecer!"

O relatório de análise precisa ser legível para todos os públicos-alvo.

Para cada informação que você planeja incluir no relatório, avalie se ela é importante e necessária para ajudar o público a entender o que aconteceu. Você pode mover dados e explicações complementares para um anexo do relatório. Os revisores que precisarem de mais informações podem solicitá-las.

Evite soluções complexas ou excessivamente projetadas

Antes de começar a buscar soluções para um problema, avalie a importância dele e a probabilidade de recorrência. Adicionar complexidade ao sistema para resolver problemas que provavelmente não vão ocorrer novamente pode aumentar a instabilidade.

Compartilhar a análise post-mortem da maneira mais ampla possível

Para garantir que os problemas não fiquem sem solução, publique o resultado da análise para um público amplo e receba o apoio da gerência. O valor de uma análise post-mortem é proporcional ao aprendizado que ocorre após a análise. Quando mais pessoas aprendem com os incidentes, a probabilidade de falhas semelhantes recorrentes é reduzida.