Alta disponibilidade e recuperação de desastres: cálculos, RTO, RPO e padrões de DR

Duas disciplinas costumam ser tratadas como se fossem uma só. Alta disponibilidade é sobreviver às falhas que você já espera — uma máquina que morre, um disco que enche, um data center que fica sem energia — sem intervenção humana e sem que os usuários percebam muita coisa. Recuperação de desastres trata dos eventos que não dá para absorver no lugar: uma queda de uma região inteira, um banco de dados corrompido e replicado para todo lado, uma conta comprometida com os recursos apagados. As duas usam mecanismos diferentes, custam valores diferentes e falham de jeitos diferentes, e um sistema pode ser excelente em uma e inútil na outra.

Este guia começa pela matemática, porque metas de disponibilidade escolhidas sem ela não passam de desejos. Em seguida percorre os domínios de falha, os padrões de redundância que aumentam a disponibilidade, os objetivos de recuperação que definem a recuperação de desastres, as quatro estratégias de DR mais usadas e sua economia e, por fim, os testes sem os quais nada disso pode ser afirmado.

A matemática da disponibilidade

Disponibilidade é o tempo no ar dividido pelo tempo total, convencionalmente expressa em noves. O que importa é a margem de indisponibilidade que ela implica.

Quatro noves permitem menos de cinco minutos de indisponibilidade por mês — menos do que o tempo de acordar alguém e fazer essa pessoa abrir o notebook. Qualquer coisa nesse nível ou acima precisa se recuperar sem intervenção humana, e isso é uma afirmação sobre arquitetura, não sobre operação.

Componentes em série — todos necessários para uma requisição dar certo — se multiplicam. Um load balancer, uma camada de aplicação, um cache e um banco de dados, cada um com 99,99% de forma independente, resultam em 0,9999⁴ ≈ 99,96%, cerca de três horas e meia por ano, antes de contar seus próprios bugs e deploys. Cada dependência que você adiciona abaixa o teto.

Componentes redundantes em paralelo, por outro lado, multiplicam suas probabilidades de falha. Duas instâncias com 99% de disponibilidade cada só falham juntas 1% × 1% do tempo, o que dá 99,99% — desde que as falhas sejam independentes. Todo o argumento depende dessa ressalva, e ela geralmente é falsa.

Domínios de falha e falhas correlacionadas

Um domínio de falha é um conjunto de recursos que podem falhar juntos. Saber nomeá-los é a habilidade central, porque redundância só ajuda quando as cópias estão em domínios diferentes.

A hierarquia física vai do processo ao host, ao rack, ao data center, à zona de disponibilidade e à região. Os provedores expõem a zona como a unidade em que você posiciona recursos, e distribuir instâncias entre zonas é a defesa padrão contra um evento em um data center.

Os domínios que realmente causam incidentes, porém, raramente são físicos:

• Dependências compartilhadas. Três instâncias em três zonas atrás de um único load balancer, todas lendo de um único banco de dados em uma única zona. O domínio é o banco.
• O control plane. APIs de provisionamento, autoscaling e IAM são serviços regionais. Durante um grande evento regional, as mesmas APIs de que você precisa para subir capacidade de reposição são as que estão degradadas. Caminhos de recuperação que exigem criar novos recursos são mais frágeis do que os que só exigem desviar tráfego para recursos que já existem — isso se chama ser estaticamente estável (statically stable).
• Configuração e deploy. A causa mais comum de falha correlacionada é uma mudança aplicada em todo lugar ao mesmo tempo: um push de configuração errado, uma migration de schema, um certificado expirado distribuído pela mesma automação para todas as réplicas. Redundância não protege nada aqui; rollout escalonado, sim.
• Capacidade e cotas. Um failover que dobra a carga na zona sobrevivente só dá certo se essa zona tinha capacidade sobrando. Escalar para duas zonas e dimensionar cada uma para exatamente metade do tráfego garante degradação quando uma delas cai.
• Destino compartilhado no software. Todas as instâncias rodando o mesmo código batem no mesmo vazamento de memória no mesmo tempo de atividade, e a mesma mensagem envenenada derruba todos os consumidores.

Dois padrões limitam o estrago correlacionado. A arquitetura baseada em células (cell-based architecture) divide os usuários em células independentes, cada uma com uma stack completa, de modo que uma célula com problema afeta uma fração conhecida dos clientes. O shuffle sharding dá a cada cliente um subconjunto aleatório de workers, então um tenant abusivo raramente derruba outro.

RTO e RPO

Recuperação de desastres é definida por dois números, e ambos são decisões de negócio que a engenharia implementa.

O objetivo de tempo de recuperação (RTO) é o tempo máximo aceitável entre o desastre e o restabelecimento do serviço. O objetivo de ponto de recuperação (RPO) é a perda máxima aceitável de dados, expressa em tempo: um RPO de quinze minutos significa que perder os últimos quinze minutos de escritas é tolerável.

Derive esses números do impacto, não da aspiração. Pergunte quanto a organização perde por hora de indisponibilidade — receita, multas regulatórias, créditos contratuais, custo de reputação — e quanto custa redigitar as transações perdidas. Compare o custo da indisponibilidade com o custo da proteção; a meta sensata fica perto do ponto em que as curvas se cruzam, não em zero. Perguntar a um responsável de negócio "quanta indisponibilidade é aceitável?" sempre rende "nenhuma", então pergunte "o que você faria durante quatro horas sem isso?".

Organize os sistemas em níveis. Um fluxo de autorização de pagamentos pode precisar de RTO de minutos e RPO próximo de zero; uma ferramenta interna de relatórios pode aceitar um dia em ambos. Aplicar o nível mais rigoroso em tudo é o jeito mais garantido de tornar a recuperação de desastres cara demais e, por isso mesmo, de ela nunca sair do papel.

Padrões de redundância para alta disponibilidade

Dentro de uma região, os blocos básicos são bem conhecidos.

Camadas stateless distribuídas entre zonas. Coloque instâncias em pelo menos três zonas atrás de um load balancer, em um grupo de autoscaling cujo mínimo sobreviva à perda de uma zona. Dimensione cada zona para que as sobreviventes absorvam a parte da zona que caiu — com três zonas, isso significa cerca de 50% de folga, contra os 100% que duas zonas exigem.

Health checks que querem dizer alguma coisa. Um check que retorna 200 sempre que o processo está vivo continua mandando tráfego para uma instância que não consegue alcançar o banco de dados; um check que falha sempre que qualquer dependência está inacessível pode tirar a frota inteira do ar durante uma instabilidade passageira. Use um check raso para o load balancer e um mais profundo para alertas e gates de deploy.

Timeouts, retries com jitter e circuit breakers. Retries sem backoff exponencial e jitter aleatório transformam uma breve lentidão de uma dependência em uma negação de serviço autoinfligida. Um circuit breaker que abre depois de um limite de falhas e deixa passar um fluxo mínimo de requisições de sondagem dá à dependência espaço para se recuperar. Bulkheads — pools de conexão separados por dependência — impedem que um serviço downstream lento esgote os recursos de que todas as outras requisições precisam.

Degradação elegante. Decida com antecedência o que o sistema faz sem cada dependência. Servir preços em cache desatualizados, enfileirar escritas para processar depois ou desligar as recomendações mantendo o checkout funcionando são resultados melhores do que uma página de erro, e precisam ser projetados, não improvisados.

Serviços de dados gerenciados multi-zona. Object storage e filas gerenciadas já são redundantes entre zonas. Bancos relacionais normalmente oferecem um standby síncrono em uma segunda zona com failover automático, além de read replicas assíncronas. Saiba quais dos seus armazenamentos replicam de forma síncrona — é a diferença entre perda de dados zero e não zero.

As quatro estratégias de recuperação de desastres

Entre regiões, quatro padrões cobrem quase qualquer requisito. O custo sobe a cada passo, e o tempo de recuperação cai.

Backup and restore. Backups e snapshots são copiados para uma segunda região; nada roda lá até ser necessário. A infraestrutura é recriada a partir de templates e os dados são restaurados da cópia mais recente. O RPO é igual ao intervalo entre backups, o RTO vai de horas a um dia e o custo contínuo é só de armazenamento. É a escolha certa para a maioria dos sistemas internos, e a única estratégia que também protege contra corrupção lógica — por isso todas as outras também a incluem.

Pilot light. A camada de dados é replicada continuamente para a segunda região e mantida ativa, enquanto a camada de computação existe como templates e imagens, mas roda com capacidade zero ou quase zero. Recuperar significa escalar a computação e promover a réplica. O RPO é de segundos a minutos, o RTO de dezenas de minutos, e o custo contínuo são os dados replicados mais uma pequena estrutura sempre ligada.

Warm standby. Uma cópia completa, porém reduzida, do ambiente roda continuamente na segunda região, sem atender tráfego ou atendendo uma fatia simbólica. O failover é um desvio de tráfego seguido de scale-out. O RPO é de segundos, o RTO de minutos, e o custo é bem maior — em geral entre um quarto e metade do de produção, dependendo de quanto o ambiente é reduzido. A vantagem decisiva é que o standby está rodando, então seus deploys, certificados e permissões são exercitados continuamente, em vez de descobertos às 3 da manhã.

Multi-site active-active. As duas regiões atendem tráfego de produção atrás de uma camada de roteamento global. O RTO se aproxima de zero, o RPO depende do modelo de replicação e o custo é no mínimo o dobro. É a única opção que também traz ganhos de latência regional, e ela obriga você a resolver tratamento de conflitos, identidade global e compatibilidade simultânea de schemas. O preço real é a complexidade; a conta de infraestrutura é a parte menor.

O failover do banco de dados domina o tempo de recuperação

Em quase toda recuperação, a camada stateless é trivial e é o banco de dados que dita o relógio.

A replicação síncrona só confirma no primário depois que um standby reconhece a escrita: perda de dados zero, com um custo de latência proporcional à distância. Ela é viável entre zonas e geralmente inviável entre regiões distantes. A replicação assíncrona confirma localmente e envia as mudanças depois, então o RPO entre regiões é igual ao lag de replicação — que precisa ter alarme, porque cresce silenciosamente com picos de escrita e transações longas.

A promoção é o momento perigoso. Promoção automática entre regiões corre o risco de split brain: uma partição convence a secundária de que a primária morreu enquanto a primária continua aceitando escritas, deixando dois históricos divergentes. Dentro de uma região, o failover automático baseado em quórum é seguro e padrão; entre regiões, a maioria das organizações exige uma decisão humana, porque o sinal de falha é ambíguo.

São os detalhes práticos que decidem se a promoção funciona: as aplicações precisam se reconectar em vez de manter em cache para sempre um endereço resolvido; as connection strings devem apontar para um alias DNS ou um endpoint de proxy que você consiga redirecionar; o failback precisa ser planejado, porque inverter a replicação costuma ser mais difícil que o failover; e a secundária precisa ter as mesmas chaves de criptografia, credenciais e versão de schema. As implicações de consistência de aceitar escritas em dois lugares são discutidas em transações distribuídas e consistência.

Backups: o que todo mundo diz ter e poucos verificam

Siga uma disciplina 3-2-1 adaptada para a nuvem: pelo menos três cópias, em dois tipos de armazenamento, com uma isolada — outra conta ou assinatura, outras credenciais, object lock ou imutabilidade ativados e, de preferência, outra região. O isolamento não tem a ver com falha de hardware; tem a ver com um atacante ou uma automação equivocada que tenha permissão de exclusão.

Depois, teste restores periodicamente e meça o tempo, porque um restore de vários terabytes a partir de armazenamento frio pode estourar o RTO em uma ordem de grandeza, e só tentando você descobre isso. Automatize um restore periódico em um ambiente descartável, rode nele um checksum e uma consulta de negócio, e registre o tempo decorrido como métrica, com alarme para regressões.

Provando com game days

Um plano de recuperação não testado é um documento, não uma capacidade. Um game day é um exercício agendado em que o time executa um cenário de falha contra um ambiente real.

Comece em um ambiente de pré-produção que realmente espelhe a produção, anuncie o exercício e formule uma hipótese antes: "se encerrarmos a instância primária do banco de dados, o tráfego se recupera em noventa segundos sem nenhuma escrita com falha". Depois injete a falha e registre o que realmente aconteceu. O resultado valioso é a lista de surpresas — uma role do IAM faltando, um alerta direcionado a um time que já foi desfeito, um passo do runbook que cita uma ferramenta desativada.

Cenários que vale a pena ensaiar, mais ou menos em ordem de maturidade: encerrar uma instância; fazer failover do banco de dados; perder uma zona de disponibilidade; restaurar o maior banco de dados e cronometrar; deixar um certificado expirar; perder o provedor de identidade; executar um failover regional; e se recuperar de uma corrupção lógica descoberta com seis horas de atraso. Este último raramente é ensaiado e está entre os mais prováveis de acontecer.

A injeção automatizada de falhas torna isso contínuo em vez de anual. As duas grandes nuvens oferecem serviços gerenciados de injeção de falhas que param instâncias, adicionam latência ou aplicam throttling em APIs dentro de um raio de impacto controlado, com uma condição de parada ligada a um alarme. Rodar pequenos experimentos continuamente — primeiro em pré-produção e, com o tempo, em produção com pessoas acompanhando — transforma resiliência declarada em resiliência medida, e é exatamente a evidência que uma revisão Well-Architected pede.

Principais aprendizados

• Metas de disponibilidade são aritmética: dependências em série se multiplicam, quatro noves exigem recuperação automática e o SLA de um provedor é uma tabela de créditos, não uma promessa sobre o seu sistema.
• Redundância só ajuda entre domínios de falha independentes; falhas correlacionadas vindas de dependências compartilhadas, control planes, pushes de configuração e falta de capacidade derrubam a duplicação ingênua.
• RTO e RPO vêm do impacto no negócio e devem ser definidos em níveis por workload; aplicar o nível mais rigoroso em tudo torna a recuperação de desastres cara demais.
• As quatro estratégias de DR trocam custo por tempo de recuperação — backup and restore, pilot light, warm standby, active-active — e todas ainda precisam de backups imutáveis e isolados.
• A replicação e a promoção do banco de dados definem o tempo de recuperação: síncrona dentro de uma região, assíncrona entre regiões, com o failback planejado com antecedência.
• Uma capacidade de recuperação só existe depois de exercitada: agende game days, meça os tempos de restore e injete falhas continuamente em vez de confiar no runbook.