Beranda Topics Sasaran Tingkat Layanan Apa yang dimaksud dengan sasaran tingkat layanan (SLO)?
Jelajahi sasaran SLO IBM Daftar untuk mendapatkan pembaruan AI
Ilustrasi dengan kolase piktogram roda gigi, lengan robotik, telepon seluler
Apa itu SLO?

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."

Membongkar mitos observabilitas

Buku elektronik ini bertujuan untuk menyanggah mitos seputar observabilitas dan menunjukkan perannya di dunia digital.

Konten terkait

Daftar untuk panduan untuk mengoperasionalkan FinOps

SLO versus SLI versus SLA

SLO adalah salah satu dari beberapa istilah yang saling terkait yang terlibat dalam pelacakan dan evaluasi kinerja layanan:

Indikator tingkat layanan (SLI)

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.

Sasaran tingkat layanan (SLO)

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.

Perjanjian tingkat layanan (SLA)

 

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

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.

Bagaimana SLO diukur

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.

Mengapa SLO penting?

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:

Menetapkan keandalan dan efisiensi sistem

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.

Meningkatkan produk dan pengalaman pengguna

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.

Menyelaraskan tim internal dengan lebih baik dan meningkatkan pengambilan keputusan

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.

Memanfaatkan otomatisasi

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.

Mengurangi waktu henti

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.

Beralih ke manajemen insiden prediktif

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.

Minimalkan kelelahan karyawan

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.

Praktik terbaik SLO

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:

Jangan terbawa suasana

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.

Jangan coba menjadi pahlawan

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.

Gunakan SLO untuk mempromosikan penyelarasan bisnis

Dengan menyetujui ekspektasi yang realistis di awal, Anda akan terhindar dari kebingungan dan konflik di kemudian hari antara tim internal dan klien.

Mengotomatiskan evaluasi

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.

Solusi terkait
Observabilitas IBM Instana Observability

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.

Jelajahi Instana Minta demo Instana Observabilitas

Optimalisasi biaya hybrid cloud IBM Turbonomic

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. 

Jelajahi Turbonomic Coba Turbonomic secara gratis
Sumber daya Dokumentasi IBM: SLO

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.

Panduan Perusahaan untuk Observabilitas

Jelajahi bagaimana observabilitas perusahaan dapat membantu Anda mengetahui kinerja segala sesuatu, di mana saja, sekaligus.

Apa yang dimaksud dengan rekayasa keandalan situs?

Mengotomatiskan tugas-tugas operasi TI, mempercepat pengiriman perangkat lunak, dan meminimalkan risiko TI dengan rekayasa keandalan situs.

Ambil langkah selanjutnya

IBM Instana menyediakan observabilitas real-time yang dapat digunakan oleh semua orang dan siapa saja. Ini memberikan time to value yang cepat sambil memverifikasi bahwa strategi observabilitas Anda dapat mengikuti kompleksitas dinamis lingkungan saat ini dan masa depan. Dari seluler hingga mainframe, Instana mendukung lebih dari 250 teknologi dan terus berkembang. 

Jelajahi IBM Instana Pesan demo langsung
Catatan kaki

1Service level objectives",IBM, 6 September 2023.