Post Mortem — Indisponibilidade do Servidor (18/07/2026)

Sobre o incidente do dia 18/07/2026

Resumo

Em 18/07/2026 às 12:57:48 (BRT), a VPS responsável pela infraestrutura principal do Império MC foi reiniciada inesperadamente. A causa do reinício não pôde ser determinada com precisão, porém tudo indica que se tratou de uma indisponibilidade temporária ou reinicialização realizada pelo provedor da VPS.

O incidente resultou na indisponibilidade do servidor até que todos os serviços fossem restaurados manualmente.

Impacto

A reinicialização interrompeu todos os serviços hospedados na VPS, incluindo:

API
Website
Bot do Discord
PostgreSQL
MariaDB
Redis
Proxy Velocity

O único serviço que foi iniciado automaticamente após o reboot foi o Velocity. Como consequência, o servidor continuou aparecendo como online na lista de servidores do Minecraft, porém qualquer tentativa de conexão resultava em erro de servidor indisponível, já que os serviços necessários para o funcionamento ainda não estavam disponíveis.

Linha do Tempo

12:57:48 — A VPS foi reiniciada inesperadamente.

Após o reboot

Apenas o Proxy Velocity iniciou automaticamente.
Os bancos de dados e demais serviços permaneceram desligados.
O servidor aparecia online, mas não aceitava conexões.

Recuperação inicial

Todos os serviços foram iniciados manualmente.
Ainda assim, o acesso continuava indisponível.

Identificação do primeiro problema

Durante a inicialização automática, o plugin Core do Velocity tentou estabelecer conexão com o banco de dados antes que ele estivesse disponível.
Como a conexão falhou durante o boot, o plugin permaneceu em estado inconsistente mesmo após o banco voltar a ficar online.

Ação corretiva

O Proxy Velocity foi reiniciado.
Após esse procedimento, já era possível conectar ao servidor.

Segundo problema identificado

Diversos plugins do servidor Paper não haviam carregado corretamente.
Inicialmente suspeitou-se de corrupção dos arquivos JAR dos plugins.

Diagnóstico

Foi constatado que não havia corrupção nos plugins.
Os plugins afetados eram justamente aqueles que haviam tentado acessar o banco de dados durante sua inicialização enquanto ele ainda estava indisponível.
Como não implementavam uma estratégia de reconexão, permaneceram em estado inválido.

Recuperação final

Após reiniciar o servidor Paper (hospedado em outra máquina), todos os plugins foram inicializados corretamente e o funcionamento do servidor foi totalmente restaurado.

Causa Raiz

A causa exata da reinicialização da VPS não pôde ser identificada.

Foram analisados os logs do Ubuntu, não sendo encontrados indícios de:

Kernel Panic;
Falhas críticas do sistema operacional;
Invasão ou acesso não autorizado;
Erros relevantes que justificassem o reboot.

A hipótese mais provável é uma indisponibilidade temporária da infraestrutura do provedor da VPS ou um reinício realizado pelo próprio provedor.

Fatores Contribuintes

Embora o reboot tenha sido um evento externo, foram identificadas algumas fragilidades na infraestrutura que ampliaram o impacto:

Apenas parte dos serviços estava configurada para iniciar automaticamente.
Não existia um mecanismo que garantisse a ordem correta de inicialização entre bancos de dados, serviços e proxy.
Alguns plugins assumiam que o banco de dados estaria disponível durante sua inicialização e não realizavam novas tentativas de conexão caso a primeira falhasse.
Não existiam verificações automáticas de integridade ou recuperação após falhas de inicialização.

Ações Corretivas

Para reduzir a probabilidade e o impacto de incidentes semelhantes, serão implementadas as seguintes melhorias:

Configurar todos os serviços essenciais para inicialização automática após reboot.
Definir dependências de inicialização para garantir que bancos de dados estejam disponíveis antes dos serviços que dependem deles.
Implementar mecanismos de reconexão automática nos plugins que utilizam banco de dados.
Adicionar verificações de saúde (health checks) para detectar serviços em estado inconsistente.
Estruturar uma pipeline de CI/CD que automatize deploys, reinicializações e recuperação da infraestrutura, reduzindo a necessidade de intervenção manual.

Conclusão

Apesar da indisponibilidade ter sido causada por um reinício inesperado da VPS, o incidente evidenciou pontos de melhoria na estratégia de recuperação automática da infraestrutura.

Nenhum dado foi perdido e não houve corrupção dos plugins ou bancos de dados. A indisponibilidade foi resultado da ordem de inicialização dos serviços e da ausência de mecanismos automáticos de recuperação.

As melhorias listadas acima serão implementadas para tornar a infraestrutura mais resiliente e minimizar o impacto de eventos semelhantes no futuro.