VPS morto? O caranguejo escreveu o ticket ao fornecedor
Um VPS de produção ficou completamente sem rede, sem ping, sem SSH, sem HTTPS, enquanto o painel da hospedagem continuava a dizer “running”. O caranguejo de perfil de operações do Alexey tratou do incidente de ponta a ponta: confirmou a indisponibilidade a partir de dois pontos de observação independentes, comandou a própria API do fornecedor a partir da shell, desenterrou a API de energia v2 mais recente deles no repositório de documentação e trouxe a prova cabal, o próprio painel do fornecedor não conseguia chegar ao nó hipervisor Proxmox. Depois, perícia do lado do hóspede após a recuperação, e um ticket de escalonamento pronto a colar na língua do fornecedor.
Incidente real, 2026-09-06. n8n, Postgres, ~20 contentores num único VDS. Em baixo às ~05:30 UTC a partir de duas redes independentes, enquanto o painel dizia “running” e dois reinícios pelo painel não faziam nada. O caranguejo tomou conta do assunto:
- Verificação a dois pontos de vista: confirmou inacessível a partir de duas redes diferentes, descartando o encaminhamento local antes de mexer em nada
- Comandou a API do fornecedor a partir da shell: usando um script CLI que tinha escrito e registado no repositório de infraestrutura dias antes, com a chave de API guardada fora do git
- Encontrou a API de energia v2 do fornecedor no repositório de documentação deles e desligou os endpoints legados, o que revelou a prova cabal: o próprio painel do fornecedor não conseguia chegar ao nó hipervisor Proxmox (
connect ETIMEDOUTna porta de gestão do nó), estado de energia desatualizado, e os quatro reinícios em fila (2 pelo painel + 2 pela API) nunca tinham sido executados - Parou de disparar reinícios no momento em que as provas apontaram para o nó anfitrião, nenhuma ação às cegas assim que ficou claro que nenhuma chamada à API ajudaria até o fornecedor intervir
- Perícia do hóspede após a recuperação: primeira ligação de saída falhada às 05:30:02 e recuperação às 08:51:59, fixadas a partir dos registos de health-check dos contentores; uptime contínuo, zero eventos de queda de ligação da NIC e syslog ininterrupto durante todo o apagão, prova de que o hóspede era inocente
- Tabela de impacto por contentor: que serviços registaram tempestades de tentativas, quais ficaram intactos, e o único contentor que sofreu OOM como efeito secundário
- O entregável: um relatório de escalonamento pronto a colar para o apoio do fornecedor, escrito na língua do fornecedor, com as cadeias de erro exatas da própria API deles como prova
Veredicto: bloqueio do datapath do hipervisor, hóspede inocente. Segunda assinatura idêntica em quatro dias, sinalizada como padrão de incidente repetido, com recomendação de migração. Todo o conhecimento de diagnóstico (peculiaridades da API do fornecedor, a lei “verificar o estado de energia antes de disparar reinícios”) ficou persistido nos ficheiros de cérebro do caranguejo, e a linha de investigação sobreviveu a ~5 horas e a várias compactações de contexto sem perder o fio.