SLO dan SLA

Definisi

SLI (Service Level Indicator)

• Metrik yang mengukur aspek tertentu dari layanan
• Data mentah yang menjadi basis SLO
• Contoh: availability, latency, error rate, throughput

SLO (Service Level Objective)

• Target yang ingin dicapai untuk SLI tertentu
• Ditetapkan secara internal oleh tim engineering
• Contoh: "availability ≥ 99.9% per bulan"

SLA (Service Level Agreement)

• Perjanjian formal dengan pengguna atau pelanggan tentang level layanan
• Biasanya lebih longgar dari SLO (SLO adalah internal target yang lebih ketat)
• Ada konsekuensi jika dilanggar (refund, penalti kontrak)

Hubungan SLI → SLO → SLA

SLI (pengukuran aktual)
  └── SLO (target internal, misal 99.9%)
        └── SLA (janji ke pelanggan, misal 99.5%)

SLO lebih ketat dari SLA agar tim punya buffer sebelum melanggar SLA.

Contoh SLI, SLO, SLA

Layanan: API Pembayaran

Error Budget

• Error budget = 1 - SLO
• Jika SLO = 99.9%, error budget = 0.1% = 43.8 menit downtime per bulan
• Error budget adalah "jatah" untuk downtime, deployment, dan eksperimen
• Ketika error budget hampir habis: kurangi risiko (tunda release besar, fokus reliability)
• Ketika error budget masih banyak: bisa lebih agresif dalam deployment dan eksperimen

Cara Menentukan SLO

Langkah 1: Tentukan SLI yang relevan

• Apa yang paling penting bagi pengguna layanan ini?
• Availability? Latency? Akurasi data?

Langkah 2: Ukur kondisi saat ini

• Berapa availability aktual dalam 3 bulan terakhir?
• Data historis menjadi baseline

Langkah 3: Tetapkan target realistis

• Tidak harus 100% — lebih tinggi berarti lebih mahal dan lebih sulit
• Tanyakan: "Berapa yang benar-benar dibutuhkan pengguna?"
• Contoh: sistem internal mungkin cukup 99.5%, payment API mungkin butuh 99.99%

Langkah 4: Review dan iterasi

• SLO adalah living document — sesuaikan berdasarkan feedback dan pengalaman

Berapa Uptime dari Angka SLO?

Menggunakan Error Budget dalam Keputusan

• Deployment baru berisiko → cek error budget tersisa sebelum deploy
• Tim ingin coba chaos engineering → butuh error budget yang cukup
• SLO konsisten tercapai dengan mudah → mungkin SLO terlalu longgar, bisa di-tighten

Praktik Terbaik

• Mulai dengan SLO yang sederhana dan sedikit sebelum menambah kompleksitas
• Tampilkan error budget di dashboard yang bisa dilihat semua engineer
• Review SLO setiap kuartal — kondisi bisnis dan teknis berubah
• Libatkan product dan bisnis dalam menentukan SLO — ini bukan keputusan teknis semata