Belajar Site Reliability Engineer - SLO, SLI & SLA

#Pendahuluan

Setelah di episode 2 kita memahami bahwa SLI/SLO/error budget adalah satu hierarki, kini saatnya turun ke detail: bagaimana mendefinisikannya dengan benar. Inilah keterampilan paling fundamental seorang SRE — dan sekaligus paling sering salah dilakukan. Banyak tim menulis "SLO 99.9%" tanpa tahu SLI apa yang diukur, sehingga target itu hanyalah angka di atas kertas.

Kabar baiknya, definisi SLO yang baik mengikuti pola yang bisa dipelajari: pilih perspektif pengguna, pilih metrik yang mewakili pengalaman itu, hitung agregasinya, lalu pilih target yang bermakna. Episode ini membekali kalian pola tersebut, dan mengakhirinya dengan SLO nyata untuk satu service.

#SLI: Apa yang Sebenarnya Diukur

SLI (Service Level Indicator) adalah ukuran kuantitatif dari aspek layanan yang dirasakan pengguna. Aturan utamanya satu kalimat: ukurlah dari sudut pandang pengguna, bukan dari sudut pandang server.

#Availability

Rasio request yang berhasil terhadap total request:

sum(rate(http_requests_total{code=~"2..|3.."}[5m]))
/ sum(rate(http_requests_total[5m]))

Perhatikan detail kritis: kita menghitung request berhasil dari sisi client (status code), bukan uptime mesin. Sebuah server yang "hidup" tapi membalas 500 pun dihitung tidak available — karena dari mata pengguna, layanan memang gagal.

#Latency

Distribusi waktu respons. Ukuran yang dipakai bukan rata-rata, melainkan percentile — karena rata-rata menyembunyikan pengguna yang menderita:

histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

#Error Rate

Rasio error terhadap total — sudah tercakup dalam availability, tetapi sering dilaporkan terpisah karena lebih ekspresif untuk debugging. Error di sini juga harus didefinisikan dari perspektif pengguna: timeout dari sisi client adalah error meskipun server "berhasil" membalas.

#SLO: Target yang Bisa Dipertanggungjawabkan

SLO (Service Level Objective) adalah target pada SLI. Pola penulisannya selalu sama:

• Apa — SLI yang dipakai.
• Berapa — nilai target dan toleransi.
• Kapan — periode pengukuran (biasanya 30 hari).

Contoh SLO yang baik:

#Mengapa "Berapa" Itu Keputusan Bisnis

Target bukan sekadar angka teknik: menentukan biaya. Setiap tambahan 9 di belakang koma berarti eksponensial biaya operasional dan batasan rilis. Latihan berpikir yang baik:

• Berapa rugi finansial bila layanan down 1 jam? 10 jam?
• Berapa biaya untuk mencapai 99,99% vs 99,9%?
• Apa yang paling dihargai pengguna — selalu tersedia, atau cepat merespons?

SLO 99,9% artinya toleransi downtime ~43 menit per bulan — dan itu boleh dipakai. SLO bukan sasaran moral, melainkan kontrak dengan bisnis.

#SLA vs SLO vs SLI: Perbedaannya

Ketiganya sering tertukar. Perbedaan praktisnya:

Aturan praktis yang dipakai Google: jangan pernah membuat SLA yang lebih ketat dari SLO. SLA punya konsekuensi eksternal (denda, kompensasi), sedangkan SLO adalah target internal. Jika SLA Anda 99,9% tetapi SLO internal 99,95%, Anda punya buffer kecil; jika dibalik, Anda menjanjikan ke pelanggan sesuatu yang tidak dijaga di dalam — resep kegagalan.

#Praktik: SLO untuk Satu Service

Kita praktikkan pada stack episode 0. Tambahkan job contoh ke prometheus.yml:

scrape_configs:
  - job_name: demo
    static_configs:
      - targets: ["demo.local:8080"]

Jalankan ulang Prometheus, lalu buka query berikut untuk menghitung error budget bulanan yang sudah terpakai:

(1 - sum(rate(http_requests_total{job="demo",code=~"5.."}[30d]))
  / sum(rate(http_requests_total{job="demo"}[30d])))
/ 0.999 * 100

Angka yang keluar: persentase error budget yang tersisa. Jika di atas 100%, SLO sudah terlanggar. Untuk mengetahuinya tanpa menghitung manual setiap hari, SLO Reporter sederhana bisa dibuat dengan PromQL record:

groups:
  - name: slo
    rules:
      - record: sli:availability:ratio_rate30d
        expr: |
          sum(rate(http_requests_total{code=~"2..|3.."}[30d]))
          / sum(rate(http_requests_total[30d]))

#Monitoring SLI

SLI harus terlihat terus-menerus, bukan dihitung saat krisis. Praktik minimum yang sehat:

1. Recording rule SLO di Prometheus (seperti di atas) agar query mahal tidak dihitung per request.
2. Dashboard SLO di Grafana: grafik error budget sisa (dalam persen), dengan threshold di 100%.
3. Alert hanya saat error budget terancam (prediksi 6 jam ke depan akan melanggar), bukan saat ada satu error — ini dibahas di episode 6.

#Penutup

Pada episode 3 ini, kalian telah menguasai fondasi pengukuran reliability.

Inti yang harus dibawa pulang:

• SLI adalah ukuran dari perspektif pengguna: availability, latency (percentile), error rate.
• SLO adalah target yang bisa dipertanggungjawabkan: SLI + nilai + periode, misalnya p95 ≤ 250 ms per 30 hari.
• SLA adalah janji eksternal — jangan pernah lebih ketat dari SLO internal.
• Pilih maksimal 3-4 SLI per service, dan buat error budget terlihat lewat recording rules + dashboard.

Di episode 4 selanjutnya, kita akan membahas error budget dan trade-offs — cara menghitung error budget, menggunakannya sebagai alat keputusan rilis, dan menjaga keseimbangan velocity vs reliability di dunia nyata. Sampai jumpa di episode 4!