Ukur perjalanan pengguna

Pertanyaan

Gimana kita tahu user lagi dilayani dengan baik, dan sinyal mana yang dipakai buat nyari sebabnya kalau nggak?

Setelah baca ini, kamu bisa milih SLI dari sisi user buat satu alur, nulis SLO dengan anggaran error yang bisa dihitung, dan nentuin kapan perlu log, metrik, atau trace.

Prasyarat dan contoh

Kamu sudah bisa nulis target yang bisa diukur (M01.04) dan paham kenapa persentil lebih jujur daripada rata-rata. Lesson ini naikin level: dari target di atas kertas ke pengukuran yang jalan terus di produksi.

Contoh: layanan checkout punya dashboard hijau. CPU 35%, error rate server 0,1%, latensi rata-rata 180 ms. Tapi tiket support naik. Ternyata load balancer nolak 3% request sebelum sampai ke aplikasi, jadi nggak pernah kehitung di log aplikasi. Dashboard mengukur kesehatan server, bukan pengalaman user.

Mekanisme

SLI (service level indicator) adalah rasio kejadian baik terhadap kejadian valid, diukur sedekat mungkin ke user. Bentuk umumnya: good events / valid events.

Untuk alur "bayar pesanan":

• Ketersediaan: request checkout yang balas non-5xx dan selesai di bawah 2 detik, dibagi semua request checkout valid. Ukur di load balancer atau klien, bukan di dalam aplikasi.
• Latensi: persentase request yang selesai di bawah 800 ms.
• Kesegaran (buat pipeline): persentase event yang muncul di dashboard dalam 60 detik.

Request yang ditolak karena input salah (400) biasanya bukan "valid event" gagal. Definisikan ini di awal, karena mengubahnya belakangan mengubah angka historis.

SLO adalah target atas SLI untuk satu jendela waktu: "99,9% request checkout baik dalam 30 hari bergulir". Anggaran error adalah sisa yang boleh gagal: 0,1%. Kalau checkout ngelayanin 20 juta request sebulan, anggaran errornya 20.000 request gagal.

Burn rate itu seberapa cepat anggaran kepakai relatif terhadap laju yang pas habis tepat di akhir jendela. Burn rate 1 artinya habis persis di hari ke-30. Burn rate 14,4 artinya 2% anggaran bulanan hilang dalam satu jam, dan itu layak membangunkan orang. Pola alert yang umum: burn rate tinggi di jendela pendek (page) dan burn rate rendah di jendela panjang (tiket).

Tiga sinyal, tiga pertanyaan.

• Metrik itu agregat numerik per waktu. Murah, cocok buat SLI dan alert. Jawab "apa yang berubah dan seberapa parah". Hati-hati dengan kardinalitas: label user_id di metrik dengan 1 juta user bikin 1 juta deret waktu per metrik.
• Log itu catatan kejadian individual. Jawab "apa yang terjadi di request ini". Pakai log terstruktur (JSON) dengan request_id. Mahal kalau volumenya besar: 5.000 request/detik × 1 KB = sekitar 430 GB per hari.
• Trace itu jalur satu request lintas service, dengan durasi tiap span. Jawab "waktu habis di mana". Biasanya disampel, misalnya 1% plus semua yang error atau lambat (tail-based sampling).

Trace terdistribusi punya batas. Konteksnya harus diteruskan lewat setiap hop (header traceparent), dan satu service yang lupa meneruskan bikin trace terpotong. Job asinkron lewat antrean butuh konteks yang ikut dibawa di pesan. Trace juga nggak ngasih jawaban soal konsistensi data atau urutan event: dia ngasih waktu, bukan kebenaran.

Saat rancangan ini gagal

• SLI dari sisi server saja. Request yang nggak pernah sampai (DNS, TLS, load balancer, klien timeout) nggak kelihatan. Ukur di tepi, dan kalau bisa tambah probe sintetis dari luar.
• SLO terlalu ketat. 99,99% berarti sekitar 4,3 menit per bulan. Satu deploy yang buruk menghabiskannya. Kalau tim nggak sanggup menjaganya, SLO itu diabaikan.
• SLO rata-rata semua alur. Pencarian yang sehat menutupi pembayaran yang rusak. Pisah SLI per alur penting.
• Alert di penyebab, bukan gejala. "CPU di atas 80%" sering berisik dan nggak berarti user terdampak. Alert di burn rate, lalu pakai metrik penyebab buat diagnosis.
• Log jadi satu-satunya alat. Tanpa metrik, kamu nyari jarum lewat grep. Tanpa request_id, log antar service nggak bisa disambung.
• Metrik dengan kardinalitas liar. Biaya dan latensi query melonjak, kadang backend metrik ikut tumbang.

Contoh tandingan: SLO ketersediaan 99,9% terpenuhi sebulan penuh, tapi semua kegagalan terjadi di satu jam saat flash sale. Secara angka lulus, secara bisnis gagal. Tambah SLI khusus jam puncak atau jendela evaluasi yang lebih pendek.

Latihan

Layanan unggah foto menerima 4 juta request unggah per bulan. Kamu memilih SLO 99,5% unggah sukses (non-5xx, selesai di bawah 5 detik) dalam 30 hari.

1. Berapa anggaran error dalam jumlah request?
2. Insiden: 8% unggahan gagal selama 45 menit, pada laju rata-rata 4 juta/(30×24×60) request per menit. Berapa anggaran yang terpakai?
3. Sebutkan satu hal yang akan kamu ukur di luar aplikasi, dan satu sinyal yang kamu pakai buat nyari tahu langkah mana yang lambat.

Lihat pembahasan+

1. 0,5% × 4.000.000 = 20.000 unggahan gagal.
2. Laju rata-rata: 4.000.000 / 43.200 menit ≈ 93 request/menit. Dalam 45 menit ada sekitar 4.167 request. Yang gagal 8% ≈ 333 request, atau sekitar 1,7% dari anggaran (333 / 20.000). Insiden itu kelihatan besar secara persentase, tapi karena trafik rendah dampaknya ke anggaran kecil. Kalau terjadi saat puncak trafik (misalnya 10 kali rata-rata), dampaknya sekitar 10 kali lebih besar.
3. Ukur di load balancer atau probe sintetis (unggah file kecil dari luar tiap menit), supaya penolakan sebelum aplikasi tetap kehitung. Buat langkah yang lambat pakai trace: span untuk validasi, simpan ke object storage, dan pembuatan thumbnail menunjukkan di mana 5 detik itu habis.

Satu catatan: hitung anggaran dengan jumlah request, bukan menit, kalau trafiknya nggak rata. Menit gagal pas sepi dan pas ramai nggak setara.

Terkait

• M01.04 Pasang target yang masuk akal nulis target awal yang dipakai di sini.
• M16.02 Batasi overload pakai SLI ini buat mutusin kapan menolak beban.
• M16.06 Tangani insiden dan tinjau rancangan pakai burn rate dan trace saat triase.

Catatan

• Asumsi: 30 hari = 43.200 menit, trafik rata-rata dianggap seragam di latihan.
• Angka burn rate 14,4 berasal dari pola alert burn rate yang umum: 2% anggaran 30 hari dalam 1 jam.
• Yang nggak dibahas: pemilihan vendor observabilitas, desain pipeline telemetri, dan SLO multi-service yang saling bergantung.
• Terakhir ditinjau: 26 Oktober 2026.