Bagaimana Anda memilih ambang peringatan untuk menghindari kelelahan peringatan dan positif palsu?

Question

IT Interview Practice · Accepted Answer

Aturan inti: **beri peringatan tentang gejala, bukan penyebab**, dan **panggil hanya apa yang dapat ditindaklanjuti dan mendesak**. Peringatan bising yang memicu setiap malam dipasang senyap atau diabaikan — jadi risiko sebenarnya bukan peringatan yang hilang, tetapi on-call yang desensitif yang tidur melalui yang sebenarnya.

## Gejala daripada penyebab

Beri peringatan tentang **SLO yang menghadap pengguna** (tingkat kesalahan, latensi, ketersediaan), bukan penyebab internal seperti "CPU > 80%". CPU tinggi mungkin tidak berbahaya; yang penting adalah apakah pengguna terpengaruh.

```text
BAD  (cause)     CPU > 80% for 5m            → fires constantly, often no impact
GOOD (symptom)   error-rate SLO burn is fast → fires only when users hurt
```

## Peringatan laju pembakaran multi-jendela

Ambang statis tunggal terlalu reaktif atau terlalu lambat. Sebagai gantinya, beri peringatan tentang seberapa cepat Anda membakar **anggaran kesalahan**, menggunakan dua jendela sehingga pembakaran cepat segera memanggil dan pembakaran lambat hanya memanggil jika berkelanjutan.

```yaml
# Page: 2% of monthly budget burned in 1h AND still burning over 5m
- alert: HighErrorBudgetBurn
  expr: |
    (slo:error_ratio_1h > 14.4 * 0.001)   # fast window: catch big outages
    and
    (slo:error_ratio_5m > 14.4 * 0.001)   # short window: confirm it's still happening
  for: 2m
  labels: { severity: page }
```

Jendela pendek mencegah memanggil untuk masalah yang sudah teratasi sendiri; jendela panjang mencegah memanggil untuk berkedip singkat.

## Panggil vs tiket vs dasbor

```text
PAGE       actionable + urgent  → wake a human now (SLO at risk, checkout down)
TICKET     actionable, not urgent → fix in business hours (disk 70%, cert in 20 days)
DASHBOARD  informational         → no alert, just visible (per-endpoint traffic)
```

Jika peringatan tidak dapat ditindaklanjuti, itu tidak boleh memanggil — ubah menjadi tiket atau panel dasbor. Kemudian **sesuaikan seiring waktu**: tinjau setiap panggilan, hapus yang tidak ditindaklanjuti oleh siapa pun.

## Mengapa ini penting

Kelelahan peringatan adalah risiko keandalan, bukan hanya gangguan: manusia secara mental menyaring saluran bising, jadi semakin banyak positif palsu yang Anda kirim, semakin mungkin pemadaman nyata terlewatkan. Memberikan peringatan tentang gejala dengan jendela laju pembakaran, dan mereservasi panggilan untuk urgensi yang dapat ditindaklanjuti, membuat setiap panggilan bermakna — itulah yang membuat on-call responsif.

Gejala daripada penyebab

Peringatan laju pembakaran multi-jendela

Panggil vs tiket vs dasbor

Mengapa ini penting

Pertanyaan terkait