Pilih tujuan tingkat layanan (SLO)

Last reviewed 2024-03-29 UTC

Dokumen dalam Framework Arsitektur Google Cloud ini menentukan cara pengalaman pengguna mendefinisikan keandalan dan cara memilih tujuan tingkat layanan yang tepat untuk memenuhi tingkat keandalan tersebut. Dokumen ini dibuat berdasarkan konsep yang ditentukan dalam Komponen SLO.

Budaya Site Reliability Engineering (SRE) menghargai layanan yang andal dan kebahagiaan pelanggan (atau kepuasan pelanggan). Tanpa tingkat layanan yang ditentukan dan metode untuk mengumpulkan metrik, akan sulit (jika tidak mungkin) untuk menentukan di mana dan berapa banyak yang harus diinvestasikan dalam peningkatan.

Metrik pengganti yang Anda gunakan untuk mengukur tingkat layanan adalah tujuan tingkat layanan (SLO). SLO terdiri dari nilai-nilai berikut:

  • Indikator tingkat layanan (SLI): Metrik dari aspek tertentu dari layanan Anda seperti yang dijelaskan dalam Memilih SLI Anda.
  • Durasi: Jendela tempat SLI diukur. Ini bisa berbasis kalender atau jendela bergulir.
  • Target: Nilai (atau rentang nilai) yang harus dipenuhi SLI dalam durasi tertentu di layanan yang sehat. Misalnya, persentase peristiwa yang baik terhadap total peristiwa yang Anda harapkan akan dipenuhi layanan Anda, seperti 99,9%.

Memilih SLO yang tepat untuk layanan Anda adalah sebuah proses. Mulailah dengan menentukan perjalanan pengguna yang menentukan keandalan dan, pada akhirnya, SLO Anda. SLO yang Anda pilih perlu mengukur seluruh sistem sekaligus menyeimbangkan kebutuhan pengembangan fitur dengan stabilitas operasional. Setelah memilih SLO, Anda harus meningkatkannya secara berulang dan mengelolanya menggunakan anggaran error.

Menentukan perjalanan pengguna Anda

SLI dan SLO Anda idealnya didasarkan pada perjalanan penting pengguna (CUJ). CUJ mempertimbangkan sasaran pengguna dan bagaimana layanan Anda membantu pengguna mencapai sasaran tersebut. Anda menentukan CUJ tanpa mempertimbangkan batas layanan. Ketika CUJ terpenuhi, pelanggan senang dan ini merupakan indikasi dari layanan yang berhasil.

Kepuasan pelanggan, atau ketidakpuasan pelanggan dalam hal itu, menentukan keandalan dan merupakan fitur paling penting dari layanan apa pun.

Oleh karena itu, tetapkan SLO cukup tinggi sehingga sebagian besar pengguna puas dengan layanan Anda, tidak lebih tinggi. Meskipun ketersediaan 100% bukanlah sasaran yang tepat, menambahkan lebih banyak "sembilan" ke SLO Anda akan menjadi mahal dan bahkan mungkin tidak penting bagi pelanggan.

Untuk waktu beroperasi dan metrik vital lainnya, targetkan target yang lebih rendah dari 100%, tetapi mencapai target. Menilai tingkat ketersediaan dan performa layanan minimum yang diperlukan. Jangan tetapkan target berdasarkan tingkat kontrak eksternal.

Menggunakan CUJ untuk mengembangkan SLO

Pilih CUJ perusahaan Anda yang paling penting, dan ikuti langkah-langkah berikut untuk mengembangkan SLO:

  1. Pilih spesifikasi SLI (seperti ketersediaan atau keaktualan).
  2. Menentukan cara menerapkan spesifikasi SLI.
  3. Pastikan paket Anda mencakup semua CUJ.
  4. Tetapkan SLO berdasarkan performa atau kebutuhan bisnis sebelumnya.

CUJ tidak boleh dibatasi pada satu layanan, maupun terbatas pada satu tim atau organisasi pengembangan. Layanan Anda mungkin bergantung pada puluhan atau lebih layanan lain. Anda mungkin juga mengharapkan layanan tersebut beroperasi pada 99,5%. Namun, jika performa end-to-end (seluruh sistem) tidak dilacak, menjalankan layanan yang andal akan sulit dilakukan.

Menentukan target dan durasi

Menentukan target dan duration (lihat definisi SLO sebelumnya) bisa jadi sulit. Salah satu cara untuk memulai proses ini adalah dengan mengidentifikasi SLI Anda dan membuat diagramnya dari waktu ke waktu. Ingat, SLO tidak harus sempurna sejak awal. Lakukan iterasi pada SLO untuk memastikannya selaras dengan kebahagiaan pelanggan dan memenuhi kebutuhan bisnis Anda.

Saat Anda melacak kepatuhan SLO selama peristiwa seperti deployment, pemadaman, dan pola traffic harian, Anda akan mendapatkan insight tentang target. Insight ini akan memperjelas mana yang baik, buruk, atau dapat ditoleransi untuk target dan durasi.

Pengembangan fitur, peningkatan kode, upgrade hardware, dan tugas pemeliharaan lainnya dapat membantu menjadikan layanan Anda lebih andal. Kemampuan untuk melakukan perubahan kecil yang sering ini membantu Anda menghadirkan fitur lebih cepat dan dengan kualitas lebih tinggi. Namun, tingkat perubahan layanan juga memengaruhi keandalan. Sasaran keandalan yang dapat dicapai menentukan kecepatan dan cakupan perubahan (disebut kecepatan fitur) yang dapat ditoleransi dan bermanfaat oleh pelanggan.

Jika tidak dapat mengukur pengalaman pelanggan dan menentukan sasaran terkaitnya, Anda dapat beralih ke sumber luar dan menganalisis tolok ukur. Jika tidak ada tolok ukur yang dapat dibandingkan, ukur pengalaman pelanggan, meskipun Anda belum dapat menentukan sasaran. Seiring waktu, Anda dapat mencapai ambang batas kebahagiaan pelanggan yang wajar. Batas ini adalah SLO Anda.

Memahami keseluruhan sistem

Layanan Anda mungkin berada dalam lini layanan yang panjang dengan pemrosesan upstream dan downstream. Mengukur performa sistem terdistribusi secara tidak konsisten (layanan menurut layanan) tidak mencerminkan pengalaman pelanggan secara akurat dan dapat menyebabkan penafsiran yang terlalu sensitif.

Sebagai gantinya, Anda harus mengukur performa terhadap SLO di frontend proses untuk memahami apa yang dialami pengguna. Pengguna tidak khawatir dengan kegagalan komponen yang menyebabkan kueri gagal jika kueri secara otomatis dan berhasil dicoba ulang.

Jika ada layanan internal bersama yang diterapkan, setiap layanan dapat mengukur performa secara terpisah terhadap SLO terkait, dengan layanan yang ditampilkan kepada pengguna sebagai pelanggan mereka. Tangani SLO ini secara terpisah.

Anda dapat membangun layanan yang sangat tersedia (misalnya, 99,99%) di atas layanan yang kurang tersedia (misalnya, 99,9%) menggunakan faktor ketahanan seperti percobaan ulang yang cerdas, caching, dan antrean. Siapa pun yang memiliki pengetahuan statistik yang memadai harus dapat membaca dan memahami SLO tanpa memahami layanan dasar atau tata letak organisasi Anda seperti yang dijelaskan dalam Hukum Conway.

Memilih SLO yang tepat

Ada ketegangan alami antara kecepatan pengembangan produk dan stabilitas operasi. Semakin sering Anda mengganti sistem, semakin besar kemungkinan sistem rusak. Alat pemantauan dan kemampuan observasi sangat penting untuk stabilitas operasional saat Anda meningkatkan kecepatan fitur. Alat tersebut dikenal sebagai alat pengelolaan performa aplikasi (APM), dan juga dapat digunakan untuk menetapkan SLO.

Jika ditentukan dengan benar, SLO membantu tim membuat keputusan operasional berbasis data yang meningkatkan kecepatan pengembangan tanpa mengorbankan stabilitas. SLO juga dapat menyelaraskan tim pengembangan dan operasi berdasarkan satu tujuan yang disepakati. Berbagi satu tujuan mengurangi ketegangan alami yang disebutkan sebelumnya: tujuan tim pengembangan untuk membuat dan melakukan iterasi pada produk, dan tujuan tim operasi untuk mempertahankan integritas sistem.

Gunakan dokumen ini dan dokumen keandalan lainnya dalam Framework Arsitektur untuk memahami dan mengembangkan SLO. Setelah Anda membaca dan memahami artikel ini, lanjutkan ke informasi yang lebih mendetail tentang SLO (dan praktik SRE lainnya) di The SRE Book dan The SRE Workbook.

Gunakan SLO internal yang ketat

Ini adalah praktik yang baik untuk memiliki SLO internal yang lebih ketat daripada SLA eksternal. Karena pelanggaran SLA cenderung mengharuskan penerbitan kredit keuangan atau pengembalian dana pelanggan, Anda ingin mengatasi masalah sebelum mencapai dampak finansial.

Sebaiknya gunakan SLO internal yang lebih ketat ini dengan proses retrospektif dan peninjauan insiden tanpa menyalahkan. Untuk mengetahui informasi selengkapnya, lihat Membangun proses manajemen insiden kolaboratif dalam kategori keandalan Architecture Center.

Tingkatkan SLO secara iteratif

SLO tidak boleh bersifat permanen. Tinjau kembali SLO secara berkala — minimal tiga bulanan, atau setidaknya setiap tahun — dan konfirmasikan bahwa SLO secara akurat mencerminkan kebahagiaan pengguna dan berkorelasi dengan pemadaman layanan. Pastikan solusi mencakup kebutuhan bisnis saat ini dan perjalanan penting baru yang dialami pengguna. Revisi dan tingkatkan SLO Anda sesuai kebutuhan setelah peninjauan ini.

Gunakan anggaran error untuk mengelola kecepatan pengembangan.

Anggaran error menunjukkan apakah layanan Anda lebih atau kurang dapat diandalkan daripada yang diperlukan untuk periode waktu tertentu. Anggaran error dihitung 100% – SLO selama jangka waktu tertentu, misalnya 30 hari.

Jika memiliki sisa kapasitas pada anggaran error, Anda dapat terus meluncurkan peningkatan atau fitur baru dengan cepat. Jika anggaran error mendekati nol, perlambat atau bekukan perubahan layanan dan investasikan resource engineering untuk meningkatkan fitur keandalan.

Kemampuan Observasi Google Cloud mencakup pemantauan SLO untuk meminimalkan upaya penyiapan SLO dan anggaran error. Operations Suite menyertakan antarmuka pengguna grafis untuk membantu Anda mengonfigurasi SLO secara manual, API untuk penyiapan SLO terprogram, dan dasbor bawaan untuk melacak laju pengeluaran anggaran error. Untuk mengetahui informasi selengkapnya, lihat Membuat SLO.

Ringkasan rekomendasi SLO

  • Tentukan dan ukur SLI yang berfokus pada pelanggan, seperti ketersediaan atau latensi layanan.
  • Tentukan anggaran error yang berfokus pada pelanggan yang lebih ketat daripada SLA eksternal Anda. Sertakan konsekuensi atas pelanggaran seperti pembekuan produksi.
  • Siapkan SLI latensi untuk mengambil nilai pencilan, seperti persentil ke-90 atau ke-99, untuk mendeteksi respons paling lambat.
  • Tinjau SLO setidaknya setiap tahun dan konfirmasi bahwa SLO tersebut berkorelasi baik dengan kepuasan pengguna dan gangguan layanan.

Langkah selanjutnya