Ketika sistem rusak, godaan pertama adalah mencoba-coba perbaikan secara acak: me-restart service, menghapus file, menyalakan-matikan koneksi. Diagnosis yang baik menolak godaan itu dan bekerja seperti saringan bertingkat — mulai dari pemeriksaan yang murah dan jangkauannya luas, sempitkan ke area yang terbukti bermasalah, lalu ambil keputusan dari bukti perintah, bukan dari firasat. Chapter ini merangkum proses itu menjadi tabel gejala → kemungkinan → perintah diagnosis untuk lima area yang paling sering rusak: boot, jaringan, disk, service, dan performa. Chapter-chapter troubleshooting detail per topik tetap menjadi rujukan mendalam — tabel-tabel di sini adalah pintu masuknya.

Quick Win — Lima Pemeriksaan Pembuka #

Sebelum menyelam ke tabel per area, ada lima pemeriksaan yang murah, cepat, dan menutupi mayoritas kejadian sehari-hari. Jalankan kelimanya berurutan; sering kali salah satunya langsung menunjuk akar masalah.

  • uptime — sejak kapan mesin menyala dan seberapa berat beban rata-ratanya
  • df -h — partisi mana yang penuh, termasuk partisi kecil seperti /boot
  • free -h — berapa memori yang benar-benar tersisa setelah cache
  • ip addr — apakah tiap interface punya alamat IP yang masuk akal
  • systemctl --failed — service mana yang statusnya gagal

Jika salah satu pemeriksaan menunjukkan kejanggalan, tabel-tabel berikut mengarahkan langkah berikutnya. Jika kelimanya bersih, masalah biasanya lebih spesifik — dan tabel tetap menjadi titik berangkat yang tepat.

Area Boot dan Startup #

Masalah boot paling menegangkan karena terminal yang biasa dipakai membedah malah ikut tidak bisa dibuka. Kabar baiknya, jurnal systemd merekam seluruh kejadian boot sehingga kita bisa membaca post-mortem dari recovery mode. Format kueri lengkapnya ada di halaman manual journalctl(1) .

GejalaKemungkinanPerintah diagnosis
Layar hitam setelah menu GRUBDriver GPU gagal; X atau Wayland tidak naikjournalctl -b -p err
Boot berhenti di pesan errorFilesystem rusak atau modul gagal dimuatjournalctl -b, dmesg
Sangat lambat sampai layar loginService startup terlalu beratsystemd-analyze blame
Restart berulang sebelum loginKernel panic atau initramfs rusakRecovery mode, lalu journalctl -b -1

Booting ke recovery mode dari menu GRUB hampir selalu menjadi langkah pertama yang aman: filesystem di-mount, shell tersedia, dan jurnal boot gagal tinggal dibaca. Pembahasan tuntasnya ada di chapter Boot Failures .

Area Jaringan #

Diagnosis jaringan paling efektif bila berurutan dari lapisan bawah: link dulu, IP kemudian, DNS terakhir. Tabel berikut menyusun kemungkinan mengikuti urutan itu, sehingga kita berhenti di lapisan yang benar.

GejalaKemungkinanPerintah diagnosis
Interface tidak punya alamat IPDHCP gagal, kabel lepas, WiFi matiip addr
Ada IP tetapi gateway tidak bisa di-pingRouting bermasalah atau kabel rusakip route, ping 192.0.2.1
Ping IP berhasil, nama domain gagalDNS server salah atau tidak terjangkaudig example.com, cat /etc/resolv.conf
Port layanan tidak bisa diakses dari luarLayanan mati, bind ke alamat salah, atau firewall memblokirss -tlnp, lalu cek aturan firewall

Aturan praktisnya: jangan menyalahkan aplikasi sebelum ip addr dan ping diperiksa. Banyak laporan “server down” berakhir di kabel yang longgar atau interface yang tidak mendapat IP. Rujukan perintah dan port lengkapnya ada di chapter Referensi Networking .

Area Disk dan Filesystem #

Disk penuh adalah masalah paling umum di server berumur panjang, dan gejalanya sering menyamar: aplikasi lambat, log berhenti tumbuh, cron gagal diam-diam. Karena itu df -h selalu masuk lima pemeriksaan pembuka.

GejalaKemungkinanPerintah diagnosis
Tulis file gagal, pesan “No space left on device”Partisi penuh, atau inode habisdf -h, df -i
Disk penuh tetapi file besar tidak ketemuFile sudah dihapus tetapi proses masih memeganglsof +L1, restart service pemiliknya
Penulisan mendadak muncul error I/OMedia rusak atau kabel longgardmesg, smartctl -a /dev/sda
Semua operasi tulis gagal read-onlyFilesystem di-remount setelah error`mount

Kasus kedua pada tabel adalah jebakan favorit: df menunjukkan penuh, du tidak menemukan penyebab, padahal proses yang masih berjalan memegang file yang sudah dihapus. Menemukan proses pemiliknya lalu me-restart-nya melepaskan ruang tersebut.

Area Service #

Service yang gagal punya keunggulan diagnostik dibanding area lain: systemd mencatat statusnya dan journalctl menyimpan jejak lengkapnya. Dua sumber itu biasanya cukup untuk menemukan akar masalah dalam beberapa menit.

GejalaKemungkinanPerintah diagnosis
systemctl status menunjukkan failedKonfigurasi salah atau dependensi gagaljournalctl -u nama -e
Service jalan tetapi port kosongBind ke alamat atau port yang salah, atau firewallss -tlnp, curl -v localhost:8080
Service mati lagi beberapa detik setelah startOOM killer atau crash loop aplikasijournalctl -u nama, `dmesg
Perubahan file unit tidak berpengaruhAda file override, atau lupa daemon-reloadsystemctl cat nama, systemctl daemon-reload

Pembahasan mendalam ada di chapter Troubleshooting Services dan Service Failures .

Area Performa #

Masalah performa jarang berbentuk “mati total” — lebih sering “pelan sejak kemarin”. Karena itu kuncinya adalah perbandingan: angka hari ini versus angka normal mesin tersebut, dan tabel berikut memilih metrik yang paling cepat membedakan keduanya.

GejalaKemungkinanPerintah diagnosis
Load average tinggiCPU jenuh atau banyak menunggu I/Ouptime, vmstat 1 (kolom wa)
Memori terus menyusutAplikasi bocor memorifree -h, `ps aux –sort=-%mem
Swap sibuk terus menerus (thrashing)RAM terlalu kecil untuk bebanfree -h, vmstat 1 (kolom si dan so)
Satu proses memakan satu core penuhAplikasi mengalami busy loop`ps aux –sort=-%cpu

Pola yang berulang di seluruh tabel performa: satu perintah menunjukkan gejala umum (uptime, free -h), perintah kedua menunjukkan pelakunya (ps aux --sort=...). Analisis lengkapnya ada di chapter Performance Bottlenecks .

Skrip Triage Mini #

Proses “gejala → area → langkah pertama” bisa kita latih dalam satu skrip kecil. Skrip berikut menerima satu gejala dan mencetak area plus langkah pertamanya. Pernyataan case menjadikan pemetaannya deterministik: gejala yang sama selalu menghasilkan arahan yang sama, dan cabang * menangkap gejala di luar peta dengan mengarahkannya kembali ke pemeriksaan pembuka.

bash 
cat > triage.sh <<'BATEK'
#!/usr/bin/env bash
# triage.sh — terjemahkan gejala menjadi area dan langkah pertama
gejala="$1"
case "$gejala" in
  "tidak bisa boot")
    area="boot";     langkah="masuk recovery mode dari GRUB, lalu journalctl -b -p err" ;;
  "tidak ada jaringan")
    area="jaringan"; langkah="cek ip addr, lalu ping gateway untuk memisah link dan DNS" ;;
  "disk penuh")
    area="disk";     langkah="jalankan df -h dan temukan partisi yang penuh" ;;
  "service mati")
    area="service";  langkah="jalankan systemctl status nama-service" ;;
  "server lambat")
    area="performa"; langkah="bandingkan uptime dan free -h dengan kondisi normal" ;;
  *)
    area="-";        langkah="gejala belum dikenali, mulai dari lima quick win" ;;
esac
printf 'gejala  : %s\narea    : %s\nlangkah : %s\n' "$gejala" "$area" "$langkah"
BATEK
bash triage.sh "tidak ada jaringan"
echo "----"
bash triage.sh "layar berkedip"

Output yang Dihasilkan:

text 
gejala  : tidak ada jaringan
area    : jaringan
langkah : cek ip addr, lalu ping gateway untuk memisah link dan DNS
----
gejala  : layar berkedip
area    : -
langkah : gejala belum dikenali, mulai dari lima quick win

Mari kita bedah baris per barisnya:

  1. Baris 1–20 (heredoc cat > triage.sh): menulis skrip triage. Setiap cabang case memasangkan satu pola gejala dengan dua variabel — area dan langkah — sehingga menambah gejala baru cukup menyalin satu pola dan mengisi dua nilai.
  2. Baris 21 (bash triage.sh "tidak ada jaringan"): mencocokkan pola jaringan; printf mencetak gejala, area, dan langkah dalam format rata yang tetap.
  3. Baris 23 (bash triage.sh "layar berkedip"): gejala tidak cocok dengan satu cabang pun, sehingga cabang * yang aktif dan hasilnya mengarah kembali ke lima pemeriksaan pembuka.

Skrip ini jelas bukan pengganti penilaian manusia — tetapi polanya nyata: mesin yang selalu menampilkan langkah pertama yang sama untuk gejala yang sama membuat tim tidak berdebat soal prosedur saat kepanikan. Kembangkan daftar cabangnya sesuai jenis insiden yang paling sering terjadi di lingkungan Anda.

Tabel-tabel di chapter ini merangkum keputusan diagnosis; chapter berikutnya merangkum perintahnya dalam bentuk paling padat: enam lembar contekan yang dirancang untuk di-screenshot dan ditempel di sebelah keyboard.