Tiket Mana Didahulukan Saat Banyak Pelanggan Lapor Down di Jam yang Sama

Antrean tiket bisa tiba-tiba penuh dengan keluhan yang hampir sama: "website saya down", "tidak bisa dibuka", "error 503". Wajar kalau kita langsung menyimpulkan ada satu server yang tumbang. Tapi tiket-tiket itu sering campuran: sebagian memang dari satu insiden besar, sebagian masalah terpisah yang kebetulan masuk di jam yang sama. Kalau semuanya ditangani sebagai satu insiden, atau sebaliknya dikerjakan satu per satu sesuai urutan masuk, ada tiket yang terlewat sampai batas SLA-nya habis. Artikel ini membahas cara menelusurinya dari gejala yang terlihat sampai akar masalah, lalu menyusun urutan penanganan berdasarkan hal yang benar-benar menentukan prioritas.

Gejala yang sama belum tentu masalah yang sama

Kata "down" dari pelanggan bisa berarti banyak hal. Bisa browser timeout, bisa error 500 dari PHP, bisa halaman "This site can't be reached" karena DNS, bisa juga email yang tidak masuk tapi disebut "hosting down". Isi keluhan memberi petunjuk, tapi bukan dasar pengelompokan yang bisa dipercaya. Yang lebih bisa dipegang ada dua: di server mana domain itu sebenarnya berjalan, dan respons teknis apa yang muncul saat domain itu dicek dari sisi kita. Dua tiket dengan keluhan berbeda bisa ternyata berada di server yang sama dan sama-sama gagal koneksi. Sebaliknya, dua tiket dengan kalimat yang persis sama bisa berada di server berbeda dengan penyebab yang tidak berhubungan. Jadi langkah pertama bukan membalas tiket satu per satu, tapi mengumpulkan daftar domain dari semua tiket yang masuk di rentang waktu itu, lalu memetakannya.

Kelompokkan berdasarkan server dan respons HTTP

Cara cepatnya adalah mengecek IP tujuan dan status HTTP tiap domain sekaligus. Loop di bawah ini read-only. Ia hanya melakukan query DNS dan request HTTP, jadi aman dijalankan dari workstation support atau server bastion.

BASH

# Ganti daftar domain dengan domain dari tiket yang masuk
for d in contoh1.com contoh2.net contoh3.id contoh4.com; do
  ip=(dig +short A "d" | tail -n1)
  code=(curl -s -o /dev/null -m 10 -w '%{http_code}' "https://d")
  echo "dip $code"
done | sort -k2

dig +short menampilkan hasil record A secara ringkas, dan tail -n1 mengambil baris terakhir karena kalau ada CNAME, IP-nya muncul paling bawah. curl -m 10 membatasi request sampai 10 detik, dan -w '%{http_code}' hanya mencetak kode status. Hasilnya diurutkan berdasarkan kolom IP supaya domain di server yang sama berkumpul.

TEXT

# contoh format output (IP memakai rentang dokumentasi, bukan data nyata)
contoh2.net 192.0.2.10 000
contoh4.com 192.0.2.10 000
contoh1.com 192.0.2.10 000
contoh3.id 198.51.100.25 500

Dari output seperti ini polanya langsung terlihat. Tiga domain di IP yang sama sama-sama mengembalikan 000, artinya tidak ada respons HTTP sama sekali (timeout, koneksi ditolak, atau gagal handshake TLS). Itu kandidat kuat satu insiden di level server atau jaringan. Domain keempat ada di server lain dan mengembalikan 500. Server-nya hidup dan menjawab, tapi aplikasinya error. Itu hampir pasti masalah terpisah, misalnya plugin, script PHP, atau database akun itu sendiri. Kalau tim punya inventaris internal yang memetakan akun ke server, pakai itu juga. Hasil DNS hanya menunjukkan ke mana domain mengarah, bukan di server mana akun itu sebenarnya tinggal.

Singkirkan red herring sebelum menyimpulkan

Pengelompokan di atas punya beberapa jebakan yang sering bikin kesimpulan meleset. Pertama, domain yang memakai CDN atau reverse proxy. dig akan mengembalikan IP edge milik CDN, bukan IP server origin. Akibatnya domain dari server berbeda bisa terlihat satu kelompok, atau domain dari server yang sama terlihat terpencar. Kalau IP yang muncul jelas bukan rentang milik kita, cek origin lewat inventaris internal, bukan lewat DNS publik. Kedua, cache DNS dan perubahan record. Kalau pelanggan baru saja mengganti nameserver atau record A, keluhan "down" bisa datang dari resolver yang masih menyimpan record lama. Polanya biasanya hanya satu-dua domain, dan dari sisi kita domain itu terbuka normal. Ketiga, masalah di sisi koneksi pelanggan. Kalau dari sisi kita domain mengembalikan 200 tapi pelanggan tetap tidak bisa membuka, kemungkinan ada di jaringan atau ISP mereka. Tiket seperti ini tetap ditangani, tapi tidak masuk kelompok insiden. Keempat, tiket lama yang kebetulan baru dibalas pelanggan. Cek waktu kejadian yang mereka laporkan, bukan hanya waktu tiket dibuat atau diperbarui. Keluhan dari kemarin yang baru ditindaklanjuti hari ini bisa terlihat seperti bagian dari lonjakan sekarang. Kelima, jadwal maintenance. Sebelum menganggap ada insiden, cek apakah ada pekerjaan terjadwal di server atau jaringan terkait. Kalau ada, yang perlu dilakukan berbeda: konfirmasi ke tim yang menjalankan maintenance, lalu beri update ke pelanggan. Setelah red herring disingkirkan, biasanya tersisa satu atau dua kelompok besar dan beberapa tiket individual. Itu peta kerja yang jauh lebih jelas daripada antrean mentah.

Verifikasi akar masalah di server yang terdampak

Untuk kelompok yang mengarah ke satu server, langkah berikutnya adalah memastikan apa yang terjadi di server itu. Kalau server masih bisa diakses lewat SSH, beberapa perintah read-only ini memberi gambaran awal.

BASH

uptime                      # load average dan sejak kapan server hidup
df -h                       # disk penuh sering bikin web server dan MySQL berhenti
systemctl --failed          # service yang gagal (distro berbasis systemd)
journalctl -p err -b --no-pager | tail -n 50   # error sejak boot terakhir

Uptime yang sangat pendek menandakan server baru reboot, entah disengaja atau tidak. Disk yang penuh di partisi utama bisa membuat web server, MySQL, dan mail server gagal menulis lalu berhenti melayani. systemctl --failed langsung menunjukkan service mana yang mati. Kalau MySQL atau proses lain mati tanpa jejak di log aplikasinya, cek apakah ia dimatikan kernel karena kehabisan memori. Caranya sudah dibahas di Membaca Log dmesg untuk Memastikan Aplikasi Dimatikan OOM Killer. Kalau SSH tidak bisa diakses sama sekali, masalahnya kemungkinan di level node, hypervisor, atau jaringan. Di titik itu tugas support biasanya berpindah ke eskalasi. Kumpulkan daftar domain terdampak, IP, hasil cek tadi, dan waktu mulai keluhan, supaya engineer tidak perlu bertanya ulang. Daftar lengkapnya ada di Memilih Info Apa yang Wajib Ada Sebelum Eskalasi Tiket ke Tim Engineering. Verifikasi akhirnya sederhana: setelah perbaikan, jalankan ulang loop pengecekan tadi untuk semua domain di kelompok itu. Kalau semuanya kembali 200 (atau kode normal untuk situs itu, misalnya redirect 301), insiden bisa dianggap pulih dari sisi layanan. Domain yang masih bermasalah setelah server pulih hampir pasti punya masalah sendiri dan perlu dipisahkan dari tiket insiden.

Pertanyaan yang benar-benar menentukan urutan penanganan

Setelah kelompoknya jelas, urutan kerja tidak lagi soal siapa yang menulis paling dulu atau paling keras. Ada beberapa pertanyaan yang lebih menentukan. Berapa banyak layanan yang terdampak oleh satu penyebab? Satu server mati yang menjatuhkan banyak akun hampir selalu didahulukan. Memperbaikinya sekaligus menutup banyak tiket, dan dampaknya ke pelanggan paling luas. Berapa sisa waktu SLA tiap tiket? Ini sering terlupa saat semua perhatian tertuju ke insiden besar. Tiket individual yang tinggal sedikit lagi melewati batas first response tetap perlu dibalas, walaupun hanya untuk konfirmasi bahwa masalahnya sedang dicek. Cara timer SLA dihitung (jam kerja atau 24 jam, response atau resolution) tergantung kontrak dan pengaturan helpdesk, jadi pastikan tim tahu definisi yang dipakai. Apakah ada risiko kehilangan data? Disk penuh di server database, filesystem yang read-only, atau indikasi server dibobol lebih mendesak daripada situs yang lambat. Kesalahan langkah di kondisi seperti ini bisa membuat data tidak bisa dipulihkan. Apakah tiket itu bagian dari insiden atau berdiri sendiri? Tiket yang masuk kelompok insiden sebaiknya ditautkan ke satu tiket induk kalau helpdesk mendukungnya. Dengan begitu satu update bisa dikirim ke semua pelanggan terdampak. Perlu dicek juga apakah tautan itu ikut menghentikan timer SLA tiket anak, karena perilakunya berbeda antar helpdesk. Layanan apa yang mati? Email yang tidak bisa menerima pesan bisa berarti pesan masuk ditolak atau tertahan di server pengirim. Situs yang down biasanya cukup pulih begitu server kembali. Keduanya penting, tapi dampak lanjutannya berbeda. Pembagian kerja yang biasanya berjalan baik: satu orang fokus ke insiden besar dan komunikasi ke tiket induk, sementara yang lain mengerjakan tiket individual berdasarkan sisa waktu SLA. Kalau semua orang menumpuk di satu insiden, tiket kecil yang sebenarnya cepat selesai justru jadi yang melanggar SLA. Saat antrean penuh dengan keluhan "down", tahan dulu keinginan membalas satu per satu. Kumpulkan domainnya, petakan ke server dan kode respons, singkirkan yang ternyata bukan bagian dari pola, lalu verifikasi di server yang paling banyak terdampak. Setelah peta itu ada, urutan penanganan hampir menyusun dirinya sendiri: penyebab yang dampaknya paling luas dulu, risiko data berikutnya, dan tiket individual diurutkan berdasarkan sisa waktu SLA, bukan urutan masuk.