Belajar Observability dengan LGTM Stack - SLI, SLO, SLA & Error Budgets

#Pendahuluan

Seberapa andal layanan kalian? Pertanyaan ini tidak bisa dijawab dengan perasaan. Dunia SRE (Site Reliability Engineering) menjawabnya dengan angka: SLI mengukur, SLO menargetkan, SLA mengikat, dan error budget memberi ruang untuk bergerak.

Episode ini membahas fondasi SRE tersebut, cara mendefinisikan SLI yang tepat, implementasi SLO dengan dashboard dan burn rate alert, pengelolaan error budget, serta pemanfaatan Grafana SLO plugin.

#Fondasi SRE

#Empat Konsep Dasar

• SLI (Service Level Indicator): ukuran nyata dari keandalan layanan — misalnya persentase request berhasil.
• SLO (Service Level Objective): target yang dipatok pada SLI — misalnya 99.9 persen.
• SLA (Service Level Agreement): perjanjian dengan pelanggan, biasanya lebih longgar dari SLO.
• Error budget: toleransi kegagalan = 100 persen dikurangi SLO.

SLI (ukuran) -> SLO (target) -> SLA (janji)
error budget = 100% - SLO

Pola SLI (ukuran) -> SLO (target) -> SLA (janji) menunjukkan urutan logis — ukur dulu, targetkan, baru janjikan.

#Mendefinisikan SLI

#Request-Based SLIs

SLI berbasis request menghitung rasio kejadian baik terhadap total:

• Availability: proporsi request yang sukses terhadap total request.
• Latency: proporsi request yang selesai lebih cepat dari ambang, misalnya 300ms.

sum(rate(http_requests_total{status!~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Query di atas menghitung rasio request non-5xx — persis bentuk SLI availability di episode 19.

#Windows dan Data Source

• Windows-based SLIs: menghitung persentase waktu kondisi baik terhadap total waktu.
• Measurement strategy: pastikan metrik yang dipakai benar-benar mewakili pengalaman pengguna.
• Data source selection: PromQL dari Mimir adalah pilihan utama untuk SLI berbasis request.

name: checkout.availability
type: ratio
numerator: sum(rate(http_requests_total{status!~"5.."}[5m]))
denominator: sum(rate(http_requests_total[5m]))

Definisi type: ratio di atas adalah pola paling umum untuk SLI ketersediaan.

#Implementasi SLO

#Menetapkan Target

Pilih target yang realistis, bukan sekadar 99.99 persen:

• 99 persen: downtime kurang lebih 7 jam per bulan — cocok untuk layanan internal.
• 99.9 persen: sekitar 43 menit per bulan — standar layanan publik umum.
• 99.99 persen: sekitar 4 menit per bulan — mahal dan sulit.

#Time Window dan Dashboard

SLO dievaluasi dalam jendela waktu — rolling 30 hari atau bulan kalender. Dashboard SLO menampilkan SLI aktual, target, dan error budget yang tersisa.

#Burn Rate Alert

Burn rate adalah seberapa cepat error budget habis. Burn rate 1 berarti budget habis tepat di akhir periode; burn rate 14 berarti habis dalam 2 hari.

sum(rate(http_requests_total{status=~"5.."}[1h])) /
sum(rate(http_requests_total[1h])) / (1 - 0.999)

Nilai (1 - 0.999) adalah error budget untuk SLO 99.9 persen. Jika hasil query di atas melebihi 14, error budget sedang terbakar terlalu cepat.

#Pengelolaan Error Budget

#Perhitungan dan Keputusan

• Calculating error budgets: 100 persen dikurangi SLO, dalam bentuk waktu atau request.
• Budget consumption tracking: pantau konsumsi budget di dashboard.
• Budget-based decision making: selama budget tersisa, tim bebas merilis fitur; saat habis, fokus ke keandalan.

Error budget mengubah perdebatan "boleh rilis atau tidak" menjadi keputusan berbasis angka yang disepakati.

#Menyeimbangkan Kecepatan dan Keandalan

SLO yang terlalu tinggi menghentikan inovasi, SLO yang terlalu rendah merusak kepercayaan. Error budget memberi ruang negosiasi yang terukur antara tim produk dan tim teknis.

#Grafana SLO Plugin

Grafana menyediakan plugin SLO resmi yang mempermudah pengelolaan:

• Configuration: mendefinisikan SLO berbasis query PromQL.
• Visualization: menampilkan SLI, error budget, dan burn rate dalam satu panel.
• Alerting integration: burn rate alert terpasang langsung ke Grafana Alerting.
• Reporting: laporan berkala status SLO untuk manajemen.

#Penutup

Di episode 20 ini kalian memahami fondasi SLI, SLO, SLA, dan error budget, cara mendefinisikan SLI berbasis request dan windows, implementasi SLO dengan target realistis, dashboard, dan burn rate alert, pengelolaan error budget, serta pemanfaatan plugin Grafana SLO.

Inti yang harus dibawa pulang:

• SLI mengukur, SLO menargetkan, SLA menjanjikan.
• Error budget adalah 100 persen dikurangi SLO.
• Pilih target realistis sesuai kebutuhan bisnis.
• Burn rate alert memperingatkan budget yang terbakar cepat.
• Error budget menjadi dasar keputusan rilis yang terukur.

Di episode 21 selanjutnya kita akan membahas incident response dan postmortems — deteksi insiden, alur triage dan eskalasi, debugging dengan observability, budaya postmortem tanpa menyalahkan, serta metrik insiden seperti MTTD dan MTTR. Semua tool yang kalian bangun akan diuji pada saat inilah.