Apa itu SLO? Panduan Lengkap untuk Reliability Engineering

Apa itu SLO? Service Level Objective adalah target reliability internal yang ditetapkan tim Anda sendiri. Bukan kontrak dengan pelanggan, bukan metrik mentah dari observability stack Anda. SLO menjawab satu pertanyaan: seberapa reliable layanan ini seharusnya, dan bagaimana kita akan mengukurnya?

SLO yang lengkap terlihat seperti ini: 99,9% dari HTTP requests ke /api/checkout mengembalikan success status dan selesai dalam 300ms, diukur dalam rolling window 30 hari. Tiga komponen: pengukuran, target, dan window. Ketiganya penting.

SLI, SLO, SLA: Tiga Singkatan yang Bermakna Berbeda

Ketiga istilah ini sering muncul bersama. Tim sering menggunakannya secara bergantian. Namun mereka menggambarkan hal yang berbeda.

Sebuah SLI (Service Level Indicator) adalah pengukuran mentah yang dihasilkan sistem monitoring Anda. Error rate sebagai persentase dari total requests. P99 latency dalam milliseconds. Persentase successful database writes. SLI adalah angka yang keluar dari Datadog, Grafana, atau stack apapun yang Anda jalankan. Ini memberi tahu apa yang terjadi.

Sebuah SLO (Service Level Objective) adalah target yang Anda definisikan di atas SLI. Ini menjawab: dari semua nilai yang bisa diambil SLI, range mana yang dianggap acceptable? Jika SLI Anda adalah error rate dan SLO Anda adalah "error rate di bawah 0,1% untuk 99% dari five-minute windows", maka Anda punya test pass/fail, bukan hanya angka di dashboard.

Sebuah SLA (Service Level Agreement) adalah versi eksternal dari logika yang sama, dengan konsekuensi kontrak. SLA Anda mungkin mengatakan "99,5% uptime atau kami memberikan 20% service credit". SLO Anda harus berada di atas threshold itu, sehingga tim tahu tentang degradation sebelum SLA breach menjadi percakapan dengan pelanggan.

Jarak antara SLO dan SLA bukan padding untuk kelalaian. Ini adalah margin yang dirancang untuk mengubah "kita trending ke arah breach" menjadi "kita punya waktu untuk fix ini sekarang".

Satu distinsi penting lagi: SLI diukur terus-menerus, tapi SLO dievaluasi dalam window. Error rate yang sama diukur dalam tujuh hari versus 30 hari menghasilkan hasil pass/fail yang sangat berbeda. Satu jam buruk penting sekali dalam window tujuh hari. Dalam window 30 hari, itu kira-kira satu persen dari periode. Memilih window yang tepat sama pentingnya dengan memilih target yang tepat.

Mengapa "Seberapa Reliable?" Bukan Pertanyaan Lengkap

Sebelum memilih angka, Anda perlu memahami apa yang dialami pengguna saat layanan menurun. "Kami butuh five nines" adalah pernyataan ambisi, bukan pengukuran. Checkout API dengan 99,999% availability berarti kira-kira 26 detik errors per bulan. Untuk layanan yang memproses sepuluh transaksi per detik, itu mungkin acceptable. Untuk layanan yang menangani real-time financial settlement, mungkin tidak.

SLO yang tepat tergantung pada dua faktor: dampak pengguna saat degradation, dan biaya operasional untuk mempertahankan target yang lebih ketat.

Jika layanan Anda telah mencatat 99,3% availability selama 90 hari terakhir, memulai SLO pertama Anda di 99,9% adalah aspirational, bukan calibrated. Pendekatan praktis: tarik data SLI 90 hari terakhir, set SLO sedikit lebih ketat dari performance saat ini, kemudian review quarterly. SLO 99,5% dengan real error budget policy mengalahkan SLO 99,9% yang diabaikan setiap kali breach.

Target SLO umum berdasarkan tipe layanan:

• User-facing APIs (checkout, auth): 99,9% availability, P99 latency di bawah 500ms

• Internal services (data pipelines, batch jobs): 99,5% success rate, diukur pada job completion

• Admin tooling: 99% availability sering cukup

• Background workers: SLO pada job completion time daripada HTTP status

Saat memilih SLI mana yang diukur, gunakan empat signals dari Google SRE book sebagai starting point: availability (apakah request berhasil?), latency (berapa lama waktu yang diambil?), throughput (berapa banyak requests yang ditangani sistem?), dan error rate (fraksi mana yang gagal?). Tidak setiap layanan butuh keempatnya. Paling banyak tim mendapat signal real dari availability plus satu latency percentile. Menambah SLI lebih banyak sebelum Anda punya baseline yang reliable untuk dua yang pertama adalah cara umum untuk menciptakan noise tanpa insight.

Error Budget: Dari Target ke Keputusan Operasional

Error budget adalah kebalikan matematis dari SLO Anda. Jika availability SLO Anda adalah 99,9%, maka 0,1% dari requests dalam measurement window diizinkan gagal. Untuk layanan yang menerima satu juta requests per bulan, itu adalah 1.000 failed requests sebelum SLO breach.

Error budget membuat SLO berguna secara operasional. Tanpa ini, SLO adalah threshold yang dilanggar dan kemudian didiskusikan. Dengan error budget policy, itu menjadi framework keputusan.

Saat error budget sehat, katakan 80% remaining dengan dua minggu tersisa dalam window, tim bisa ship cepat. Feature baru, experiments, deployments yang lebih berisiko semuanya dalam bounds. Error budget adalah signal bahwa speed saat ini bukan constraint.

Saat error budget burning down, tim shift. Non-critical changes ditunda. Deployment policy mengencang. Reliability fixes diprioritaskan. Error budget membuat keputusan, bukan manager judgment call tentang apakah keadaan "terasa stable enough".

Skenario konkret: checkout service mengalami 12-menit degradation pada Selasa sore, mengonsumsi 15% dari monthly error budget. Incident kedua pada Kamis mengonsumsi 12% lagi. Pada 27% dikonsumsi di minggu pertama bulan, error budget policy trigger: tidak ada new feature deployments sampai postmortem selesai dan root cause dipatch. Keputusan itu bukan negoisasi product/engineering. Itu adalah read dari data.

Google mempublikasikan error budget policy-nya dalam SRE Workbook: incident tunggal yang mengonsumsi lebih dari 20% dari quarterly error budget memerlukan postmortem. Itu adalah satu concrete policy untuk adapt.

Burn rate alerts membawa ini lebih jauh. Daripada menunggu sampai error budget hampir habis, burn rate alert fires saat rate of consumption menunjukkan Anda akan exhaust budget sebelum window berakhir. Jika layanan Anda mengonsumsi error budget pada 14 kali normal rate, Anda akan exhaust 30-day budget dalam kira-kira 50 jam. Alert pada rate itu memberi tim dua hari untuk respond daripada postmortem notification setelah breach. Tools seperti Datadog dan Grafana support multi-window, multi-burn-rate alerting out of the box. Setup-nya butuh sebuah afternoon. Tidak memilikinya berarti discover SLO breaches setelah customers sudah notice.

Menetapkan SLO Pertama Tanpa Salah dengan Angka

Mistake paling umum adalah mulai dengan target sebelum establish pengukuran.

Langkah 1: Define SLI. "Availability" bukanlah SLI. "HTTP requests yang mengembalikan non-error status (2xx/3xx), dibagi semua HTTP requests" adalah SLI. Pengukuran harus producible dari telemetry yang sudah ada. Berjanji untuk instrument sesuatu "soon" berarti SLO tidak punya data source.

Langkah 2: Pull historical data. Lihat 60 sampai 90 hari terakhir. Seperti apa SLI Anda sebenarnya? Apa saja dua atau tiga hari terburuk? Ini memberitahu apa target achievable hari ini dan berapa banyak headroom sebelum breach pertama.

Langkah 3: Set measurement window. Rolling 30-day windows paling umum dan memberikan Anda responsive, always-current data. Calendar-month windows menciptakan cliff effects pada boundaries bulan. Seven-day rolling windows lebih sensitive tapi bisa trigger terlalu frequent untuk tim yang masih building reliability muscle.

Langkah 4: Write error budget policy sebelum Anda membutuhkannya. Pada burn rate error budget berapa tim pause non-critical changes? Pada burn rate berapa on-call escalate? Document ini sebelum incident, bukan saat incident.

Langkah 5: Mulai dengan satu layanan. Define SLO untuk 15 layanan sekaligus menghasilkan 15 dashboards yang tidak dibaca siapa pun. Mulai dengan layanan paling user-visible, jalankan satu quarter, adjust, kemudian expand.

Opsi measurement window dan trade-off mereka:

• 7-day rolling: fast feedback, lebih sensitive terhadap short incidents, bisa create alert fatigue

• 30-day rolling: paling umum, balance signal dan noise

• 90-day rolling: berguna untuk infrequent tapi critical operations seperti batch jobs

Contoh worked example: untuk e-commerce API, Anda mungkin set SLO pertama sebagai "95% dari requests ke /checkout berhasil dan return dalam 500ms, diukur dalam rolling 28-day window." Itu memberikan Anda concrete SLI (success rate combined dengan latency), specific target (95%), dan defined window (28 hari). Dari sana, Anda calculate error budget: 5% dari total requests boleh gagal atau slow. Jika Anda menerima 200.000 requests per hari, monthly error budget Anda adalah kira-kira 280.000 failed requests sebelum SLO breach.

Di Mana Monitoring SLO Terhubung ke Codebase Work

Error budget yang burning lebih cepat dari expected adalah codebase problem lebih sering daripada infrastructure one. Latency spikes trace back ke N+1 queries yang tidak diperhatikan dalam code review. Availability drops trace back ke null pointer exception dalam code path yang hanya trigger di bawah specific load combination. SLO detect gejala. Codebase berisi penyebabnya.

Ini adalah di mana waktu antara "alert fires" dan "root cause identified" menjadi practical constraint. Saat checkout service mengonsumsi 30% dari error budget dalam tiga hari dan on-call engineer harus grep di seluruh 150.000-line monorepo untuk find retry logic yang behave berbeda di bawah load, SLO melakukan jobnya. Tooling untuk root cause analysis tidak.

Tim yang telah instrument AI-assisted code search bersama observability stack mereka report significantly shorter time-to-diagnosis selama incidents. Natural-language query untuk di mana payment service menangani retries pada 503 responses surfaces relevant function dalam seconds daripada 20 menit yang dibutuhkan untuk read di seluruh lima files dan satu Confluence page. 43-minute error budget window dihabiskan untuk fixing issue, bukan reading code.

Empat Cara Tim Salah dengan SLO

Terlalu banyak SLOs. Tim yang track 12 SLOs simultaneously akan treat alerts sebagai background noise dalam dua bulan. Tiga sampai lima SLOs focused pada most user-visible behaviors adalah workable ceiling untuk tim 10 engineers. Jika Anda butuh lebih, organize dalam tiers: critical SLOs yang trigger error budget policies, dan informational SLOs yang hanya generate data.

Mengukur infrastructure, bukan user experience. CPU utilization, memory usage, dan disk I/O adalah useful debug signals. Mereka adalah poor SLIs kecuali Anda bisa prove mereka directly correlate dengan user-visible degradation. Measure apa yang dialami pengguna: request success rate, response time di P95 atau P99, time to render first meaningful piece of data.

SLOs set tanpa operational cost analysis. Achieving 99,99% availability typically memerlukan active redundancy, multi-region failover, dan immediate on-call response di setiap jam. Jika tim tidak bisa sustainably operate seperti itu, SLO akan breached regularly dan kemudian ignored. Breached-and-ignored SLO lebih buruk daripada no SLO: itu train tim untuk dismiss reliability alerts.

Menggunakan error budget data untuk assign blame. Jika first response terhadap consumed error budget adalah identify siapa yang shipped change yang caused itu, reporting akan stop menjadi honest. Error budgets adalah team resource. Saat budget runs low, pertanyaan adalah "what do we fix?" bukan "who is responsible?"

Organizational health test: apakah Anda akan share current error budget status Anda dalam engineering all-hands tanpa itu trigger political discussion? Jika tidak, kultur sekitar SLOs butuh lebih banyak attention daripada targets themselves. Reliability metrics work sebagai decision tools hanya saat tim percaya bahwa reporting problem tidak create personal risk.

SLOs Butuh Quarterly Reviews, Bukan Tahunan

Menetapkan SLO bukanlah satu kali calibration. Layanan berubah, traffic patterns shift, dan cost untuk maintain given reliability level berubah dengan mereka.

Setiap 90 hari, run melalui empat pertanyaan:

1. Apakah SLO hold? Jika ya, apakah comfortable, suggesting target bisa lebih ketat?

2. Apakah error budget fully consumed? Incidents apa yang drive itu?

3. Apakah SLO surface useful signal, atau apakah tim override error budget policy?

4. Apakah measurement window masih appropriate untuk bagaimana layanan digunakan?

Jika tim override error budget policy lebih dari twice dalam quarter, SLO probably miscalibrated. Baik target terlalu ketat, window terlalu pendek, atau pengukuran tidak reflect apa yang benar-benar dialami pengguna.

SLOs adalah calibration tools. Mereka dimaksudkan untuk disesuaikan saat reliability improves, saat traffic grows, dan saat bisnis changes toleransi untuk downtime. Tim yang review dan adjust SLOs quarterly menjalankan reliability practice. Tim yang set mereka once dan belum touch sejak itu punya dashboard dengan angka yang tidak bermakna untuk siapa pun.