Google Cloud Well-Architected Framework: confiabilidade

Last reviewed 2025-02-14 UTC

O pilar de confiabilidade no Google Cloud Framework de arquitetura bem estruturada oferece 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.

A confiabilidade é a capacidade de um sistema de executar consistentemente as funções desejadas 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 recursosGoogle 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:

  • Tempo de inatividade mínimo: o tempo de inatividade pode levar a perda de receita, menor produtividade e danos à reputação. Arquiteturas resilientes podem ajudar a garantir que os sistemas continuem funcionando durante falhas ou se recuperem de forma eficiente.
  • Experiência do usuário aprimorada: os usuários esperam interações perfeitas com a tecnologia. Sistemas resilientes podem ajudar a manter a performance e a disponibilidade consistentes e oferecem um serviço confiável mesmo durante alta demanda ou problemas inesperados.
  • Integridade dos dados: 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 de 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 oferece suporte a uma recuperação rápida.
  • Compliance: muitos setores têm requisitos regulamentares 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.
  • Menor custo a longo prazo: arquiteturas resilientes exigem investimento inicial, mas a resiliência pode ajudar a reduzir os custos ao longo do tempo, evitando tempos de inatividade caros, correções reativas e permitindo o uso de recursos mais eficiente.

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 com outras iniciativas.

Estabeleça 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). Até mesmo grupos focados em negócios, como marketing e vendas, podem influenciar a confiabilidade.

Todas as equipes precisam 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 regular de recursos do produto precisam ser priorizados e escalados de acordo.

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

Á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 deste 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 se interagem, como os dados e as ações fluem pelo sistema e o que pode dar errado. Identifique falhas, gargalos e riscos em potencial, o que ajuda você a tomar medidas para mitigar esses problemas.
  • Observação: para ajudar a evitar falhas do sistema, implemente observação e monitoramento abrangentes e contínuos. Com essa observação, você pode entender as tendências e identificar possíveis problemas de forma proativa.
  • Resposta: para reduzir o impacto das falhas, responda de forma adequada e se recupere de forma eficiente. As respostas automatizadas também podem ajudar a reduzir o impacto das falhas. Mesmo com planejamento e controles, as falhas ainda podem ocorrer.
  • Aprendizado: para evitar que falhas ocorram novamente, aprenda com cada experiência e tome as medidas adequadas.

Princípios básicos

As recomendações no pilar de confiabilidade do Framework de arquitetura bem estruturada são mapeadas para os seguintes princípios básicos:

Colaboradores

Autores:

Outros colaboradores:

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

Esse princípio no pilar de confiabilidade do Google Cloud Framework bem estruturado ajuda você a avaliar a experiência dos usuários e 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 os dados se relacionam diretamente aos impactos nos usuários. Por exemplo, você pode observar um uso alto da CPU, operações lentas do servidor ou até mesmo tarefas com falha. No entanto, se esses problemas não afetarem a experiência do usuário, eles não vão constituir uma interrupção.

Para medir a experiência do usuário, é preciso distinguir o comportamento interno do sistema dos problemas enfrentados pelo 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 app ou serviço de maneira consistente e eficaz.

Recomendações

Para ajudar 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 serviço, priorize as métricas que refletem a experiência real dos usuários. Por exemplo, meça a proporção de sucesso da consulta dos usuários, 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 de dados direta não for viável, mude o ponto de medição progressivamente para 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 possam afetar significativamente os usuários.

Analisar as jornadas dos usuários

Para entender como os usuários interagem com seu sistema, use ferramentas de rastreamento, como o Cloud Trace. Ao seguir a jornada do usuário pelo aplicativo, você pode encontrar gargalos e problemas de latência que podem prejudicar a experiência do usuário. O Cloud Trace captura dados de desempenho 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

Esse princípio no pilar de confiabilidade do Google Cloud Framework bem estruturado ajuda a definir metas de confiabilidade que sejam tecnicamente viáveis para suas cargas de trabalho em 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 que sejam confiáveis o suficiente para a satisfação do usuário. Pode parecer contra-intuitivo, 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 na inovação. Se os usuários já estão satisfeitos com o nível atual de serviço, os esforços para aumentar ainda mais a satisfação podem gerar um baixo retorno do investimento. Em vez disso, é melhor gastar recursos em outro lugar.

Você precisa determinar o nível de confiabilidade que deixa seus usuários satisfeitos e o ponto em que o custo das melhorias incrementais começa a ser maior que os benefícios. Ao determinar esse nível de confiabilidade suficiente, você pode alocar recursos de forma estratégica e se concentrar em recursos e melhorias que tragam 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

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

A diferença entre o tempo de atividade de 100% e a meta de 99,99% é a margem de falha. Essa lacuna é chamada de orçamento de erros. O orçamento de erro pode ajudar você a correr riscos e inovar, o que é fundamental para qualquer empresa se manter competitiva.

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

Equilíbrio entre confiabilidade e custo

Para determinar o nível de confiabilidade ideal do sistema, faça análises de custo-benefício completas.

Considere fatores como requisitos do sistema, as consequências de falhas e a tolerância de risco da sua organização para o aplicativo específico. Considere 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 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 com redundância de recursos

Esse princípio no pilar de confiabilidade do Google Cloud Framework bem arquitetado 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, você precisa projetar 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 ser 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 falha temporária, o sistema terá uma falha 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 em todos 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 falhas temporárias de zona ou região.

Para exemplos de arquiteturas de várias zonas e regiões, consulte Projetar uma infraestrutura confiável para suas cargas de trabalho no Google Cloud.

Detectar e resolver problemas rapidamente

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

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

Testar cenários de failover

Como um exercício de simulação, 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

Esse princípio no pilar de confiabilidade do Google Cloud Framework bem estruturado fornece recomendações para ajudar você a usar a escalabilidade horizontal. Ao usar a escalonabilidade horizontal, você pode garantir que as cargas de trabalho em Google Cloud possam ser escalonadas de forma eficiente e manter o desempenho.

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

Visão geral do princípio

Refazer a arquitetura do sistema para uma arquitetura horizontal. Para acomodar o crescimento do tráfego ou dos dados, adicione mais recursos. Também é possível remover recursos quando eles não estão em uso.

Para entender o valor da escala horizontal, considere as limitações da escala vertical.

Um cenário comum para 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ários. Eventualmente, o banco de dados atinge o limite de memória na máquina host e precisa ser atualizado. Talvez seja necessário repetir esse processo várias vezes. O problema é que há limites rígidos para o crescimento de um banco de dados. Os tamanhos de VM 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 sejam 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 no sistema que afeta todos os usuários. Evite pontos únicos de falha, conforme descrito em Criar sistemas de alta disponibilidade com redundância de recursos.

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

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

Recomendações

Para fazer a transição de uma arquitetura de VM única para uma arquitetura horizontal de várias máquinas, é necessário planejar com cuidado e usar as ferramentas certas. Para ajudar você a alcançar a escala 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 de instâncias gerenciadas (MIGs, na sigla em inglês) do Compute Engine, é possível adicionar ou remover VMs para dimensionar o aplicativo horizontalmente. Para aplicativos em contêineres, o Cloud Run é uma plataforma sem servidor que pode escalonar automaticamente os contêineres sem estado com base no tráfego recebido.

Promover o design modular

Componentes modulares e interfaces claras ajudam a dimensionar componentes individuais conforme necessário, em vez de dimensionar 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

Esse princípio no pilar de confiabilidade do Google Cloud Framework bem estruturado oferece recomendações para ajudar a identificar proativamente áreas em que erros e falhas podem ocorrer.

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

Visão geral do princípio

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

  • Métricas são medições numéricas de atividades que você quer acompanhar no seu app em intervalos de tempo específicos. Por exemplo, você pode rastrear métricas técnicas, como taxa de solicitações e taxa de erros, que podem ser usadas como indicadores de nível de serviço (SLIs). Talvez você também precise 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 no estado. Os registros podem incluir métricas, e você também pode usá-los para SLIs.
  • Um rastro 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 rastros ajudam a rastrear quais componentes foram usados nas jornadas, onde existem gargalos e quanto tempo elas levaram.

Métricas, registros e rastros ajudam a monitorar seu sistema continuamente. O monitoramento abrangente ajuda a descobrir onde e por que os erros ocorreram. Você também pode detectar falhas potenciais antes que os erros ocorram.

Recomendações

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

Receber insights completos

Para acompanhar as principais métricas, 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 do Google Cloud.

Resolver problemas de forma proativa

Implemente um tratamento de erros robusto e ative o registro em todos os componentes das cargas de trabalho em Google Cloud. Ative registros como os Registros de acesso do Cloud Storage e os Registros de fluxo de VPC.

Ao configurar o registro, considere os custos associados. Para controlar os custos de registro, configure filtros de exclusão nos coletores de registros para excluir o armazenamento de determinados registros.

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 Dataproc. Para uma lista completa de serviços com suporte, consulte a Visão geral do Cloud Monitoring.

Priorizar alertas

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

Projetar para degradação suave

Esse princípio no pilar de confiabilidade do Google Cloud Framework com boa arquitetura oferece recomendações para ajudar você a projetar as cargas de trabalho Google Cloud para falhar graciosamente.

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

Visão geral do princípio

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

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

Recomendações

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

Implementar limitação

Garanta que as réplicas possam lidar de forma independente com sobrecargas e limitar as solicitações recebidas durante cenários de tráfego intenso. 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íticas para refletir como você quer reduzir as solicitações.

Descartar solicitações em excesso antecipadamente

Configure seus sistemas para descartar solicitações em excesso na camada de front-end para proteger componentes de back-end. A exclusão de algumas solicitações evita falhas globais e permite que o sistema se recupere de forma mais suave.Com essa abordagem, alguns usuários podem encontrar erros. No entanto, é possível minimizar o impacto das falhas, em contraste com uma abordagem como a interrupção de circuito, em que todo o tráfego é interrompido durante uma sobrecarga.

Processar erros parciais e novas tentativas

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

Testar cenários de sobrecarga

Para validar se os mecanismos de limitação e de descarte de solicitações funcionam de maneira eficaz, simule regularmente as 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 precoces podem ajudar a manter a disponibilidade do serviço durante períodos de alta demanda.

Realizar testes de recuperação de falhas

Esse princípio no pilar de confiabilidade do Google Cloud Framework de arquitetura bem estruturada 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 da confiabilidade do aprendizado.

Visão geral do princípio

Para garantir que o sistema possa se recuperar de falhas, é necessário executar periodicamente testes que incluem failovers regionais, revisões de lançamento e restauração de dados de backups.

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

No caso improvável de uma região inteira falhar, você precisa 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 principal para a região de failover. É necessário verificar se os dados replicados são sempre muito recentes para que os usuários não tenham 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 no 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 maneira manual e eficiente, no menor tempo possível. Essa operação às vezes é chamada de drenar uma região, o que significa interromper o tráfego de entrada para a região e mover todo o tráfego para outro lugar.

Recomendações

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

Definir os objetivos e o escopo do teste

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

  • 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.
  • Teste a eficácia dos mecanismos de failover automáticos.

Decida quais componentes, serviços ou regiões estão no escopo do teste. O escopo pode incluir camadas de aplicativos específicas, como front-end, back-end e banco de dados, ou recursos Google Cloud específicos, 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 ambiente de preparo ou sandbox que replique a configuração de produção. Se você realizar o teste na produção, verifique se as medidas de segurança estão prontas, como monitoramento automatizado e procedimentos de reversão manual.

Crie um plano de backup. Faça snapshots ou backups de bancos de dados e serviços essenciais para evitar a perda de dados durante o teste. Garanta que sua equipe esteja preparada para fazer intervenções manuais caso os mecanismos de failover automático falhem.

Para evitar interrupções no teste, verifique se as funções, as políticas e as configurações de failover do IAM estão configuradas 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 a programação, 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 essenciais, como o desligamento de um nó principal em um cluster do GKE com várias zonas ou uma instância do Cloud SQL desativada. Também é possível usar scripts para simular uma interrupção de rede em toda a região com regras de firewall ou restrições de API com base no seu escopo de 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 real durante interrupções. Teste os impactos da falha 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 envolvem configurações incorretas. Por exemplo, execute testes com configurações de failover de DNS ou permissões do IAM incorretas.

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 taxa de transferência durante e após a simulação de falha e monitore o impacto geral na performance. Identifique qualquer degradação ou inconsistência na experiência do usuário.

Verifique se os registros são gerados e os alertas são acionados para eventos importantes, como falhas temporárias ou failovers. Use esses dados para verificar a eficácia dos sistemas de alerta e resposta a incidentes.

Verificar a recuperação com base no RTO e RPO

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

Confira se a integridade e a disponibilidade dos dados estão alinhadas ao RPO. Para testar a consistência do banco de dados, compare os 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 a menor interrupção possível para o usuário.

Documentar e analisar os 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.

Sugerir 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. Apresente um relatório post mortem às partes interessadas. O relatório precisa resumir os resultados, as lições aprendidas e as próximas etapas. Para mais informações, consulte Realizar análises pós-ocorrência detalhadas.

Iterar e melhorar

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 de 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 pós-ocorrência, use o feedback das partes interessadas e dos usuários finais para melhorar o processo de teste e a resiliência do sistema.

Realizar testes de recuperação de perda de dados

Esse princípio no pilar de confiabilidade do Google Cloud Framework de arquitetura bem estruturada 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 da confiabilidade do aprendizado.

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-restabelecidos.

Recomendamos que você use três critérios para avaliar o sucesso ou o fracasso desse tipo de teste de recuperação: integridade de dados, objetivo de tempo de recuperação (RTO, na sigla em inglês) e objetivo de ponto de recuperação (RPO, na sigla em inglês). Para mais 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 a atender aos requisitos de continuidade de negócios. Além de medir RTO e RPO, um teste de restauração de dados precisa incluir o teste de toda a pilha de aplicativos e todos os serviços de infraestrutura essenciais com os dados restaurados. Isso é necessário para confirmar que 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

É necessário 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 dos 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 maneira eficiente e que os dados restaurados atendam aos requisitos do aplicativo, simule regularmente cenários de recuperação de dados. Documente as etapas de 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 atender às 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 automáticos 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) do Cloud SQL ou backups incrementais para grandes conjuntos de dados.

Definir e monitorar a 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 monitorar a integridade dos seus 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 para 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.

Realizar análises post mortem completas

Esse princípio no pilar de confiabilidade do Google Cloud Framework bem estruturado fornece recomendações para ajudar você a realizar análises pós-fato eficazes após falhas e incidentes.

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

Visão geral do princípio

Uma análise post-mortem é um registro escrito de um incidente, do impacto dele, das ações tomadas para mitigá-lo ou resolvê-lo, das causas raiz e das ações de acompanhamento para evitar a recorrência do incidente. O objetivo de uma análise retrospectiva é aprender com os erros e não apontar culpados.

O diagrama a seguir mostra o fluxo de trabalho de uma análise pós-ocorrência:

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

O fluxo de trabalho de uma análise pós-ocorrência inclui as seguintes etapas:

  • Criar análise pós-ocorrência
  • Coletar os fatos
  • Identificar e analisar as causas raiz
  • Planejar para o futuro
  • Execute o plano.

Realize análises post-mortem após eventos importantes e não importantes, como estes:

  • Tempos de inatividade ou degradações visíveis para o usuário além de um determinado limite.
  • Perda de dados de qualquer tipo.
  • Intervenções de engenheiros de plantão, como uma reversão de lançamento ou redirecionamento do tráfego.
  • Tempos de resolução acima de um limite definido.
  • Monitorar falhas, o que geralmente implica a descoberta manual de incidentes.

Recomendações

Defina critérios de análise pós-incidente antes que um incidente ocorra para que todos saibam quando uma análise pós-incidente for necessária.

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

Realizar análises post-mortem sem culpa

As análises pós-ocorrência 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 é analisar os erros e aprender com eles.

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

  • Feedback que atribui culpa: "Precisamos reescrever todo o sistema de back-end complicado. Ela está quebrando semanalmente nos últimos três trimestres, e tenho certeza de que todos nós estamos cansados de consertar as coisas aos poucos. Sério, se eu receber mais uma chamada, vou reescrever o texto…"
  • Feedback sem culpar ninguém: "Uma ação para reescrever todo o sistema de back-end pode impedir que essas páginas continuem a acontecer. O manual de manutenção dessa versão é bastante longo e muito difícil de ser totalmente treinado. Tenho certeza de que nossos engenheiros de plantão vão agradecer."

Tornar o relatório pós-fato 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 apêndice do relatório. Os revisores que precisarem de mais informações podem solicitar.

Evite soluções complexas ou excessivamente elaboradas.

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

Compartilhe a análise post-mortem o máximo possível

Para garantir que os problemas não permaneçam sem solução, publique o resultado da análise post-mortem para um público amplo e receba suporte 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 incidentes, a probabilidade de falhas semelhantes recorrentes é reduzida.