Apa Itu SLO? Panduan Praktis untuk Tim Platform dan SRE

Apa itu SLO? Service level objective adalah target seberapa andal satu perilaku pengguna tertentu harus berjalan, diukur dalam jendela waktu yang tetap. "99.9% permintaan checkout berhasil dalam kurang dari 800 ms, selama 30 hari" adalah SLO. "Situsnya harus cepat" hanyalah harapan. Angkanya sendiri kurang penting dibanding apa yang dikendalikannya: SLO menentukan kapan tim boleh terus merilis dan kapan harus berhenti.

Jam 03:12. PagerDuty memberi tahu bahwa latensi checkout "meningkat". Anda membuka dashboard dan melihat garis p99 yang naik pelan selama empat puluh menit. Tidak ada yang bisa memastikan apakah itu masalah, karena tidak ada yang pernah menuliskan seberapa besar latensi yang masih bisa diterima. Perdebatan yang terjadi setelahnya, di panggilan telepon dengan satu mata tertuju pada Slack, adalah harga dari tidak punya SLO.

SLI, SLO, SLA: tiga istilah, tiga pemilik

Orang sering memakai ketiganya secara bergantian. Padahal ketiganya berbeda, dan mencampurkannya adalah cara tim berakhir dengan kontrak yang tidak bisa mereka penuhi.

• SLI (service level indicator) adalah pengukurannya. Rasio event baik terhadap event yang valid: permintaan yang mengembalikan 2xx dalam kurang dari 800 ms, dibagi dengan semua permintaan yang seharusnya dihitung.

• SLO (service level objective) adalah target untuk rasio itu selama satu jendela waktu. 99.9% selama 30 hari.

• SLA (service level agreement) adalah kontrak dengan pelanggan, dengan konsekuensi uang jika meleset. SLA selalu lebih longgar daripada SLO. Jika SLA Anda 99.9% dan SLO Anda juga 99.9%, Anda tidak punya ruang untuk menyadari masalah sebelum harus membayar kompensasi.

Bab Google SRE tentang service level objectives menggambarkan garis yang sama: SLO adalah target internal yang berada lebih ketat daripada janji apa pun kepada pihak luar. Insinyur memiliki SLI dan SLO. Produk dan legal memiliki SLA.

Jangan tambahkan istilah keempat untuk setiap metrik yang sudah Anda kumpulkan. CPU, memori, dan kedalaman antrean berguna untuk debugging. Itu bukan SLI, karena pelanggan tidak merasakannya secara langsung.

Seperti apa SLI yang baik dalam praktik

SLI yang baik berbentuk rasio, diukur sedekat mungkin dengan pengguna, dan punya definisi yang jelas tentang apa itu "baik".

Untuk layanan berbasis permintaan, pilihan defaultnya adalah dua SLI: availability (respons non-5xx dibagi semua permintaan valid) dan latency (permintaan di bawah ambang batas dibagi semua permintaan valid). Gunakan ambang batas, bukan rata-rata. Rata-rata menyembunyikan ekor distribusi, dan ekor itulah sumber tiket dukungan pelanggan.

Ukur di load balancer atau di edge, bukan di dalam layanan. Layanan yang crash saat startup akan melaporkan tingkat error sempurna untuk permintaan yang tidak pernah sampai kepadanya. Metrik sisi server buta terhadap kegagalan seperti itu, sementara pengguna mengalaminya sebagai outage.

Tuliskan dengan jelas apa yang dikecualikan. Health check, probe sintetis dari monitoring Anda sendiri, dan respons 4xx akibat input klien yang salah biasanya tidak seharusnya dihitung sebagai kegagalan. Tulis pengecualian itu di samping SLO. Ketika seseorang memperdebatkan angka saat review insiden, perdebatannya harus soal definisi, bukan soal apa yang kebetulan ditampilkan dashboard.

Aritmetika nines yang dilewatkan banyak tim sebelum memilih

Setiap tambahan sembilan memangkas waktu down yang diizinkan sepuluh kali lipat. Ini tabel yang sebaiknya disimpan di dokumen Anda.

• 99% selama 30 hari: anggaran error 1%, atau 7.2 jam outage penuh yang diizinkan.

• 99.9%: anggaran 0.1%, 43.2 menit.

• 99.95%: anggaran 0.05%, 21.6 menit.

• 99.99%: anggaran 0.01%, 4.32 menit.

Baca baris terakhir sekali lagi. Pada 99.99%, satu deploy buruk yang butuh lima menit untuk terdeteksi dan di-revert sudah menghabiskan anggaran sebulan. Manusia tidak bisa merespons page, membuka laptop, dan melakukan revert dalam waktu kurang dari empat menit, yang berarti target itu hanya bisa dicapai dengan otomasi: gerbang otomatis yang menghentikan rollout sebelum anggaran habis.

Jadi pilih angka yang benar-benar dibutuhkan layanan. Sebagian besar API internal hidup nyaman di 99.9%. Jalur pembayaran mungkin membenarkan angka lebih tinggi. Job batch yang berjalan setiap malam mungkin cukup di 99%. Memilih 99.99% karena terdengar serius adalah cara tim mendaftar ke rotasi pager yang tidak bisa mereka isi.

Error budget adalah intinya, bukan SLO-nya

SLO 99.9% berarti Anda boleh gagal 0.1% dari waktu. Sisa 0.1% itu adalah error budget Anda, dan itu adalah gagasan paling berguna dalam seluruh disiplin ini.

Budget mengubah argumen menjadi angka. Produk ingin merilis migrasi yang berisiko. SRE bilang itu berisiko. Tanpa budget, itu adalah opini melawan opini, dan senioritas yang menang. Dengan budget, pertanyaannya menjadi: berapa yang tersisa, dan berapa banyak perubahan ini kemungkinan menghabiskannya?

Dua aturan membuatnya bekerja.

1. Budget tersisa: rilis. Anda boleh mengambil risiko, jadi ambillah. Tim yang tidak pernah menghabiskan budgetnya terlalu banyak berinvestasi pada keandalan yang tidak diminta pengguna.

2. Budget habis: bekukan. Pekerjaan fitur dihentikan sampai pekerjaan keandalan membawa SLI kembali di atas target. Ini hanya berlaku jika pimpinan menyetujuinya sebelum insiden pertama, bukan saat insiden sedang terjadi.

Jika aturan kedua tidak disepakati sebelumnya, Anda tidak punya SLO. Yang Anda punya hanyalah dashboard dengan zona hijau dan merah.

Alert pada burn rate, bukan pada SLI itu sendiri

Di sinilah sebagian besar percobaan pertama gagal. Seseorang memasang alert saat availability turun di bawah 99.9%. Alert itu menyala setelah kerusakan terjadi, atau berkedip setiap ada gangguan kecil, atau keduanya.

Sinyal yang lebih baik adalah burn rate: seberapa cepat Anda menghabiskan budget dibandingkan laju yang tepat akan menghabiskannya di akhir jendela waktu. Burn rate 1 berarti Anda akan menutup bulan dengan budget nol. Burn rate 14.4 berarti Anda berada di jalur untuk menghabiskan budget satu bulan penuh dalam sekitar dua hari.

Google SRE Workbook tentang alerting pada SLO menyarankan memasangkan jendela panjang dan pendek agar alert bermakna sekaligus masih berlangsung. Untuk SLO 30 hari, dua page adalah titik awal yang baik:

• Burn rate 14.4 selama 1 jam, dikonfirmasi selama 5 menit: menghabiskan 2% budget bulanan. Bangunkan seseorang.

• Burn rate 6 selama 6 jam, dikonfirmasi selama 30 menit: menghabiskan 5% budget bulanan. Bangunkan seseorang.

Hitungannya sederhana. Jendela 30 hari adalah 720 jam. Membakar pada 14.4x selama satu jam memakai 14.4 / 720 = 2% dari budget. Jendela pendek mencegah alert menyala satu jam setelah masalahnya sudah berakhir.

Ini aturan pertama sebagai alert Prometheus, dengan asumsi Anda merekam rasio error per jendela:

groups:
  - name: checkout-slo-burn
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        expr: |
          job:checkout_error_ratio:rate1h > (14.4 * 0.001)
          and
          job:checkout_error_ratio:rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "Checkout membakar 2% error budget 30 hari per jam"

Konstanta 0.001 adalah rasio error yang diizinkan untuk SLO 99.9%. Ubah target, dan konstanta itu ikut berubah. Simpan di satu tempat, atau alert dan SLO akan saling menjauh tanpa ada yang menyadarinya.

Burn yang lebih lambat tidak perlu page. Burn rate 1 yang bertahan selama tiga hari cukup dijadikan tiket untuk pagi hari kerja berikutnya. Membangunkan seseorang karena kebocoran lambat adalah cara tim on-call belajar mengabaikan pager.

Di mana menghitung SLI tanpa membeli platform kedua

Anda tidak butuh produk SLO khusus untuk memulai. Yang Anda butuhkan adalah counter event baik, counter total event, dan tempat untuk menyimpannya selama 30 hari.

Jika metrik Anda sudah berada di platform hosted, fitur SLO biasanya hanyalah lapisan tipis di atas data yang sudah Anda bayar.

Datadog mendukung SLO secara native, dengan alert burn-rate, dan itu jalur termudah jika trace dan metrik Anda sudah ada di sana. Tagihannya adalah jebakannya: custom metric dan tag kardinalitas tinggi berlipat ganda dengan cepat, jadi periksa harga seri SLI sebelum berkomitmen.

Jika Anda menjalankan Prometheus, Grafana mencakup wilayah yang sama melalui recording rule dan tooling SLO-nya, dengan konsekuensi lebih banyak setup dan lebih banyak waktu Anda sendiri.

Perbandingan yang jujur adalah waktu hingga alert berguna pertama versus biaya pada skala besar. Datadog menang di yang pertama. Grafana dengan Prometheus biasanya menang di yang kedua. Pilih berdasarkan mana yang kekurangan di tim Anda.

Menghubungkan SLO ke rollout, bagian yang paling sering dilewati tim

SLO yang hanya menghasilkan laporan baru setengah dipakai. Langkah yang benar-benar mengubah perilaku adalah menghubungkan budget ke jalur deploy, sehingga rilis berhenti sendiri.

Rollout progresif dengan gerbang SLO bekerja begini. Kirim ke 1% trafik di balik feature flag. Pantau SLI untuk kohort itu terhadap baseline. Jika burn rate kohort canary melewati ambang batas, revert otomatis. Jika bertahan, naikkan ke 5%, lalu 25%, lalu 100%.

Itu berbeda dari dashboard yang seharusnya diawasi seseorang pada 03:12. Pada 03:12, Anda tidak ingin berpikir. Anda ingin sebuah tombol, atau lebih baik lagi, tidak perlu tombol sama sekali.

Di sinilah feature flag menunjukkan gunanya, karena flag mengubah revert menjadi perubahan konfigurasi yang selesai dalam hitungan detik, bukan redeploy yang memakan sepuluh menit.

LaunchDarkly dan platform sejenis memberi Anda rollout persentase dan kill switch. Yang sebagian besar mereka serahkan kepada Anda adalah keputusannya: SLI mana yang dibaca, ambang batas mana yang dianggap buruk, dan siapa yang boleh mengganti keputusan. Di situlah celah yang coba ditutup oleh pilot otomatis dengan auto-rollback berbasis SLO, dan itu adalah sudut pandang yang kami ambil di upstreamapi. LaunchDarkly unggul dalam cakupan SDK dan kontrol enterprise, dan kami mengakuinya.

Berikut bentuk gerbangnya dalam TypeScript. Logika keputusan adalah bagian yang layak Anda tulis sendiri, apa pun sistem flag yang Anda pakai:

type Cohort = { good: number; total: number };

const SLO_TARGET = 0.999;
const BUDGET = 1 - SLO_TARGET; // 0.001
const PAGE_BURN_RATE = 14.4;

function burnRate(c: Cohort): number {
  if (c.total === 0) return 0;
  const errorRatio = 1 - c.good / c.total;
  return errorRatio / BUDGET;
}

export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" {
  if (canary.total < 500) return "hold"; // trafik belum cukup untuk menilai
  return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance";
}

Perhatikan cabang hold. Kanari di 1% dari layanan yang sepi mungkin hanya melihat empat puluh permintaan dalam sepuluh menit, dan satu error dari empat puluh adalah rasio error 2.5%. Tanpa sampel minimum, gerbang akan revert karena noise, dan tim Anda belajar untuk tidak mempercayainya.

Kesalahan di tim 80 engineer dan langkah pertama minggu ini

Kegagalan yang sama muncul di banyak tim, dan hampir tidak ada yang bersifat teknis.

Terlalu banyak SLO. Dua puluh objective per layanan berarti tidak ada yang mengingat satu pun. Dua atau tiga per perjalanan pengguna sudah cukup.

SLO yang tidak pernah disepakati. Seorang engineer menulisnya sendirian selama akhir pekan. Produk belum pernah melihatnya, jadi kebijakan budget runtuh pada pertama kali ia mengatakan "tidak" untuk sebuah rilis.

SLO yang diatur sesuai performa saat ini. Jika layanan berjalan di 99.97% hari ini, menetapkan target di 99.97% tidak menyisakan budget dan menjamin kegagalan. Tetapkan di titik ketika pengguna mulai tidak puas, yang hampir selalu lebih rendah.

Menganggap SLO bersifat permanen. Tinjau angkanya setiap kuartal. Jika Anda tidak pernah menghabiskan budget, perketat target atau rilis lebih cepat. Jika Anda selalu melampauinya setiap bulan, perbaiki sistemnya atau akui bahwa targetnya tidak realistis.

Menghitung apa yang mudah, bukan apa yang dirasakan. Respons 200 dengan keranjang kosong adalah sukses di log Anda dan kegagalan bagi pelanggan. Definisikan "baik" dari sisi pengguna.

Anda tidak butuh program khusus untuk langkah pertama. Pilih satu perjalanan yang akan membuat CEO menelepon seseorang jika rusak. Definisikan satu SLI availability dan satu SLI latency untuknya. Tetapkan target 99.9% untuk kuartal pertama, tuliskan kebijakan pembekuan dalam dua kalimat, dan minta produk membalas "setuju" secara tertulis.

Lalu tambahkan alert burn-rate dan tempat untuk melihat sisa budget, di tempat seluruh tim bisa melihatnya.

Jika Anda butuh tempat ringan untuk memulai sebelum berkomitmen pada platform penuh, Better Stack menangani uptime monitoring dan paging insiden dengan setup yang jauh lebih kecil, meskipun ia tidak memberi hitungan budget secara gratis.

Versi pertama pasti akan keliru. Itu tidak masalah. Yang penting, review insiden berikutnya dimulai dari angka yang sudah Anda tuliskan sebelumnya, bukan dari perasaan.

Ambil insiden terakhir yang dialami tim Anda. Apakah ada angka yang tertulis sebelumnya dan menentukan apakah insiden itu penting? Jika jawabannya jujur tidak, itulah SLO pertama Anda, dan post-mortem sudah memberi tahu apa yang harus diukur.