Bagian ini meninjau konsep indikator tingkat layanan (SLI), menentukan hal-hal yang membuat SLI yang baik atau berguna, dan memberikan contoh penerapan SLI untuk layanan yang dipilih. Halaman ini ditujukan bagi orang yang ingin contoh yang menerapkan SLI khusus layanan.
Pengantar SLI
Keandalan layanan adalah konsep abstrak; arti keandalan bergantung pada layanan dan kebutuhan penggunanya. Indikator tingkat layanan (SLI) adalah ukuran keandalan yang akan digunakan untuk menyampaikan informasi tentang keandalan layanan dan untuk mengelola layanan.
SLI diukur selama jangka waktu tertentu. Ukuran jendela biasanya bergantung pada keputusan yang dibuat berdasarkan informasi. Misalnya, Anda dapat mengukur satu SLI dengan cara berikut:
- Selama satu jam terakhir, untuk membuat kebijakan pemberitahuan.
- Selama berminggu-minggu, untuk membuat keputusan taktis.
- Selama berbulan-bulan, untuk membuat keputusan strategis.
Sebaiknya gunakan 28 hari sebagai titik awal untuk mengukur SLI Anda; nilai ini memberikan keseimbangan yang baik antara kasus penggunaan strategis dan taktis.
Untuk informasi selengkapnya, lihat bagian berikut dalam Workbook Site Reliability Engineering:
Properti SLI yang baik
Kami menganggap SLI "baik" sebagai tindakan yang memenuhi kriteria berikut:
SLI adalah ukuran proxy yang baik untuk kepuasan pengguna.
SLI yang baik berkorelasi kuat dengan kepuasan pengguna. Anda menggunakan SLI sebagai dasar untuk tujuan tingkat layanan (SLO), yaitu nilai minimum yang ditetapkan pada SLI. Anda menetapkan SLO sehingga, saat SLI berada dalam rentang yang ditentukan, sebagian besar pengguna akan puas. Agar hubungan ini berlaku, SLI harus menjadi ukuran proxy yang baik untuk kepuasan pengguna.
Jika SLI adalah proxy yang baik untuk kepuasan pengguna, maka saat ada peristiwa yang memengaruhi kepuasan pengguna, SLI akan berubah ke beberapa arah. Demikian pula, jika tidak ada peristiwa yang memengaruhi kepuasan pengguna, SLI tidak akan berubah.
SLI diskalakan secara monoton dan linear dengan kepuasan pengguna.
SLI yang baik diskalakan secara monoton, dan linear, dengan tingkat kepuasan pengguna. Jika SLI meningkat, kepuasan pengguna juga akan meningkat. Demikian pula, jika SLI menurun, kepuasan pengguna akan menurun. Jumlah peningkatan nilai SLI yang baik sesuai dengan jumlah peningkatan kepuasan pengguna.
SLI menghasilkan pengukuran yang berkisar antara 0% hingga 100%.
SLI yang baik menghasilkan pengukuran performa yang berkisar antara 0% hingga 100%: rentang ini intuitif dan mudah digunakan. Misalnya, performa SLI 100% berarti semuanya berfungsi, dan performa SLI 0% berarti tidak ada yang berfungsi.
Memiliki SLI yang berkisar antara 0% hingga 100% akan memudahkan dan memperjelas penetapan SLO di SLI: tetapkan target persentase seperti 99,9%, dan performa SLI harus sama dengan atau lebih tinggi dari target tersebut agar layanan memenuhi SLO-nya.
Promise
Salah satu cara menerapkan SLI yang memiliki properti ini adalah dengan memikirkan SLI dalam hal janji yang dibuat kepada pengguna. Dengan menghitung janji yang Anda buat dan pertahankan selama jangka waktu tertentu, Anda dapat memperoleh angka yang berkisar dari 0% hingga 100%. SLI tersebut juga diterjemahkan dengan baik ke dalam anggaran error: untuk SLO tertentu, anggaran error Anda adalah jumlah janji yang dapat Anda gagalkan untuk dipenuhi selama periode waktu sambil tetap memenuhi SLO.
Contoh promise meliputi:
- Untuk menampilkan respons dengan kode status
200
HTTP ke permintaan pelanggan. - Untuk merespons permintaan gRPC dalam waktu kurang dari 100 md.
- Untuk menyelesaikan alur kerja "Buat Virtual Machine" dengan sukses.
- Untuk menayangkan data yang telah diperbarui dalam 10 menit terakhir.
- Untuk mulai menjalankan tugas batch terjadwal dalam waktu satu menit dari waktu mulainya.
Spesifikasi dan penerapan SLI
Spesifikasi SLI adalah hal yang ingin Anda ukur. Spesifikasi ini tidak menyertakan detail teknis yang tepat tentang cara Anda akan mengukurnya. Misalnya, berikut adalah spesifikasi SLI untuk waktu pemuatan halaman:
- Persentase permintaan halaman beranda yang dimuat dalam waktu kurang dari 100 milidetik.
Ada banyak cara untuk mengukur SLI, masing-masing dengan konsekuensi dan manfaat. Cara mengukur SLI adalah Implementasi SLI. Misalnya, Anda dapat menerapkan spesifikasi pemuatan halaman sebagai salah satu hal berikut:
- Kolom latensi log permintaan server aplikasi.
- Metrik yang diekspor oleh server aplikasi.
- Metrik yang diekspor oleh load balancer di depan server aplikasi.
- Layanan pemantauan kotak hitam yang mengirim permintaan buatan ke sistem dan menghitung waktu yang diperlukan untuk menerima respons yang valid.
- Kode khusus aplikasi yang dijalankan di browser pelanggan yang mencatat informasi pengaturan waktu dan mengirimkannya kembali ke layanan pengumpulan.
Setiap pilihan ini melibatkan kompromi antara karakteristik berikut:
- Fidelitas: seberapa akuratnya prototipe mencerminkan pengalaman pengguna.
- Cakupan: proporsi interaksi pengguna yang diukur.
- Biaya: jumlah uang dan waktu engineer yang diperlukan untuk membuat dan memelihara solusi.
Fidelitas terhadap pengalaman pengguna biasanya meningkat saat SLI diukur lebih dekat dengan pengguna. Misalnya, implementasi yang menggunakan kode di browser pengguna menghasilkan pengukuran latensi yang lebih akurat daripada latensi yang dirasakan oleh pengguna atau oleh pilihan pengukuran lainnya.
Namun, pengukuran berbasis browser juga mencakup latensi apa pun yang diperkenalkan oleh koneksi pengguna ke layanan Anda. Misalnya, saat layanan digunakan melalui internet publik, latensi ini mungkin bervariasi secara signifikan dengan lokasi geografis atau kondisi jaringan.
Hasilnya adalah sinyal berbasis browser adalah proxy yang baik untuk kepuasan pengguna. Namun, sinyal ini mungkin tidak memberikan informasi yang dapat ditindaklanjuti yang dapat Anda gunakan untuk meningkatkan keandalan layanan.
Untuk informasi tentang cara menggabungkan beberapa pengukuran untuk menyeimbangkan kompromi ini, lihat postingan dari The Telegraph ini.
Pengelompokan
Anda mungkin memerlukan beberapa SLI untuk layanan saat layanan melakukan berbagai jenis pekerjaan untuk pengguna yang berbeda, atau saat layanan melakukan tugas tertentu dengan kemungkinan hasil yang berbeda.
Tugas yang berbeda
Layanan yang melakukan beberapa jenis pekerjaan, untuk berbagai kategori pengguna, dan di mana setiap jenis pekerjaan memengaruhi kepuasan pengguna secara berbeda akan mendapatkan manfaat dari beberapa SLI.
Misalnya, jika layanan Anda menangani permintaan baca dan tulis, pengguna yang melakukan tugas tersebut mungkin memiliki persyaratan yang berbeda:
- Permintaan baca harus cepat.
- Permintaan tulis harus berhasil.
Untuk menangkap persyaratan yang berbeda ini, SLI Anda harus dapat membedakan antara kedua kasus ini. Biasanya, metrik SLI memiliki label yang dapat Anda gunakan untuk mengklasifikasikan nilai ke dalam salah satu dari beberapa bucket.
Satu tugas dengan hasil yang berbeda
Layanan yang melakukan satu jenis pekerjaan, tetapi ekspektasi pengguna berbeda berdasarkan manfaat respons dari beberapa SLI.
Misalnya, jika layanan Anda hanya menawarkan akses baca ke data, pengguna mungkin memiliki toleransi latensi yang berbeda, bergantung pada hasil permintaan:
- Pengguna mungkin toleran terhadap error yang ditampilkan dengan cepat, karena pengguna dapat segera mencoba lagi permintaan tersebut.
- Pengguna mungkin kurang toleran terhadap permintaan yang berhasil tetapi memerlukan waktu lama.
- Pengguna paling tidak toleran terhadap skenario terburuk: permintaan yang memerlukan waktu lama untuk menampilkan error.
Dalam hal ini, SLI latensi Anda harus dapat membedakan antara permintaan yang berhasil dan gagal.
Langkah selanjutnya
Untuk mengetahui informasi tentang cara menerapkan SLI untuk layanan Google Cloud menggunakan metrik Google Cloud, lihat referensi berikut:
Untuk informasi tentang cara menerapkan SLI khusus aplikasi, lihat artikel berikut:
Untuk contoh yang menggambarkan cara membuat SLI untuk layanan yang melaporkan metrik kustom, lihat Menetapkan SLO: visibilitas menggunakan metrik kustom.