Sasaran tingkat layanan (SLO) adalah target kinerja yang disepakati untuk layanan tertentu selama periode waktu tertentu. SLO mendefinisikan status layanan yang diharapkan dan membantu para pemangku kepentingan mengelola kesehatan layanan tertentu, serta mengoptimalkan keputusan dengan menyeimbangkan inovasi dan keandalan.1
SLOs diukur menggunakan indikator tingkat layanan (SLI), metrik kuantitatif dari beberapa aspek layanan. SLO adalah bagian dari perjanjian yang lebih luas antara penyedia layanan dan pelanggan—perjanjian tingkat layanan (SLA)—yang menguraikan tingkat layanan yang dapat diharapkan pelanggan dari penyedia dan menetapkan penalti jika target tidak terpenuhi.
Untuk memastikan bahwa tingkat layanan konsisten dengan persyaratan bisnis serta keinginan pelanggan, tim rekayasa keandalan situs (SRE), DevOps, TI, dan tim terkait lainnya harus mengetahui perjalanan pengguna yang penting untuk setiap aplikasi: yaitu, interaksi yang memungkinkan pengguna akhir mencapai hasil yang diinginkan.
Dukungan internal sangat penting untuk keberhasilan SLO (dan oleh karena itu, SLA), dan beberapa pemangku kepentingan harus ikut serta dalam menentukan SLO, termasuk manajer produk, DevOps dan tim manajemen masalah, dan insinyur infrastruktur. Pelanggan eksternal diikutsertakan dalam diskusi melalui grup fokus, studi, keluhan pelanggan, dan media sosial.
Logika utama dari SLO adalah bahwa keandalan layanan mengarah pada kebahagiaan pengguna, yang memberikan peluang bisnis yang lebih besar. Menetapkan target keandalan yang terukur membantu organisasi menyeimbangkan pengalaman pengguna yang menyenangkan dan efisien dengan biaya yang masuk akal: tidak membebani anggaran TI dengan tingkat layanan di luar yang dibutuhkan atau diharapkan.
SLO diperlukan karena SLO mendefinisikan kualitas layanan (QoS) dan tujuan keandalan secara konkret, terukur, dan objektif. Standar ini tidak dimaksudkan untuk menentukan tingkat kinerja terbaik, tetapi merupakan kisaran standar kinerja terbaik yang mungkin dicapai dan yang paling tidak dapat diterima.1
Tujuan dari SLO dirangkum dengan baik dalam 97 Things Every Cloud Engineer Should Know (tautan berada di luar ibm.com), dari O`Reilly Media: "Bagaimana Anda bisa memberikan cara yang mudah bagi manajemen untuk langsung memahami timbal balik antara keandalan, kecepatan inovasi, dan biaya? SLO adalah jawabannya. SLO menciptakan pedoman keandalan yang jelas yang menyeimbangkan antara biaya cloud, kecepatan perubahan, dan risiko eksternal."
Buku elektronik ini bertujuan untuk menyanggah mitos seputar observabilitas dan menunjukkan perannya di dunia digital.
Daftar untuk panduan untuk mengoperasionalkan FinOps
SLO adalah salah satu dari beberapa istilah yang saling terkait yang terlibat dalam pelacakan dan evaluasi kinerja layanan:
SLI adalah ukuran kuantitatif dari beberapa aspek layanan. SLI memberikan angka nyata—tongkat pengukur untuk kinerja sistem—seperti tingkat kesalahan, throughput batch, atau latensi permintaan. Biasanya, pengukuran dikumpulkan dan disajikan sebagai tarif, rata-rata, atau persentil.
SLO adalah nilai target untuk pengukuran tersebut (seperti memastikan waktu respons tetap di bawah 200 milidetik, misalnya) yang harus dipenuhi untuk menegakkan perjanjian tingkat layanan (SLA). Nilai-nilai ini biasanya dinyatakan sebagai persentase selama periode waktu tertentu.
SLA adalah kontrak antara vendor dan pelanggan, yang terdiri dari SLO individual, yang menjamin tingkat tertentu untuk aktivitas, fungsi, atau proses layanan. SLA juga menetapkan penalti jika perjanjian tidak terpenuhi.
Anggaran kesalahan adalah aspek SLO yang mendefinisikan jumlah kegagalan yang dapat diterima sebelum kontrak dilanggar. Anggaran kesalahan memungkinkan penggabungan waktu henti layanan yang direncanakan atau tidak direncanakan yang tidak dapat dihindari dalam praktiknya. Membangun waktu henti memungkinkan tim pengembangan Anda untuk membuat keputusan yang matang terkait pengembangan baru, operasi, dan memperbarui atau memperbaiki perangkat lunak yang terinstal.
Keandalan dan daya tanggap sering diukur dalam “sembilan menuju ke 100%”: 90%, 99%, 99,9% dan seterusnya. Misalnya, sasaran untuk ketersediaan CPU dapat ditampilkan seperti ini:
Tingkat keandalan | Jendela ketidakandalan yang diizinkan | ||
|
|
| |
Per tahun | Per kuartal | Per 30 hari | |
90% | 36,5 hari | 9 hari | 3 hari |
95% | 18,25 hari | 4,5 hari | 1,5 hari |
99% | 3,65 hari | 21,6 jam | 7,2 jam |
99,5% | 1,83 hari | 10,8 jam | 3,6 jam |
99,9% | 8,76 jam | 2,16 jam | 43,2 menit |
99,95% | 4,38 jam | 1,08 jam | 21,6 menit |
99,99% | 52,6 menit | 12,96 menit | 4,32 menit |
99,999% | 5,26 menit | 1 menit 30 detik | 26,9 detik |
|
|
|
Setiap titik desimal yang mendekati 100 biasanya melibatkan biaya dan kompleksitas yang lebih besar untuk dicapai. Pelanggan—internal dan eksternal—mungkin memerlukan tingkat responsif tertentu, setelah itu mereka tidak dapat lagi mendeteksi perbedaannya. Menetapkan SLO adalah sebagian ilmu pengetahuan dan sebagian seni, yang menyeimbangkan antara kesempurnaan statistik dan tujuan yang realistis dan hemat biaya.
Tim pengembangan mungkin ingin menghadirkan fitur-fitur baru, sementara tim operasi ingin menghadirkan stabilitas dan kualitas, dengan memperkenalkan perubahan melalui cara yang terkendali. Karena bisnis menyediakan produk atau layanan kepada pelanggan internal dan eksternal, penting untuk mengukur tingkat layanan apa pun dari sudut pandang pelanggan.
SLO membantu menyatukan organisasi seputar keandalan. Pada akhirnya, para pemangku kepentingan harus menyepakati SLO yang terukur bagi pelanggan yang merupakan keseimbangan yang efektif antara kecepatan dan kualitas layanan.
Pada tingkat dasar, sasaran tingkat layanan penting karena memastikan keandalan layanan dan perjanjian tingkat layanan terpenuhi. Jika Anda memenuhi SLA, pelanggan Anda senang, dan itu bagus untuk bisnis.
SLO tidak hanya bermanfaat bagi klien eksternal tetapi juga menawarkan insight berharga bagi pelanggan internal. SLO membantu berbagai tim untuk mengukur kinerja layanan dan aplikasi serta menentukan cara-cara untuk meningkatkannya. Di antara manfaat lainnya, SLO membantu organisasi untuk:
Masalah keandalan dapat merugikan keuangan perusahaan Anda. Jika SLO disiapkan dengan benar, Anda dapat melihat dan mengungkap kesenjangan dalam observabilitas. Penyiapan SLO Anda mungkin satu-satunya tempat di mana Anda dapat memusatkan insight dari berbagai alat pemantauan yang digunakan di organisasi Anda. Observabilitas yang lebih baik membantu Anda menyediakan produk yang lebih baik, mengurangi pergantian pelanggan, dan beroperasi lebih efisien.
SLO dan SLI memberikan insight tentang kinerja layanan dan aplikasi serta memberikan tim ukuran yang akurat tentang waktu henti dan masalah potensial lainnya. Informasi ini berguna untuk DevOps, IT, dan tim lain yang ingin mencapai keseimbangan antara inovasi dan keandalan saat mereka memperbarui produk yang sudah ada dan merilis fitur baru.
SLO yang dipertimbangkan dengan baik yang mengukur kesehatan layanan mikro Anda, seperti yang dialami oleh pelanggan Anda, memberikan insight yang tak ternilai tentang kinerja produk dan pengalaman pengguna.
Baik penetapan maupun pelacakan SLO membantu menyatukan tim dari seluruh organisasi dalam memahami layanan dan ekspektasi terkait. SLO yang dipertimbangkan dengan matang membantu menumbuhkan budaya komunikasi, di mana semua pemangku kepentingan mempertimbangkan apa yang diharapkan oleh unit mereka dari suatu layanan, dan memahami peran mereka dalam memastikan bahwa SLA terpenuhi.
Selain itu, membuat laporan dan otomatisasi dengan SLO dapat membantu setiap anggota tim Anda menjawab pertanyaan tentang insiden dengan lebih cepat. SLO penting bagi tim DevOps, infrastruktur, dan SRE Anda, tetapi juga dapat membantu mengubah hampir setiap aspek perusahaan Anda. Data yang diperoleh melalui observabilitas dapat dikonversi menjadi informasi yang dapat diakses, kontekstual, dan dapat ditindaklanjuti. Insight ini memberikan visibilitas yang dibutuhkan tim Anda untuk membuat keputusan tepat waktu dan hemat biaya.
Dengan target yang diartikulasikan dengan jelas, organisasi dapat beralih ke otomatisasi untuk memantau dan mengukur SLI. Pendekatan ini dapat membantu memastikan bahwa target terpenuhi, dengan sasaran lebih dari sekadar pemantauan, tetapi juga mengotomatiskan proses end-to-end.
Sistem pemantauan otomatis dapat membantu mendeteksi potensi masalah saat masalah mulai berkembang, sebelum kinerja layanan benar-benar meleset dari target yang ditetapkan dalam SLO atau melanggar SLA. Setelah proses yang memenuhi SLO ditetapkan, otomatisasi dapat diimplementasikan untuk memastikan kinerja yang konsisten, misalnya, dengan menggunakan platform yang mengotomatiskan alokasi sumber daya berdasarkan permintaan beban kerja.
SLO memberi tim DevOps pandangan ke depan untuk mengidentifikasi potensi masalah sebelum terjadi. Pandangan ke depan ini mencegah waktu henti yang tidak dapat diterima atau peristiwa lain yang dapat berdampak negatif pada pengguna akhir atau merugikan perusahaan.
SLA sering menggunakan persentase waktu henti atau ketersediaan bulanan untuk menghitung penagihan. Durasi waktu henti adalah periode waktu ketika sistem gagal melakukan fungsi utamanya. Kegagalan komunikasi, misalnya, dapat menyebabkan waktu henti jaringan. Standar ketersediaan di industri tetap tinggi dan begitu pula biaya waktu henti, yang terus meningkat. Selain dampak finansial, SLO yang tidak terpenuhi juga dapat menyebabkan ketidakpuasan pelanggan.
Banyak organisasi beroperasi berdasarkan proses manajemen insiden reaktif. Namun, jika Anda menunggu insiden terjadi, dibutuhkan waktu lebih lama untuk memitigasi dan menyelesaikan masalah dalam sistem Anda, sehingga meningkatkan waktu rata-rata untuk memperbaiki (MTTR)1. SLO yang ditetapkan dengan benar membantu meningkatkan observabilitas dan memungkinkan organisasi untuk menjadi lebih proaktif tentang manajemen insiden.
Peringatan yang tidak relevan tidak hanya meningkatkan biaya operasional tetapi juga dapat menyebabkan tingkat kelelahan yang tinggi ketika insinyur membuang waktu dan kehilangan produktivitas akibat harus menanggapi peringatan yang tidak nyata. Salah satu tantangan terbesar dalam menyiapkan peringatan adalah menemukan keseimbangan yang tepat antara terlalu banyak dan terlalu sedikit.
Peringatan yang relevan adalah peringatan yang memberi tahu insinyur ketika degradasi kemungkinan besar akan menyebabkan sasaran keandalan tidak tercapai—peringatan yang berbasis gejala. Sebagai contoh, merupakan masalah yang nyata ketika latensi respons layanan dalam satu jam terakhir dapat menyebabkan SLO latensi menjadi tidak terpenuhi untuk minggu ini.
Jika Anda bertanya kepada orang-orang dalam bisnis, berapa target waktu aktif sistem mereka, banyak yang mungkin mengatakan bahwa mereka ingin mencoba 100%. Angka tersebut sangat aspiratif, tetapi juga sangat mahal dan bisa menghabiskan sebagian besar anggaran TI Anda sebelum yang lainnya. SLO dirancang bukan untuk menyombongkan diri, tetapi untuk menemukan dan memenuhi harapan pelanggan sehingga Anda dapat membuat pelanggan Anda senang dan kembali lagi. Keandalan adalah sarana, bukan tujuan.
Hanya karena sebuah metrik kinerja dapat diukur, bukan berarti itu penting bagi kebahagiaan pelanggan atau keuntungan Anda. Prioritaskan. Fokus pada metrik yang paling akurat mengindikasikan pengalaman pelanggan yang positif.
Dalam Foundations of Service Level Management (tautan berada di luar ibm.com), Rick Sturm dan Wayne Morris menyajikan daftar periksa ini untuk menetapkan SLO yang realistis:
SLO harus:
· Dapat dicapai
· Dapat diulang
· Dapat diukur
· Dapat dimengerti
· Dapat dimaknai
· Dapat dikendalikan
· Terjangkau
- Dapat diterima bersama
Perhatikan bahwa daftar mereka dimulai dengan "dapat dicapai." Membidik target yang terlalu tinggi bisa sangat mahal dan mungkin memberikan waktu aktif lebih dari yang diharapkan oleh pelanggan Anda. Berikut adalah beberapa praktik terbaik penting yang dapat membantu Anda mencapai tujuan SLO Anda:
Tentukan SLO yang mendukung SLA atau tujuan bisnis. Apakah 20 SLO benar-benar empat kali lebih baik dari lima SLO? Atau akankah ini hanya menciptakan lebih banyak pekerjaan untuk tim TI Anda dan membingungkan klien—tanpa manfaat yang berarti? Jangan merasa Anda harus menilai segala sesuatu yang dapat diukur.
Tetapkan target SLO yang realistis daripada memberikan janji yang berlebihan dan kemudian memberikan hasil yang kurang, yang dapat menyebabkan penalti yang mahal dan bahkan dapat menyebabkan bisnis kehilangan klien. Bersikap realistis dengan pemangku kepentingan internal serta klien memungkinkan setiap orang untuk membuat keputusan berdasarkan informasi. Target SLO tinggi yang tidak realistis hanya akan lebih mahal dalam jangka panjang.
Dengan menyetujui ekspektasi yang realistis di awal, Anda akan terhindar dari kebingungan dan konflik di kemudian hari antara tim internal dan klien.
Lembar pengumpulan metrik manual dapat memperlambat remediasi dan mungkin tidak mendukung analisis akar masalah. Kumpulkan SLI yang relevan untuk mengevaluasi SLO secara otomatis dan bangun peringatan otomatis sebelum SLO dilanggar. Sertakan konteks yang dibutuhkan staf Anda dan dependensi untuk mengatasi masalah sebelum menjadi masalah yang berdampak luas.
IBM Instana mendemokratisasikan observabilitas dengan memberikan solusi yang dapat digunakan siapa pun di DevOps, SRE, platform, ITOps, dan pengembangan untuk mendapatkan data yang diinginkan dengan konteks yang dibutuhkan. Dibangun khusus untuk cloud native namun tidak bergantung pada teknologi, platform ini secara otomatis dan terus menerus menyediakan data dengan ketelitian tinggi—granularitas 1 detik dan pelacakan menyeluruh—dengan konteks ketergantungan logis dan fisik di perangkat seluler, web, aplikasi, dan infrastruktur.
Platform pengoptimalan biaya hybrid cloud IBM Turbonomic memungkinkan Anda untuk terus mengotomatiskan tindakan penting secara real time yang secara proaktif memberikan penggunaan sumber daya komputasi, penyimpanan, dan jaringan yang paling efisien ke aplikasi Anda di setiap lapisan tumpukan.
Pelajari bagaimana dengan Instana, Anda dapat membuat dan mengelola sasaran tingkat layanan Anda untuk menganalisis kualitas layanan dan tujuan keandalan secara konkret, terukur, dan objektif.
Jelajahi bagaimana observabilitas perusahaan dapat membantu Anda mengetahui kinerja segala sesuatu, di mana saja, sekaligus.
Mengotomatiskan tugas-tugas operasi TI, mempercepat pengiriman perangkat lunak, dan meminimalkan risiko TI dengan rekayasa keandalan situs.
1“Service level objectives",IBM, 6 September 2023.