Kelelahan Peringatan Itu Nyata: Cara Pengembang Cerdas Mengatasinya

Kalau semua peringatan tampak sama mendesaknya, tidak ada yang terasa mendesak. Ini cara membenahi setup pemantauan Anda dengan notifikasi berjenjang — dan alat mana saja yang akur dengan Echobell.

Diperbarui

Daftar Isi

Ada namanya: alert fatigue, kelelahan peringatan. Itu yang terjadi ketika alat pemantauan Anda mengirim begitu banyak notifikasi sampai otak Anda mulai menyaringnya secara otomatis — termasuk yang sebenarnya penting.

Biasanya dimulai dari hal kecil. Anda menyiapkan peringatan email untuk setiap error 5xx. Lalu notifikasi Slack untuk setiap build yang gagal. Lalu ping Datadog, email Sentry, SMS UptimeRobot. Dalam sebulan, ponsel Anda bergetar 50 kali sehari dan tak satu pun terasa mendesak. Bagian terburuknya? Ketika sesuatu benar-benar rusak, Anda sudah terlatih untuk mengabaikannya.

Kelelahan peringatan membunuh waktu respons. Dan waktu respons yang lambat membunuh produk.

Mengapa kebanyakan setup pemantauan menghasilkan lebih banyak kebisingan daripada sinyal

Masalah mendasarnya, sebagian besar alat peringatan memperlakukan semua kejadian secara sama. Sebuah tes labil yang gagal 10% dari waktunya mendapat format notifikasi yang sama dengan "API pembayaran mengembalikan 500 untuk setiap pengguna". Salah satunya butuh panggilan telepon pukul 2 pagi. Yang satunya lagi mestinya cukup muncul di ringkasan mingguan.

Ketika semuanya diperlakukan sama, manusia mulai mengabaikan semuanya.

Solusinya bukan mengurangi jumlah peringatan — melainkan pengiriman yang lebih cerdas. Kejadian yang sama pada tingkat keparahan berbeda, atau dengan frekuensi berbeda, seharusnya menghasilkan tingkat urgensi yang berbeda di ponsel Anda.

Pendekatan tiga tingkat

Echobell memberi Anda tiga mode pengiriman, dan memakai ketiganya dengan baik adalah inti seluruh permainannya:

  • Active (Standar): Notifikasi push biasa. Cocok untuk kejadian informatif yang tidak butuh tindakan segera.
  • Peka waktu: Menembus Mode Fokus iOS. Bagus untuk hal yang butuh perhatian dalam satu-dua jam ke depan.
  • Panggilan: Membuat ponsel Anda berdering seperti panggilan masuk. Simpan ini untuk "perbaiki sekarang juga atau ada konsekuensi nyata".

Tujuannya adalah menjaga tingkat panggilan hanya untuk kejadian yang keterlambatan responsnya berkonsekuensi nyata — pendapatan hilang, kegagalan berantai, data pengguna terancam. Selebihnya turun ke peka waktu atau lebih rendah.

Sentry: Berhenti dipanggil untuk setiap exception Python

Sentry adalah contoh paling khas dari kelelahan peringatan. Secara bawaan ia mengirimi Anda email untuk setiap jenis isu baru. Pada basis kode yang aktif dalam satu minggu normal, itu seperti selang pemadam kebakaran.

Berikut setup yang lebih cerdas:

  1. Di Sentry, buka Alerts → Create Alert → Issue Alert
  2. Tambahkan kondisi: The issue is seen more than 10 times in 1 hour
  3. Tambahkan aksi: Send a notification via webhook → tempelkan URL saluran Echobell Anda
  4. Setel jenis notifikasi saluran itu ke time-sensitive

Untuk jalur yang benar-benar kritis — exception tak tertangani di alur pembayaran, kegagalan autentikasi, kerusakan data — buat peringatan terpisah dengan ambang yang lebih rendah dan saluran Echobell bertingkat calling. Saluran itu hanya berdering ketika ada yang rusak di jalur spesifik tersebut.

Hasilnya: isu rutin menumpuk dengan tenang di dashboard Sentry Anda. Masalah yang menjatuhkan produksi membuat ponsel Anda berdering.

Prometheus dan AlertManager: Rutekan berdasarkan tingkat keparahan

Jika Anda menjalankan Prometheus, Anda sudah punya AlertManager yang menangani perutean. Anda bisa mengirim peringatan langsung ke Echobell dengan menambahkannya sebagai webhook receiver.

Di alertmanager.yml Anda:

receivers:
  - name: echobell-critical
    webhook_configs:
      - url: https://hook.echobell.one/t/<channel-token>
        send_resolved: true

  - name: slack-warnings
    slack_configs:
      - api_url: YOUR_SLACK_WEBHOOK

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: slack-warnings
  routes:
    - match:
        severity: critical
      receiver: echobell-critical

Dengan setup ini, peringatan severity: critical masuk ke Echobell dan membuat ponsel Anda berdering; peringatan warning masuk ke Slack tempat ia bisa menunggu sampai pagi. Anda tidak perlu mengubah satu pun aturan Prometheus — cukup tambahkan lapisan perutean di AlertManager.

Setel saluran Echobell-nya sendiri ke Panggilan. Kalau AlertManager melabelinya critical, itu memang layak berdering sungguhan.

AWS CloudWatch: SNS → Lambda → Echobell

CloudWatch tidak punya keluaran webhook bawaan, tetapi Anda bisa mencapainya dalam beberapa menit dengan SNS dan fungsi Lambda kecil.

  1. Buat sebuah SNS topic lalu lampirkan ke alarm CloudWatch Anda
  2. Buat fungsi Lambda yang berlangganan topic tersebut:
import json
import urllib.request

def lambda_handler(event, context):
    message = json.loads(event['Records'][0]['Sns']['Message'])
    alarm_state = message.get('NewStateValue', 'UNKNOWN')

    payload = {
        "title": f"AWS: {message['AlarmName']}",
        "body": message.get('NewStateReason', 'No details'),
        "notificationType": "calling" if alarm_state == "ALARM" else "active"
    }

    req = urllib.request.Request(
        'https://hook.echobell.one/t/<channel-token>',
        data=json.dumps(payload).encode(),
        headers={'Content-Type': 'application/json'},
        method='POST'
    )
    urllib.request.urlopen(req)

Pola ini berlaku untuk layanan AWS mana pun yang mendukung SNS: peristiwa RDS, kegagalan layanan ECS, peringatan ambang tagihan, perubahan status instance EC2. Tambahkan satu Lambda, hubungkan ke SNS, dan setiap alarm CloudWatch menjadi panggilan telepon saat ia benar-benar menyala.

Menjadikan perutean peringatan sebagai keputusan tim

Manfaat sesungguhnya dari peringatan berjenjang adalah membuat keputusan peruteannya eksplisit — bukan sekadar sesuatu yang dulu dikonfigurasi satu orang dan kini tak seorang pun bisa menemukannya.

Struktur yang praktis untuk tim engineering kecil:

SaluranJenisSiapa yang berlangganan
production-api-criticalPanggilanInsinyur yang sedang on-call
production-api-warningsPeka waktuSeluruh tim dev
staging-allActiveTim dev (opsional)
background-jobsActiveSiapa saja yang berminat

Saat rotasi on-call berganti, orang yang selesai bertugas berhenti berlangganan saluran kritis dan orang yang masuk giliran berlangganan. Itu saja seluruh serah terima rotasinya — tanpa berkas konfigurasi, tanpa panel admin.

Saluran Echobell bisa dibagikan lewat tautan, jadi berlangganan hanya butuh sekitar 10 detik untuk setiap anggota tim baru.

Uji rasio sinyal terhadap kebisingan

Sebelum menambahkan peringatan baru, tanyakan satu hal: kalau ini menyala pukul 3 pagi di hari Jumat, apa yang sebenarnya akan saya lakukan?

  • "Bangun dan langsung perbaiki" → Panggilan
  • "Tangani begitu pagi tiba" → Peka waktu atau Active
  • "Kemungkinan besar tidak ngapa-ngapain, saya tidur lagi" → pertimbangkan ulang apakah peringatan itu perlu ada sama sekali

Kebanyakan setup pemantauan menaruh terlalu banyak hal di kategori pertama dan terlalu sedikit di kategori kedua. Jawaban yang tepat untuk mayoritas kejadian adalah "tangani besok", dan notifikasi peka waktu yang muncul di layar kunci tanpa berdering justru alat yang paling pas untuk itu.

Satu perubahan setiap kali

Kalau setup Anda saat ini menimbulkan kelelahan peringatan, cara tercepat memperbaikinya bukanlah perombakan total. Pilih sumber Anda yang paling berisik — kemungkinan besar email Sentry atau kanal Slack yang sudah dibisukan semua orang — lalu golongkan setiap jenis kejadian ke dalam panggilan, peka waktu, atau active.

Satu sumber. Satu minggu. Lihat apakah kebisingannya turun tanpa kehilangan sinyal.

Lalu lanjut ke sumber berikutnya.

Setup peringatan yang tertata rapi adalah salah satu hal yang diam-diam memperbaiki keseharian kerja Anda tanpa perlu drama. Anda berhenti takut pada ponsel Anda. Anda mulai percaya bahwa kalau ia berdering, itu memang penting.


Terkait