Memilih Info Apa yang Wajib Ada Sebelum Eskalasi Tiket ke Tim Engineering

Pola ini sering terjadi. Tiket diteruskan ke engineering dengan catatan "website customer error, mohon dicek". Lalu engineer membalas dengan pertanyaan yang hampir selalu sama: errornya seperti apa, terjadi jam berapa, dan sudah dicoba apa saja. Tiket pun tertahan hanya untuk mengumpulkan info yang sebenarnya bisa diambil di awal. Ini bukan soal engineer yang terlalu teliti. Cara investigasi di sisi server memang butuh titik awal yang spesifik, dan kalau kita paham kenapa, menyusun eskalasi jadi jauh lebih mudah.

Apa yang sebenarnya dilakukan engineer saat menerima eskalasi

Investigasi di server pada dasarnya adalah mempersempit ruang pencarian. Server hosting yang sibuk bisa menulis sangat banyak baris log per menit, tersebar di access log web server, error log, log PHP-FPM, log database, dan log mail. Engineer tidak membaca semua itu dari atas ke bawah. Mereka memfilter. Setiap filter butuh jangkar, yaitu potongan info yang bisa dicocokkan langsung dengan isi log. Jangkar yang paling berguna biasanya ada tiga:

Waktu, untuk memotong log ke rentang beberapa menit saja.
Identitas objek, misalnya domain, URL, username akun, IP pengunjung, alamat email pengirim dan penerima, atau Message-ID email.
Lapisan yang gagal, untuk menentukan log mana yang perlu dibuka.

Kalau ketiganya ada, engineer bisa langsung menjalankan pencarian yang sempit dan mulai membaca konteks di sekitar kejadian. Kalau tidak ada, mereka harus menebak, atau bertanya balik. Bertanya balik itulah yang membuat tiket bolak-balik.

Waktu kejadian, lengkap dengan zona waktunya

Setiap daemon menulis timestamp ke log menurut jam sistem dan formatnya sendiri. Daemon adalah proses layanan yang berjalan di background, seperti Nginx, Exim, atau MySQL. Access log Nginx dan Apache dengan format standar biasanya mencantumkan offset zona waktu, misalnya +0800. Tapi tidak semua log begitu. Ada log yang hanya menulis jam lokal tanpa offset, dan ada server yang jamnya diset ke UTC. Di Indonesia ini jadi masalah nyata karena ada tiga zona waktu: WIB (UTC+7), WITA (UTC+8), dan WIT (UTC+9). Kalau customer di Bali bilang "jam 9 pagi", server diset UTC, dan engineer membaca dengan asumsi WIB, pencarian bisa meleset satu jam penuh. Hasilnya, engineer melihat log yang normal-normal saja lalu menyimpulkan tidak ada masalah. Jadi tulis waktu secara absolut dan sertakan zonanya, misalnya "23 Oktober, sekitar 09.40-09.55 WITA". Hindari kata seperti "tadi siang" atau "barusan". Tambahkan juga dua hal lain: apakah masalahnya masih terjadi sekarang, dan kalau sifatnya hilang-timbul, kapan pertama dan terakhir kali terlihat. Masalah yang masih berlangsung bisa diamati langsung, sedangkan masalah yang sudah lewat hanya bisa direkonstruksi dari log. Kalau kamu punya akses shell, cocokkan jam server dengan jam kamu dengan perintah berikut.

BASH

# Jam server dalam zona lokalnya dan dalam UTC
date
date -u

# Resolusi DNS dari sisi kamu, untuk dibandingkan dengan IP server
dig +short example.com A

# Timing tiap tahap request (nilai kumulatif sejak request dimulai)
curl -o /dev/null -s -w 'dns: %{time_namelookup}
connect: %{time_connect}
tls: %{time_appconnect}
ttfb: %{time_starttransfer}
total: %{time_total}
code: %{http_code}
' https://example.com/

Semua perintah di atas hanya membaca data dan aman dijalankan. Ganti example.com dengan domain yang bermasalah.

Di lapisan mana request itu gagal

Saat seseorang membuka sebuah situs, request melewati beberapa tahap berurutan. Pertama, browser meminta resolver DNS menerjemahkan nama domain menjadi IP. Kedua, browser membuka koneksi TCP ke IP itu di port 443. Ketiga, terjadi TLS handshake. Di tahap ini browser mengirim nama domain lewat SNI (Server Name Indication) supaya server tahu sertifikat mana yang harus dipakai. Keempat, request HTTP diterima web server, yang biasanya meneruskannya ke backend seperti PHP-FPM. Terakhir, backend mungkin menanyakan data ke database sebelum mengirim respons. Kegagalan di setiap tahap menghasilkan gejala yang berbeda, dan setiap gejala mengarahkan engineer ke tempat yang berbeda:

Error DNS seperti NXDOMAIN berarti request bahkan belum sampai ke server. Yang perlu dicek adalah zona DNS atau nameserver, bukan web server.
Connection timed out biasanya berarti paket tidak mendapat jawaban. Penyebabnya bisa firewall, routing, atau server yang sedang down.
Connection refused berarti paket sampai ke host tapi tidak ada proses yang listen di port itu, atau koneksinya ditolak secara aktif.
Error sertifikat menunjuk ke tahap TLS, misalnya sertifikat kedaluwarsa atau tidak cocok dengan nama domain.
Kode 5xx berarti web server sudah menerima request, dan masalahnya ada di web server atau di belakangnya. Pada setup reverse proxy, 502 biasanya berarti proxy menerima respons yang tidak valid atau tidak menerima respons sama sekali dari upstream, sedangkan 504 berarti upstream terlalu lama menjawab.

Itulah kenapa "website error" hampir tidak berguna sebagai deskripsi. Kode HTTP, teks error yang persis, atau screenshot halaman error yang memperlihatkan URL lengkap bisa langsung memotong separuh kemungkinan penyebab. Output curl -w di atas membantu untuk masalah "situs lambat". Karena nilainya kumulatif, durasi tiap tahap adalah selisih dengan tahap sebelumnya.

TEXT

contoh format output (angka ilustratif):
dns: 0.020
connect: 0.050
tls: 0.150
ttfb: 4.800
total: 4.900
code: 200

Pada contoh ini, DNS, TCP, dan TLS selesai cepat. Hampir seluruh waktu habis antara selesainya TLS dan datangnya byte pertama, jadi yang perlu diselidiki adalah aplikasi atau database, bukan jaringan. Satu baris output seperti ini lebih berguna daripada kalimat "situsnya lemot banget". Bandingkan juga IP hasil dig dengan IP server yang seharusnya. Kalau IP-nya berbeda, mungkin request customer mendarat di server lama, cache DNS belum habis, atau ada entri di file hosts lokal. Dalam kasus seperti itu, log di server yang benar memang tidak akan mencatat apa-apa.

Siapa yang kena, dan bisakah diulang

Info cakupan membantu engineer membedakan masalah global dari masalah lokal. Kalau semua pengunjung kena, kemungkinan besar masalahnya ada di server atau konfigurasi. Kalau hanya satu orang, satu jaringan, atau satu ISP, arahnya ke routing, cache resolver, atau blokir di tengah jalan. Kalau hanya satu URL yang error, biasanya penyebabnya plugin, script, atau rule tertentu, bukan seluruh stack. Coba juga ulangi sendiri masalahnya dari sisi support. Kalau berhasil direproduksi, tulis langkahnya secara urut, apa yang diharapkan terjadi, dan apa yang benar-benar terjadi. Engineer bisa menjalankan langkah yang sama sambil memantau log secara langsung, dan cara ini biasanya jauh lebih cepat daripada membaca log masa lalu. Kalau tidak bisa direproduksi, itu juga info penting. Tulis saja "tidak bisa direproduksi dari jaringan support". Untuk masalah email, jangkarnya sedikit berbeda: alamat pengirim, alamat penerima, waktu kirim, dan teks bounce lengkap kalau ada. Bounce biasanya memuat kode dan pesan dari server penerima, dan bagian itulah yang menjelaskan alasan email ditolak. Screenshot yang memotong bagian bawah bounce sering menghilangkan info paling penting. Kalau email sampai tapi bermasalah, header lengkap dan Message-ID memudahkan pencarian di log mail.

Apa yang sudah dicoba, dan apa yang berubah sebelumnya

Ada dua hal yang berbeda di sini, dan keduanya perlu dicatat. Pertama, perubahan sebelum masalah muncul. Banyak gangguan berkaitan dengan sesuatu yang baru diubah: DNS dipindah, versi PHP diganti, plugin diupdate, akun dimigrasi, atau sertifikat diperbarui. Customer sering tidak menyebutkannya karena merasa tidak berhubungan. Pertanyaan sederhana seperti "ada yang diubah beberapa hari terakhir?" layak ditanyakan sebelum eskalasi. Kedua, langkah yang sudah dicoba oleh support atau customer, lengkap dengan hasil dan waktunya. Tulis langkahnya bersama hasilnya, misalnya "clear cache LSCache 09.50 WITA, error tetap muncul", bukan hanya "sudah clear cache". Waktu itu penting karena tindakan kita juga meninggalkan jejak di log. Tanpa catatan, engineer bisa salah membaca restart yang kita lakukan sebagai bagian dari insiden. Perlu diingat juga bahwa beberapa langkah bisa menghapus bukti. Restart PHP-FPM atau MySQL menghentikan proses yang sedang macet, padahal proses itu mungkin yang ingin diperiksa engineer. Menghapus cache atau mengosongkan mail queue juga mengubah kondisi yang sedang diselidiki. Kalau layanan harus dipulihkan dulu, itu wajar. Catat saja kondisinya sebelum tindakan diambil, misalnya error yang muncul dan jumlah email di queue, lalu sebutkan di tiket. Semua info di atas bisa dirangkum dalam format pendek seperti ini. Isi yang relevan dan tulis "belum dicek" untuk sisanya. Kolom kosong lebih mudah dikenali daripada info yang dikarang.

TEXT

Gejala      : teks error persis / kode HTTP / bounce lengkap
Objek       : domain, URL, akun, IP pengunjung, alamat email, Message-ID
Waktu       : mulai dan terakhir terlihat, dengan zona waktu (WIB/WITA/WIT/UTC)
Status      : masih terjadi / sudah hilang / hilang-timbul
Cakupan     : semua pengunjung / satu jaringan / satu URL / satu akun
Reproduksi  : langkah, hasil yang diharapkan vs hasil aktual
Perubahan   : apa yang berubah sebelum masalah muncul
Sudah dicoba: tindakan, jam, dan hasilnya
Data teknis : output dig, curl, atau log yang sudah diambil

Patokannya sederhana: sebelum menekan tombol eskalasi, bayangkan engineer membuka tiket itu tanpa bisa bertanya apa-apa. Apakah mereka tahu log mana yang harus dibuka, rentang waktu mana yang harus dicari, dan string apa yang harus difilter? Kalau ya, eskalasinya siap. Kalau belum, lima menit tambahan untuk mengumpulkan info biasanya jauh lebih murah daripada satu putaran tanya-jawab di tiket.