Alta disponibilidade de sistemas: o que mantém tudo no ar

Segunda-feira, nove da manhã. O sistema de pedidos para de responder. Os vendedores ligam para o TI, o TI liga para o fornecedor, e alguém descobre que o único servidor do banco de dados ficou sem espaço em disco. O sistema volta depois do almoço. Ninguém perdeu dados, mas a manhã de vendas foi para a planilha e metade dos pedidos precisou ser redigitada à tarde.

A reação natural é pedir que isso "nunca mais aconteça". O problema é que "nunca cair" não é uma especificação técnica. Não existe sistema que nunca cai, e cada passo em direção a essa promessa custa mais esforço, mais infraestrutura e mais complexidade do que o anterior. A pergunta útil é outra: quanto tempo fora do ar a sua operação tolera, em quais funções e em quais horários?

Em resumo, alta disponibilidade de sistemas é a capacidade de continuar atendendo quando um servidor, um disco ou uma conexão falha, porque existe outra peça pronta para assumir. Este texto mostra como redundância, balanceamento e failover funcionam na prática e como decidir quanto disso o seu sistema realmente precisa.

O que é alta disponibilidade, em uma frase

Alta disponibilidade é a capacidade de um sistema continuar funcionando quando uma das suas partes falha. Ela não impede que o servidor queime, que a rede caia ou que o disco encha. Ela garante que, quando isso acontecer, outra parte assuma o trabalho rápido o bastante para que o usuário perceba pouco ou nada.

Na prática, isso se resume a três ideias:

• Ter mais de um de cada coisa importante (redundância).
• Distribuir o trabalho entre essas cópias (balanceamento).
• Trocar automaticamente para a cópia saudável quando uma falha (failover).

O que significa 99%, 99,9% e 99,99% no dia a dia

Disponibilidade costuma ser expressa em percentual do tempo em que o sistema está funcionando. Os números parecem todos altos, mas a diferença entre eles é grande quando convertida em tempo fora do ar:

Algumas leituras importantes dessa tabela:

• 99% parece muito, mas permite um dia inteiro parado por trimestre. Para um sistema interno usado em horário comercial, isso pode ser aceitável. Para a loja virtual, não.
• 99,99% significa que ninguém tem tempo de agir. Quatro minutos por mês não dão para alguém receber o alerta, abrir o notebook e entender o problema. Nesse patamar, a recuperação precisa ser automática.
• O percentual sozinho não diz nada sem a definição de "no ar". Se a tela abre, mas a emissão de nota fiscal falha, o sistema está disponível? A medição precisa olhar para as funções que importam para o negócio. Esse cuidado aparece também na hora de contratar; detalhamos isso no texto sobre o que exigir de um SLA de software.

Outro ponto pouco discutido: a disponibilidade de um sistema é limitada pela das partes de que ele depende. Se o seu sistema depende de um servidor de aplicação, de um banco de dados e de uma integração com o gateway de pagamento, e qualquer um deles parado derruba a venda, as indisponibilidades se somam. Três componentes razoavelmente estáveis, encadeados, resultam em um sistema menos estável do que cada um deles.

Quanto de disponibilidade o seu sistema precisa

Esta é a decisão que importa, e ela é de negócio, não de tecnologia. Cada nove a mais exige mais servidores, mais automação, mais testes e uma equipe preparada para operar tudo isso. Pagar por 99,99% em um sistema que só é usado de segunda a sexta, das oito às dezoito, é desperdício. Ficar em 99% numa operação que fatura de madrugada é risco.

Critérios para decidir

Responda a estas perguntas para cada sistema, ou melhor, para cada função crítica dentro dele:

1. O que deixa de acontecer quando ele para? Venda, faturamento, expedição, atendimento, produção, nada imediato?
2. Existe contingência manual? Dá para anotar pedidos em papel e lançar depois? Dá para expedir sem etiqueta do sistema? Contingência viável reduz a exigência.
3. Em que horários ele é usado? Sistema de horário comercial pode ter manutenção planejada à noite. Loja virtual e central de pedidos 24 horas não.
4. Quem é afetado: a equipe interna ou o cliente? Cliente parado na tela de pagamento costuma ir embora; colaborador parado costuma esperar.
5. Há obrigações contratuais ou regulatórias? Contratos com clientes, prazos fiscais ou exigências do setor podem impor um mínimo.
6. Quanto tempo de parada passa a ser grave? Dez minutos, uma hora, meio dia? Essa resposta define a meta mais do que qualquer percentual.

Exemplos de enquadramento

• Sistema interno de gestão de projetos, usado em horário comercial: um servidor bem monitorado, backup testado e um plano de restauração rápida costumam bastar.
• ERP que emite notas e controla estoque: vale redundância na aplicação, banco de dados com réplica e monitoramento das funções críticas. Uma parada de horas já trava a expedição.
• Loja virtual, aplicativo do cliente ou API usada por parceiros: aqui faz sentido redundância em todas as camadas, failover automático e servidores em mais de uma zona da nuvem.

Repare que o mesmo sistema pode ter partes com exigências diferentes. O módulo de relatórios pode ficar fora uma hora sem drama; a finalização da compra, não.

Pontos únicos de falha

Antes de falar em redundância, é preciso encontrar o que não tem. Um ponto único de falha é qualquer componente que, sozinho, derruba o sistema quando para. A maioria das empresas tem vários e não sabe.

Os mais comuns:

• Um servidor só rodando aplicação e banco de dados juntos.
• Banco de dados sem réplica, ou com réplica que nunca foi promovida em teste.
• Disco que enche sem alerta, como no exemplo da abertura.
• Certificado digital ou domínio que expira sem que ninguém seja avisado.
• Uma integração externa sem fila nem nova tentativa: se o parceiro cai, o seu sistema trava junto.
• Link de internet único no escritório ou na fábrica, quando o sistema é acessado de lá.
• Uma pessoa que é a única que sabe reiniciar o serviço ou onde fica a senha do servidor.

O último item é tão real quanto os outros. Disponibilidade também depende de documentação, acesso compartilhado e procedimento escrito.

Redundância, balanceamento e failover

Redundância

Redundância é ter cópias. Em vez de um servidor de aplicação, dois ou mais. Em vez de um banco, um principal e uma réplica. Em vez de tudo em um único data center, servidores em zonas diferentes da mesma região de nuvem, que ficam em instalações separadas, com energia e rede independentes.

Para que a redundância funcione, a aplicação precisa estar preparada. Se o sistema guarda a sessão do usuário na memória de um servidor específico, o usuário é deslogado quando aquele servidor cai. Se arquivos enviados ficam no disco local, a outra cópia não os enxerga. Parte do trabalho de alta disponibilidade é ajustar a aplicação para que qualquer cópia consiga atender qualquer pedido.

Balanceamento

O balanceador de carga é a porta de entrada. Ele recebe os acessos e distribui entre as cópias saudáveis da aplicação. Para saber quais estão saudáveis, ele consulta cada uma periodicamente por meio de uma verificação de saúde (o health check).

O detalhe que faz diferença: essa verificação precisa testar algo significativo. Um servidor que responde "estou vivo", mas não consegue falar com o banco, não está saudável. Uma boa verificação confirma que a aplicação consegue cumprir sua função principal.

Failover

Failover é a troca automática quando algo falha. No servidor de aplicação, costuma ser simples: o balanceador para de mandar acessos para a cópia doente. No banco de dados, é mais delicado, como veremos a seguir.

Failover manual também existe e, para muitos sistemas, é uma escolha sensata: alguém recebe o alerta, confirma o problema e executa um procedimento documentado. É mais lento, mas evita trocas indevidas por um alarme falso. A escolha entre automático e manual volta à pergunta de quanto tempo de parada é tolerável.

Banco de dados: o ponto mais delicado

Servidores de aplicação são, em geral, intercambiáveis. O banco de dados não, porque ele guarda o estado da empresa: pedidos, estoques, títulos, cadastros. Duplicar exige decidir como as cópias ficam sincronizadas.

• Replicação síncrona: cada gravação só é confirmada depois de chegar às duas cópias. Em princípio, nenhuma gravação confirmada se perde na troca, mas cada gravação fica um pouco mais lenta, e a distância entre as cópias pesa.
• Replicação assíncrona: o principal confirma a gravação e envia para a réplica logo depois. É mais rápida, mas, se o principal cair, as últimas gravações podem não ter chegado à réplica.

Há ainda o risco de as duas cópias acreditarem, ao mesmo tempo, que são a principal e aceitarem gravações diferentes. Isso gera dados divergentes difíceis de reconciliar. Os bancos gerenciados das grandes nuvens tratam boa parte disso por você, e costumam ser o caminho mais seguro para empresas que não querem manter especialistas em banco de dados de plantão.

Mesmo com tudo isso, o banco merece atenção a coisas simples: espaço em disco, crescimento de tabelas, consultas lentas que travam as outras, rotinas de manutenção. Muitas paradas vêm daí, e não de servidores queimados.

Disponibilidade não é recuperação de desastres

Uma confusão comum: achar que, com réplica e failover, o backup deixou de ser necessário. Não deixou.

Alta disponibilidade protege contra falhas de componente: um servidor que para, uma zona da nuvem com problema. Ela não protege contra erros que se replicam. Se alguém apaga uma tabela por engano, se um ransomware criptografa os dados ou se uma atualização corrompe registros, a réplica recebe o estrago em segundos.

Para esses cenários, o que salva é backup isolado, com versões, testado com restauração real, e um plano escrito de recuperação. As duas coisas se complementam:

Se o seu sistema ainda não tem esse segundo lado definido, vale começar pelo plano de recuperação de desastres, que ajuda a fixar quanto de dado e de tempo a empresa aceita perder em cada cenário.

Testar a falha antes que ela aconteça

Redundância que nunca foi testada é uma suposição. É comum descobrir, no dia da pane, que a réplica estava atrasada havia semanas, que o failover dependia de uma senha expirada ou que o balanceador não removia o servidor doente.

Checklist prático

Use esta lista para avaliar o sistema que você tem hoje:

1. Mapeie as funções críticas e defina, para cada uma, quanto tempo de parada é tolerável e em quais horários.
2. Desenhe o caminho de uma operação crítica (por exemplo, do clique em "finalizar pedido" até a gravação no banco) e marque cada componente envolvido.
3. Identifique os pontos únicos de falha nesse caminho, incluindo pessoas e credenciais.
4. Priorize os pontos que derrubam funções críticas e que têm maior chance de falhar.
5. Monitore o que importa: verificações que simulam a operação real, alertas de disco, de certificado e de atraso da réplica. Sem visibilidade, a falha é descoberta pelo cliente; o texto sobre observabilidade com logs, métricas e traces mostra como montar essa base.
6. Escreva o procedimento de failover e de restauração, com responsáveis e acessos.
7. Teste em ambiente controlado: desligue um servidor de aplicação, promova a réplica do banco, simule a queda de uma integração. Meça quanto tempo levou e o que quebrou.
8. Repita periodicamente, e sempre depois de mudanças grandes na arquitetura.
9. Registre cada incidente real com causa, tempo de detecção e tempo de recuperação, e use isso para ajustar as metas.

O objetivo não é provocar crise, é transformar uma falha desconhecida em um procedimento conhecido. E vale lembrar: uma meta que a equipe não consegue operar tende a falhar de formas novas, então a arquitetura precisa caber na capacidade de quem cuida dela.

Perguntas frequentes

Qual a diferença entre alta disponibilidade e backup?

Alta disponibilidade protege contra falha de componente, como servidor, disco ou zona da nuvem, com cópias prontas para assumir. Backup protege contra erros que se replicam, como exclusão acidental, ransomware ou dado corrompido, que chegam à réplica em segundos. Um não substitui o outro: sistemas críticos precisam dos dois, com backup isolado e testado.

Failover automático é sempre melhor que o manual?

Não necessariamente. O failover automático troca para a cópia saudável em segundos e é indispensável em metas muito altas, como 99,99%. O failover manual, com alerta e procedimento documentado, é mais lento, mas evita trocas indevidas causadas por alarme falso. A escolha depende de quanto tempo de parada a operação tolera.

Hospedar o sistema na nuvem garante alta disponibilidade?

Não por si só. A nuvem oferece zonas separadas e bancos de dados gerenciados que facilitam a redundância, mas a aplicação precisa estar preparada para rodar em mais de uma cópia, sem guardar sessão ou arquivos no disco de um servidor específico. Um sistema em servidor único na nuvem continua sendo um ponto único de falha.

Por onde começar a melhorar a disponibilidade de um sistema existente?

Comece mapeando as funções críticas e o caminho de uma operação, como finalizar um pedido, até a gravação no banco. Marque cada componente, inclusive pessoas e credenciais, e identifique o que derruba tudo quando para. Priorize esses pontos, monitore o que importa e teste a falha em ambiente controlado antes de ampliar a infraestrutura.

Como a Pervian Tech trabalha alta disponibilidade

Na Pervian Tech, começamos pela pergunta de negócio: quais funções não podem parar, em quais horários e por quanto tempo uma parada é aceitável. A partir disso, mapeamos o caminho de cada operação crítica, encontramos os pontos únicos de falha e propomos a menor arquitetura que atende à meta, sem duplicar o que não precisa.

O trabalho faz parte do nosso serviço de cloud e DevOps e inclui ajustes na aplicação para rodar em mais de uma cópia, banco de dados com réplica e failover definidos, monitoramento das funções que importam, procedimentos escritos e testes de falha em ambiente controlado. Prazos dependem do ponto de partida e são definidos depois do diagnóstico; outros temas de infraestrutura estão reunidos na categoria cloud e infraestrutura.

Cada operação tem criticidade própria, então o projeto é sob medida e o investimento é sob consulta, depois de um diagnóstico inicial gratuito. Se o seu sistema ainda depende de um servidor só ou de uma pessoa só para voltar ao ar, conte como ele funciona hoje.