HEROCTL
[Alta disponibilidade]

Alta disponibilidade real: o que o cliente B2B exige

A diferença entre "tá no ar" e "tá no ar quando o cliente assina o contrato".

O primeiro cliente B2B grande não pede feature. Pede SLA. E o SLA dele é assinado, com multa contratual, calculado em horas/mês de indisponibilidade. Esta página agrega tudo que escrevemos sobre operar uma aplicação que sustenta 99,9% real — não single-server feliz, não multi-server fake, mas plano de controle replicado, eleição automática, deploy seguro e backup que sobrevive ao pior cenário.

TL;DR

Alta disponibilidade não é "ter dois servidores". É um contrato técnico: o sistema continua respondendo quando qualquer componente individual falha. Single-server falha redondo no primeiro hardware morto. Painéis self-hosted populares (Coolify, Dokploy single-mode) entregam HA fake — replicam dados, mas o painel central sobre eles é ponto único de falha. HA real exige plano de controle replicado em 3+ nós, eleição automática de líder em segundos, rolling deploy que aborta sozinho se a versão nova quebra health check, e backup com janela mensurável (RPO < 5 min) testado em recuperação real. Os quatro posts agregados cobrem exatamente esses degraus: o que comparar entre painéis simples, deployer minimalista, processo de rolling deploy seguro e estratégias de backup pra cluster que ninguém quer descobrir às 3 da manhã.

[01]

Painel self-hosted simples sustenta SLA contratual de 99,9%?

A pergunta separa o segmento. Coolify e Dokploy entregam UX excelente e instalação em 5 minutos — mas seu plano de controle não é replicado. Quando o painel cai, o cluster vira deploy estático: não consegue self-healing, não consegue novo deploy, não consegue reagir a tráfego. Pra cliente que pediu SLA por escrito, é jogo encerrado.

Leia o post completo
HeroCtl vs Coolify: o degrau da alta disponibilidade →
  • →Multi-server ≠ cluster com consenso
  • →Painel central caído = sem self-healing, sem novo deploy
  • →Eleição automática em ~7s vs intervenção manual
[02]

Por que Kamal e os deployers minimalistas batem na parede no segundo cliente?

Kamal foi a resposta técnica certa pra um problema legítimo: complexidade de Kubernetes pra app monolítica em 1 VPS. A premissa "you don't need orchestration" funciona pros 75% dos casos onde 30 segundos de downtime mensal não doem. Cai exatamente quando: cliente exige SLA, segundo servidor entra na conta, ou rolling deploy precisa ser realmente seguro com auto-revert.

Leia o post completo
HeroCtl vs Kamal: cluster real depois do single-server →
  • →Kamal multi-server = deploy paralelo a hosts independentes
  • →Sem health check antes de promover novo container
  • →VPS cai = downtime total (zero failover)
[03]

Por que o seu rolling deploy talvez não seja realmente seguro?

A maioria dos times acha que tem rolling deploy porque a ferramenta tem um botão chamado "rolling". Na prática: sem health check próprio (não confunda com TCP probe), sem espera por traffic drain, sem auto-revert quando a versão nova falha — não é rolling deploy, é "deploy sequencial com torcida". A diferença aparece na primeira sexta-feira 17h.

Leia o post completo
Rolling deploy seguro: por que o seu talvez não seja →
  • →Health check de aplicação é mandatório, não opcional
  • →Auto-revert pede comparação 2xx histórica vs nova
  • →Drain de tráfego antes de derrubar instância antiga
[04]

O que fazer com o backup quando o banco fica fora às 3 da manhã?

HA do plano de controle não cobre o banco de dados. Backup mal estratégia é o ponto cego mais comum em SaaS de tamanho médio: snapshot diário no S3 sem teste de recuperação, replicação síncrona sem failover automático, ou dump por cron job sem rotação. Levantamos as estratégias que sobrevivem aos cenários reais, com tempos de recuperação mensurados.

Leia o post completo
Backup de banco em cluster: estratégias pra 3 da manhã →
  • →Snapshot ≠ backup (não testou, não tem)
  • →RPO < 5 min pede WAL shipping contínuo
  • →Recovery time real: meça antes do incidente
[05]

Como saber se o seu cluster aguentaria queda de um nó agora?

A única forma honesta é derrubar um nó de propósito e medir. Toda arquitetura HA séria tem uma rotina de chaos drill — desligar a máquina mais carregada em horário de pico e cronometrar o tempo até o sistema voltar ao normal. Se você nunca fez, seu HA é teórico. As métricas que importam: tempo de eleição, tempo de re-roteamento de tráfego, % de requisições com erro durante o evento.

Leia o post completo
Como rodar o seu primeiro chaos drill →
  • →Eleição automática deve fechar em < 10s
  • →Tráfego deve re-rotear sem requisição perdida
  • →Documente o resultado e re-teste a cada release maior
[ferramentas]

Ferramentas relacionadas

HeroCtl vs Coolify →
O degrau quando painel single-server não basta
HeroCtl vs Kamal →
Quando deployer simples vira limitação
Documentação completa →
Configuração de cluster, backup, deploy
Calculadora de custo →
Estimativa pro cluster mínimo HA real
[perguntas]

Perguntas que aparecem em todo planejamento

Qual o número mínimo de servidores pra alta disponibilidade real?

Três. Plano de controle replicado precisa de quórum (maioria) — com dois nós, qualquer falha quebra o quórum e o cluster vira somente leitura. Três nós toleram a queda de um e mantêm operação plena. Cinco nós toleram dois — caro pro tamanho médio, padrão pro grande.

SLA de 99,9% representa quanto de downtime aceito por mês?

Cerca de 43 minutos por mês, ou 8 horas e 45 minutos por ano. SLA de 99,99% (quatro noves) cai pra 4 minutos/mês — só faz sentido pra aplicações financeiras ou de comunicação onde minuto extra dói monetariamente.

Posso ter HA com 2 servidores se um deles for "ativo" e o outro "passivo"?

Não no sentido contratual. Failover ativo-passivo manual (ou semi-manual via DNS) tem janela de detecção e promoção que costuma passar dos 10 minutos — e durante a janela, requisições caem. Pra SLA de 99,9%, você sai do orçamento de downtime em uma única falha por mês. Cluster ativo-ativo de 3+ nós é o mínimo viável.

Backup precisa de outra estratégia além de snapshot do disco?

Sim, sempre. Snapshot do disco é cópia consistente de bytes, mas pra banco transacional precisa snapshot consistente da aplicação (file system freeze ou WAL flush). Snapshot diário sem WAL contínuo te dá RPO de 24h — se o cliente perde 1 dia de dados, é incidente regulatório em vários setores. WAL shipping contínuo derruba RPO pra menos de 5 minutos.

Como medir se rolling deploy está funcionando bem?

Três métricas durante o deploy: taxa de erro 5xx (deve ficar zero ou perto), latência p99 (não deve subir mais de 10%), e tempo total do deploy (deve ser previsível — variação grande indica health check inconsistente). Se uma das três falha, o deploy aborta e auto-reverte.

Chaos drill em produção é seguro?

É, se planejado. Faça em janela combinada, em horário de tráfego razoável (não pico, não vale), com a equipe inteira em call. O ganho é descobrir os pontos cegos antes do cliente — toda startup que medimos descobriu pelo menos uma surpresa no primeiro drill. O custo de não fazer é descobrir no fim de semana.

Vale a pena pagar Business ou Enterprise pra ter SLA de fornecedor sobre HA?

Pra cliente B2B regulado (financeiro, saúde, governo), vale — eles vão pedir. O contrato comercial publicado e o suporte humano por dentro do produto tira você do "você que se vire" do open-source puro. Pra startup early-stage sem cliente regulado, o tier Community resolve.

HA real começa no degrau seguinte

Se a próxima conversa comercial vai pedir SLA contratual, single-server e painel não-replicado já saíram da equação. Compare os caminhos e escolha pelo critério honesto.

Comparar com Coolify → Outros temas →
Posts agregados nesta página
HeroCtl vs Coolify: comparativo direto →
HeroCtl vs Kamal: comparativo direto →
Rolling deploy seguro: por que o seu talvez não seja →
Backup de banco em cluster: estratégias pra 3 da manhã →