VPS mati? Sang kepiting yang menulis tiket ke provider
Sebuah VPS produksi mati total di jaringan: tidak ada ping, tidak ada SSH, tidak ada HTTPS, sementara panel hosting terus bilang “running”. Kepiting profil ops Alexey menggarap insiden itu dari awal sampai akhir: mengonfirmasi gangguan dari dua titik pandang independen, menggerakkan API provider langsung dari shell, menggali API power v2 mereka yang lebih baru dari repo dokumentasi, dan menarik bukti utamanya: panel provider sendiri tidak bisa menjangkau node hypervisor Proxmox. Lalu forensik dari sisi guest setelah pemulihan, dan tiket eskalasi siap tempel dalam bahasa provider.
Insiden nyata, 2026-09-06. n8n, Postgres, ~20 kontainer di satu VDS. Mati sekitar 05:30 UTC dari dua jaringan independen sementara panel mengklaim “running” dan dua reboot panel tidak berpengaruh. Sang kepiting mengambil alih dari situ:
- Verifikasi dua titik pandang: memastikan tidak terjangkau dari dua jaringan berbeda, menyingkirkan routing lokal sebelum menyentuh apa pun
- Menggerakkan API provider dari shell: memakai skrip CLI yang sudah ia tulis dan commit ke repo infra beberapa hari sebelumnya, dengan kunci API disimpan di luar git
- Menemukan API power v2 provider di repo dokumentasi mereka dan beralih dari endpoint legacy, yang justru mengungkap bukti utamanya: panel provider sendiri tidak bisa menjangkau node hypervisor Proxmox (
connect ETIMEDOUTdi port manajemen node itu), status power basi, dan keempat reboot yang diantrekan (2 panel + 2 API) tidak pernah dieksekusi - Berhenti menembakkan reboot begitu bukti mengarah ke node host: tanpa aksi buta setelah jelas tidak ada panggilan API yang bisa menolong sampai provider turun tangan
- Forensik guest pasca-pemulihan: koneksi keluar pertama yang gagal pada 05:30:02 dan pemulihan pada 08:51:59 dipastikan dari log health-check kontainer; uptime tanpa putus, nol event link-down NIC, dan syslog tanpa celah sepanjang blackout, bukti bahwa guest-nya tidak bersalah
- Tabel dampak per kontainer: layanan mana yang mencatat badai retry, mana yang tidak tersentuh, dan satu kontainer yang kena OOM sebagai efek samping
- Hasil akhirnya: laporan eskalasi siap tempel untuk support provider, ditulis dalam bahasa provider, dengan string error persis dari API mereka sendiri sebagai bukti
Vonis: wedge di datapath hypervisor, guest tidak bersalah. Tanda tangan identik kedua dalam empat hari, ditandai sebagai pola insiden berulang dengan rekomendasi migrasi. Semua pengetahuan diagnosis (keanehan API provider, hukum “periksa status power sebelum menembakkan reboot”) disimpan ke file brain sang kepiting, dan thread investigasinya bertahan ~5 jam serta beberapa kali context compaction tanpa kehilangan jejak.