Artikel

Error budget dan alert burn rate: membangunkan orang untuk alasan yang tepat

Cara mengubah SLO menjadi alert yang cepat menyala saat gangguan nyata, diam saat ada derau, dan berhenti begitu masalah selesai.

Contoh-contohnya bersifat umum dan ilustratif. Tidak diambil dari lingkungan klien mana pun: sesuaikan ambang batas dan pengaturan dengan sistem Anda sendiri.

Mulai dari apa yang dialami pengguna

Sebagian besar alert yang berisik berasal dari peringatan atas penyebab — CPU, memori, pod yang restart — bukan atas apa yang dirasakan pengguna. Service-level indicator (SLI) mengukur hal itu secara langsung: porsi permintaan valid yang berhasil baik. Baik bisa berarti respons tanpa error server, respons yang lebih cepat dari ambang batas, atau keduanya.

Service-level objective (SLO) menetapkan target rasio itu dalam suatu jendela waktu, misalnya 99,9% permintaan berhasil dalam 30 hari. Selisihnya dengan 100% adalah error budget: di sini 0,1% permintaan, atau sekitar 43 menit gangguan total dalam sebulan.

Mengapa alert ambang tetap gagal

Alert seperti “tingkat error di atas 1% selama 5 menit” terlalu sensitif sekaligus terlalu lambat. Ia membangunkan orang karena lonjakan singkat yang hanya memakai sedikit budget, dan tidak pernah menyala untuk tingkat error 0,5% yang diam-diam menghabiskan seluruh budget dalam seminggu.

Burn rate mengatasi hal ini. Burn rate adalah kecepatan budget terpakai relatif terhadap SLO: burn rate 1 menghabiskan tepat seluruh budget sepanjang jendela; burn rate 14,4 menghabiskan budget 30 hari dalam sedikit lebih dari dua hari.

Alert multi-jendela dan multi-burn-rate

Pendekatan yang dijelaskan dalam SRE Workbook dari Google memasangkan setiap ambang burn rate dengan jendela panjang, yang membuktikan masalahnya signifikan, dan jendela pendek, yang membuktikan masalahnya masih berlangsung. Untuk SLO 99,9% dalam 30 hari, titik awal yang umum adalah:

Bangunkan: burn rate di atas 14,4 dalam 1 jam dan dalam 5 menit — 2% budget terpakai dalam satu jam.
Bangunkan: burn rate di atas 6 dalam 6 jam dan dalam 30 menit — 5% budget terpakai.
Tiket: burn rate di atas 1 dalam 3 hari dan dalam 6 jam — 10% budget terpakai.

# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
    / sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
    / sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)

Jendela pendek sama pentingnya dengan jendela panjang: begitu perbaikan diterapkan, rasio 5 menit turun dan alert selesai, alih-alih terus menyala sampai akhir jam.

Detail yang menentukan berhasil tidaknya

Recording rule: hitung lebih dulu rasio error tiap jendela agar ekspresi alert tetap ringan dan mudah dibaca.
Lalu lintas rendah: dengan beberapa permintaan per menit, satu kegagalan sudah menjadi rasio besar. Wajibkan jumlah permintaan minimum, atau ukur dengan probe sintetis.
SLO latensi: hitung permintaan yang lebih lambat dari ambang sebagai kejadian buruk, dengan bucket histogram yang mencakup nilai ambang tersebut.
Pengecualian: putuskan sejak awal apakah error klien dan health check ikut dihitung, lalu tuliskan di samping SLO.

Untuk apa budget itu

Budget adalah alat pengambilan keputusan, bukan sekadar pager. Selama masih sehat, tim bisa merilis lebih cepat dan mengambil perubahan yang lebih berisiko. Saat habis, pekerjaan keandalan didahulukan dari fitur sampai trennya pulih. Sepakati kebijakan ini dengan pemilik produk sebelum pelanggaran pertama, bukan saat sedang terjadi.