SLA, juga dikenal sebagai “perjanjian tingkat layanan”, adalah perjanjian jaminan antara pelanggan dan penyedia layanan tentang apa yang akan diterima pelanggan dalam hal layanan. Ditetapkan juga kompensasi jika terjadi downtime karena kesalahan pemasok, dan sebagainya. Intinya, SLA adalah kredensial yang digunakan oleh pusat data atau penyedia hosting untuk meyakinkan klien potensial bahwa dia akan diperlakukan dengan baik dengan segala cara yang memungkinkan. Pertanyaannya adalah Anda bisa menulis apapun yang Anda inginkan di SLA, dan kejadian yang tertulis di dokumen ini tidak terlalu sering terjadi. SLA jauh dari pedoman dalam memilih pusat data dan Anda tentu tidak boleh mengandalkannya.
Kita semua terbiasa menandatangani perjanjian tertentu yang membebankan kewajiban tertentu. Tidak terkecuali SLA - biasanya merupakan dokumen paling tidak realistis yang bisa dibayangkan. Satu-satunya hal yang mungkin lebih tidak berguna adalah NDA di yurisdiksi di mana konsep “rahasia dagang” tidak benar-benar ada. Namun masalahnya adalah SLA tidak membantu klien dalam memilih pemasok yang tepat, tetapi hanya membuang-buang waktu.
Apa yang paling sering ditulis oleh hoster dalam SLA versi publik yang mereka tunjukkan kepada publik? Nah, baris pertama adalah istilah "keandalan" dari hoster - biasanya angkanya antara 98 hingga 99,999%. Faktanya, angka-angka ini hanyalah penemuan indah para pemasar. Dahulu kala, ketika hosting masih muda dan mahal, dan cloud hanyalah impian bagi para spesialis (dan juga akses broadband untuk semua orang), indikator uptime hosting sangatlah penting. Sekarang, ketika semua pemasok menggunakan, plus atau minus, peralatan yang sama, berada di jaringan tulang punggung yang sama dan menawarkan paket layanan yang sama, indikator uptime benar-benar biasa-biasa saja.
Apakah ada SLA yang “benar”?
Tentu saja, ada versi SLA yang ideal, tetapi semuanya merupakan dokumen non-standar dan didaftarkan serta diselesaikan antara klien dan pemasok secara manual. Selain itu, jenis SLA ini paling sering menyangkut beberapa jenis pekerjaan kontrak daripada jasa.
Apa saja yang harus disertakan dalam SLA yang baik? Sederhananya TLDR, SLA yang baik adalah dokumen yang mengatur hubungan antara dua entitas, yang memberikan salah satu pihak (pelanggan) kendali maksimal atas proses tersebut. Artinya, cara kerjanya di dunia nyata: ada dokumen yang menggambarkan proses interaksi global dan mengatur hubungan antar pihak. Ini menetapkan batasan, aturan, dan dengan sendirinya menjadi pengungkit pengaruh yang dapat digunakan sepenuhnya oleh kedua belah pihak. Jadi, berkat SLA yang benar, pelanggan dapat dengan mudah memaksa kontraktor untuk bekerja sesuai kesepakatan, dan ini membantu kontraktor untuk melawan “keinginan” klien yang terlalu aktif yang tidak dibenarkan dalam kontrak. Tampilannya seperti ini: “SLA kami mengatakan ini dan itu, keluar dari sini, kami melakukan semuanya sesuai kesepakatan.”
Artinya, “SLA yang benar” = “kontrak yang memadai untuk penyediaan layanan” dan memberikan kendali atas situasi tersebut. Namun hal ini hanya mungkin terjadi ketika bekerja “sama setara”.
Apa yang tertulis di website dan apa yang menunggu di kenyataan adalah dua hal yang berbeda
Secara umum, semua yang akan kita bahas lebih lanjut adalah trik pemasaran yang khas dan ujian perhatian.
Jika kita mengambil hoster domestik yang populer, maka satu penawaran lebih baik dari yang lain: dukungan 25/8, waktu aktif server 99,9999999%, sekumpulan pusat data mereka sendiri setidaknya di Rusia. Harap ingat poin tentang pusat data, kita akan membahasnya lagi nanti. Sementara itu, mari kita bahas tentang statistik toleransi kesalahan yang ideal dan apa yang dihadapi seseorang ketika servernya masih berada dalam “0,0000001% kegagalan”.
Dengan indikator 98% ke atas, penurunan apa pun merupakan peristiwa yang berada di ambang kesalahan statistik. Peralatan kerja dan sambungannya ada atau tidak. Anda dapat menggunakan penghosting dengan peringkat “keandalan” 50% (menurut SLA-nya sendiri) selama bertahun-tahun tanpa satu masalah pun, atau Anda dapat “gagal” sebulan sekali selama beberapa hari dengan penghosting yang mengklaim 99,99%.
Ketika momen kejatuhan tiba (dan, kami ingatkan Anda, semua orang suatu hari nanti akan jatuh), maka klien dihadapkan pada mesin internal perusahaan yang disebut "dukungan", dan perjanjian layanan serta SLA terungkap. Apa artinya:
- Kemungkinan besar, selama empat jam pertama waktu henti Anda tidak akan dapat menyajikan apa pun sama sekali, meskipun beberapa hoster mulai menghitung ulang tarif (pembayaran kompensasi) sejak terjadinya kerusakan.
- Jika server tidak tersedia untuk jangka waktu yang lebih lama, Anda mungkin dapat mengajukan permintaan penghitungan ulang tarif.
- Dan ini dengan syarat masalah tersebut muncul karena kesalahan pemasok.
- Jika masalah Anda muncul karena pihak ketiga (di jalan raya), maka seolah-olah “tidak ada yang bisa disalahkan” dan kapan masalah tersebut teratasi adalah masalah keberuntungan Anda.
Namun, penting untuk dipahami bahwa Anda tidak pernah mendapatkan akses ke tim teknik, paling sering Anda dihentikan oleh lini dukungan pertama, yang berkorespondensi dengan Anda sementara teknisi sebenarnya mencoba memperbaiki situasi. Kedengarannya familier?
Di sini, banyak orang mengandalkan SLA, yang tampaknya akan melindungi Anda dari situasi seperti itu. Namun pada kenyataannya, perusahaan jarang melampaui batas-batas dokumen mereka atau mampu membalikkan keadaan sedemikian rupa untuk meminimalkan biaya mereka sendiri. Tugas utama SLA adalah untuk menidurkan kewaspadaan dan meyakinkan bahwa bahkan jika terjadi situasi yang tidak terduga, “semuanya akan baik-baik saja.” Tujuan kedua dari SLA adalah untuk mengomunikasikan poin-poin penting utama dan memberikan ruang bagi penyedia layanan untuk bermanuver, yaitu kemampuan untuk menghubungkan kegagalan dengan sesuatu yang “tidak menjadi tanggung jawab” pemasok.
Pada saat yang sama, klien besar sebenarnya tidak peduli sama sekali tentang kompensasi dalam SLA. “Kompensasi SLA” adalah pengembalian uang sesuai tarif sebanding dengan waktu henti peralatan, yang tidak akan pernah mencakup bahkan 1% dari potensi kerugian moneter dan reputasi. Dalam hal ini, jauh lebih penting bagi klien untuk menyelesaikan masalah sesegera mungkin daripada semacam “penghitungan ulang tarif”.
“Banyak pusat data di seluruh dunia” menimbulkan kekhawatiran
Kami telah menempatkan situasi dengan sejumlah besar pusat data di penyedia layanan dalam kategori terpisah, karena selain masalah komunikasi yang dijelaskan di atas, masalah yang tidak jelas juga muncul. Misalnya, penyedia layanan Anda tidak memiliki akses ke pusat data “mereka”.
Di artikel terakhir kami , yang hakikatnya adalah penjualan kembali kapasitas orang lain dengan kedoknya sendiri. Sebagian besar hoster modern yang mengklaim memiliki “pusat data sendiri” di banyak wilayah adalah pengecer yang menggunakan model White Label. Artinya, secara fisik mereka tidak ada hubungannya dengan pusat data bersyarat di Swiss, Jerman atau Belanda.
Tabrakan yang sangat menarik muncul di sini. SLA Anda dengan penyedia layanan masih berfungsi dan valid, namun pemasok tidak dapat mempengaruhi situasi secara radikal jika terjadi kecelakaan. Dia sendiri berada dalam posisi bergantung pada pemasoknya sendiri - pusat data tempat rak listrik dibeli untuk dijual kembali.
Oleh karena itu, jika Anda tidak hanya menghargai kata-kata indah dalam kontrak dan SLA tentang keandalan dan layanan, namun juga kemampuan penyedia layanan untuk menyelesaikan masalah dengan cepat, Anda harus bekerja sama langsung dengan pemilik fasilitas. Faktanya, ini melibatkan interaksi langsung dengan pusat data.
Mengapa kita tidak mempertimbangkan opsi ketika banyak DC sebenarnya bisa dimiliki oleh satu perusahaan? Ya, hanya sedikit sekali perusahaan seperti itu. Satu, dua, tiga pusat data kecil atau satu pusat data besar dimungkinkan. Tapi selusin DC, setengahnya berada di Federasi Rusia, dan yang kedua di Eropa, hampir mustahil. Artinya, terdapat lebih banyak perusahaan reseller daripada yang Anda bayangkan. Berikut ini contoh sederhananya:
Perkirakan jumlah pusat data layanan Google Cloud. Hanya ada enam di antaranya di Eropa. Di London, Amsterdam, Brussels, Helsinki, Frankfurt dan Zurich. Artinya, di semua titik jalan raya utama. Karena pusat data adalah proyek yang mahal, kompleks, dan sangat besar. Sekarang ingatlah perusahaan hosting dari suatu tempat di Moskow yang memiliki “selusin pusat data di seluruh Rusia dan Eropa.”
Tentu saja, tidak ada pemasok bagus yang memiliki mitra dalam program White Label, jumlahnya cukup banyak, dan mereka memberikan layanan pada tingkat tertinggi. Mereka memungkinkan untuk menyewa kapasitas di UE dan Federasi Rusia secara bersamaan melalui jendela browser yang sama, menerima pembayaran dalam rubel, bukan dalam mata uang asing, dan sebagainya. Namun ketika kasus yang dijelaskan dalam SLA terjadi, mereka menjadi sandera situasi yang sama seperti Anda.
Hal ini mengingatkan kita sekali lagi bahwa SLA tidak ada gunanya jika Anda tidak memiliki pemahaman tentang struktur organisasi dan kemampuan pemasok.
Dengan hasil yang
Server crash selalu menjadi kejadian yang tidak menyenangkan dan bisa menimpa siapa saja, dimana saja. Pertanyaannya adalah seberapa besar kendali atas situasi yang Anda inginkan. Sekarang tidak terlalu banyak pemasok kapasitas langsung di pasar, dan jika kita berbicara tentang pemain besar, maka mereka, secara relatif, hanya memiliki satu DC di suatu tempat di Moskow dari selusin DC di seluruh Eropa yang dapat Anda akses.
Di sini, setiap klien harus memutuskan sendiri: apakah saya memilih kenyamanan saat ini atau menghabiskan waktu dan tenaga mencari pusat data di lokasi yang dapat diterima di Rusia atau Eropa, tempat saya dapat menempatkan peralatan atau membeli kapasitas. Dalam kasus pertama, solusi standar yang ada di pasaran saat ini cocok. Yang kedua, Anda harus berkeringat.
Pertama-tama, perlu ditentukan apakah penjual jasa adalah pemilik langsung fasilitas/pusat data tersebut. Banyak reseller yang menggunakan model White Label berusaha semaksimal mungkin untuk menyamarkan statusnya, dan dalam hal ini Anda perlu mencari beberapa tanda tidak langsung. Misalnya, jika “DC Eropa mereka” memiliki beberapa nama dan logo tertentu yang berbeda dari nama perusahaan pemasok. Atau jika kata “mitra” muncul di suatu tempat. Mitra = Label Putih dalam 95% kasus.
Selanjutnya, Anda perlu membiasakan diri dengan struktur perusahaan itu sendiri, atau lebih baik lagi, melihat peralatannya secara langsung. Di antara pusat data, praktik tamasya atau setidaknya artikel tamasya di situs web atau blog mereka sendiri bukanlah hal baru (kami menulisnya и ), di mana mereka berbicara tentang pusat data mereka dengan foto dan deskripsi rinci.
Dengan banyaknya pusat data, Anda dapat mengatur kunjungan pribadi ke kantor dan tamasya mini ke DC itu sendiri. Di sana Anda dapat menilai tingkat pesanan, mungkin Anda dapat berkomunikasi dengan salah satu insinyur. Jelas bahwa tidak ada yang akan memberi Anda tur produksi jika Anda memerlukan satu server seharga 300 RUB/bulan, tetapi jika Anda memerlukan kapasitas yang serius, maka departemen penjualan mungkin akan menemui Anda. Misalnya, kami melakukan tamasya semacam itu.
Bagaimanapun, akal sehat dan kebutuhan bisnis harus digunakan. Misalnya, jika Anda memerlukan infrastruktur terdistribusi (beberapa server berada di Federasi Rusia, yang lain di UE), akan lebih mudah dan menguntungkan menggunakan layanan hoster yang bermitra dengan DC Eropa menggunakan Label Putih model. Jika seluruh infrastruktur Anda akan terkonsentrasi pada satu titik, yaitu di satu pusat data, maka ada baiknya meluangkan waktu untuk mencari pemasok.
Karena SLA biasa kemungkinan besar tidak akan membantu Anda. Namun bekerja sama dengan pemilik fasilitas, dan bukan dengan reseller, akan mempercepat penyelesaian masalah yang mungkin terjadi secara signifikan.
Sumber: www.habr.com