Bagaimana menghitung Service Level Agreement (SLA)?

Bro-sis sekalian.. Melihat kejadian beberapa aplikasi google yang sempat down kemarin, tribd penasaran sebenarnya berapa Service Level Agreement (SLA) yang google janjikan kepada para penggunanya. Sampai saat ini tribd belum mendapatkan data tersebut, dan nampaknya, untuk layanan gratis, tidak ada SLA yang dipublikasikan kepada para penggunanya. Mungkin ada pembaca yang tahu dan ingin sharing? Masih sedikit berhubungan dengan hal tersebut, sebenarnya jika kita ada di posisi google (atau sebagai penyedia suatu layanan TI), bagaimana sih cara menghitung SLA?

Sebelum melangkah lebih jauh, ada baiknya kita menyamakan persepsi mengenai SLA terlebih dahulu. Dalam ITIL, Service Level Agreement atau SLA didefinisikan sebagai: 

An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple Customers.

Dari definisi diatas, secara simpel kita bisa bilang bahwa SLA adalah perjanjian antara penyedia layanan dengan konsumen terkait layanan yang diberikan. Biasanya, ketika kita berbicara mengenai SLA, yang sudah terbayang adalah tingkat avaliability dari layanan tersebut. Metrik yang digunakan biasa berbentuk persentase. Misalkan, layanan email memiliki SLA 98%. Nah, metrik inilah yang mau kita bahas selanjutnya. Availability akan menjadi fokus pembahasan meskipun ada hal-hal lain yang biasanya termasuk dalam SLA, seperti reliability, dan security.

Penghitungan tingkat availability untuk suatu layanan sebenarnya cukup mudah. Kita ambil satu contoh adalah layanan email. Jika kita merupakan penyedia layanan email, berapakah SLA yang sebaiknya diberikan kepada konsumen agar didapat layanan yang optimal secara keseluruhan? Kebanyakan konsumen akan bilang 100% adalah angka yang harus dicapai. Well, tribd bisa bilang bahwa angka tersebut mustahil untuk tercapai. Jadi, berapa? Untuk menghitung SLA suatu layanan, kita harus sepakat terlebih dahulu dengan layanan lain yang mendukung layanan tersebut. Untuk kasus email, kita bisa bilang bahwa email sangat tergantung dengan server, jaringan, dan database. Tiga komponen tersebut adalah komponen yang paling sering dijadikan dasar perhitungan SLA. Setiap penyedia layanan dapat menambahkan komponen lain yang dianggap penting, misalkan ketersediaan SDM operator, ketersediaan service desk, dan lain sebagainya.

Nah, kita lanjutkan perhitungannya. Dari performa masa lalu didapat bahwa availability server mencapai 95%, ketersediaan jaringan yang dijanjikan oleh pihak ketiga adalah 99%, dan ketersediaan database mencapai 99%. Dari ketiga angka ini, selanjutnya kita bisa dapatkan angka SLA untuk layanan email dengan cara mengalikan setiap angka tersebut :

SLA Email = Availability Server x Availability Jaringan x Availability Database

SLA Email = 0.95 x 0.99 x 0.99 = 0.9311 = 93%

Wow, ternyata dari ketiga komponen tersebut, SLA email yang dihasilkan hanya sebesar 93%. Apa artinya? Dalam setahun, layanan email boleh mengalami down selama 7%. Jika setahun adalah 365 hari, maka layanan email boleh down selama 25.55 hari, atau 613.2 jam. Jadi, konsumen harus siap mengalami layanan email yang down selama total 613.2 jam dalam setahun tanpa bisa berbuat apa-apa. Waktu yang sangat lama.

Nah bagaimana jika penyedia layanan memutuskan untuk menaikkan availability layanan email menjadi 99%? Cara yang umum digunakan adalah dengan redundansi. Redundansi artinya melebihkan, jadi komponen pendukung dari layanan email dilebihkan untuk dijadikan cadangan ketika komponen tersebut down. Dalam hal contoh email diatas, komponen server merupakan komponen yang memiliki tingkat availability terendah. Jadi, kita bisa coba melakukan redundansi pada komponen ini. Pertanyaannya, seberapa banyak komponen redundansi yang dibutuhkan agar server dapat mencapai availability 99%? yuk kita coba hitung.

Contoh pertama, jika kita melakukan redundansi server sebanyak 1 buah (total menjadi 2 server), maka untuk mendapatkan availability komponen tersebut, harus dihitung probability of failure -nya terlebih dahulu. Perhatikan hitungan dibawah ini:

Probability of failure (2 server) = Prob of failure server 1 x Prob of failure server 2

Probability of failure (2 server) = 0.05 x 0.05 = 0.0025 = 0.25%

Availability (2 server) = 100% - 0.25% = 99.75%

Ternyata, dengan melakukan redundansi satu buah server saja, sudah didapatkan availability sebesar 99.75%. Tapi, apakah hal ini cukup? Dengan menggunakan rumus yang sama sebelumnya, ternyata SLA layanan email setelah dilakukan redundansi server hanya mencapai 97.76%. Masih kurang 1.24% untuk mencapai SLA 99%. Lalu apa yang harus dilakukan? Kita coba untuk melakukan redundansi jaringan. Dengan menambahkan satu jalur cadangan jaringan maka tingkat availability jaringan mencapai 99.99%. SLA layanan email setelah dilakukan redundansi server dan jaringan mencapai 99.87%. Ternyata masih belum cukup juga mz bro. Terakhir, kita coba melakukan redundansi database, dan akhirnya didapatkan SLA email sebesar 99.74%. Pfiuuh... 

Dari perhitungan sederhana diatas, dapat terbayang untuk mencapai target SLA yang tinggi, dibutuhkan biaya dan usaha yang sangat besar. Menggunakan contoh email diatas, jika kita ingin menaikkan SLA dari 93% ke 97%, maka penambahan satu server redundansi sudahlah cukup. Namun, jika ingin mencapai 99% lebih, ternyata semua komponen harus dilakukan redundansi minimal satu buah. Sungguh biaya yang sangat besar. Mudah-mudahan dari tulisan ini sudah bro-sis dapat terbayang bagaimana cara kerja SLA dan bagaiman carai menghitung SLA tersebut. Monggo jika ada komen, kritik atau pertanyaan.

~ tribd ~