Quando alguém promete "99.9% de disponibilidade", está prometendo, em números concretos, no máximo 8 horas e 45 minutos fora do ar por ano inteiro. Parece pouco até o sistema cair numa Black Friday.

Disponibilidade se mede em "noves", e cada nove a mais muda a ordem de grandeza do problema (e do custo):

O pulo do gato que este artigo quer te dar: alta disponibilidade não é um produto que se compra, é uma propriedade que se arquiteta. E ela nasce de uma premissa contraintuitiva, popularizada pela engenharia do Google no livro Site Reliability Engineering (sre.google/books): componentes falham o tempo todo; o sistema é que não pode falhar junto.

Passo 1: cace os pontos únicos de falha

SPOF (Single Point of Failure) é qualquer componente que, sozinho, derruba tudo: o único servidor de aplicação, o único banco, o único NAT gateway, aquele job noturno que roda numa máquina só. O exercício é simples e desconfortável: percorra a arquitetura perguntando "se ISSO morrer agora, o que acontece?". Cada resposta "cai tudo" é um item do plano.

Passo 2: redundância nas camadas certas

• Aplicação: no mínimo duas instâncias, atrás de um load balancer com health checks que tiram máquina doente do jogo automaticamente. Em nuvem, distribua entre zonas de disponibilidade (AZs), que são datacenters fisicamente separados.
• Banco de dados: réplica em outra AZ com failover automático (as três grandes nuvens oferecem isso gerenciado). O detalhe que separa amadores de profissionais: failover não testado é failover que não existe.
• Dependências externas: timeout, retry com backoff e circuit breaker. Se o gateway de pagamento ficar lento, seu checkout não pode afundar junto.

Passo 3: degrade com elegância

Nem toda falha precisa ser tudo-ou-nada. Sistema maduro degrada por partes: se a recomendação personalizada caiu, mostre os mais vendidos; se a busca avançada morreu, sirva a simples. O usuário percebe um produto um pouco pior, não um produto fora do ar. Esse desenho (graceful degradation) costuma valer mais noves do que hardware extra.

Passo 4: backups que restauram, monitoramento que avisa

Backup sem teste de restauração é uma esperança, não uma estratégia. Agende restaurações de verdade, meça o tempo, documente o passo a passo. E instrumente tudo: você não consegue sustentar um SLA que não consegue medir. Métricas de disponibilidade por endpoint, alertas para sintomas (latência, taxa de erro) e não apenas para causas.

O nove certo para o seu negócio

Aqui vem a parte que consultoria séria precisa dizer: mais noves nem sempre é a resposta certa. Sair de 99.9% para 99.99% costuma significar multi-região, replicação síncrona, engenharia de caos e plantão estruturado. O custo pode multiplicar por vários, para reduzir o downtime anual de ~8h45 para ~52 minutos.

O Google formalizou essa racionalidade com error budgets: se o SLA é 99.9%, os 0.1% restantes são orçamento de risco, que se gasta com deploys, mudanças e experimentos. Estourou o orçamento? Congela lançamento e investe em confiabilidade. Sobrou? Dá para acelerar. Confiabilidade vira decisão de negócio, não religião.

A pergunta certa, então: quanto custa 1 hora do seu sistema fora do ar, em receita e em reputação? A resposta define quantos noves comprar. Um e-commerce em pico de campanha e um back-office interno não merecem a mesma arquitetura, e tudo bem.

Do diagnóstico ao SLA cumprido

Se você não sabe hoje quantos noves seu sistema entrega (ou descobriu que tem SPOFs demais), esse é o tipo de trabalho que fazemos no serviço de Cloud e Infraestrutura: mapa de pontos de falha, desenho de redundância que cabe no orçamento (com custo sob controle e infra como código) e testes de failover de verdade.

Quer estimar quantos noves seu sistema tem hoje? Descreva a arquitetura para a IA da Rabelo Digital, aqui no canto da tela, e ela aponta os pontos frágeis. Sem formulário, sem espera.

---

Leia também

• AWS vs Azure vs GCP: qual escolher para seu produto?
• Infraestrutura como Código com Terraform
• Quanto custa a nuvem de verdade, e como controlar