On-call yang sehat: kenapa alert-mu bikin orang berhenti peduli

Isi

Ada pola yang hampir selalu sama di tim yang baru mulai on-call. Minggu pertama, semua orang siaga. Minggu ketiga, mulai ada yang mematikan notifikasi malam. Minggu keenam, alert pagi jam 3 di-snooze tanpa dibaca — dan satu insiden nyata lolos karena semua orang sudah belajar bahwa "alert ini biasanya palsu".

Itu alert fatigue. Bukan masalah disiplin orang. Masalah desain sistem alert.

Tanda kebiasaan buruk sudah parah: - Alert masuk lebih dari ~2x per shift tanpa tindakan berarti - Ada alert yang selalu di-ack lalu diabaikan ("nanti juga hijau sendiri") - Orang takut pegang jadwal on-call → jadwal selalu kosong H-1 - Satu insiden menghasilkan 40 notifikasi untuk satu akar masalah

Prinsip yang lebih realistis: alert = panggilan bangun tengah malam. Kalau tidak layak membangunkan orang, jangan kirim sebagai page — kirim ke channel/dashboard saja. Google SRE mendefinisikan page sebagai "harus actionable sekarang" dan sisanya cukup tiket. Dua jalur ini beda, dan mencampurnya adalah akar fatigue.

Aturan praktis yang bisa dipakai tim kecil:

Poin terakhir itu yang paling sering dilewat. Alert yang sering palsu punya biaya: kepercayaan. Satu false positive per minggu cukup untuk melatih seluruh tim mengabaikan semua alert.

Runbook = beda antara panik 20 menit dan fix 3 menit.

Runbook yang berguna bukan dokumen 12 halaman Confluence. Cukup 5 baris, ditulis saat insiden masih hangat:

Symptom: 5xx naik di /api/checkout, >2% selama 5 menit
Cek pertama: dashboard payment, lihat error code dominan
Langkah 1: kalau 502 dari upstream → cek health endpoint provider
Langkah 2: kalau DB connection pool habis → restart pod (aman, stateless)
Eskalasi: kalau >15 menit belum jelas → panggil @backend-lead
Rollback: git revert deploy terakhir, lihat #deploys

Yang bikin runbook mati: ditulis setelah insiden selesai oleh satu orang, disimpan di tempat yang tidak dibuka jam 3 pagi. Solusi: taruh link runbook langsung di isi alert. Satu klik dari notifikasi ke instruksi.

Postmortem tanpa blameless akan jadi ajang pembelaan diri. Kalau pertanyaannya "siapa yang deploy", orang akan menyembunyikan informasi. Kalau pertanyaannya "kenapa sistem mengizinkan perubahan itu lolos", orang akan jujur. Selalu arahkan ke sistem, bukan orang.

Satu hal yang bisa langsung dipakai

Buka daftar alert-mu hari ini, urutkan berdasarkan frekuensi 30 hari terakhir. Ambil 3 teratas yang paling sering muncul. Untuk masing-masing, jawab satu pertanyaan: "Kalau alert ini dihapus, apa yang benar-benar hilang?" Kalau jawabannya "tidak ada", hapus. Kalau jawabannya "kami tidak tahu", itu justru alert yang paling berbahaya — hapus juga, lalu buat alert baru yang mengukur dampak ke user, bukan gejala internal.

Takeaway

Alert yang tidak pernah ditindaklanjuti bukan alarm — itu noise yang melatih tim untuk tidak percaya pada sistemnya sendiri. Lebih baik 5 alert yang selalu benar daripada 50 yang kadang-kadang berguna.