Penyebab Server Down dan Solusinya, Diurut dari yang Paling Sering

Langkah pertama saat server down: pastikan dulu apa yang mati

Langkah pertama saat server down bukan menyentuh server, tapi menentukan sejauh mana masalahnya. Ini menghemat banyak waktu karena mengarahkan Anda ke lapisan yang benar.

Uji dari luar: apakah situsnya tidak merespons, atau merespons dengan pesan kesalahan? Halaman error berarti server web hidup dan masalahnya di aplikasi atau basis data. Tidak ada respons sama sekali berarti masalahnya lebih dalam — server web mati, jaringan terganggu, atau mesinnya sendiri berhenti.

Lalu uji apakah mesinnya masih menjawab: `ping` ke alamat IP-nya, lalu coba SSH. Kalau ping menjawab tetapi SSH tidak, biasanya sistem masih hidup tetapi terlalu sibuk atau kehabisan sumber daya untuk menerima koneksi baru.

Memeriksa server dari luar sebelum menuduh servernya

Kebiasaan memeriksa server dari luar jaringan Anda sendiri menyelamatkan banyak jam yang terbuang. Situs yang tidak bisa dibuka dari kantor belum tentu mati — bisa jadi hanya tidak terjangkau dari jalur jaringan itu.

Cek cepat: buka situs dari koneksi seluler, atau lewat layanan pemeriksa ketersediaan pihak ketiga. Kalau dari luar bisa dan dari kantor tidak, masalahnya di DNS lokal, firewall kantor, atau rute jaringan penyedia Anda — dan menyentuh server sama sekali tidak perlu.

Periksa juga apakah domainnya masih menunjuk ke tempat yang benar. Domain kedaluwarsa dan catatan DNS yang berubah adalah penyebab yang cukup sering, dan gejalanya identik dengan server mati.

Empat penyebab yang paling sering, beserta jejaknya

Setelah dipastikan servernya memang bermasalah, empat hal ini yang paling sering menjadi penyebabnya. Semuanya meninggalkan jejak yang bisa diperiksa.

• Disk penuh — layanan gagal menulis dan berhenti. Periksa `df -h` dan `df -i`; keduanya, karena inode bisa habis meski ruang masih ada.
• Memori habis — kernel mematikan proses terbesar. Cari `Out of memory` atau `oom-killer` di `journalctl -k` atau `/var/log/syslog`.
• Layanan mati setelah pembaruan — konfigurasi lama tidak lagi valid di versi baru. Periksa `systemctl status` dan log layanannya.
• Sertifikat TLS kedaluwarsa — situs tidak mati, tetapi browser menolak membukanya. Gejalanya terlihat seperti mati bagi pengguna.
• Beban melonjak — bisa trafik nyata, bisa serangan, bisa tugas terjadwal yang bertabrakan. Periksa beban rata-rata dan log akses pada jam kejadian.

Server tidak bisa diakses solusinya bertingkat

Ketika server tidak bisa diakses solusinya sebaiknya diambil dari yang paling ringan, karena setiap langkah yang lebih keras menghapus lebih banyak informasi.

Kalau SSH masih bisa: kosongkan sedikit ruang disk bila itu penyebabnya, mulai ulang layanan yang mati satu per satu, dan simpan salinan log sebelum apa pun dirotasi. Jangan reboot dulu — sebagian besar masalah selesai tanpa itu.

Kalau SSH tidak bisa: masuk lewat konsol yang disediakan penyedia. Hampir semua penyedia VPS menyediakannya, dan dari sana Anda masih bisa membaca log meski jaringan bermasalah.

Reboot adalah pilihan terakhir, bukan pertama. Ia sering memulihkan layanan, tetapi juga menghapus keadaan yang menyebabkan masalahnya — dan masalah yang tidak diketahui penyebabnya akan kembali pada waktu yang tidak Anda pilih.

Mencegah server down: yang benar-benar berpengaruh

Dari daftar panjang praktik baik, beberapa hal ini yang paling banyak mencegah gangguan berdasarkan penyebab yang benar-benar sering terjadi. Upaya mencegah server down yang efektif tidak menuntut arsitektur rumit.

Pemantauan disk dengan peringatan pada 80 persen, bukan 95. Pada 95 persen Anda sudah kehabisan waktu untuk bertindak tenang. Rotasi log yang benar-benar berjalan — periksa, jangan diasumsikan. Peringatan sertifikat 30 hari sebelum kedaluwarsa. Dan yang paling sering diabaikan: memori swap secukupnya, supaya lonjakan sesaat memperlambat alih-alih mematikan proses.

Di luar itu, satu hal yang tidak berhubungan dengan teknis tapi paling menentukan lamanya gangguan: catatan tertulis tentang apa saja yang berjalan di server itu dan siapa yang harus dihubungi. Gangguan yang perbaikannya lima menit bisa berlangsung tiga jam hanya karena tidak ada yang tahu kata sandinya.

Setelah pulih: catat sebelum lupa

Bagian ini hampir selalu dilewat karena begitu layanan hidup, semua orang kembali ke pekerjaan lain. Padahal justru di sini nilai terbesarnya.

Catat empat hal saja: kapan mulai dan kapan pulih, apa gejalanya, apa yang ternyata penyebabnya, dan satu perubahan yang mencegahnya terulang. Empat baris itu, dikumpulkan selama setahun, menjadi peta kelemahan sistem Anda yang jauh lebih berguna daripada dokumen arsitektur mana pun.

Kalau penyebabnya tidak berhasil ditemukan, catat itu juga apa adanya. Gangguan tanpa penyebab yang diketahui dan terjadi berulang adalah sinyal untuk memasang pemantauan lebih rinci, bukan untuk menunggu kejadian berikutnya.

Menyiapkan diri sebelum gangguan berikutnya

Sebagian besar waktu gangguan tidak habis untuk memperbaiki, tetapi untuk mencari tahu. Beberapa persiapan berikut memangkas bagian itu secara langsung.

Satu hal terakhir yang layak dibiasakan: setelah setiap gangguan, tanyakan apakah pemantauan sudah memberi tahu lebih dulu. Kalau jawabannya tidak, itu celah yang lebih penting ditutup daripada penyebab teknis kejadian itu sendiri.

• Kumpulkan log ke tempat di luar server, supaya bukti tidak hilang saat server dipulihkan atau di-reboot.
• Simpan satu berkas berisi daftar layanan, port, dan ketergantungan antar-sistem — diperbarui saat ada perubahan, bukan saat dibutuhkan.
• Pastikan ada jalur akses kedua yang tidak lewat SSH, biasanya konsol dari penyedia, dan uji sekali supaya tahu cara masuknya.
• Catat siapa yang berwenang mengambil keputusan berisiko seperti reboot produksi, supaya tidak ada yang menunggu izin di tengah malam.
• Simpan kredensial darurat di pengelola kata sandi yang bisa diakses lebih dari satu orang.
• Tetapkan siapa yang mengabari pengguna atau pelanggan, karena gangguan teknis selalu punya sisi komunikasi.