Um site pode ficar lento porque uma matéria viralizou, porque um plugin entrou em loop ou porque alguém está tentando derrubá-lo. Para quem administra um projeto pequeno, os três cenários parecem iguais no começo: páginas que não abrem, erros 502 ou 503 e um painel que demora tanto que parece ter desistido. A diferença está nos sinais e na forma de reagir.
Em uma atualização publicada em 18 de agosto de 2026, o Google explicou como usa inteligência artificial para prever enchentes. O exemplo ajuda a entender uma ideia que também vale para segurança: um modelo não adivinha o futuro por mágica. Ele cruza dados, reconhece padrões e precisa ser interpretado dentro de seus limites.
DoS e DDoS: a diferença está na origem do tráfego
Um ataque de negação de serviço, ou DoS, tenta consumir os recursos de um servidor até que ele não consiga atender visitantes reais. Pode ser uma enxurrada de requisições, conexões mantidas abertas por muito tempo ou pedidos caros demais para a aplicação processar. No DDoS, a carga vem de várias máquinas ao mesmo tempo, geralmente uma rede de dispositivos infectados chamada botnet.
Essa distribuição dificulta o bloqueio. Barrar um endereço IP pode resolver uma parte do problema, mas não a campanha inteira. Também existe o risco de bloquear pessoas legítimas quando o ataque usa redes residenciais, serviços de nuvem ou requisições que se parecem com acessos comuns.
Nem todo pico é ataque. Uma campanha bem-sucedida, uma transmissão comentada nas redes ou uma publicação que aparece em um portal grande também pode multiplicar acessos. Antes de concluir, compare o horário do aumento, as páginas solicitadas, os países ou redes de origem, os códigos de resposta e o consumo de CPU, memória e banco de dados.
Como reconhecer um problema de disponibilidade
O primeiro sinal costuma ser uma mudança brusca no padrão normal. O servidor recebe muito mais requisições do que o habitual, mas isso sozinho não prova nada. Observe se as solicitações se concentram em uma URL, se repetem o mesmo parâmetro, ignoram arquivos estáticos ou chegam em uma velocidade incompatível com o comportamento dos seus leitores.
Outro indício é a diferença entre as camadas. Se a CDN entrega imagens normalmente, mas a página dinâmica começa a falhar, o gargalo pode estar no servidor de origem, no PHP ou no banco de dados. Se tudo falha, inclusive arquivos estáticos, a saturação pode estar na rede, na hospedagem ou em um serviço intermediário.
Registros são mais úteis que uma impressão rápida do painel. Guarde os horários, gráficos de tráfego, códigos HTTP, rotas mais acessadas e mensagens do provedor. Compare com um dia normal. Essa documentação também acelera o atendimento quando a hospedagem precisa aplicar filtros que você não consegue configurar sozinho.
O que reduz o impacto
O básico é limitar requisições de forma proporcional. Rate limiting impede que uma mesma origem consuma uma quantidade ilimitada de recursos em poucos segundos. A regra precisa considerar o tipo de página: uma busca pode exigir mais trabalho que a leitura de um texto, e uma API pode ter limites diferentes do site público.
Um firewall de aplicação web, conhecido como WAF, filtra tráfego usando regras para padrões suspeitos. Ele pode ajudar contra alguns ataques na camada de aplicação, mas não substitui a hospedagem. Quando o volume já ocupa a conexão antes de chegar ao firewall, é preciso que a rede do provedor absorva e distribua a carga.
CDNs e redes anycast colocam uma camada distribuída entre o visitante e o servidor. Em vez de cada pedido chegar diretamente à origem, pontos de presença podem responder conteúdo em cache e absorver parte da demanda. Isso não torna um site invulnerável, e uma configuração errada pode continuar expondo a origem, mas reduz a pressão sobre projetos pequenos.
Mantenha o contato de emergência da hospedagem à mão. Pergunte antes do incidente quais filtros existem, qual é o limite de tráfego, como solicitar mitigação e quais registros o suporte precisa receber. Durante o problema, evite apagar logs, mudar muitas configurações ao mesmo tempo ou instalar um plugin desconhecido prometendo proteção instantânea. Essas ações dificultam a investigação.
Previsão ajuda, mas não substitui confirmação
O Google diz que o Flood Hub combina dados meteorológicos, níveis de rios e condições do solo. Para cheias de rios, os modelos podem fazer previsões com até sete dias de antecedência; para enchentes urbanas repentinas, a janela citada é de até 24 horas. O Groundsource foi criado para preencher uma lacuna de dados sobre áreas urbanas e usou milhões de reportagens históricas para montar um conjunto de eventos.
A lição para quem cuida de um site é simples: sinais agregados ajudam a agir antes, mas precisam de contexto. Um gráfico de tráfego não explica sozinho a causa. Cruze métricas técnicas com os logs, o calendário de campanhas, o status da hospedagem e o comportamento das páginas. Quanto melhor o registro, menor a chance de confundir um sucesso inesperado com um ataque ou de reagir tarde a um problema real.
Antes do próximo pico, faça um teste seguro: anote o tráfego normal de uma semana, identifique as páginas mais caras e confirme se existe backup funcional. Depois, escreva um roteiro com os contatos e os primeiros comandos de diagnóstico. Segurança não começa quando o site já caiu. Começa quando ainda dá para observar o que está acontecendo.
Fonte: Google Research, “How Google uses its AI to predict floods”, consultado em 31 de agosto de 2026.
