Alta disponibilidade na prática: o que está por trás dos 99,999% de uptime

Disponibilidade de sistema tem uma matemática implacável que vale a pena memorizar antes de qualquer conversa de SLA. 99% de uptime parece muito? São 3 dias e 15 horas de queda por ano. 99,9% — o famoso três noves — corta para 8 horas e 45 minutos. 99,99% baixa para 52 minutos. 99,999%, os cinco noves, são pouco mais de 5 minutos por ano inteiro.

Cada nove adicional custa exponencialmente mais em infraestrutura, engenharia e operação. Não existe disponibilidade infinita. Existe a disponibilidade certa para o seu negócio — e a engenharia que entrega ela.

Por onde sistemas caem (em ordem de frequência real)

Em duas décadas de incidentes públicos analisados — Google SRE Book, post-mortems publicados por Stripe, GitHub, Cloudflare, AWS, Fastly — a distribuição das causas é surpreendentemente consistente:

• Mudança de código mal testada: cerca de 70% dos incidentes. Alguém fez deploy, alguma coisa quebrou.
• Configuração errada: 10 a 15%. Variável de ambiente, DNS, certificado expirado, regra de firewall, limite de quota.
• Falha de dependência externa: cerca de 10%. API de terceiros caiu, gateway de pagamento travou, serviço de e-mail engasgou.
• Hardware ou rede: cerca de 3%. Disco enchendo, memória corrompida, link entre datacenters intermitente.
• Causa rara, genuinamente inesperada: 2 a 3%. O evento que ninguém modelou e que só faz sentido depois que aconteceu.

A tradução prática é importante: se você quer subir uptime, foque em deploy, configuração e dependências. Não foque em hardware, porque infraestrutura em nuvem moderna já resolveu essa parte. Investir em redundância de hardware quando o problema é deploy ruim é gastar dinheiro no lugar errado.

Camada 1 — Deploy sem medo

Cada deploy é uma oportunidade para quebrar tudo. A solução não é deployar menos (isso é um anti-padrão clássico), é deployar com rede de proteção. Quatro práticas baratas que cortam a maior parte dos incidentes:

Pipeline de CI/CD com testes obrigatórios. Nenhum código vai para produção sem passar pela bateria automatizada de testes. Pull request não pode ser mergeado se algum teste falha, e a pessoa que tenta forçar tem que escrever justificativa no review. Cultura, não só ferramenta.

Deploy gradual (canary release). Código novo vai primeiro para 1% das instâncias, depois 10%, depois 100%. Se a taxa de erro sobe durante a transição, o deploy é abortado automaticamente — antes mesmo de alguém perceber. O usuário afetado é uma fração pequena por um curto período, não toda a base.

Rollback em segundos, não em minutos. Um comando, sem hesitação. Se algo cheirou estranho — taxa de erro subiu, latência aumentou, alerta disparou — volta para a versão anterior agora, investiga depois. O custo de um rollback desnecessário é zero; o custo de uma indecisão de 15 minutos com sistema degradado é alto.

Feature flags separando deploy de release. O deploy de código novo não é a mesma coisa que ativar a feature para o usuário. Bugs novos viram flag desligada, não incidente.

Camada 2 — Arquitetura que aguenta

Mesmo com deploy perfeito, hardware morre, rede oscila, DNS expira, certificado vence. O sistema precisa estar desenhado para tolerar isso — não como adição posterior, mas como princípio desde o primeiro commit.

Múltiplas instâncias por padrão. Nada que importa roda em apenas um servidor, em apenas uma zona de disponibilidade. Mínimo: duas instâncias em zonas diferentes. Se uma cai, o balanceador de carga redireciona automaticamente, e o usuário final não percebe.

Banco com replicação contínua. O banco primário tem uma réplica em standby, sincronizada em tempo quase real. Em caso de falha do primário, promoção automática em menos de um minuto. Para sistemas críticos (financeiro, pagamentos), múltiplas réplicas e backup contínuo com point-in-time recovery.

Circuit breakers. Quando uma dependência (gateway, API externa, microserviço interno) começa a falhar repetidamente, o sistema para de chamar ela por alguns segundos. Em vez de continuar afogando o serviço já com problema, dá tempo para ele se recuperar. Pattern simples, salva incidentes inteiros.

Retries com backoff exponencial e idempotência. Falhou na primeira chamada? Tenta de novo em 1 segundo. Falhou de novo? Em 2 segundos. Em 4, em 8, em 16. Não martela o serviço já caído. E idempotência garante que repetir uma operação não causa efeito duplicado — crítico em pagamentos.

Disponibilidade não é uma escolha de tecnologia. É uma escolha de design, feita em cada decisão pequena desde o primeiro commit.

Camada 3 — Observabilidade que avisa antes do cliente

O pior tipo de incidente é aquele que você descobre pelo telefone do cliente tocando. O segundo pior é o que você descobre olhando um gráfico aleatório por acaso. O melhor é o que o sistema te avisa antes mesmo de virar problema visível para o usuário final.

Métricas-chave que monitoramos em todo sistema crítico:

• Latência percentil 50, 95 e 99. A maioria dos usuários, os usuários com experiência ruim, os usuários com experiência péssima. O p99 é o que vira reclamação.
• Taxa de erro (códigos 5xx). Se sobe acima do baseline, alguma coisa quebrou agora — e o alerta dispara antes do cliente abrir ticket.
• Throughput em requisições por segundo. Queda súbita sem motivo aparente geralmente significa que alguma coisa antes do servidor (CDN, balanceador, DNS) está com problema.
• Saturação de recursos: CPU, memória, conexões de banco, profundidade de fila. 80% sustentado por mais de alguns minutos = problema iminente.
• Saúde das dependências externas: o gateway de pagamento responde em quanto tempo? E o banco? E o serviço de SMS? Cada dependência é um risco rastreado.

Alertas baseados em desvio do normal, não em valor absoluto arbitrário. "Latência acima de 500ms" é um número escolhido sem critério. "Latência 3 desvios padrão acima da média da última semana neste mesmo horário" é informação acionável de verdade.

Camada 4 — Pessoas preparadas, não improviso

Tecnologia sozinha não mantém uptime. Pessoas em plantão, com procedimentos claros e treinamento de incidente, fazem a diferença entre 5 minutos de queda e 5 horas. Quatro práticas operacionais:

• Runbook por cenário. Documentação operacional separada por tipo de incidente: "banco não responde", "gateway timeout", "fila acumulando", "deploy travado". Cada um com passos claros e ordem de ação.
• Rotação de plantão (on-call) justa. Ninguém de plantão duas semanas seguidas. Saúde mental do time é fundamental — quem está cansado erra mais.
• Post-mortem sem culpado. Depois de cada incidente, análise técnica honesta. O que falhou? Por quê? Como evitar? Foco em sistema, não em culpa pessoal.
• Game days e exercícios. Simulamos incidentes em ambiente de staging para treinar o time. Já encontramos runbooks errados, atalhos quebrados, e dependências esquecidas — antes de virar incidente real.

Quanto custa cada "nove" — escolhendo o nível certo

Subir de 99% para 99,9% (de 3,65 dias para 8h45min de queda anual) custa relativamente pouco: deploy gradual + replicação básica + observabilidade. Faixa de R$ 5 a 15 mil/mês em infraestrutura para um sistema de porte médio. É o nível mínimo recomendável para qualquer negócio sério online.

Subir de 99,9% para 99,99% (de 8h45min para 52min) custa muito mais: replicação multi-região, failover automático testado regularmente, equipe 24/7 ou pelo menos plantão noturno bem estruturado. Faz sentido para fintech, e-commerce de alto volume, sistemas que processam dinheiro real em tempo real.

Subir de 99,99% para 99,999% (de 52min para 5min) é território de bancos, sistemas de telecomunicação, infraestrutura crítica. Custa caríssimo e raramente vale para um software de negócio comum. Quem promete cinco noves sem cobrar o preço dos cinco noves está prometendo o que não consegue entregar.

O que faz sentido para o seu caso

Pergunta honesta para fazer ao seu fornecedor de software (e a si mesmo): quanto custa em receita um minuto de queda do seu sistema, no pior horário possível?

Se a resposta for R$ 100, 99% de uptime é suficiente. Se for R$ 10 mil, vale investir em 99,9%. Se for R$ 100 mil, persegue 99,99%. Engenharia útil é proporcional ao impacto financeiro real, não ao desejo abstrato de "ter sistema bom". Esse cálculo simples evita gasto desnecessário e também evita economia em lugar errado.

O que entregamos por padrão em todo projeto

• Deploy automatizado com testes bloqueando merge.
• Múltiplas instâncias por padrão, sem ponto único de falha conhecido.
• Banco com replicação ativa e backup contínuo com retenção configurável.
• Observabilidade completa: logs estruturados, métricas, alertas em Slack ou WhatsApp.
• Runbooks documentados — o seu time também consegue operar, não fica refém do fornecedor.
• Post-mortem sem culpa após cada incidente significativo, compartilhado com você.

Em Foz do Iguaçu, atendendo o mercado trinacional, construímos infraestrutura que aguenta o Black Friday do e-commerce, a virada de mês do ERP financeiro e o pico de fim de tarde que derruba sistema mal projetado. Não porque é mágica — porque foi desenhada para isso desde o início.

Pronto para um sistema que se mantém de pé?

Se você está cansado de acordar com sistema fora do ar, ou de prometer SLA que não consegue cumprir, ou de gastar com infraestrutura sem saber se está pagando o que precisa pagar — vamos desenhar uma arquitetura que aguente o uso real do seu negócio. Conversa sem compromisso, diagnóstico sem custo na primeira hora.