Framework de arquitetura bem estruturada: pilar de confiabilidade

O pilar da confiabilidade do Google Cloud framework bem arquitetado (em inglês) apresenta 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 do sistema de executar consistentemente as funções pretendidas dentro das condições definidas e manter o serviço ininterrupto. As práticas recomendadas de 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 suportar falhas ou interrupções inesperadas, mantendo o desempenho. Google Cloud Recursos, como implantações multirregionais, backups automatizados e soluções de recuperação de desastres, ajudam a melhorar a resiliência do sistema.

A confiabilidade é importante para sua estratégia de nuvem por vários motivos, incluindo:

  • Inatividade mínima: a inatividade pode levar a perda de receita, redução da produtividade e danos à reputação. As arquiteturas resilientes podem ajudar a garantir que os sistemas continuem funcionando durante falhas ou se recuperem de modo eficiente durante essas falhas.
  • Experiência do usuário aprimorada: os usuários esperam interações perfeitas com a tecnologia. Os sistemas resilientes ajudam 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 dos dados: as falhas podem causar perda ou corrupção de dados. Os 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 oferece suporte a uma recuperação rápida.
  • Conformidade: muitos setores têm requisitos regulatórios para disponibilidade de sistemas 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 de longo prazo mais baixos: arquiteturas resilientes exigem investimento inicial, mas a resiliência pode ajudar a reduzir os custos ao longo do tempo, evitando inatividade cara, evitando 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 uma estratégia estabelecida. Essa estratégia precisa incluir educação e autoridade para priorizar a confiabilidade ao lado de outras iniciativas.

Defina com clareza 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 grupos focados em negócios, como marketing e vendas, podem influenciar a confiabilidade.

Toda equipe precisa entender as metas de confiabilidade e os riscos dos aplicativos. As equipes precisam ser responsáveis por esses requisitos. Conflitos entre a confiabilidade e o desenvolvimento regular de recursos de produtos precisam ser priorizados e escalados adequadamente.

Planeje e gerencie a confiabilidade de maneira holística em todas as suas 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, acesse Otimizar a jornada da sua organização para a nuvem com um Centro de Excelência em Nuvem.

Áreas de foco para confiabilidade

As atividades realizadas 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 interagem, como os dados e as ações fluem pelo sistema e o que pode dar errado. Identifique possíveis falhas, gargalos e riscos que ajudem 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. Por meio dessa observação, é possível entender tendências e identificar problemas em potencial de maneira proativa.
  • Resposta: para reduzir o impacto das falhas, responda adequadamente e recupere-se de forma eficiente. Respostas automatizadas também podem ajudar a reduzir o impacto das falhas. Mesmo com planejamento e controles, ainda podem ocorrer falhas.
  • Aprendizado: para ajudar a evitar falhas recorrentes, aprenda com cada experiência e tome as ações apropriadas.

Princípios básicos

As recomendações no pilar de confiabilidade do framework bem-arquitetado estão associadas aos seguintes princípios fundamentais:

Colaboradores

Autores:

Outros colaboradores:

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

Esse princípio do pilar de confiabilidade do Google Cloud framework bem-arquitetado (em inglês) ajuda você a avaliar a experiência dos usuários e, em seguida, associar as descobertas a metas e métricas de confiabilidade.

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

Visão geral do princípio

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

Para avaliar a experiência do usuário, você precisa distinguir entre o comportamento interno do sistema e os problemas do usuário. Concentre-se em métricas como a taxa de sucesso das solicitações do usuário. Não confie apenas em métricas centradas no servidor, como o uso de CPU, que podem levar a conclusões equivocadas sobre a confiabilidade do seu serviço. Confiabilidade verdadeira significa que os usuários podem usar seu aplicativo ou serviço de maneira consistente e eficaz.

Recomendações

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

Avaliar a experiência do usuário

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

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 seu 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 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 de um usuário pelo seu 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 de serviço. Esses dados ajudam a identificar e resolver problemas de performance com mais eficiência, o que pode resultar em uma experiência do usuário mais confiável e satisfatória.

Defina metas realistas de confiabilidade

Esse princípio do pilar de confiabilidade do Google Cloud framework bem-arquitetado (em inglês) ajuda a definir metas de confiabilidade tecnicamente viáveis para suas cargas de trabalho no Google Cloud.

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

Visão geral do princípio

Projete seus sistemas para que sejam confiáveis o suficiente para a satisfação dos usuários. 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 em 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, é possível gastar melhor os recursos em outro lugar.

Você precisa determinar o nível de confiabilidade em que seus usuários estão satisfeitos e determinar o ponto em que o custo de 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 agreguem 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 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 lacuna entre 100% de tempo de atividade e uma meta de 99,99% é a chance de falhas. Essa lacuna costuma ser chamada de margem de erro. A margem de erro pode ajudar você a correr riscos e inovar, o que é fundamental para manter a competitividade de qualquer negócio.

Priorize a confiabilidade dos componentes mais críticos do sistema. Aceitar 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 ao risco 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 recursos essenciais de confiabilidade.

Crie sistemas altamente disponíveis com redundância de recursos

Esse princípio do pilar de confiabilidade do Google Cloud framework bem arquitetado (em inglês) oferece 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 da confiabilidade do escopo.

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 essenciais 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 única zona ou região. Nesses exemplos, se a única zona ou região sofrer 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.

Identifique domínios de falha e replique os serviços

Mapeie os domínios de falha do sistema, de VMs individuais a regiões, e projete a redundância nos 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 de zona ou região.

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

Detectar e resolver problemas imediatamente

Acompanhe continuamente o status dos domínios de falha para detectar e resolver problemas de imediato.

É possível monitorar o status atual dos Google Cloud serviços em todas as regiões usando o Google Cloud painel Service Health. 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 o tráfego automaticamente para back-ends íntegros. Para mais informações, consulte Visão geral das verificações de integridade.

Testar cenários de failover

Como uma simulação de incêndio, simule falhas regularmente para validar a eficácia de suas estratégias de replicação e failover.

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

Aproveitar a escalonabilidade horizontal

Esse princípio do pilar de confiabilidade do Google Cloud framework bem arquitetado (em inglês) oferece recomendações para ajudar você a usar a escalonabilidade horizontal. Ao usar a escalonabilidade horizontal, você garante que as cargas de trabalho no Google Cloud sejam escalonadas de maneira eficiente e mantenha o desempenho.

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

Visão geral do princípio

Rearquitetar seu sistema para uma arquitetura horizontal. Para acomodar o crescimento de tráfego ou dados, você pode adicionar mais recursos. Você também pode 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 de escalonamento vertical é usar um banco de dados MySQL como o banco de dados primário com dados críticos. À medida que o uso do banco de dados aumenta, mais RAM e CPU são necessários. Com o tempo, o banco de dados atinge o limite de memória na máquina host e precisa ser atualizado. Esse processo pode precisar ser repetido várias vezes. O problema é que há limites rígidos em relação ao tamanho do 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 recursos.

Mesmo que os recursos sejam ilimitados, uma VM grande pode se tornar um ponto único de falha. Qualquer problema com a VM primária do banco de dados pode causar respostas de erro ou causar 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 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 maiores quantidades de poder de computação e memória forem adquiridas.

O escalonamento horizontal, por outro lado, pode custar menos. O potencial para o 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 com várias máquinas, é preciso planejar cuidadosamente 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

Com os serviços gerenciados, não é necessário administrar o escalonamento horizontal manualmente. Por exemplo, com os grupos gerenciados de instâncias (MIGs) do Compute Engine, é possível adicionar ou remover VMs para escalonar seu 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 design modular

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

Implementar um design sem estado

Projete aplicativos para serem 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 do pilar de confiabilidade do Google Cloud framework bem arquitetado fornece recomendações para ajudar a identificar proativamente áreas em que erros e falhas podem ocorrer.

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

Visão geral do princípio

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

  • As métricas são medidas numéricas de atividades que você quer rastrear para seu aplicativo em intervalos de tempo específicos. Por exemplo, é possível rastrear métricas técnicas, como taxa de solicitação e de erro, que podem ser usadas como indicadores de nível de serviço (SLIs). Talvez também seja necessário acompanhar métricas de negócios específicas do aplicativo, como pedidos feitos e pagamentos recebidos.
  • Registros são registros com carimbo de data/hora de eventos distintos 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 também é possível usar registros para SLIs.
  • Um trace representa a jornada de um único usuário ou transação por vários aplicativos separados ou os componentes de um aplicativo. Por exemplo, esses componentes podem ser microsserviços. Eles ajudam a acompanhar quais componentes foram usados nas jornadas, onde existem gargalos e quanto tempo as jornadas levaram.

Métricas, registros e traces ajudam você a monitorar seu 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 ocorram erros.

Recomendações

Para detectar possíveis falhas com eficiência, considere as recomendações nas subseções a seguir.

Receba insights abrangentes

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

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.

Realize a solução de problemas proativa

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

Ao configurar a geração de registros, considere os custos associados. Para controlar os custos da 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 da rede e as métricas de E/S de disco para detectar recursos provisionados ou insuficientes em serviços como GKE, Compute Engine e Dataproc. Para uma lista completa dos serviços compatíveis, consulte Visão geral do Cloud Monitoring.

Priorizar alertas

Em relação aos alertas, concentre-se em métricas críticas, defina limites apropriados para minimizar a fadiga do alerta e garanta respostas em tempo hábil para problemas significativos. Essa abordagem direcionada permite manter a confiabilidade da carga de trabalho de maneira proativa. Para mais informações, consulte Visão geral de alertas.

Design voltado à degradação graciosa

Esse princípio do pilar de confiabilidade do Google Cloud framework bem arquitetado (em inglês) fornece recomendações para ajudar você a projetar suas Google Cloud cargas de trabalho para que apresentem falhas normalmente.

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

Visão geral do princípio

A degradação graciosa é uma abordagem de design em que um sistema que passa por uma carga alta continua funcionando, possivelmente com performance ou acurácia reduzida. A degradação suave garante a disponibilidade contínua do sistema e impede uma falha completa, mesmo que o trabalho do sistema não seja o 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ções mais altas, possivelmente sacrificando alguma precisão. Quando a carga diminui, a Pesquisa Google recalcula os resultados da pesquisa.

Recomendações

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

Implementar a limitação

Verifique se as réplicas lidam com sobrecargas de modo independente e se podem limitar as solicitações de entrada durante cenários de tráfego intenso. Essa abordagem ajuda a evitar falhas em cascata causadas por mudanças no tráfego excessivo entre as zonas.

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

Remova as solicitações em excesso antecipadamente

Configure seus sistemas para descartar as solicitações em excesso na camada de front-end e proteger os componentes do back-end. O descarte 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 encontrar erros. No entanto, é possível minimizar o impacto das interrupções, em contraste com uma abordagem como quebra de circuito, em que todo o tráfego é descartado durante uma sobrecarga.

Lidar com 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 exibido durante cenários de alta carga.

Testar cenários de sobrecarga

Para validar se os mecanismos de limitação e queda de solicitação funcionam de maneira eficaz, simule regularmente condições de sobrecarga no sistema. Isso ajuda a garantir que o 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 surtos de tráfego antes que eles se transformem em sobrecargas. Detecção e resposta antecipadas ajudam a manter a disponibilidade do serviço em períodos de alta demanda.

Realizar testes para recuperação de falhas

Esse princípio do pilar de confiabilidade do Google Cloud framework bem arquitetado (em inglês) oferece recomendações para ajudar a projetar e executar testes de recuperação em caso de falhas.

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

Visão geral do princípio

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

Esse teste ajuda 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 conforme o esperado durante uma interrupção.

No caso improvável de uma região inteira cair, é necessário fazer 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 de 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 a inatividade após uma interrupção regional, os engenheiros de operações também precisam ser capazes de deslocar o tráfego do usuário de maneira manual e eficiente para longe de uma região, 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 na região e move 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 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 camadas de aplicativo específicas, como front-end, back-end e banco de dados, ou pode incluir recursos Google Cloud específicos, como instâncias do Cloud SQL ou clusters do GKE. O escopo também precisa especificar dependências externas, como APIs de terceiros ou Cloud Interconnects.

Preparar o ambiente para testes

Escolha um ambiente apropriado, de preferência um ambiente de preparação ou sandbox que replique sua configuração de produção. Se você realizar o teste na produção, verifique se tem medidas de segurança prontas, como monitoramento automatizado e procedimentos manuais de reversão.

Criar um plano de backup. Crie 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 realizar intervenções manuais se os mecanismos de failover automatizados falharem.

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

Informe as partes interessadas, incluindo proprietários de aplicativos, operações e DevOps, 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.

Simule 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ó primário em um cluster do GKE de várias zonas 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.

Introduzir o teste de carga com cenários de falha para replicar o uso real durante interrupções. Teste os impactos de falha em cascata, por exemplo, 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 envolvem configurações incorretas. Por exemplo, execute testes com configurações incorretas de failover de DNS ou permissões de IAM incorretas.

Monitorar o comportamento do sistema

Monitore como balanceadores de carga, verificações de integridade e outros mecanismos redirecionam o tráfego. Use ferramentas Google Cloud , 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 na capacidade durante e após a simulação de falha e monitore o impacto geral no desempenho. Identifique qualquer degradação ou inconsistências na experiência do usuário.

Garanta que os registros sejam gerados e que os alertas sejam acionados para eventos principais, como falhas temporárias ou failovers de serviço. Use esses dados para verificar a eficácia dos sistemas de alerta e resposta a incidentes.

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

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

Garantir que a integridade e a disponibilidade dos dados estejam alinhadas ao 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 são restaurados para um estado funcional com interrupção mínima para os usuários.

Documentar e analisar resultados

Documente cada etapa do teste, cenário de falha e comportamento correspondente do sistema. 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, classifique os problemas por gravidade e impacto.

Sugira melhorias para a arquitetura do sistema, mecanismos de failover ou configurações de monitoramento. Com base nas descobertas do teste, atualize as políticas e os manuais de failover relevantes. Apresentar um relatório 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 análises post-mortem completas.

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 alterações de infraestrutura, atualizações de software e aumento das cargas de tráfego.

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

Durante a análise post-mortem, 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 para recuperação de perda de dados

Esse princípio do pilar de confiabilidade do Google Cloud framework bem-arquitetado oferece recomendações para ajudar você a projetar e executar testes para recuperação de perda de dados.

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

Visão geral do princípio

Para garantir que seu 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. Após esses eventos, é necessário restaurar dados de backups e restaurar todos os serviços novamente usando os dados recém-restaurados.

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

O objetivo do teste de restauração de dados é verificar periodicamente se sua organização pode continuar a atender aos requisitos de continuidade de negócios. Além de medir o RTO e o RPO, os testes de restauração de dados precisam incluir o teste de toda a pilha do aplicativo 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 a 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 dos dados que podem ser restaurados para que os aplicativos voltem a funcionar 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 cenários de recuperação de dados regularmente. Documente as etapas da 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 aos objetivos 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 backups para serem executados pelo menos a cada 15 minutos. Otimizar os intervalos de backup para reduzir o risco de perda de dados.

Use ferramentas Google Cloud como o Cloud Storage, backups automatizados do Cloud SQL ou backups do Spanner para programar e gerenciar backups. Para aplicativos críticos, use soluções de backup quase contínua, como recuperação pontual (PITR, na sigla em inglês) 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 do negócio e monitore a adesão ao RPO. 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 rastrear a integridade dos backups e confirmar se eles estão armazenados em locais seguros e confiáveis. Garanta que os backups sejam replicados em várias regiões para aumentar a 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.

Faça análises post-mortem minuciosas

Esse princípio do pilar de confiabilidade do Google Cloud framework bem arquitetado fornece recomendações para ajudar você a conduzir análises post-mortem eficazes após falhas e incidentes.

Esse princípio é relevante para o aprendizado área de foco de 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 atenuar ou resolver o incidente, as causas raiz e as ações de acompanhamento para evitar que o incidente se repita. O objetivo da análise post-mortem é aprender com os erros e não apontar culpados.

O diagrama a seguir 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 as seguintes etapas:

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

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

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

Recomendações

Defina critérios de análise post-mortem antes que ocorra um incidente para que todos saibam quando o processo é necessário.

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

Realize 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 dessa análise é melhorar a tecnologia e o futuro, e não descobrir quem é o culpado. Todo mundo comete erros. A meta deve ser analisar os erros e aprender com eles.

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

  • Feedback que atribui culpa: "Precisamos reescrever todo o sistema de back-end complicado. Nos últimos três trimestres, está se desfazendo das coisas, e tenho certeza de que estamos cansados de fazer as coisas aos poucos. Sério, se eu receber uma página mais uma vez, eu mesmo vou reescrever..."
  • Feedback sem culpa: "Um item de ação para reescrever todo o sistema de back-end pode impedir que essas páginas continuem acontecendo. O manual de manutenção desta versão é muito longo e muito difícil de ser totalmente treinado. Tenho certeza de que nossos futuros engenheiros de plantão nos agradecerão!"

Torne o relatório de análise post-mortem legível para todos os públicos-alvo.

Para cada informação que você planeja incluir no relatório, avalie se elas são importantes e necessárias para ajudar o público a entender o que aconteceu. É possível mover dados e explicações complementares para um apêndice do relatório. Os revisores que precisarem de mais informações poderão solicitá-las.

Evite soluções complexas ou com excesso de engenharia

Antes de começar a explorar soluções para um problema, avalie a importância dele e a probabilidade de recorrência. Se o sistema for mais complexo para resolver problemas que dificilmente ocorrerão novamente, isso poderá aumentar a instabilidade.

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

Para garantir que os problemas não permaneçam sem resolução, publique o resultado da análise 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 post-mortem. Quando mais pessoas aprendem com os incidentes, a probabilidade de que falhas semelhantes ocorram novamente é reduzida.