5 erros comuns em Alta disponibilidade (e como evitar)

Nem todo projeto envolvendo Alta disponibilidade dá errado por falta de conhecimento técnico — na maioria das vezes, é por repetir os mesmos erros básicos.

Sistemas de alta disponibilidade assumem que componentes individuais vão falhar em algum momento e são projetados para continuar operando mesmo assim, distribuindo carga e redundância entre múltiplos pontos.

Os tropeços mais comuns

1. Ignorar que redundância em múltiplas zonas de disponibilidade protege contra a falha de um único data center.
2. Ignorar que balanceamento de carga distribui tráfego entre instâncias saudáveis, retirando automaticamente as que falham.
3. Ignorar que testar cenários de falha de propósito (chaos engineering) revela pontos fracos antes que um incidente real os exponha.
4. Ignorar que dependências únicas (single points of failure) em qualquer camada anulam o esforço de redundância no restante do sistema.
5. Ignorar que definir claramente a meta de disponibilidade (99.9%, 99.99%) orienta quanto investimento em redundância faz sentido.

A boa notícia é que nenhum desses erros é difícil de corrigir uma vez identificado — o problema é raramente pararem para revisar até que algo dê errado.

O padrão por trás da maioria desses erros em Alta disponibilidade não é falta de conhecimento técnico — é pressa, falta de revisão e ausência de um processo que force uma segunda checagem antes de algo ir para produção.

Na nuvem, alta disponibilidade é obtida principalmente por redundância: distribuir servidores em múltiplas zonas de disponibilidade dentro de uma região, de modo que a falha de um data center físico não derrube o sistema inteiro. Balanceadores de carga direcionam o tráfego apenas para instâncias saudáveis, e bancos de dados gerenciados costumam oferecer réplicas automáticas prontas para assumir em caso de falha, um mecanismo chamado failover. A AWS documenta esse conceito de forma acessível em sua página sobre alta disponibilidade.

Para um negócio, definir o nível de disponibilidade necessário é uma decisão de custo-benefício: um site institucional pode tolerar minutos de indisponibilidade ocasional, mas um sistema de pedidos ou pagamento em tempo real, não. A arquitetura — e o custo de infraestrutura — deve ser dimensionada de acordo com o que a operação realmente exige, não pelo padrão mais caro disponível.

Perguntas frequentes

Como evitar os erros mais comuns em Alta disponibilidade?

Redundância em múltiplas zonas de disponibilidade protege contra a falha de um único data center.

Como evitar os erros mais comuns em Alta disponibilidade?

Definir claramente a meta de disponibilidade (99.9%, 99.99%) orienta quanto investimento em redundância faz sentido.

Esta matéria faz parte da cobertura de alta disponibilidade assinada por Diego Almeida na Revista SmartWeb — acompanhe as próximas colunas sobre o tema para aprofundar cada um dos pontos levantados aqui.

Fontes e leitura complementar

• Wikipédia — Computação em nuvem
• Cloud Native Computing Foundation