O que é HA de verdade
Alta disponibilidade (HA) é a capacidade de um sistema continuar operando mesmo quando um ou mais componentes falham. Não é sobre nunca falhar — é sobre fazer com que as falhas sejam invisíveis ou imperceptíveis para os usuários.
O conceito é frequentemente mal interpretado. Muitas empresas acham que HA é ter um servidor de backup guardado no armário. Não é. HA é uma arquitetura onde a falha de qualquer componente individual não causa indisponibilidade — porque outro componente assume automaticamente, sem intervenção humana.
Alta disponibilidade é medida como a proporção de tempo que um sistema está operacional. Um sistema com 99,9% de disponibilidade pode ficar fora do ar por no máximo 8,7 horas por ano. Com 99,99%, apenas 52 minutos por ano.
SLAs e os "noves" de disponibilidade
O mercado usa a expressão "noves" para descrever o SLA de disponibilidade:
| SLA | Nome | Downtime/ano | Downtime/mês |
|---|---|---|---|
| 99% | Dois noves | 87,6 horas | 7,3 horas |
| 99,9% | Três noves | 8,7 horas | 43 minutos |
| 99,99% | Quatro noves | 52 minutos | 4,3 minutos |
| 99,999% | Cinco noves | 5,2 minutos | 26 segundos |
A maioria das organizações brasileiras de médio porte opera adequadamente com 99,9% (três noves). Quatro noves e além exigem investimentos significativos em infraestrutura redundante e processos operacionais maduros.
Componentes de uma arquitetura HA
Uma arquitetura de alta disponibilidade elimina pontos únicos de falha (SPOF — Single Point of Failure) em cada camada:
Camada de rede
- Dois provedores de internet (failover automático via BGP ou DNS)
- Switches redundantes com LACP/bonding
- Balanceadores de carga em par ativo-passivo (HAProxy, Nginx)
Camada de aplicação
- Dois ou mais servidores de aplicação atrás de um load balancer
- Health checks configurados para remover instâncias com falha automaticamente
- Sessões armazenadas em cache externo (Redis) para permitir failover sem perda de sessão
Camada de dados
- Replicação de banco de dados (master-slave ou multi-master)
- Failover automático via Orchestrator (MySQL/MariaDB) ou Patroni (PostgreSQL)
- Storage redundante com DRBD ou volumes EBS multi-AZ em cloud
Camada de infraestrutura
- Múltiplas zonas de disponibilidade (cloud) ou data centers (on-premise)
- Energia redundante (geradores, nobreak duplo, dois circuitos)
- Monitoramento com alertas e runbooks automatizados
Custo-benefício
Implementar HA tem custo — tanto financeiro quanto operacional. A decisão deve ser baseada no custo da indisponibilidade para o negócio, não no desejo abstrato de "nunca cair".
Se uma hora de downtime custa R$ 5.000 para a empresa, investir R$ 2.000/mês em infraestrutura HA se paga em uma única falha evitada por ano.
A calculadora simples: multiplique o custo por hora de downtime pelo número de horas de indisponibilidade que você estima ter por ano com a arquitetura atual. Se esse número superar o custo anual da solução HA, o investimento se justifica.
Quando você realmente precisa de HA
Nem todo sistema precisa de HA. Alguns critérios que indicam a necessidade:
- O sistema é utilizado por clientes ou cidadãos em tempo real
- Transações financeiras dependem do sistema
- Indisponibilidade causa dano reputacional ou legal significativo
- A equipe operacional não pode garantir tempo de resposta rápido a incidentes
- A organização tem SLA contratual com usuários ou clientes
Para sistemas internos de baixo impacto, backup sólido e tempo de restauração de 2-4 horas pode ser suficiente e muito mais econômico.
Conclusão
Alta disponibilidade é um espectro, não um estado binário. A estratégia certa depende do impacto da indisponibilidade para a sua organização. A WSUL projeta arquiteturas calibradas para o nível de criticidade real de cada ambiente — sem superdimensionar e sem subestimar riscos.