Memilih indikator tingkat layanan (SLI)

Last reviewed 2024-03-29 UTC

Dokumen dalam Framework Arsitektur Google Cloud ini menjelaskan cara memilih indikator tingkat layanan (SLI) yang sesuai untuk layanan Anda. Dokumen ini dibuat berdasarkan konsep yang ditentukan dalam Komponen SLO.

Metrik diperlukan untuk menentukan apakah tujuan tingkat layanan (SLO) Anda terpenuhi. Anda menentukan metrik tersebut sebagai SLI. Setiap SLI adalah pengukuran aspek tertentu dari layanan Anda seperti waktu respons, ketersediaan, atau tingkat keberhasilan.

SLO mencakup satu atau beberapa SLI, dan idealnya didasarkan pada perjalanan penting pengguna (CUJ). CUJ mengacu pada serangkaian interaksi pengguna atau jalur tertentu yang diambil pengguna untuk mencapai sasaran mereka di situs. Pertimbangkan pelanggan yang berbelanja di layanan e-commerce. Pelanggan login, menelusuri produk, menambahkan item ke keranjang, membuka halaman checkout, dan melakukan checkout. CUJ mengidentifikasi berbagai cara untuk membantu pengguna menyelesaikan tugas secepat mungkin.

Saat memilih SLI, Anda perlu mempertimbangkan metrik yang sesuai dengan layanan Anda, berbagai jenis metrik yang dapat Anda gunakan, kualitas metrik, dan jumlah metrik yang benar yang diperlukan.

Memilih SLI yang sesuai untuk jenis layanan Anda

Ada banyak jenis layanan. Tabel berikut mencantumkan jenis layanan umum dan memberikan contoh SLI untuk setiap jenis layanan. Beberapa SLI berlaku untuk beberapa jenis layanan. Jika SLI muncul lebih dari sekali dalam tabel, hanya instance SLI pertama yang memberikan definisi. Ingat bahwa SLI sering kali dinyatakan dengan jumlah "sembilan" dalam metrik.

Jenis layanan SLI Umum
Sistem penayangan
  • Ketersediaan — persentase layanan yang dapat digunakan. Ketersediaan didefinisikan sebagai pecahan permintaan yang berhasil dibagi dengan jumlah total permintaan, dan dinyatakan sebagai persentase seperti 99,9%.
  • Latensi — seberapa cepat persentase permintaan tertentu terpenuhi. Misalnya, persentil ke-99 pada 300 md.
  • Kualitas — sejauh mana konten dalam respons terhadap permintaan menyimpang dari konten respons yang ideal. Misalnya, skala dari 0% hingga 100%.
Sistem pemrosesan data
  • Cakupan — jumlah data yang telah diproses, dinyatakan sebagai fraksi. Misalnya, 95%.
  • Koreksi — fraksi data output yang dianggap benar. Misalnya, 99,99%.
  • Keaktualan — Keaktualan data sumber atau data output gabungan. Misalnya, data diperbarui 20 menit yang lalu.
  • Throughput — Jumlah data yang diproses. Misalnya, 500 MiB per detik atau 1.000 permintaan per detik.
Sistem penyimpanan
  • Ketahanan — kemungkinan data yang ditulis ke sistem diakses di masa mendatang. Misalnya, 99,9999%.
  • Time to first byte (TTFB) — waktu yang diperlukan untuk mengirim dan mendapatkan byte pertama halaman.
  • Ketersediaan blob — rasio permintaan pelanggan yang menampilkan respons error non-server terhadap jumlah total permintaan pelanggan.
  • Throughput
  • Latensi
Sistem permintaan
  • Ketersediaan
  • Latensi
  • Kualitas
Sistem eksekusi terjadwal
  • Skew — proporsi eksekusi yang dimulai dalam jangka waktu yang dapat diterima dari waktu mulai yang diharapkan.
  • Eksekusi — Waktu yang diperlukan untuk menyelesaikan tugas. Untuk eksekusi tertentu, mode kegagalan yang umum adalah agar durasi aktual melebihi durasi terjadwal.

Mengevaluasi berbagai jenis metrik

Selain memilih SLI yang sesuai untuk layanan Anda, Anda perlu menentukan jenis metrik yang akan digunakan untuk SLI. SLI yang tercantum di bagian sebelumnya cenderung berupa salah satu jenis berikut:

  • Penghitung: Jenis metrik ini dapat meningkat, tetapi tidak dapat menurun. Misalnya, jumlah error yang terjadi hingga titik pengukuran tertentu.
  • Pengukur: Jenis metrik ini dapat meningkat atau menurun. Misalnya, nilai sebenarnya dari bagian sistem yang dapat diukur (seperti panjang antrean).
  • Distribusi (histogram): Jumlah peristiwa yang mengisi segmen pengukuran tertentu selama jangka waktu tertentu. Misalnya, mengukur jumlah permintaan yang memerlukan waktu 0-10 md untuk diselesaikan, yang memerlukan waktu 11-30 md, dan yang memerlukan waktu 31-100 md. Hasilnya adalah jumlah untuk setiap bucket, seperti [0-10: 50], [11-30: 220], dan [31-100: 1103].

Untuk mengetahui informasi selengkapnya tentang jenis ini, lihat dokumentasi project Prometheus dan Jenis nilai dan jenis metrik di Cloud Monitoring.

Pertimbangkan kualitas metrik

Tidak semua metrik berguna. Selain rasio peristiwa yang berhasil terhadap total peristiwa, Anda perlu menentukan apakah metrik merupakan SLI yang baik untuk kebutuhan Anda. Untuk membantu Anda membuat penentuan tersebut, pertimbangkan karakteristik metrik yang baik berikut:

  • Metrik berhubungan langsung dengan kepuasan pengguna. Pengguna tidak puas jika layanan tidak berperilaku seperti yang diharapkan, seperti saat layanan lambat, tidak akurat, atau gagal sepenuhnya. Validasi SLO apa pun berdasarkan metrik ini dengan membandingkan SLI dengan sinyal kepuasan pengguna lainnya. Perbandingan ini mencakup data seperti jumlah tiket keluhan pelanggan, volume panggilan dukungan, dan sentimen media sosial. (Untuk mempelajari lebih lanjut, lihat Peningkatan Berkelanjutan pada Target SLO).

    Jika metrik Anda tidak selaras dengan indikator kepuasan pengguna lainnya, metrik tersebut mungkin bukan SLI yang baik.

  • Penurunan metrik berkorelasi dengan pemadaman layanan. Setiap metrik yang melaporkan hasil layanan yang baik selama pemadaman layanan jelas merupakan metrik yang salah untuk SLI. Sebaliknya, metrik yang terlihat buruk selama operasi normal juga bermasalah

  • Metrik ini memberikan rasio sinyal terhadap noise yang baik. Hapus metrik apa pun yang menghasilkan negatif palsu atau positif palsu dalam jumlah besar.

  • Metrik ini diskalakan secara monoton dan linear dengan kepuasan pelanggan. Singkatnya, seiring dengan meningkatnya metrik, kepuasan pelanggan juga meningkat.

Memilih jumlah metrik yang benar

Satu layanan dapat memiliki beberapa SLI, terutama jika layanan tersebut melakukan berbagai jenis pekerjaan atau melayani jenis pengguna yang berbeda. Sebaiknya pilih metrik yang sesuai untuk setiap jenis.

Sebaliknya, beberapa layanan melakukan jenis pekerjaan serupa yang dapat dibandingkan secara langsung. Misalnya, pengguna yang melihat halaman yang berbeda di situs Anda (seperti halaman beranda, subkategori, dan daftar 10 teratas). Daripada mengembangkan SLI terpisah untuk setiap tindakan ini, gabungkan ke dalam satu kategori SLI, seperti layanan jelajah.

Harapan pengguna Anda tidak banyak berubah di antara tindakan dari kategori yang serupa. Kepuasan pengguna dapat diukur dengan jawaban atas pertanyaan: "Apakah saya melihat item sehalaman penuh dengan cepat?"

Gunakan sesedikit mungkin SLI untuk menunjukkan toleransi layanan Anda secara akurat. Sebagai panduan umum, miliki dua hingga enam SLI. Dengan terlalu sedikit SLI, Anda dapat kehilangan sinyal yang berharga. Terlalu banyak dan tim dukungan Anda memiliki terlalu banyak data dengan sedikit manfaat tambahan. SLI harus menyederhanakan pemahaman Anda terkait kondisi produksi dan memberikan gambaran cakupan, bukan membuat Anda kewalahan (atau tidak puas).

Apa langkah selanjutnya?