Panic Button dalam Skala Besar: Alarm Darurat untuk 100 Lokasi

Panic Button dalam Skala Besar: Alarm Darurat untuk 100 Lokasi

Di skala seratus lokasi, bagian sulit panic button bukan mengirim alert. Bagian sulitnya memastikan setiap tombol benar-benar bekerja di hari ketika keselamatan orang bergantung padanya.

Demo panic button itu proyek akhir pekan: satu tombol, satu jaringan, satu pesan masuk ke group chat. Demonya meyakinkan semua orang, pilotnya lancar, lalu datang permintaan itu — "pasang di seratus lokasi." Di situ produk yang sebenarnya baru dimulai.

Dari proof of concept ke seratus lokasi

Kasus di balik artikel ini: deployment operasi keamanan yang tumbuh dari proof of concept satu lokasi menjadi kurang lebih seratus. PoC-nya cuma perlu menjawab satu hal — tombol ditekan, alert keluar. Begitu unitnya tersebar di seratus lokasi, pertanyaan yang sebenarnya baru bermunculan.

Dari seratus lokasi itu, mana saja yang hidup sekarang? Alert dari lokasi 37 masuk ke siapa — dan kalau orangnya tidak merespons, lari ke siapa? Drill bulanan bagaimana caranya jalan tanpa membuat semua orang terbiasa mengabaikan alarm? Tiap pertanyaan itu ujungnya jadi pekerjaan engineering yang lebih besar daripada tombolnya sendiri.

Hardware dan fallback konektivitas

Tiap lokasi punya tombol fisik yang terhubung ke gateway kecil. Gateway ini mem-publish state tombol ke server lewat MQTT — pilihan protokol sisi perangkat yang sama dengan sistem telemetri mana pun, karena alarm itu telemetri juga. Bedanya, yang ini ada konsekuensinya.

Kepercayaan pada sistem darurat paling sering runtuh di urusan konektivitas. WiFi gedung bisa mati — dan biasanya mati justru di jenis kejadian yang membuat orang meraih panic button. Karena itu setiap gateway dibekali fallback GSM: jalur utama lewat jaringan lokasi, modem seluler mengambil alih begitu jalur itu putus.

Satu aturan yang tidak boleh ditawar: fallback-nya dites terjadwal. Jalur failover yang belum pernah dilewati trafik itu bukan desain — itu harapan.

Supervised liveness: produk yang sebenarnya

Bayangkan satpam yang wajib lapor ke pos tiap 30 menit. Sekali dia tidak lapor, atasannya langsung tahu ada yang tidak beres — tanpa harus menunggu insiden. Supervised liveness bekerja persis begitu: tiap gateway mem-publish heartbeat pada interval tetap, laporan rutin "saya masih hidup."

Ini penting karena sistem darurat matinya diam-diam. Tombol yang rusak dan hari yang tenang terlihat sama persis: sama-sama tidak ada trafik. Tanpa supervisi, unit-unit di lapangan mati satu per satu tanpa ada yang sadar — sampai tekanan yang paling menentukan itu ternyata tidak sampai ke siapa-siapa.

Di background, satu worker health-check menyisir semua lokasi. Senyap melewati ambang pertama, status lokasi turun jadi warning. Senyap melewati ambang kedua, lokasi ditandai offline dan workflow tim fasilitas jalan. Di deployment ini dua ambang itu di bawah satu menit, dua-duanya bisa dikonfigurasi. Hasilnya, tombol mati ketahuan dalam hitungan menit di hari biasa — bukan pas keadaan darurat.

Satu detail desain menjaga sistem tetap tenang: heartbeat yang isinya cuma mengulang state tidak pernah dijadikan insiden. Kanal kehadiran dan kanal alarm dipisah. Kalau dicampur, satu pesan yang penting bakal terkubur di bawah ribuan pesan yang tidak.

Routing alert dan eskalasi

Tombol yang armed ditekan, sistem membuat emergency. Emergency di-routing per area dan per peran: responder di lokasi dinotifikasi lebih dulu, lewat kanal yang memang dipantau orang — di sistem ini Telegram, dan hanya ke penerima terdaftar yang sudah disetujui.

Tidak ada yang acknowledge dalam jendela waktu tertentu? Alert naik ke ring berikutnya: supervisor area, lalu meja operasi pusat.

Rantai eskalasi ini tertanam di sistem, bukan diandalkan dari ingatan orang. Jam 2 pagi tidak ada yang sempat improvisasi menyusun daftar telepon — sistem sudah tahu ring dua dan ring tiga, dan menjalankannya pakai timer.

Test mode versus alarm sungguhan

Jaringan sebesar ini wajib drill — regulasi menuntutnya, akal sehat juga. Tapi kalau tiap drill bulanan mem-paging seluruh rantai eskalasi, yang diproduksi bukan kesiapan, melainkan alarm fatigue. Inilah yang pelan-pelan mematikan sistem alerting: notifikasi ke-seratus yang diabaikan terlihat sama persis dengan alarm sungguhan yang pertama.

Maka drill jalan di test mode yang eksplisit. Tekanan uji tetap melewati seluruh pipeline — tombol, gateway, broker, routing — tapi mendarat di kanal drill dan tercatat sebagai test. Eskalasi sungguhan disimpan untuk kejadian sungguhan. Justru itu yang membuatnya tetap dipercaya.

False trigger

Tombol pasti ada yang tertekan tanpa sengaja. Petugas kebersihan, pengunjung yang penasaran, kardus yang disandarkan ke dinding. Dua mekanisme menjaga hal itu tidak menggerus kepercayaan pada sistem.

Pertama, tombol punya state armed/disarmed — tekanan pada tombol yang disarmed tetap tercatat, tapi tidak mem-paging siapa pun. Kedua, tiap insiden diberi disposisi oleh operator: real, false, atau drill, diselesaikan dari dashboard yang aksesnya dibatasi per peran dan per area.

Data disposisi itu jadi metrik untuk seluruh jaringan. Lokasi yang tiap minggu mencetak false alarm merusak kepercayaan lebih parah daripada lokasi yang offline. Yang offline setidaknya kelihatan rusak.

Audit trail

Setiap tekanan, setiap transisi state, setiap notifikasi yang terkirim, setiap acknowledgment dan resolusi — semuanya dicatat append-only. Setelah insiden sungguhan, pertanyaannya selalu sama: kapan tombol ditekan, siapa yang dinotifikasi, berapa lama responsnya.

Yang bisa menjawab itu log, bukan ingatan orang. Jejak yang sama jadi bukti drill benar-benar dijalankan, sekaligus bahan untuk menyetel ambang dan jendela eskalasi.

Intinya

Tombolnya sendiri cuma lima persen dari sistem panic button. Sisanya: supervised liveness, routing, eskalasi, disiplin drill, dan audit trail — struktur MQTT-ingest-ke-live-state yang sama dengan backend IoT mana pun, dengan taruhan yang jauh lebih tinggi.

Bangun dulu 95 persen yang membosankan itu. Bagian itulah yang bekerja jam 2 pagi.