Quem cuida do site às três da manhã: monitoramento e resposta a incidente

O horário em que as coisas quebram

Site não escolhe hora para cair, mas escolhe hora para ser atacado: varredura automatizada roda o tempo todo, e o momento em que ninguém está olhando é o melhor momento para persistir sem ser notado.

O problema não costuma ser a falha em si. É a distância entre o momento em que ela acontece e o momento em que alguém percebe. Um site fora do ar por vinte minutos de madrugada é um contratempo. O mesmo site fora do ar por nove horas é uma perda de tráfego, de posição e de confiança.

O que precisa ser vigiado

1. Ele responde?

O básico, e o que quase todo mundo tem.

2. Ele responde a coisa certa?

O que quase ninguém tem, e o que mais engana.

Um monitor que só olha o código de resposta vai reportar tudo normal enquanto a home exibe uma mensagem de erro de banco de dados — porque a página com o erro também responde com sucesso. O servidor está de pé; o site não está funcionando.

A verificação que vale procura um trecho conhecido dentro da resposta: um pedaço do título, o nome do site, um elemento que só existe quando a página montou de verdade. Se o trecho sumiu, alguma coisa aconteceu, mesmo que o código diga que está tudo bem.

3. O certificado está válido?

Certificado vencido derruba a confiança do visitante instantaneamente, e a renovação automática falha em silêncio com mais frequência do que se imagina. O aviso precisa vir dias antes do vencimento, não no dia.

4. O conteúdo mudou sem ninguém ter mudado?

Este é o que pega invasão.

Arquivo do núcleo do sistema alterado, arquivo novo aparecendo numa pasta que não recebe upload, código injetado no rodapé do tema. Comparar o estado atual com uma referência conhecida é o que transforma “algo estranho está acontecendo” em “este arquivo mudou nesta hora”.

Sem isso, invasão é descoberta pelo caminho ruim: pelo aviso do navegador, pela queda de tráfego ou pelo cliente ligando.

O que justifica acordar alguém

Duas coisas:

• O site está fora do ar e não voltou sozinho depois de duas verificações seguidas.
• Há sinal de invasão — arquivo do núcleo alterado, arquivo desconhecido em pasta de upload, redirecionamento que ninguém configurou.

Só isso.

O que pode esperar o café

Certificado vencendo em cinco dias. Tempo de resposta piorando. Página específica com erro enquanto o resto funciona. Espaço em disco em 80%. Plugin com atualização de segurança disponível.

Todos merecem ação. Nenhum merece madrugada.

Alertar demais é um problema real, não um exagero: quem é acordado três vezes por semana por coisa que podia esperar aprende a silenciar o aviso, e vai silenciar também o que importava. A disciplina de manter a lista de alertas críticos curta é o que preserva o valor dela.

O que fazer quando o alerta chega

A resposta útil não é “olhar o site”. É uma ordem:

1. Confirmar de fora. O problema é do site ou da rede de quem está olhando?
2. Separar o tipo. Fora do ar é um caminho; conteúdo alterado é outro, e o segundo pede isolar antes de investigar.
3. Preservar antes de consertar. Em suspeita de invasão, apagar o arquivo estranho antes de olhar destrói a única pista de como ele chegou.
4. Ver o que mudou recentemente. Atualização, alteração de configuração, publicação. A causa costuma estar na última coisa que alguém mexeu.
5. Registrar. Um incidente sem registro vira o mesmo incidente daqui a três meses, investigado do zero.

Por que isso não é opcional em site que trabalha

Site institucional parado é constrangimento. Site que publica, vende ou recebe formulário parado é prejuízo que continua enquanto ninguém percebe.

E a diferença entre um incidente pequeno e um grande quase nunca está na gravidade da falha. Está no tempo até alguém saber.