Quando uma empresa decide montar infraestrutura própria — seja um servidor dedicado, um cluster Docker, uma stack Kubernetes ou um ambiente de IA self-hosted — a conversa costuma girar em torno de custo por hora de processamento e latência. O que raramente aparece nessa conta é o custo do momento em que tudo para. E ele para. A questão não é se, mas quando. Ter um runbook, um plano de backup testado e alguém que atende às 2h da manhã é o que separa uma operação profissional de uma aposta.
Resumo rápido: Infraestrutura própria entrega controle, custo previsível e privacidade de dados, mas exige três pilares operacionais: uptime monitorado ativamente, runbook documentado para cada cenário de falha e backup que você já restaurou pelo menos uma vez. Sem esses três, a infra própria vira um risco operacional, não um ativo.
O Que Custa, de Fato, Uma Hora de Sistema Fora do Ar?
A pergunta parece simples. A resposta costuma ser desconfortável.
Segundo o relatório ITIC 2024 Hourly Cost of Downtime, uma hora de downtime não planejado custa mais de US$ 300.000 para mais de 90% das empresas de médio e grande porte. Mesmo para pequenas e médias empresas, o mesmo estudo aponta perdas de US$ 25.000 ou mais por hora — e isso antes de contabilizar dano de reputação, perda de SLA com clientes e o desgaste do time que passa a madrugada tentando recuperar um ambiente sem documentação.
O problema é que o custo do downtime é invisível até acontecer. Ninguém provisiona servidor pensando em falha. A infra aparece no radar quando está funcionando. A conta chega quando para.
Três fontes de custo que costumam ser subestimadas:
- Perda de receita direta: pedidos não processados, transações não concluídas, contratos não assinados
- Custo de recuperação: horas de engenheiro, eventual contratação emergencial, licenças de suporte avulso
- Custo de reputação: clientes que não voltam, avaliações negativas, renegociação de SLA com penalidade
O Que É Uptime Real e Como Ele É Medido?
Uptime é a porcentagem de tempo em que um sistema está disponível e funcional dentro de um período. O número que você mais vai encontrar em SLAs de infraestrutura é 99,9% — os famosos "três noves". Parece alto. Na prática, significa até 8 horas e 45 minutos de indisponibilidade acumulada por ano.
Veja como os noves se traduzem em tempo de inatividade permitido:
| SLA de uptime | Downtime permitido por ano | Downtime permitido por mês |
|---|---|---|
| 99% (dois noves) | 3 dias 15 horas | 7 horas 18 min |
| 99,9% (tres noves) | 8 horas 45 min | 43 min |
| 99,95% | 4 horas 22 min | 21 min |
| 99,99% (quatro noves) | 52 min | 4 min |
| 99,999% (cinco noves) | 5 min | 26 seg |
Dois erros frequentes ao falar de uptime:
Confundir disponibilidade com funcionamento. Um servidor pode estar "no ar" mas com CPU travada em 100%, banco de dados recusando conexões ou API retornando erro 500 em todas as requisições. Uptime real mede se o sistema entrega o que deve entregar, não apenas se a máquina responde a um ping.
Confiar em monitoramento reativo. Se você descobre que o sistema caiu porque um cliente ligou, o seu monitoramento não está funcionando. Uptime real exige checks ativos a cada 30 ou 60 segundos, com alerta imediato para quem pode agir.
O Que É um Runbook e Por Que Ele Salva a Operação às 2h da Manhã?
Runbook é um documento operacional que descreve, passo a passo, como responder a cada cenário de falha ou operação de rotina em um sistema. Pense nele como o roteiro que qualquer membro do time consegue seguir — com cabeça fria ou às 2h da manhã — para resolver um problema sem improvisar.
A analogia mais direta: pilotos de avião não improvisam em emergência. Eles abrem a checklist. O runbook é a checklist da sua infraestrutura.
Um runbook bem feito para infraestrutura própria cobre no mínimo:
- Procedimentos de reinicialização: como reiniciar cada serviço na ordem correta sem gerar dependências quebradas
- Cenários de falha de banco: o que fazer quando o PostgreSQL não sobe, quando há lock de transação, quando o disco enche
- Processos de rollback: como voltar para a versão anterior de uma aplicação após um deploy problemático
- Contatos de escalonamento: quem chamar primeiro, segundo e terceiro, com telefone e horário de disponibilidade
- Procedimentos de backup e restore: onde estão os backups, como restaurar, qual é o tempo esperado de recuperação
Exemplo de estrutura de entrada em um runbook:
Incidente: Banco de dados PostgreSQL não responde
Sintoma: API retornando timeout / erro de conexão
Severidade: P1 (impacto direto em produção)
Passo 1: Verificar status do processo
systemctl status postgresql
Passo 2: Checar logs de erro
journalctl -u postgresql -n 100 --no-pager
Passo 3: Verificar uso de disco (fill-up é causa comum)
df -h /var/lib/postgresql
Passo 4: Se processo morto, tentar restart controlado
systemctl restart postgresql
Passo 5: Se não subir, escalar para DBA de plantão
Contato: [nome] — [telefone]
Abrir incidente no canal #infra-p1
Sem esse documento, cada incidente se torna uma expedição de investigação. Com ele, o tempo de resolução cai de horas para minutos.
Backup Que Ninguém Testou Não É Backup
Esta é a verdade mais inconveniente da operação de infraestrutura: a maioria dos backups que "existem" nunca foi restaurada. E um backup não testado é teoria, não segurança.
Os três cenários clássicos de falha de backup que aparecem nos piores momentos:
O backup estava sendo feito do lugar errado. O script apontava para o diretório de desenvolvimento, não para o de produção. Os dados reais nunca foram copiados.
O backup estava corrompido. Arquivo de dump incompleto porque o banco estava em lock no momento da cópia, ou porque o disco de destino estava cheio e o processo falhou silenciosamente.
O backup existe mas o processo de restore leva 14 horas. E ninguém sabia disso até precisar. O RTO (Recovery Time Objective — quanto tempo você tem para restaurar) não combina com o tempo real de recuperação.
Uma estratégia de backup mínima para infraestrutura própria:
- 3-2-1: três cópias dos dados, em dois tipos de mídia diferentes, uma offsite (ou em cloud separada)
- Frequência adequada ao RPO: se você tolera perder no máximo 4 horas de dados (RPO de 4h), o backup precisa rodar a cada 4 horas
- Restore testado mensalmente: restaurar para um ambiente de staging e validar integridade dos dados, não apenas a existência do arquivo
- Criptografia em repouso e em trânsito: backup descriptografável por terceiros é risco de segurança, não proteção
A pergunta que qualquer responsável por infraestrutura precisa conseguir responder sem hesitar: "Se o servidor principal morrer agora, em quanto tempo estou de volta e quantos dados perco?" Se a resposta for "não sei ao certo", o backup não está pronto.
Quem Responde Quando Cai? O Problema do Plantão
Imagine que são 2h17 da manhã de uma segunda-feira. O sistema de pedidos da sua operação parou. O gateway de pagamento retorna erro. Os pedidos não estão sendo registrados.
Nesse momento, quem você liga?
Se a resposta for "o desenvolvedor que fez o deploy ontem" ou "vou esperar amanhecer para ver o que aconteceu", você está operando sem plantão. E sem plantão, o custo do downtime noturno não é uma hora — é seis, oito horas, até o horário comercial.
Plantão 24x7 para infraestrutura não é luxo de grande empresa. É um requisito para qualquer operação que processa transações, atende clientes ou tem obrigações contratuais de disponibilidade.
Os elementos mínimos de um plantão funcional:
- Alerta ativo: o sistema chama o responsável, não o contrário. Pager, SMS, chamada de voz — o alerta precisa acordar quem deve agir
- Tempo de resposta definido e documentado: o SLA interno diz "reconhecer o alerta em 5 minutos, primeira ação em 15 minutos"
- Escalonamento em camadas: se o primeiro responsável não confirma em 5 minutos, o sistema chama o segundo automaticamente
- Runbook acessível: o responsável de plantão acessa o runbook pelo celular, sem precisar de VPN ou credencial especial armazenada apenas em memória
Trabalhamos com uma empresa de e-commerce que tinha servidor próprio e "alguém que olhava de vez em quando". Em uma madrugada de promoção relâmpago, o banco de dados travou por lock de transação — resolução de 8 minutos com runbook. Sem documentação, o incidente se arrastou por 3h40min e custou aproximadamente R$ 47.000 em pedidos perdidos. O runbook foi implementado na semana seguinte.
SLA Real x Promessa de Uptime: Como Distinguir
Todo fornecedor de infraestrutura promete uptime alto. A diferença entre promessa e SLA real está nos detalhes contratuais — especificamente, no que acontece quando a promessa não é cumprida.
Perguntas que revelam se um SLA é real ou marketing:
- O que conta como downtime? Manutenção programada entra no cálculo? Degradação parcial é computada?
- Qual é o mecanismo de crédito? Downtime de 30 minutos gera quanto de crédito na fatura? É automático ou requer abertura de chamado?
- Qual é a janela de medição? SLA medido por mês tem comportamento diferente de SLA medido por trimestre.
- Há penalidade financeira real? Crédito de 10% da mensalidade por uma hora de downtime que custou R$ 50.000 à empresa não é penalidade — é cortesia.
Para infraestrutura própria gerenciada, o SLA precisa cobrir não apenas disponibilidade do servidor, mas tempo de resposta ao incidente, tempo de restauração de backup e janela de manutenção previamente acordada.
Quando Faz Sentido Infraestrutura Dedicada Versus Cloud Genérica?
A cloud genérica (AWS, Azure, GCP) resolve muitos problemas com velocidade e sem equipe de infra dedicada. Mas ela não é a resposta para todos os cenários. Avaliar quando a infraestrutura própria ou dedicada faz sentido é uma decisão técnica e de negócio.
Sinais de que infraestrutura dedicada faz sentido:
- Dados que não podem sair da sua rede: registros médicos, dados financeiros detalhados, propriedade intelectual. Se você está avaliando rodar IA com esses dados, veja IA self-hosted x nuvem para entender o trade-off completo
- Volume previsível e alto: acima de determinado uso, o custo por hora de compute em cloud supera o custo de um servidor dedicado
- Latência crítica: aplicações que precisam de resposta em menos de 10ms beneficiam de hardware fisicamente próximo ao usuário
- Conformidade regulatória específica: setores com regulação de residência de dados (saúde, financeiro, governo) podem ter obrigações que tornam a cloud pública inviável sem arquitetura complexa
- Dependência de workload específico: modelos de IA rodando GPU, processamento de vídeo, renderização — cargas que em cloud pública têm custo variável alto e imprevisível
Sinais de que a cloud genérica ainda é a escolha certa:
- Volume variável ou imprevisível, onde pagar pelo uso é mais eficiente que provisionar para o pico
- Time sem capacidade de operar infra — um servidor dedicado sem administração competente é pior que cloud
- Fase de prototipagem onde o overhead operacional impede a velocidade de iteração
A pergunta certa não é "cloud ou infra própria". É: "dado o meu volume, os meus dados e o meu time, qual modelo de operação entrega mais confiabilidade pelo custo total?"
Para orquestração de automações que conectam serviços nessa infraestrutura, o que é n8n explica como a ferramenta funciona tanto em cloud quanto em ambiente self-hosted.
Perguntas Frequentes
O que é RTO e RPO e por que importam para minha infra?
RTO (Recovery Time Objective) é o tempo máximo aceitável para restaurar o sistema após uma falha. RPO (Recovery Point Objective) é a quantidade máxima de dados que você tolera perder. Definir esses dois números antes de configurar o backup é o que determina a frequência e a estratégia de cópia necessária para a sua operação.
Preciso de um runbook mesmo com equipe pequena?
Sim, especialmente com equipe pequena. Quanto menor o time, maior o risco de o único responsável estar indisponível no momento do incidente. O runbook garante que outra pessoa consiga atuar com o mesmo nível de eficiência, sem depender de memória ou experiência acumulada de quem construiu o ambiente.
Qual é a diferença entre monitoramento de uptime e monitoramento de performance?
Monitoramento de uptime verifica se o sistema está acessível e respondendo. Monitoramento de performance mede tempo de resposta, uso de CPU/memória e throughput. Ambos são necessários: um sistema "no ar" com 8 segundos de latência é operacionalmente equivalente a estar fora do ar para a maioria dos usuários.
Backup em nuvem é suficiente para infraestrutura própria?
Backup em nuvem é uma das cópias da estratégia 3-2-1, não a estratégia completa. O ponto crítico não é onde o backup está, mas se ele foi testado com restore real. Um backup em nuvem nunca restaurado oferece a mesma segurança operacional que nenhum backup.
Com que frequência devo revisar e testar o runbook?
Revisar após cada incidente real e testar formalmente a cada trimestre é o mínimo. Toda mudança significativa na infraestrutura — novo serviço, upgrade de banco, mudança de rede — exige atualização imediata do runbook correspondente. Runbook desatualizado é mais perigoso que nenhum runbook, porque gera falsa confiança.
Conclusão
Infraestrutura própria entrega o que cloud genérica não consegue garantir: controle real sobre dados, custo previsível em escala e performance consistente para cargas específicas. Mas esse controle tem um preço operacional que precisa ser pago ativamente: uptime monitorado em tempo real, runbook testado para cada cenário de falha, backup restaurado periodicamente e plantão que responde antes que o cliente perceba o problema.
O custo invisível do downtime — perdas de receita, desgaste de reputação, penalidade de SLA — supera em muitas vezes o custo de operar a infra corretamente. O investimento em operação não é overhead: é o que transforma o servidor em ativo.
Se você quer avaliar, provisionar ou assumir a operação da sua infraestrutura com SLA real, o departamento de DevOps e Infra da MaxVision oferece provisionamento, hardening, orquestração Docker e Kubernetes, backup criptografado, monitoramento ativo e plantão 24x7. Para conversar sobre o seu cenário, entre em contato.
