Tentukan sasaran yang berguna

Pertanyaan

Sasaran mana yang sebenarnya membatasi rancangan ini, dan bagaimana kita tahu sudah tercapai?

Hasil yang bisa diamati: kamu bisa menilai sebuah pernyataan sasaran sebagai berguna atau tidak, lalu menulis ulang yang tidak berguna menjadi klaim yang bisa diukur.

Prasyarat dan contoh

Kamu sudah punya beban kerja dan perkiraan kebutuhan sumber daya (M01.02–M01.03). Kamu paham perbedaan rata-rata dan puncak.

Pernyataan seperti "sistem harus cepat dan selalu tersedia" terdengar aman, tetapi tidak memilih apa pun. Engineer tidak bisa membedakan rancangan yang memenuhi dari yang tidak. Sebaliknya, "redirect di bawah 100 ms p95 pada 200 request/detik, dengan ketersediaan bulanan 99,9%" langsung menyingkirkan beberapa pilihan dan mengizinkan yang lain.

Mekanisme

Sasaran yang berguna punya empat sifat: dimensi yang jelas, angka dengan satuan, kondisi pengukuran, dan konsekuensi saat dilanggar.

Latensi. Nyatakan persentil, bukan rata-rata. p50 adalah pengalaman umum; p95 dan p99 adalah pengalaman sebagian pengguna dan sering menentukan kepuasan. Rata-rata menyembunyikan ekor: satu request 10 detik di antara 99 request 10 ms menghasilkan rata-rata sekitar 110 ms, yang tetap terlihat baik padahal ada pengguna yang gagal.

Throughput. Berapa unit kerja per satuan waktu pada tingkat latensi yang dijanjikan. Throughput tanpa batas latensi tidak bermakna: sistem bisa memproses banyak request jika boleh lambat.

Ketersediaan. Nyatakan periode dan definisi gagal. "99,9% per bulan" berarti sekitar 43 menit dalam sebulan. "99,99%" berarti sekitar 4,3 menit. Setiap tambahan sembilan biasanya menambah biaya dan kompleksitas secara tidak linear. Tentukan juga apakah kegagalan sebagian dihitung.

Durabilitas. Ini soal data yang sudah diakui, bukan soal layanan hidup. Pertanyaannya: setelah sistem mengatakan "tersimpan", seberapa besar kemungkinan data itu hilang? Replika bukan backup. Durabilitas tidak bisa disimpulkan dari ketersediaan.

Konsistensi. Nyatakan jaminan yang dibutuhkan pengguna: apakah pembacaan harus melihat tulisan terakhir, apakah urutan harus monoton, apakah operasi harus terlihat atomik. "Konsisten" tanpa kualifikasi tidak bisa diuji.

Sasaran juga harus punya pemilik dan cara pengukuran. Jika metriknya tidak ada, sasaran itu hanya harapan.

Saat rancangan ini gagal

• Sasaran tanpa pengukuran. "p99 di bawah 50 ms" tanpa instrumentasi berarti tidak ada yang tahu kapan dilanggar. Sasaran yang tidak diukur cenderung diabaikan saat insiden.
• Merata-ratakan persentil. p99 dari dua server bukan rata-rata p99 keduanya. Gabungkan distribusinya atau laporkan per kelompok.
• Menuntut 100%. Ketersediaan 100% mengimplikasikan tidak ada deployment, tidak ada kegagalan dependensi, dan tidak ada pemeliharaan. Biayanya meledak untuk manfaat yang jarang sepadan.
• Sasaran yang saling bertentangan tanpa prioritas. "Selalu tersedia dan selalu konsisten" saat partisi jaringan bukan pilihan; kamu harus menyatakan mana yang dikorbankan.
• Latensi rata-rata yang bagus, ekor yang hancur. Fan-out ke sepuluh layanan membuat p99 request ditentukan oleh layanan paling lambat. Rata-rata terlihat baik karena banyak request cepat.

Contoh tandingan: sistem menetapkan "p95 di bawah 200 ms". Ternyata 4% pengguna melakukan pembayaran, dan jalur pembayaran punya p99 3 detik. Sasaran keseluruhan terpenuhi, tetapi pengalaman yang paling penting rusak. Sasaran harus dipisah per alur yang penting.

Latihan

Nilai lima pernyataan berikut. Tandai berguna atau tidak berguna, lalu tulis ulang yang tidak berguna.

1. "Sistem harus cepat."
2. "p99 redirect di bawah 150 ms, diukur dari sisi server, pada beban 300 request/detik."
3. "Ketersediaan 100%."
4. "Data yang sudah diakui tidak hilang, bahkan jika satu zona gagal."
5. "Konsisten."

Lihat pembahasan+

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

Perhatikan pola: menulis ulang sasaran biasanya menambahkan satu kondisi pengukuran. Itu bukan birokrasi; di situlah keputusan desain bersembunyi.

Terkait

• M01.05 Mulai dari satu mesin memakai sasaran ini untuk memutuskan kapan mesin tunggal tidak lagi cukup.
• M16.01 Ukur perjalanan pengguna membahas SLI, SLO, dan anggaran error secara operasional.
• M02.06 Jelaskan tail latency menjelaskan mengapa p99 penting.

Catatan

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