Sistem yang sehat lebih sering diam

Di cockpit pesawat modern ada prinsip yang menarik: quiet, dark cockpit.

Kalau semua normal, panel harus sunyi dan gelap. Tidak ada lampu yang menyala hanya untuk memberi tahu bahwa semuanya baik-baik saja. Tidak ada bunyi yang sekadar bilang, "tenang, aku masih hidup." Lampu dan alarm baru muncul saat pilot perlu mengambil keputusan.

Ini bukan karena data di cockpit sedikit. Justru sebaliknya. Pesawat modern punya terlalu banyak sensor, status, mode, dan kemungkinan masalah. Kalau semua hal itu ditampilkan sebagai alarm, pilot bukan makin aman. Pilot malah tenggelam.

Prinsipnya sederhana: sistem yang sehat tidak perlu cerewet.

Alert yang lengkap belum tentu berguna

Banyak sistem monitoring gagal bukan karena datanya kurang. Mereka gagal karena terlalu banyak bicara.

Setiap service punya health check. Setiap script punya log. Setiap cron punya status. Setiap integrasi bisa mengirim notifikasi. Lama-lama Telegram, Slack, email, dan dashboard berubah jadi museum alarm: banyak lampu, sedikit keputusan.

Masalahnya bukan alert. Masalahnya alert yang tidak punya konsekuensi.

Kalau sebuah notifikasi membuat kita bertanya, "ini penting nggak?", berarti alert itu belum matang. Alert yang bagus seharusnya langsung menjawab tiga hal:

1. Apa yang terjadi?
2. Apa dampaknya?
3. Apa aksi berikutnya?

Tanpa tiga hal itu, alert hanya memindahkan beban berpikir dari mesin ke manusia.

Alarm fatigue itu nyata

Di operasi teknis, alarm fatigue biasanya muncul pelan-pelan.

Awalnya satu alert palsu masih ditoleransi. Besoknya muncul lagi. Minggu depannya semua orang sudah hafal bahwa alert itu "biasanya aman". Setelah itu, otak mulai melakukan filter otomatis.

Dan di situlah bahayanya.

Begitu manusia terbiasa mengabaikan alert, alert yang benar-benar penting ikut tenggelam. Sistem masih mengirim sinyal, tapi manusia sudah berhenti percaya.

Dalam konteks server, gateway, automation, atau workflow bisnis, ini bisa kelihatan sepele. Misalnya health check berulang bilang ada API key yang hilang, padahal runtime sebenarnya sehat. Kalau dibiarkan, notifikasi itu berubah dari sinyal menjadi noise.

Noise tidak netral. Noise merusak kepercayaan.

Monitoring harus didesain untuk aksi

Aku mulai suka satu aturan sederhana:

No alert without next action.

Setiap alert harus punya aksi yang masuk akal. Kalau tidak ada aksi, jangan kirim alert. Simpan saja sebagai log.

Contoh:

• "Gateway mati" adalah alert, karena aksi jelas: restart, cek service, atau failover.
• "Disk 92%" adalah alert, karena aksi jelas: cleanup atau tambah storage.
• "API provider gagal 3 kali" adalah alert, karena aksi jelas: switch provider atau cek quota.
• "Health check optional provider belum dikonfigurasi" belum tentu alert. Kalau provider itu memang tidak dipakai, itu cuma catatan.

Bedanya tipis, tapi penting. Alert harus mewakili risiko operasional, bukan sekadar ketidaksempurnaan konfigurasi.

Quiet bukan berarti buta

Ada kekhawatiran umum: kalau alert dikurangi, nanti kita tidak tahu apa-apa.

Menurutku ini salah framing. Quiet system bukan berarti data hilang. Data tetap dikumpulkan. Log tetap disimpan. Dashboard tetap ada. Bedanya, sistem tidak memaksa manusia melihat semuanya setiap saat.

Ada tiga lapisan yang perlu dipisah:

1. Log untuk investigasi.
2. Dashboard untuk observasi.
3. Alert untuk aksi.

Banyak tim mencampur ketiganya. Semua log ingin jadi alert. Semua dashboard ingin jadi notification feed. Akhirnya tidak ada hierarki.

Padahal manusia butuh prioritas, bukan banjir informasi.

Pelajaran untuk automation kecil

Prinsip quiet dark cockpit bukan cuma untuk aviation atau data center besar. Ini relevan juga untuk otomasi kecil: bot Telegram, cron job, AI assistant, reminder pribadi, sampai dashboard bisnis.

Kalau sebuah automation terlalu sering menyuruh kita melihat sesuatu, lama-lama automation itu berubah jadi pekerjaan tambahan.

Automation yang bagus harus mengurangi beban mental. Bukan menambah daftar hal yang perlu dicek.

Untuk sistem seperti Hermes VPS, standar sederhananya bisa begini:

• Kalau sehat, diam.
• Kalau ada masalah tapi belum butuh aksi, log saja.
• Kalau butuh aksi, kirim alert yang pendek dan jelas.
• Kalau alert berulang tanpa tindakan, berarti desain alert-nya salah.

Ini juga berlaku untuk bisnis. Laporan harian, update sales, monitoring project, pipeline konten, semuanya bisa mengikuti pola yang sama. Jangan kirim semua hal. Kirim hal yang mengubah keputusan.

Standar kecil yang bisa dipakai

Sebelum membuat alert baru, tanya empat pertanyaan ini:

1. Kalau alert ini muncul, siapa yang harus bergerak?
2. Apa aksi pertama yang paling masuk akal?
3. Apa dampaknya kalau diabaikan satu jam?
4. Apakah ini perlu notifikasi, atau cukup masuk log?

Kalau jawabannya kabur, alert itu belum siap.

Sistem yang bagus bukan sistem yang paling banyak bicara. Sistem yang bagus tahu kapan harus diam, kapan harus menyala, dan kapan harus membangunkan manusia.

Karena pada akhirnya, alert yang baik bukan yang paling lengkap.

Alert yang baik adalah yang bikin orang bergerak.

Reference:

• Quiet dark cockpit principle: https://en.wikipedia.org/wiki/Dark_cockpit
• Alert fatigue: https://en.wikipedia.org/wiki/Alarm_fatigue