Alta disponibilidade: por que 99.9% de uptime não é suficiente

Por que o "uptime" é a métrica que mais mentiras conta

"Temos 99,9% de disponibilidade." É uma frase que soa a conquista, mas esconde uma verdade incómoda: 99,9% significa que um serviço pode estar indisponível durante 8 horas e 45 minutos por ano e, mesmo assim, cumprir o prometido. Para uma loja online que fatura €10.000 por hora, esse número traduz-se em até €87.500 de receita em risco anualmente — sem que ninguém tenha formalmente falhado nada.

A disponibilidade não é uma percentagem abstrata: é tempo, dinheiro e confiança. Este artigo destrincha o que os "noves" realmente significam, introduz o conceito de error budget usado pelas equipas de engenharia de confiabilidade do Google, e mostra — de forma concreta e com a arquitetura de um cluster real — como construir sistemas que continuam de pé quando as coisas correm mal.

O que os "noves" realmente significam

A indústria mede a disponibilidade em "noves" (do inglês, nines). Cada nove extra divide o tempo de indisponibilidade admissível por (quase) dez. A diferença entre 99,9% e 99,99% não é "um pouco melhor" — é passar de 8h 45m para 52 minutos de paragem por ano. A tabela e o gráfico abaixo mostram a duração máxima de interrupção admissível para cada patamar.

Nível de SLA	Downtime / dia	Downtime / mês	Downtime / ano
99% (2 noves)	14 min 24 s	~7 h 18 min	3 dias 15 h 36 min
99,9% (3 noves)	1 min 26 s	~43 min 48 s	8 h 45 min 36 s
99,95%	43 s	~21 min 54 s	4 h 22 min 48 s
99,99% (4 noves)	8,6 s	~4 min 22 s	52 min 33 s
99,999% (5 noves)	0,86 s	~26 s	5 min 15 s

Repare no detalhe: o salto de 99,9% para 99,999% reduz o downtime admissível cem vezes. É por isso que cada "nove" adicional custa exponencialmente mais em infraestrutura, processos e equipa.

O custo do downtime

O impacto financeiro varia brutalmente consoante o negócio. Usando um exemplo ilustrativo de um serviço que gera €10.000/hora de receita, o custo anual potencial do downtime permitido por cada SLA é o seguinte:

SLA	Downtime/ano	Custo potencial/ano (a €10k/h)
99%	3 dias 15 h 36 m	~€876.000
99,9%	8 h 45 min	~€87.600
99,99%	52 min	~€8.760
99,999%	5 min	~€876

Mas o custo não é só directo. Há custos indirectos dificilmente quantificáveis: perda de confiança, churn de clientes, equipa de suporte saturada,SLAs contratuais não cumpridos (com penalizações), e o efeito reputacional que dura muito para lá da própria interrupção.

SLI, SLO e SLA — e o orçamento de erro

Para gerir disponibilidade de forma rigorosa, as equipas de Site Reliability Engineering usam três conceitos distintos, popularizados pelo Google no livro Site Reliability Engineering:

• SLI (Service Level Indicator) — a medição objetiva: por exemplo, "pedidos HTTP bem-sucedidos / pedidos totais".
• SLO (Service Level Objective) — o alvo interno: "99,9% dos pedidos com sucesso, numa janela de 28 dias".
• SLA (Service Level Agreement) — o contrato externo com o cliente, tipicamente menos ambicioso do que o SLO, deixando margem de segurança.

O conceito que tudo une é o error budget (orçamento de erro): a diferença entre 100% e o SLO. Se o SLO é 99,9%, o orçamento de erro mensal é de ~44 minutos. Enquanto há orçamento, a equipa pode lançar features novas (assumir risco); quando o orçamento se esgota, o foco muda para estabilização. É um mecanismo elegantíssimo que transforma a fiabilidade numa decisão de produto, não num dogma técnico.

Como se constrói, na prática, alta disponibilidade

Alta disponibilidade não vem de "um servidor muito bom". Vem de remover pontos únicos de falha em cada camada — e de automatizar a recuperação.

1. Redundância em todas as camadas

Cada componente deve ter réplicas: load balancers em paralelo, várias réplicas da aplicação, bases de dados em primary-replica (ou multi-primary), e armazenamento replicado. Se um elemento morre, outro assume sem intervenção manual.

2. Orquestração com Kubernetes

Sistemas como Kubernetes (k3s, EKS, GKE, GKE) oferecem, de raio, as primitivas de resiliência:

• Auto-healing — pod em falha é recriado automaticamente noutro nó;
• Rolling updates — novas versões entram gradualmente, sem cortes;
• Health checks (liveness/readiness) — o tráfego só segue para instâncias saudáveis;
• Replicação e escalonamento — número de réplicas ajusta-se à carga.

3. Armazenamento resiliente

Os dados são, quase sempre, o bem mais valioso. Armazenamento distribuído como Longhorn, Ceph ou Rook replica cada volume por vários nós; se um disco ou uma máquina falha, os dados continuam acessíveis. Snapshots regulares dão rollback e proteção contra ataques (incluindo ransomware).

4. Multi-zona / multi-região

Para resiliência verdadeira, o serviço existe em mais do que uma zona de disponibilidade. Se um data center cai — por falha de energia, incêndio ou fibre cortada — o tráfego é reencaminhado para outra. Isto é caro, pelo que se reserva para cargas realmente críticas.

5. Observabilidade e resposta proativa

Não se pode melhorar o que não se mede. Pilhas como Prometheus + Grafana + Alertmanager, ou serviços como Uptime Kuma e Datadog, monitorizam SLIs em tempo real e disparam alertas antes de o utilizador notar. Defina runbooks e faça chaos engineering (ex.: encerrar um nó de propósito, em altura calma, para validar a recuperação).

No seu próprio cluster: o Raspberry Pi como laboratório

Não é preciso uma cloud pública para praticar estes princípios. Um cluster de três Raspberry Pi a correr k3s, com Longhorn (volumes replicados entre nós) e Traefik + cert-manager, já implementa a maior parte do que se descreveu: auto-healing, rolling deploys, redundância de dados e TLS automático. É um ambiente excelente para interiorizar, a baixo custo, os padrões que depois escalam para infraestruturas profissionais.

Conclusão

99,9% não é "quase perfeito" — é um compromisso que tolera quase 9 horas de paragem por ano. A questão certa não é "qual é o nosso uptime?", mas sim: "qual é o SLO que o nosso negócio exige, e como está a ser medido e defendido?". Alta disponibilidade constrói-se camada a camada, com redundância, automação e observabilidade — e começa, sempre, por olhar honestamente para os números.

Referências

• Google — Site Reliability Engineering (livro, gratuito): capítulo Service Level Objectives e conceito de error budget — sre.google/sre-book
• AWS — Well-Architected Framework, pilar Confiabilidade — docs.aws.amazon.com/wellarchitected
• Microsoft Azure — Resumo dos SLA por serviço — azure.microsoft.com/support/legal/sla
• B. Beyer et al., The Site Reliability Workbook, O'Reilly / Google (aplicação prática de SLOs e error budgets).