Memilih tujuan tingkat layanan (SLO)

Last reviewed 2024-03-29 UTC

Dokumen dalam Framework Arsitektur Google Cloud ini menentukan bagaimana pengalaman pengguna menentukan keandalan dan cara memilih tujuan tingkat layanan yang sesuai 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 kepuasan 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 utama yang Anda gunakan untuk mengukur tingkat layanan adalah tujuan tingkat layanan (SLO). SLO terdiri dari nilai-nilai berikut:

  • Indikator tingkat layanan (SLI): Metrik aspek tertentu dari layanan Anda seperti yang dijelaskan dalam Memilih SLI.
  • Durasi: Periode waktu saat SLI diukur. Periode ini dapat berbasis kalender atau periode bergulir.
  • Target: Nilai (atau rentang nilai) yang harus dipenuhi SLI dalam durasi tertentu dalam layanan yang sehat. Misalnya, persentase peristiwa yang baik terhadap total peristiwa yang Anda harapkan akan dipenuhi oleh layanan, seperti 99,9%.

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

Menentukan perjalanan pengguna

Idealnya, SLI dan SLO Anda didasarkan pada perjalanan penting pengguna (CUJ). CUJ mempertimbangkan tujuan pengguna dan cara layanan Anda membantu pengguna mencapai tujuan tersebut. Anda menentukan CUJ tanpa mempertimbangkan batas layanan. Jika CUJ terpenuhi, pelanggan akan puas dan ini adalah indikasi layanan yang berhasil.

Kepuasan pelanggan, atau ketidakpuasan, menentukan keandalan dan adalah fitur terpenting dari setiap layanan.

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

Untuk waktu beroperasi dan metrik vital lainnya, targetkan target yang lebih rendah dari 100%, tetapi mendekatinya. Menilai tingkat minimum performa dan ketersediaan layanan yang diperlukan. Jangan menetapkan 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. Tentukan cara menerapkan spesifikasi SLI.
  3. Pastikan rencana 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 lainnya. Anda mungkin juga mengharapkan layanan tersebut beroperasi pada 99,5%. Namun, jika performa menyeluruh (seluruh sistem) tidak dilacak, menjalankan layanan yang andal akan menjadi tantangan.

Menentukan target dan durasi

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

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

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

Jika tidak dapat mengukur pengalaman pelanggan dan menentukan sasaran terkait hal tersebut, Anda dapat menggunakan sumber eksternal dan analisis 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. Nilai minimum ini adalah SLO Anda.

Memahami seluruh sistem

Layanan Anda mungkin ada dalam deretan panjang layanan dengan pemrosesan upstream dan downstream. Mengukur performa sistem terdistribusi dengan cara yang tidak konsisten (layanan berdasarkan layanan) tidak mencerminkan pengalaman pelanggan secara akurat dan dapat menyebabkan interpretasi 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, setiap layanan dapat mengukur performa secara terpisah terhadap SLO terkait, dengan layanan yang ditampilkan kepada pengguna bertindak sebagai pelanggan mereka. Tangani SLO ini secara terpisah.

Anda dapat membuat layanan dengan ketersediaan tinggi (misalnya, 99,99%) di atas layanan yang kurang tersedia (misalnya, 99,9%) menggunakan faktor ketahanan seperti percobaan ulang cerdas, caching, dan antrean singkat ini. Siapa pun yang memiliki pengetahuan statistik yang memadai harus dapat membaca dan memahami SLO Anda tanpa memahami layanan atau tata letak organisasi yang mendasarinya seperti yang dijelaskan dalam hukum Conway.

Memilih SLO yang benar

Ada ketegangan alami antara kecepatan pengembangan produk dan stabilitas operasional. Semakin sering Anda mengubah sistem, semakin besar kemungkinan 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 berdasarkan data yang meningkatkan kecepatan pengembangan tanpa mengorbankan stabilitas. SLO juga dapat menyelaraskan tim pengembangan dan operasi berdasarkan satu tujuan yang disepakati. Membagikan satu tujuan akan mengurangi ketegangan alami yang disebutkan sebelumnya: sasaran tim pengembangan untuk membuat dan melakukan iterasi pada produk, dan sasaran tim operasi untuk menjaga 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 Buku SRE dan Workbook SRE.

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 menimbulkan dampak finansial.

Sebaiknya gunakan SLO internal yang lebih ketat ini dengan proses retrospective dan peninjauan insiden tanpa menyalahkan. Untuk mengetahui informasi selengkapnya, lihat Membangun proses manajemen insiden kolaboratif.

Tingkatkan SLO secara iteratif

SLO tidak boleh bersifat permanen. Tinjau kembali SLO secara berkala — setiap tiga bulan, atau setidaknya setiap tahun — dan pastikan SLO tersebut mencerminkan kepuasan pengguna secara akurat dan berkorelasi dengan pemadaman layanan. Pastikan keduanya mencakup kebutuhan bisnis saat ini dan perjalanan penting pengguna baru. 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 jangka waktu tertentu. Anggaran error dihitung sebagai 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.

Google Cloud Observability 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

  • Menentukan dan mengukur SLI yang berfokus pada pelanggan, seperti ketersediaan atau latensi layanan.
  • Tetapkan anggaran error yang berfokus pada pelanggan yang lebih ketat dibandingkan 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 pemadaman layanan.

Langkah selanjutnya