Operação que não dá vergonha: monitorar, backup e incidente

Tem uma frase que separa amador de profissional em operação digital: o profissional não é quem nunca cai, é quem descobre antes do cliente, tem backup que funciona de verdade e sabe o que fazer quando para.

Todo mundo vai cair em algum momento. Servidor reinicia, integração muda, disco enche, alguém aperta o botão errado. A pergunta não é "se", é "quando". E quando acontecer, a diferença entre um susto de 10 minutos e um desastre de dois dias está em três coisas que você monta ANTES de precisar: monitoramento, backup e um plano de incidente.

Esse artigo é o mínimo pra você dormir tranquilo. Nenhuma dessas três coisas custa caro. Custam disciplina de montar quando está tudo bem, em vez de improvisar quando já está pegando fogo.

Monitorar: descobrir antes do cliente

A pior forma de descobrir que seu sistema caiu é o cliente te mandando print do erro no WhatsApp. Nesse ponto, o problema já durou tempo, já gerou prejuízo e já queimou sua imagem.

Monitorar é ter um robô checando seu sistema o tempo todo e te avisando no segundo que algo sai do lugar. Existem dois níveis, e você precisa dos dois.

Monitor de disponibilidade (uptime)

É o básico inegociável: um serviço externo que bate no seu site a cada minuto e pergunta "você está de pé?". Se não responde, te manda alerta na hora (email, WhatsApp, SMS).

Por que tem que ser externo: se o monitor roda no mesmo servidor que caiu, ele cai junto e não te avisa de nada. Tem que ser alguém de fora olhando de fora.

Ferramentas com plano gratuito que resolvem: UptimeRobot, BetterStack, Hetrix. Você cadastra a URL, configura o alerta e pronto. Cinco minutos de trabalho que mudam completamente o jogo. Na nossa operação, é a primeira coisa que configuro em qualquer sistema novo.

Monitor de comportamento

Um nível acima: não basta o site responder, ele precisa responder CERTO. Tem casos em que o site está "de pé" (responde) mas com erro, lentidão absurda, ou um número que despencou (conversão caiu, pedidos pararam de entrar).

Aqui entram ferramentas de observabilidade (a trilha de fundamentos técnicos cobre isso a fundo: logs, métricas, traces). Para uma PME, o começo é simples: alguns alertas sobre os números que importam pro seu negócio. "Me avise se nenhum pedido entrar em 2 horas no horário comercial" vale mais que dez dashboards bonitos que ninguém olha.

A pergunta de dono: "se o sistema cair às 3 da manhã de sábado, em quanto tempo a gente fica sabendo, e como?"

Backup: o que funciona vs o que só existe

Aqui mora a armadilha que pega quase todo mundo, inclusive gente experiente. Existe uma diferença enorme entre backup configurado e backup que funciona.

Backup configurado roda todo dia e gera arquivos. Parece que está tudo certo. Backup que funciona é aquele que você JÁ TESTOU restaurar pelo menos uma vez, e viu os dados voltarem inteiros.

A quantidade de gente que descobre que o backup estava corrompido, incompleto ou vazio justamente no dia em que precisou é assustadora. O arquivo estava lá, gerado todo dia, mas na hora de restaurar veio quebrado. O backup que nunca foi testado é um seguro que você não sabe se vai pagar.

As três perguntas do backup

Para qualquer dado importante (principalmente o banco de dados), responda:

1. Com que frequência ele é salvo? Diário é o mínimo para a maioria. Se você tem muita movimentação, pode precisar de mais.
2. Onde ele fica guardado? Backup que mora no mesmo servidor do dado original não serve. Se o servidor morrer, morre os dois juntos. Backup tem que estar em outro lugar (outro serviço, outra conta, outra região).
3. Quando foi a última vez que você restaurou com sucesso? Se a resposta é "nunca", você não tem backup, tem esperança.

Na nossa operação, o banco tem dump automático diário guardado fora do servidor principal, com retenção de alguns dias, e snapshot do servidor inteiro à parte. Mas o que faz dormir tranquilo não é a configuração, é ter restaurado e visto funcionar.

Dois números que todo dono deveria saber

Backup leva a duas perguntas que parecem técnicas mas são decisões de negócio:

• RPO (quanto dado você aceita perder). Se o backup é diário e o sistema cai antes do backup de hoje, você perde até um dia de dados. Isso é aceitável pro seu negócio? Para uma agência, talvez. Para um sistema de pagamento, jamais. Definir o RPO decide a frequência do backup.
• RTO (em quanto tempo você consegue voltar). Restaurar um backup leva tempo. Quanto tempo seu sistema pode ficar fora antes de virar problema sério? Isso é o RTO. Definir o RTO decide quanto você investe em recuperação rápida.

Você não precisa de números perfeitos. Precisa ter pensado neles antes do incidente. "Aceito perder no máximo um dia e voltar em até 4 horas" já transforma pânico em plano.

Incidente: o plano que você escreve com calma

Incidente sempre acontece no pior momento. Madrugada, feriado, com você longe do computador, ou no meio de uma reunião importante. É o pior momento pra tomar decisões difíceis sob estresse. Por isso você define o plano ANTES, com calma, e escreve num documento curto chamado runbook.

Runbook é uma página (de verdade, uma página) que responde:

• Como eu descubro que caiu? (o monitor, o alerta, o canal)
• Onde eu olho primeiro? (os 3 ou 4 lugares mais prováveis: o porteiro/Caddy, o container da aplicação, o banco, o disco cheio)
• Como eu restauro? (o passo a passo de subir de novo ou voltar o backup)
• Quem eu aciono e quando? (se sou eu sozinho, se tem um técnico, se tem o fornecedor)
• O que eu falo pro cliente? (uma mensagem honesta pronta, melhor que silêncio ou improviso)

O valor do runbook não é o documento, é ter pensado no problema antes. No meio do incidente, você não inventa, você executa. E erro grave quase sempre nasce de decisão tomada com pressa e pânico.

A regra de ouro do incidente

Quando algo crítico vaza ou quebra, a primeira ação muitas vezes é estancar, não consertar. Se um token vazou, revogue antes de gerar o novo, mesmo que isso cause uns minutos de indisponibilidade. Alguns minutos de sistema fora é menos pior do que um atacante usando um acesso vazado por meia hora. Estancar primeiro, consertar depois.

Postmortem: aprender em vez de só apagar incêndio

Depois que o incidente passa e o sistema voltou, tem uma última etapa que separa quem evolui de quem repete o mesmo erro: o postmortem. É uma conversa honesta (ou um parágrafo escrito) respondendo o que aconteceu, por que aconteceu, e o que muda pra não acontecer de novo.

O detalhe que importa: postmortem bom é sem culpa. O foco não é "de quem foi a culpa", é "que parte do sistema ou do processo permitiu isso". Procurar culpado faz as pessoas esconderem erro. Procurar a causa faz o sistema melhorar. Essa é uma das marcas de operação madura, e é vocabulário que aparece em reunião com TI sério (postmortem blameless está no glossário).

O kit mínimo, e quanto custa

Operação que não dá vergonha, na prática, é isto:

• Monitor de uptime externo com alerta no seu celular. Custo: zero (plano gratuito).
• Backup diário do banco guardado fora do servidor, com um teste de restore por trimestre marcado no calendário. Custo: centavos de storage.
• Runbook de uma página com os passos de incidente. Custo: uma hora pra escrever.
• Hábito de postmortem depois de cada susto. Custo: zero, só disciplina.

Repara que nada disso é caro. A barreira nunca é dinheiro, é montar quando está tudo calmo, em vez de quando já está pegando fogo. Quem monta antes dorme tranquilo. Quem deixa pra depois descobre o custo no pior dia possível.

O que você consegue fazer com isso

Ao fim deste capítulo, você consegue:

• Configurar (ou cobrar) um monitor que te avisa antes do cliente
• Diferenciar backup que existe de backup que funciona, e exigir o teste de restore
• Definir o RPO e o RTO da sua operação, mesmo que informalmente
• Escrever um runbook de uma página pro próximo incidente
• Conduzir um postmortem que melhora o sistema em vez de procurar culpado

Isso é o que tira o "operar no susto" e coloca o "operar com rede de segurança". Você não vai parar de ter incidente. Vai parar de ser pego de surpresa por ele.

No próximo passo da jornada, fechamos o estágio com o lado comercial: contrato, precificação e onboarding de cliente, pra vender e contratar sem improvisar e sem expor sua operação.