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 em 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 realizar consistentemente as funções pretendidas nas condições definidas e manter o serviço ininterrupto. As práticas recomendadas para confiabilidade incluem redundância, design com tolerância 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:

  • Tempo de inatividade mínimo: o tempo de inatividade pode levar à perda de receita, diminuição da produtividade e danos à reputação. As arquiteturas resilientes ajudam a garantir que os sistemas continuem funcionando durante falhas ou se recuperem de maneira eficiente delas.
  • Experiência do usuário aprimorada: os usuários esperam interações perfeitas com a tecnologia. Sistemas resilientes ajudam a manter a performance e a disponibilidade consistentes, além de oferecer 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. Arquiteturas resilientes ajudam a garantir a continuidade após uma falha catastrófica, permitindo que as funções comerciais continuem sem interrupções significativas e oferecendo 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.
  • Redução dos custos de longo prazo: as arquiteturas resilientes exigem investimento inicial, mas a resiliência pode ajudar a reduzir os custos ao longo do tempo, evitando períodos de inatividade caros, correções reativas e permitindo um uso mais eficiente dos 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 junto com outras iniciativas.

Deixe claro 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 os 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 suas 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 neste pilar é relevante para uma dessas áreas de foco.

  • Escopo: para entender seu sistema, faça uma análise detalhada da arquitetura dele. É preciso 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 tomar medidas para mitigar esses problemas.
  • Observação: para evitar falhas no sistema, implemente uma observação e um monitoramento abrangentes e contínuos. Com essa observação, você pode entender tendências e identificar possíveis problemas de forma proativa.
  • Resposta: para reduzir o impacto das falhas, responda de maneira adequada e recupere com eficiência. As respostas automáticas 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 se repitam, aprenda com cada experiência e tome as medidas adequadas.

Princípios básicos

As recomendações no pilar de confiabilidade do Well-Architected Framework sã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 Framework bem arquitetado ajuda você a avaliar a experiência dos usuários e mapear os resultados 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 estão diretamente relacionados aos impactos nos usuários. Por exemplo, você pode observar uso alto da CPU, operações lentas do servidor ou até mesmo falhas nas tarefas. 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 entre o comportamento interno do sistema e os problemas enfrentados pelo usuário. Concentre-se em métricas como a proporção de sucesso das solicitações dos usuários. 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 seu serviço. A verdadeira confiabilidade significa que os usuários podem usar seu aplicativo ou serviço de forma consistente e eficaz.

Recomendações

Para 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 sucesso das consultas 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 direta de dados não for viável, afaste progressivamente o ponto de medição do usuário no sistema. Por exemplo, é possível usar o balanceador de carga ou o serviço de front-end como ponto de medição. Essa abordagem ajuda a identificar e resolver problemas antes que eles afetem 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 acompanhar a jornada de um usuário no aplicativo, é possível encontrar gargalos e problemas de latência que podem prejudicar a experiência dele. O Cloud Trace captura dados detalhados de desempenho 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 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 arquitetado ajuda você 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 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 na inovação. Se os usuários já estiverem satisfeitos com o nível atual de serviço, os esforços para aumentar ainda mais a satisfação poderão gerar um baixo retorno do investimento. Em vez disso, você pode gastar melhor os recursos em outro lugar.

Você precisa 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. Quando você determina esse nível de confiabilidade suficiente, é possível alocar recursos de forma estratégica e se concentrar em recursos e melhorias que oferecem mais valor aos usuários.

Recomendações

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

Aceitar algumas falhas e priorizar componentes

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

A diferença entre 100% de tempo de atividade e uma meta de 99,99% é a tolerância a falhas. Essa lacuna é chamada de orçamento de erros. A margem de erro ajuda 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.

Equilibrar confiabilidade e custo

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

Considere fatores como requisitos do sistema, consequências de falhas e a tolerância a riscos da sua organização para o aplicativo específico. Não se esqueça de considerar suas 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 os custos sem comprometer os recursos essenciais de confiabilidade.

Criar sistemas altamente disponíveis usando a 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 você 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 sistema, desde VMs individuais até regiões, e crie redundância em todos os domínios.

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 e garanta que os serviços e aplicativos continuem disponíveis em caso de interrupções na zona ou região.

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

Detectar e resolver problemas rapidamente

Acompanhe continuamente o status dos seus 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 de integridade do serviço 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 mais informações, consulte Visão geral das verificações de integridade.

Testar cenários de failover

Assim como um simulado de incêndio, simule falhas regularmente para validar a eficácia das suas 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 Well-Architected Framework fornece recomendações para ajudar você a usar a escalonabilidade horizontal. Ao usar a escalonabilidade horizontal, você garante que suas cargas de trabalho noGoogle 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

Migre a arquitetura do seu sistema para uma arquitetura horizontal. Para acomodar o crescimento do tráfego ou dos dados, adicione 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 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á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 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 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 de escalonamento, o escalonamento vertical tende a ser mais caro. O custo pode aumentar exponencialmente à medida que máquinas com maior poder 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 escalonar.

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 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 seu aplicativo horizontalmente. Para aplicativos em contêineres, 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

Esse princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar você a identificar de forma proativa á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, é necessário 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 seu aplicativo em intervalos de tempo específicos. Por exemplo, talvez você queira rastrear 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). Talvez também seja 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 rastreamento representa a jornada de um único usuário ou transação por vários aplicativos separados ou componentes de um aplicativo. Por exemplo, esses componentes podem ser microsserviços. Os rastreamentos ajudam a acompanhar quais componentes foram usados nas jornadas, onde existem gargalos e quanto tempo as jornadas levaram.

Métricas, registros e rastreamentos ajudam você a monitorar seu sistema continuamente. O monitoramento abrangente ajuda você a descobrir onde e por que os erros ocorreram. Você também pode 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 importantes, 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 consistentemente à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.

Fazer a solução de problemas proativa

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

Ao configurar o registro em log, 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 de disco para detectar recursos subprovisionados e superprovisionados em serviços como GKE, Compute Engine e Dataproc. Para uma lista completa de serviços compatíveis, consulte a Visão geral do Cloud Monitoring.

Priorizar alertas

Para alertas, concentre-se em métricas críticas, defina limites adequados para minimizar a fadiga de alertas e garanta respostas rápidas a 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.

Projetar para degradação suave

Esse princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar você a projetar suas Google Cloud cargas de trabalho para falhar normalmente.

Esse princípio é relevante para a resposta área de foco 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, talvez 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 da precisão. Quando a carga diminui, a Pesquisa Google recalcula os resultados.

Recomendações

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

Implementar a limitação

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

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

Descarte solicitações em excesso com antecedência

Configure seus sistemas para descartar solicitações em excesso na camada de front-end e proteger os componentes de back-end. Descartar algumas solicitações evita falhas globais e permite que o sistema se recupere de maneira mais adequada.Com essa abordagem, alguns usuários podem ter erros. No entanto, é possível minimizar o impacto das interrupções, ao contrário de uma abordagem como 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 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 descarte de solicitações funcionam de maneira eficaz, simule regularmente condições de sobrecarga no seu sistema. Os testes ajudam a garantir que seu sistema esteja preparado para picos de tráfego no mundo real.

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.

Realizar testes de recuperação de falhas

Esse 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 aprendizagem da confiabilidade.

Visão geral do princípio

Para garantir que seu sistema possa se recuperar de falhas, execute periodicamente testes que incluam failovers regionais, reversões de lançamento 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 conforme o esperado durante uma interrupção.

No caso improvável de uma região inteira ficar inativa, é necessário fazer failover de todo o tráfego para outra região. Durante a operação normal da sua carga de trabalho, quando os dados são modificados, eles precisam ser sincronizados da região principal para a de failover. É necessário verificar se os dados replicados estão sempre atualizados 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 conseguir 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 conseguir 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 desativação de 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 para 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 capacidade de recuperação e a tolerância a falhas do sistema em vários cenários de falha.
  • Teste a eficácia dos mecanismos de failover automático.

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 específicos do Google Cloud , como instâncias do Cloud SQL ou clusters do GKE. O escopo também precisa especificar dependências externas, como APIs de terceiros ou interconexões de nuvem.

Preparar o ambiente para testes

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

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

Para evitar interrupções no teste, verifique se as funções e políticas do IAM e as configurações de failover estão configuradas corretamente. Verifique se as permissões necessárias estão em vigor para as ferramentas e 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 aos stakeholders 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 desligamento de um nó principal em um cluster do GKE multizona ou uma instância do Cloud SQL desativada. Você também pode 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 junto 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 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 de failover de DNS ou permissões de 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 ferramentas como o Cloud Monitoring e o Cloud Logging para capturar métricas e eventos durante o teste. Google Cloud

Observe as mudanças na latência, nas taxas de erro e na capacidade 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 estão sendo gerados e se os alertas estão sendo acionados para eventos importantes, como falhas temporárias do 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 leva para o sistema retomar as operações normais após uma falha e compare esses dados com o RTO definido. Documente todas as lacunas.

Verifique se a integridade e a disponibilidade dos dados estão 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 foram restaurados para um estado funcional com mínima interrupção para o usuário.

Documentar e analisar os resultados

Documente cada etapa de 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 ajudar a priorizar 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 nos resultados 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 precisa resumir os resultados, as lições aprendidas e as próximas etapas. Para mais informações, consulte Fazer análises pós-mortem completas.

Iterar e melhorar

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

Faça testes em diferentes cenários, incluindo mudanças na infraestrutura, atualizações de software e aumento nas 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 o post-mortem, use o feedback das partes interessadas e dos usuários finais para melhorar o processo de teste e a capacidade de recuperação do sistema.

Realizar testes de recuperação de perda de dados

Esse 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 aprendizagem da 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. Depois desses eventos, é necessário restaurar os dados dos backups e colocar todos os serviços de volta em funcionamento 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 dos dados, objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO). Para mais detalhes sobre as métricas de RTO e RPO, consulte Noções básicas do planejamento de DR.

O objetivo dos testes de restauração de dados é verificar periodicamente se sua 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 o teste de toda a pilha de aplicativos e de todos os serviços de infraestrutura críticos 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

Verifique se os backups contêm snapshots consistentes e utilizáveis de dados que podem ser restaurados para colocar os aplicativos 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 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 executá-las de maneira eficaz durante uma falha.

Agendar 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 ferramentas como o Cloud Storage, os backups automáticos do Cloud SQL ou os backups do Spanner para programar e gerenciar backups. Google Cloud 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<<a href="https://www.youtube.com/watch?v=4_4-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-

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 que eles estão armazenados em locais seguros e confiáveis. Verifique se os backups são replicados em várias regiões para aumentar a 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.

Realizar análises post mortem completas

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

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

Visão geral do princípio

Uma análise postmortem é um registro escrito de um incidente, do impacto dele, das ações tomadas para reduzir ou resolver o problema, das causas raiz e das ações de acompanhamento para evitar que ele aconteça de novo. O objetivo de uma análise retrospectiva é aprender com os erros, 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 um postmortem
  • Capture os fatos
  • Identificar e analisar as causas principais
  • Planeje para o futuro
  • Execute o plano.

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

  • Indisponibilidades 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 lançamento ou redirecionamento de tráfego.
  • Tempos de resolução acima de um limite definido.
  • Falhas de monitoramento, que geralmente implicam descoberta manual de incidentes.

Recomendações

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

Para fazer 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-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 é 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 apresentado falhas semanais nos últimos três trimestres, e tenho certeza de que todos estão cansados de corrigir as coisas aos poucos. É sério, se eu receber mais um aviso, vou reescrever tudo sozinho…"
  • Feedback sem culpa: "Um item de ação para reescrever todo o sistema de back-end pode impedir que essas páginas continuem aparecendo. O manual de manutenção dessa versão é muito longo e difícil de aprender. Tenho certeza de que nossos futuros engenheiros de plantão vão agradecer!"

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

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 projetadas

Antes de começar a procurar 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 de novo pode aumentar a instabilidade.

Compartilhe o post mortem o máximo possível

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

Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.

Última atualização 2025-02-14 UTC.