Pasang target yang masuk akal

Pertanyaan

Target mana yang sebenernya ngebatasin desain ini, dan gimana kita tahu udah tercapai?

Setelah baca ini, kamu bisa nilai sebuah target itu berguna atau cuma kalimat motivasi, lalu nulis ulang yang nggak berguna jadi klaim yang bisa diukur.

Prasyarat dan contoh

Kamu sudah punya beban kerja dan perkiraan kebutuhan resource (M01.02 sampai M01.03). Kamu juga udah paham bedanya rata-rata dan puncak.

Kalimat kayak "sistemnya harus cepat dan selalu tersedia" kedengeran aman, tapi nggak milih apa-apa. Engineer nggak bisa bedain desain yang lolos dari yang nggak. Bandingin sama: "redirect di bawah 100 ms p95 pada 200 request/detik, ketersediaan bulanan 99,9%". Yang kedua langsung ngilangin beberapa pilihan dan ngizinin yang lain.

Mekanisme

Target yang berguna punya empat sifat: dimensinya jelas, ada angka dan satuannya, kondisi pengukurannya disebut, dan ada konsekuensi kalau dilanggar.

Latensi. Pakai persentil, bukan rata-rata. p50 itu pengalaman umum. p95 dan p99 itu pengalaman sebagian user yang sering nentuin mereka puas atau nggak. Rata-rata nyembunyiin ekor: satu request 10 detik di antara 99 request 10 ms bikin rata-ratanya sekitar 110 ms, kelihatan baik padahal ada user yang gagal.

Throughput. Berapa unit kerja per detik pada latensi yang dijanjiin. Throughput tanpa batas latensi nggak ada artinya: sistem bisa ngolah banyak request kalau boleh lambat.

Ketersediaan. Sebut periode dan definisi gagalnya. "99,9% per bulan" itu sekitar 43 menit dalam sebulan. "99,99%" sekitar 4,3 menit. Tiap tambahan sembilan biasanya nambah biaya dan kerumitan nggak linear. Tentukan juga: kegagalan sebagian dihitung gagal atau nggak.

Durabilitas. Ini soal data yang udah diakui, bukan soal layanannya hidup. Pertanyaannya: setelah sistem bilang "tersimpan", seberapa besar kemungkinan data itu hilang? Replika bukan backup. Durabilitas nggak bisa disimpulin dari ketersediaan.

Konsistensi. Sebut jaminan yang dibutuhin user: pembacaan harus lihat tulisan terakhir nggak, urutannya harus monoton nggak, operasinya harus kelihatan atomik nggak. "Konsisten" tanpa kualifikasi nggak bisa diuji.

Target juga harus punya pemilik dan cara ukur. Kalau metriknya nggak ada, target itu cuma harapan.

Saat rancangan ini gagal

• Target tanpa pengukuran. "p99 di bawah 50 ms" tanpa instrumentasi artinya nggak ada yang tahu kapan dilanggar. Target yang nggak diukur biasanya dilupakan pas insiden.
• Rata-ratain persentil. p99 dari dua server bukan rata-rata p99 dua-duanya. Gabungin distribusinya atau laporkan per kelompok.
• Nuntut 100%. Ketersediaan 100% artinya nggak ada deploy, nggak ada dependensi yang gagal, dan nggak ada maintenance. Biayanya meledak buat manfaat yang jarang sepadan.
• Target yang saling bertentangan tanpa prioritas. "Selalu tersedia dan selalu konsisten" pas jaringan terpartisi itu bukan pilihan. Kamu harus bilang mana yang dikorbankan.
• Rata-rata bagus, ekor hancur. Fan-out ke sepuluh service bikin p99 request ditentuin service paling lambat. Rata-ratanya kelihatan bagus karena banyak request yang cepat.

Contoh tandingan: sistem nargetin "p95 di bawah 200 ms". Ternyata 4% user melakukan pembayaran, dan jalur pembayaran punya p99 3 detik. Target keseluruhannya terpenuhi, tapi pengalaman paling penting justru rusak. Target harus dipisah per alur yang penting.

Latihan

Nilai lima pernyataan ini. Tandai berguna atau nggak berguna, lalu tulis ulang yang nggak berguna.

1. "Sistemnya harus cepat."
2. "p99 redirect di bawah 150 ms, diukur dari sisi server, pada beban 300 request/detik."
3. "Ketersediaan 100%."
4. "Data yang udah diakui nggak hilang, walaupun satu zona mati."
5. "Konsisten."

Lihat pembahasan+

1. Nggak berguna. Nggak ada dimensi, angka, atau kondisi. Perbaikan: "p95 halaman daftar di bawah 300 ms pada 100 request/detik."
2. Berguna. Ada persentil, angka, titik ukur, dan beban. Masih perlu definisi gagal (misalnya error 5xx dihitung) dan periode evaluasi.
3. Nggak berguna. Nggak ada periode, definisi gagal, atau konsekuensi. Perbaikan: "99,9% per bulan kalender, diukur dari health check eksternal tiap menit; kegagalan sebagian dihitung gagal."
4. Berguna sebagai pernyataan durabilitas. Tinggal ditambah angka: "kehilangan data yang udah diakui kurang dari 1 dalam 10^9 operasi" atau "RPO 0 untuk satu kegagalan zona".
5. Nggak berguna. Konsistensi harus dikualifikasi. Perbaikan: "setelah user nulis, bacaan berikutnya dari user yang sama selalu lihat tulisan itu" (read-your-writes).

Polanya: nulis ulang target hampir selalu nambah satu kondisi pengukuran. Itu bukan birokrasi. Di situ keputusan desainnya nyempil.

Terkait

• M01.05 Mulai dari satu server pakai target ini buat mutusin kapan satu mesin udah nggak cukup.
• M16.01 Ukur perjalanan pengguna bahas SLI, SLO, dan anggaran error secara operasional.
• M02.06 Jelaskan tail latency jelasin kenapa p99 penting.

Catatan

• Asumsi: satu bulan dihitung 30 hari buat ilustrasi anggaran error.
• Angka 43 menit berasal dari 0,1% × 30 hari × 24 jam × 60 menit.
• Yang nggak dibahas: cara bangun instrumentasi, sampling trace, dan desain SLO multi-service.
• Terakhir ditinjau: 25 Oktober 2026.