Di artikel observability sebelumnya, kita sudah membahas OpenTelemetry untuk mengumpulkan sinyal, Jaeger untuk tracing request, Falco untuk runtime security events, Loki untuk centralized logs, serta Prometheus dan Grafana untuk metrics, alerts, dan kesehatan service. Tool-tool itu membantu tim melihat apa yang sedang terjadi di dalam sistem. Pertanyaan berikutnya lebih tajam: bagaimana kita memutuskan apakah sebuah service sudah cukup reliable untuk user?

Dashboard dan alerts itu berguna, tetapi keduanya bukan reliability goal. Dashboard bisa menampilkan latency, error rate, CPU, memory, queue depth, dan database connections. Alert bisa membangunkan on-call. Namun tim tetap butuh cara yang jelas untuk mengukur apakah sebuah service benar-benar memenuhi ekspektasi user dari waktu ke waktu.

Di sinilah SLI, SLO, SLA, dan error budget menjadi penting. Mereka mengubah reliability dari sekadar perasaan menjadi operating model yang bisa diukur.

Recap: Dari Observability Signals ke Reliability Goals

Observability signals membantu engineer memahami perilaku sistem. Metrics menunjukkan pola dan severity. Logs menunjukkan konteks aplikasi. Traces menunjukkan jalur request. Security events menunjukkan aktivitas runtime yang mencurigakan.

Reliability goals memakai sinyal-sinyal itu untuk menjawab pertanyaan yang berbeda:

  • Apakah user bisa menyelesaikan workflow penting?
  • Apakah request cukup cepat?
  • Apakah error cukup rendah?
  • Apakah data yang dibutuhkan user cukup fresh?
  • Apakah service cukup reliable untuk janji produk?
Observability Signals
  metrics, logs, traces, security events
        |
        v
Service Behavior
  success, failure, latency, freshness, durability
        |
        v
Reliability Measurement
  SLI
        |
        v
Reliability Target
  SLO
        |
        v
Engineering Decisions
  ship, pause, fix, scale, simplify

Prometheus dan Grafana bisa membantu menghitung dan memvisualisasikan SLI. Logs dan traces membantu menginvestigasi kenapa sebuah SLO tidak tercapai. Perubahan cara berpikir yang penting adalah reliability goals sebaiknya dimulai dari user experience, bukan dari metric yang paling mudah digambar di dashboard.

Masalah yang Diselesaikan oleh SLI, SLO, dan SLA

Tanpa reliability goals, tim sering berdebat berdasarkan cerita masing-masing.

Satu engineer bilang service baik-baik saja karena pod masih running. Engineer lain bilang service bermasalah karena customer komplain. Dashboard menunjukkan CPU normal, tetapi checkout requests gagal. Alert firing untuk memory usage, tetapi user tidak merasakan dampak apa pun. Di saat yang sama, product team bertanya apakah sistem cukup stabil untuk meluncurkan fitur baru.

SLI, SLO, dan SLA memberi tim bahasa yang sama.

  • SLI mengukur apa yang benar-benar terjadi.
  • SLO mendefinisikan target internal untuk seberapa reliable service seharusnya.
  • SLA mendefinisikan janji eksternal atau kontraktual, sering kali dengan konsekuensi bisnis atau legal.

Dengan ini, tim bisa bergerak dari pernyataan kabur ke tradeoff yang terukur:

  • "Service terasa lambat" menjadi "p95 checkout latency di atas 800 ms."
  • "Availability bulan ini buruk" menjadi "successful checkout requests adalah 99.82% selama 30 hari."
  • "Apakah kita masih boleh ship fitur?" menjadi "kita sudah memakai 70% monthly error budget dalam satu minggu."

Ini tidak menghilangkan judgment. Ini memberi judgment input yang lebih baik.

Apa Itu SLI?

SLI, atau Service Level Indicator, adalah pengukuran aktual dari perilaku service. Ini adalah angka yang dihitung dari kejadian nyata.

SLI yang baik menggambarkan sesuatu yang penting bagi user. Biasanya SLI dihitung dari metrics, logs, request outcomes, synthetic checks, atau hasil data processing.

Contoh SLI yang umum:

  • Availability: apakah service bisa merespons.
  • Request success rate: persentase request yang berhasil.
  • Error rate: persentase request yang gagal.
  • Latency percentile: durasi request p95 atau p99.
  • Freshness: apakah data diperbarui dalam waktu yang diharapkan.
  • Durability: apakah data yang sudah committed tetap tersimpan dengan aman.

Untuk backend API, SLI yang berguna sering berasal dari perilaku request:

User Experience
  user mengirim checkout
        |
        v
Service Behavior
  checkout-api mengembalikan success atau failure
        |
        v
SLI Measurement
  successful checkout requests / total valid checkout requests
        |
        v
Reliability Signal
  checkout success rate dari waktu ke waktu

Perhatikan bahwa SLI ini bukan CPU usage. CPU adalah data operasional yang berguna, tetapi user tidak mengalami CPU secara langsung. User mengalami apakah checkout berhasil, apakah cukup cepat, dan apakah order mereka diproses dengan benar.

Infrastructure metrics tetap penting. CPU, memory, disk, network, pod restarts, dan database saturation membantu menjelaskan kenapa reliability berubah. Namun metrics seperti itu biasanya kurang cocok sebagai SLI user-facing secara langsung, kecuali service tersebut memang produk infrastructure dan customer experience-nya terkait langsung dengan resource itu.

Apa Itu SLO?

SLO, atau Service Level Objective, adalah target reliability internal untuk sebuah SLI dalam window waktu tertentu.

Jika SLI adalah measurement, maka SLO adalah goal.

Contoh:

SLI
  percentage of successful checkout requests

SLO
  99.9% of valid checkout requests succeed over 30 days

SLO memberi tim target yang cukup spesifik untuk dioperasikan. SLO juga memberi ruang untuk tradeoff. Sebuah service tidak harus sempurna. Service harus cukup reliable untuk user dan konteks bisnis yang dilayaninya.

Bagian terakhir itu penting. Tidak semua service membutuhkan reliability 99.99%.

Path payment authorization mungkin membutuhkan SLO lebih kuat dibanding internal analytics export. Public API yang dipakai paying customers mungkin membutuhkan target lebih ketat daripada halaman reporting khusus admin. Fitur early beta mungkin bisa menerima lebih banyak instability dibanding core checkout flow.

Reliability yang lebih tinggi biasanya punya biaya:

  • Lebih banyak redundancy
  • Lebih banyak testing
  • Operational complexity yang lebih tinggi
  • Rollout process yang lebih hati-hati
  • Lebih banyak engineering time untuk resilience
  • Product velocity yang lebih lambat ketika error budget rendah

Tujuannya bukan memilih angka terbesar agar terlihat keren. Tujuannya adalah memilih target reliability yang sesuai dengan ekspektasi user dan risiko bisnis.

Apa Itu SLA?

SLA, atau Service Level Agreement, adalah janji eksternal atau kontraktual. SLA sering dibuat untuk customers, partners, atau business unit lain. Isinya bisa mencakup support terms, credits, penalties, atau bahasa legal.

SLA biasanya lebih rendah atau didefinisikan lebih hati-hati dibanding SLO internal. Jarak ini memberi engineering team ruang untuk mendeteksi masalah, merespons, dan recover sebelum komitmen eksternal dilanggar.

SLI
  actual measured behavior

SLO
  internal engineering target
  biasanya lebih ketat daripada SLA

SLA
  external customer atau contractual commitment
  biasanya terkait business terms

Sebagai contoh, sebuah tim mungkin beroperasi secara internal dengan SLO 99.9%, sementara SLA formalnya adalah 99.5%. SLO memberi tahu engineer kapan reliability sudah tidak cukup baik. SLA mendefinisikan apa yang sudah dijanjikan ke pihak luar engineering team.

SLA harus ditulis dengan hati-hati karena memengaruhi trust, support, contract, dan ekspektasi customer. Engineering team perlu memahaminya, tetapi SLA bukan hanya dokumen engineering.

Bagaimana Ketiganya Terhubung

SLI, SLO, dan SLA paling mudah dipahami sebagai sebuah rantai.

User Experience
        |
        v
Service Behavior
        |
        v
SLI
  what do we measure?
        |
        v
SLO
  what target do we aim for?
        |
        v
Error Budget
  how much failure can we tolerate?
        |
        v
Engineering Decision
  ship features, slow down, or fix reliability?
        |
        v
SLA
  what do we formally promise?

SLI, SLO, SLA, dan error budget mengubah data observability menjadi keputusan reliability yang lebih jelas. SLI harus bisa diukur. SLO harus berguna untuk keputusan engineering. SLA harus selaras dengan komitmen bisnis.

Contoh praktis:

  • SLI: percentage of successful checkout requests.
  • SLO: 99.9% of valid checkout requests succeed over 30 days.
  • SLA: customer-facing commitment bahwa checkout availability akan memenuhi threshold formal, mungkin lebih rendah dan didefinisikan secara legal.

Prometheus bisa menghitung SLI dari request metrics. Grafana bisa menampilkan status SLO dan burn rate. Alertmanager bisa memberi tahu tim ketika error budget dikonsumsi terlalu cepat. Logs dan traces membantu menjelaskan dependency, route, deployment, atau code path mana yang menyebabkan burn.

Error Budget

Error budget adalah jumlah unreliability yang masih dapat diterima dalam sebuah SLO window.

Jika SLO adalah 99.9% success selama 30 hari, maka error budget-nya adalah 0.1% failure dalam window yang sama. Angka 0.1% ini bukan target untuk dihabiskan sembarangan. Ini adalah toleransi yang memungkinkan sistem nyata untuk berubah, gagal, recover, dan tetap memenuhi ekspektasi.

30-Day SLO Window

SLO: 99.9% success
Allowed unreliability: 0.1%

Total valid requests: 10,000,000
Allowed failed requests: 10,000

Successful requests
  9,990,000 atau lebih

Error Budget
  sampai 10,000 failed requests

Error budget berguna karena menghubungkan reliability dengan pilihan engineering.

Jika service sehat dan error budget hampir tidak terpakai, tim bisa tetap ship seperti biasa. Jika error budget terbakar terlalu cepat, tim mungkin perlu memperlambat risky releases, memprioritaskan reliability work, rollback deployment buruk, menambah capacity, memperbaiki dependency issue, atau memperbaiki failure handling.

Inilah balance praktisnya:

  • Reliability yang terlalu rendah membuat user kehilangan trust.
  • Reliability yang terlalu tinggi bisa menciptakan cost dan complexity yang tidak perlu.
  • Tanpa reliability target, tim akan berdebat berdasarkan opini.
  • Error budget memberi tim cara terukur untuk memutuskan kapan bergerak cepat dan kapan stabilisasi.

Error budget burn rate sangat berguna. Sebuah service bisa masih berada di dalam SLO 30 hari, tetapi membakar budget begitu cepat sehingga target akan terlewat jika tidak ada perubahan. Itu waktu yang tepat untuk alerts.

Contoh Praktis

Bayangkan sebuah platform Kubernetes menjalankan checkout-api. Service ini menerima checkout requests, memanggil payment-api, menulis orders ke PostgreSQL, dan mem-publish fulfillment events ke queue.

Tim memilih SLI yang user-facing:

SLI:
  successful valid checkout requests / total valid checkout requests

SLO:
  99.9% of valid checkout requests succeed over 30 days

SLA:
  formal customer commitment, defined separately
  biasanya lebih rendah, lebih sempit, atau legally constrained

Prometheus mengumpulkan request metrics dari checkout-api dan payment-api. Grafana menampilkan SLO dashboard. Alertmanager melakukan routing notification ketika service membakar error budget terlalu cepat.

User submits checkout
        |
        v
checkout-api
  mencatat request outcome dan latency
        |
        v
Prometheus
  scrape request metrics
        |
        v
Grafana
  menampilkan SLI, SLO status, error budget burn
        |
        v
Alertmanager
  memberi tahu tim ketika burn rate berbahaya

Suatu sore, SLO dashboard menunjukkan bahwa checkout-api membakar error budget lebih cepat dari biasanya. SLO 30 hari belum terlewat, tetapi burn rate cukup tinggi sehingga service akan gagal memenuhi target jika tren ini berlanjut.

Platform engineer memeriksa dashboard:

  • Request rate normal.
  • 5xx errors meningkat pada POST /checkout.
  • p95 latency naik sebelum 5xx spike.
  • Database connection usage normal.
  • Queue backlog stabil.
  • Timeout errors dari payment-api meningkat.

Engineer kemudian bergerak dari SLO view ke metrics, logs, dan traces.

SLO Burn Alert
  checkout-api memakai error budget terlalu cepat
        |
        v
Metrics
  5xx spike, latency increase, dependency timeout
        |
        v
Traces
  slow checkout requests menunggu payment-api
        |
        v
Logs
  payment provider timeout untuk charge operation
        |
        v
Decision
  rollback, fail over, adjust timeout, reduce traffic, atau escalate dependency

Metrics menunjukkan di mana gejalanya. Traces menunjukkan jalur request. Logs menunjukkan konteks aplikasi dan dependency. SLO memberi tahu tim seberapa serius masalahnya dari sisi user-facing reliability.

Ini perbedaan utama dari dashboard biasa. Sebuah graph mungkin menunjukkan error sedang naik. SLO view memberi tahu tim apakah reliability target sedang berisiko.

SLO yang Baik vs SLO yang Buruk

SLO yang baik terhubung dengan user experience dan keputusan engineering. SLO yang buruk sering hanya menyalin template, berbasis infrastructure metrics saja, atau memakai angka yang terdengar keren tetapi tidak cocok dengan service.

Good SLO
  SLI: successful checkout requests / total valid checkout requests
  Target: 99.9% over 30 days
  Why it matters: users can complete purchases
  Decision: slow risky releases if burn rate is too high

Bad SLO
  SLI: average CPU usage below 70%
  Target: 99.99% over 30 days
  Why it matters: unclear user impact
  Decision: unclear, may cause noisy work

SLO yang baik biasanya punya ciri seperti:

  • Mengukur perilaku yang terlihat oleh user.
  • Menggunakan SLI yang bisa dihitung konsisten oleh tim.
  • Punya time window yang jelas.
  • Mendukung keputusan release dan incident.
  • Realistis untuk maturity service dan nilai bisnisnya.
  • Bisa dijelaskan ke engineer, product team, dan support team.

SLO yang buruk sering punya masalah seperti:

  • Menggunakan CPU, memory, atau disk sebagai direct reliability target tanpa konteks user.
  • Menargetkan 99.99% karena terdengar profesional, bukan karena user membutuhkannya.
  • Mengukur perilaku yang tidak bisa dikumpulkan datanya secara reliable.
  • Mengabaikan user journey yang penting.
  • Membuat alerts yang tidak mengarah ke tindakan.
  • Menghukum gejala infrastructure yang tidak berbahaya sambil melewatkan real user pain.

CPU, memory, dan disk tetap penting. Metrics itu membantu mengoperasikan sistem dan menjelaskan failure. Hanya saja, biasanya mereka lebih cocok sebagai supporting metrics daripada SLO utama untuk API yang user-facing.

Hal yang Perlu Diwaspadai

Risiko pertama adalah memilih SLO yang terlalu jauh dari user experience. Sebuah service bisa punya pod sehat dan CPU normal sementara user tidak bisa menyelesaikan checkout. Mulai dari user journey yang penting, lalu tentukan measurement apa yang paling mewakilinya.

Risiko kedua adalah memberi semua service target 99.99%. Reliability tidak gratis. Target yang lebih tinggi biasanya membutuhkan lebih banyak redundancy, automation, testing, deployment yang lebih hati-hati, dan operational effort. Beberapa service memang layak mendapat investasi itu. Yang lain tidak.

Risiko ketiga adalah mencampuradukkan SLA dan SLO. SLA adalah janji eksternal. SLO adalah target operasi internal. Tim biasanya perlu beroperasi dengan SLO yang memberi ruang untuk melindungi SLA.

Risiko keempat adalah membangun SLO dari data yang buruk. Jika metrics hilang, labels tidak konsisten, atau success dan failure tidak didefinisikan jelas, SLO akan menciptakan rasa percaya diri yang palsu. Sebelum mempercayai sebuah SLO, pastikan SLI diukur dari event yang benar.

Risiko kelima adalah alerting pada setiap pergerakan kecil SLO. SLO alerts sebaiknya fokus pada burn rate dan risiko nyata. Budget burn yang kecil dan pelan mungkin masih dapat diterima. Burn yang cepat dan mengancam target bulanan mungkin butuh respons segera.

Risiko keenam adalah memperlakukan SLO sebagai hukuman. SLO seharusnya memandu keputusan, bukan mempermalukan tim. Jika service gagal memenuhi target, pertanyaan yang berguna adalah apa yang sedang diberitahukan sistem: dependency weakness, fallback yang hilang, rollout process yang berisiko, capacity yang kurang, instrumentation yang buruk, atau target yang tidak realistis.

Useful Reliability Loop

Define user journey
        |
        v
Choose SLI
        |
        v
Set realistic SLO
        |
        v
Monitor error budget
        |
        v
Investigate burn with metrics, logs, traces
        |
        v
Improve service, platform, or target

Loop ini seharusnya membuat percakapan reliability lebih tenang. Alih-alih berdebat apakah service "cukup stabil", tim bisa melihat pengukuran yang user-facing dan memutuskan tindakan apa yang layak diambil.

Penutup

SLI, SLO, SLA, dan error budget memberi arah reliability untuk observability. Metrics, logs, traces, dan dashboards menunjukkan apa yang terjadi. Reliability goals membantu tim memutuskan apakah yang terjadi masih dapat diterima.

SLI adalah measurement dari perilaku service yang nyata. SLO adalah target internal yang dipakai tim untuk beroperasi. SLA adalah janji eksternal, sering kali terkait business terms atau kontrak. Error budget adalah jumlah unreliability yang bisa ditoleransi tim sambil tetap memenuhi SLO.

Bagi platform dan backend team, di sinilah observability menjadi lebih dari sekadar graph. Prometheus dan Grafana bisa menunjukkan apakah service memenuhi reliability target. Alertmanager bisa melakukan routing risiko pada waktu yang tepat. Logs dan traces membantu menjelaskan kenapa target tidak tercapai.

Tujuan praktisnya bukan perfect reliability di semua tempat. Tujuannya adalah reliability yang sesuai dengan kebutuhan user, risiko bisnis, kapasitas engineering, dan product velocity. SLO yang baik membantu tim membuat tradeoff itu berdasarkan evidence, bukan tebakan.