Belajar Site Reliability Engineer - Alerting & On-call

#Pendahuluan

Setelah di episode 5 kita membangun observability, sekarang muncul masalah baru: data yang melimpah justru bikin bising. Begitu metrics, logs, dan traces mengalir, godaan terbesarnya adalah membuat alert untuk semua yang tampak aneh. Hasilnya bukan sistem yang aman, melainkan alert fatigue — pager berdering terus, lalu semua orang mulai mengabaikannya, dan insiden nyata tenggelam dalam kebisingan.

Episode ini mengajarkan cara berpikir yang benar: alert bukan alat pemantauan, melainkan alat keputusan. Setiap alert yang berbunyi harus membebani seorang manusia — jadi ia harus layak berbunyi. Kita bahas desain alert (accurate, relevant, actionable), pola threshold berbasis SLO, dan on-call rotation yang tidak membakar tim.

#Anatomi Alert yang Baik

Seorang SRE harus bisa membela setiap alert yang ia buat. Tolok ukurnya ada tiga:

Contoh: alert "CPU > 90%" gagal di semua kriteria — CPU tinggi belum tentu masalah, dan jika ya, tidak ada tindakan yang jelas. Bandingkan dengan "error budget SLO 30d berisiko habis dalam 6 jam" — akurat (dari SLO), relevan (menyentuh janji pengguna), actionable (freeze rilis / cek deploy terakhir).

#Format Pesan yang Layak

Setiap alert wajib memuat, minimal:

• Judul: [service][SLO] burn rate tinggi — payment API
• Ringkasan: apa yang terjadi, sejak kapan.
• Aksi: langkah pertama yang harus dilakukan (link runbook).
• Severity: P1 (service down / budget habis) sampai P3 (perlu perhatian siang hari).

Template contoh:

TITLE:  [payments][SLO] burn rate 30d = 1.4 (threshold 1.0)
AKSI:   Cek deploy terakhir di #deploy-log. Jika berasal dari
        rilis baru, rollback. Runbook: docs/runbooks/payments-slo.md
SEVERITY: P1

#Pola Threshold: Lebih dari Sekadar Angka

#Threshold Statis Itu Rapuh

Alert latency > 500ms berbunyi karena satu request lambat saat traffic sepi — noise. Sebaliknya, saat traffic meledak, threshold statis sering terlambat. Pola yang lebih sehat:

• Burn rate SLO (episode 4): alert hanya saat error budget terancam, bukan saat ada satu error. Dua jendela (1 jam + 6 jam) membedakan ledakan baru dari kondisi lama.
• Kontraksi berkelanjutan (for: 10m): konfirmasi masalah bertahan sebelum membangunkan manusia.
• Seasonal / relative baseline: bandingkan dengan perilaku periode sebelumnya, bukan absolut yang "dikira-kira".

groups:
  - name: slo-alerts
    rules:
      - alert: ErrorBudgetBurn
        expr: |
          burn_rate_1h > 14.4 * 1.0
          or
          burn_rate_6h > 6 * 1.0
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Error budget SLO 30d terancam habis"

#Mematikan Noise secara Disiplin

Alert fatigue biasanya karena ini: alert lama yang sudah tidak relevan, atau threshold yang pernah salah dan kemudian "dinormalisasi". Praktik sehat:

1. Setiap alert harus punya owner dan runbook — alert tanpa runbook dianggap belum selesai.
2. Review alert bulanan: hapus yang tidak pernah action, atau yang selalu "false positive".
3. Silence/ack harus berakhir otomatis — silence manual permanen adalah utang yang membusuk.

#On-Call Rotation yang Sehat

Alert hanya berguna bila ada manusia yang merespons dengan benar. On-call rotation perlu dirancang agar insiden tertangani tanpa membakar engineer.

#Prinsip Dasar

• Primary & Secondary: primary menjawab, secondary siap saat primary tidak bisa (sakit, overlap shift).
• Durasi rotasi: 1 minggu adalah titik tengah yang sehat — cukup untuk memahami sistem, tidak terlalu lama hingga burnout.
• Escalation path: primary → secondary → tim lead, dengan batas waktu tiap lapis (misal 15 menit).

#PagerDuty vs Grafana OnCall

Untuk tim kecil yang sudah memakai Grafana stack, Grafana OnCall cukup dan murah; tim besar dengan integrasi luas sering memilih PagerDuty. Keduanya mendukung hal yang sama: rotation, escalation, dan ack tracking. Jangan sampai terjebak fitur — yang penting adalah disiplin rotasi.

#Metrik Kesehatan On-call

Tim SRE yang sehat memantau dirinya sendiri:

• Ack time dan MTTA (waktu sampai ack) — apakah alert direspons tepat waktu?
• Alert per shift — jika sering belasan per malam, itu bukan "on-call yang sibuk", melainkan desain yang gagal.
• Follow-up burden — apakah on-call selesai saat shift selesai, atau pekerjaan menumpuk ke keesokan harinya?

#Praktik: Setup Alerting yang Sehat

Langkah konkret di stack kalian:

1. Buat satu alert burn rate SLO seperti contoh di atas untuk service demo.
2. Buat alert test dengan severity: page untuk memverifikasi routing ke channel on-call.
3. Tulis runbook satu halaman per alert (di repo, bukan di kepala) — isi: cara ack, langkah pertama, link dashboard.
4. Atur escalation primary → secondary → lead dengan batas waktu.
5. Catat MTTA/MTTR — kita pakai metrik ini lagi di episode 7.

#Penutup

Pada episode 6 ini, kalian telah belajar merancang alerting dan on-call yang sehat.

Inti yang harus dibawa pulang:

• Alert yang baik: accurate, relevant, actionable — dan setiap alert wajib punya runbook.
• Threshold berbasis burn rate SLO lebih sehat daripada angka statis.
• Alert tanpa tindakan adalah bug — review dan hapus noise secara berkala.
• On-call yang sehat: rotasi mingguan, escalation berjenjang, dan metrik MTTA/MTTR yang dipantau.

Di episode 7 selanjutnya, kita akan membahas incident management — dari detection dan response, peran IC (incident commander) dan komunikasi, hingga blameless postmortem yang menutup siklus perbaikan, lengkap dengan simulasi incident drill. Sampai jumpa di episode 7!