SLA, ini juga merupakan "perjanjian tingkat layanan" - perjanjian jaminan antara pelanggan dan penyedia layanan tentang apa yang akan diterima pelanggan dalam hal layanan. Ini juga menetapkan kompensasi jika terjadi downtime karena kesalahan pemasok dan sebagainya. Intinya, SLA adalah kredensial yang digunakan oleh pusat data atau penyedia hosting meyakinkan klien potensial bahwa ia akan diperlakukan dengan baik dengan segala cara dan secara umum. Pertanyaannya adalah Anda dapat menulis apa pun dalam SLA, dan peristiwa yang dijelaskan dalam dokumen ini tidak terlalu sering terjadi. SLA jauh dari pedoman dalam memilih pusat data dan Anda tentu tidak harus bergantung padanya.
Kita semua terbiasa menandatangani semacam perjanjian yang membebankan kewajiban tertentu. SLA juga tidak terkecuali - biasanya dokumen yang paling bercerai dari kenyataan. Mungkin lebih tidak berguna mungkin hanya NDA di yurisdiksi di mana konsep "rahasia dagang" tidak benar-benar ada. Dan seluruh masalahnya adalah bahwa SLA tidak membantu klien dalam pilihan yang tepat dari pemasok, tetapi hanya pembelanjaan.
Apa yang paling sering ditulis oleh hosters dalam versi publik SLA yang mereka perlihatkan kepada publik? Nah, baris pertama adalah istilah "keandalan" host - ini biasanya angka dari 98 hingga 99,999%. Bahkan, angka-angka ini hanyalah penemuan indah pemasar. Sekali waktu, ketika hosting masih muda dan mahal, dan hanya spesialis yang memimpikan cloud (dan juga akses broadband untuk semua orang), indikator waktu hosting menjadi sangat dan sangat penting. Sekarang, ketika semua pemasok menggunakan plus atau minus satu dan peralatan yang sama, duduk di jaringan backbone yang sama dan menawarkan paket layanan yang sama, indikator uptime sama sekali tidak indikatif.
Apakah ada "benar" SLA sama sekali
Tentu saja, ada versi ideal SLA, tetapi semuanya adalah dokumen atipikal yang ditulis dan disimpulkan antara klien dan penyedia dalam mode manual. Selain itu, jenis SLA inilah yang paling sering berhubungan dengan beberapa jenis pekerjaan kontrak daripada layanan.
Apa yang harus dalam SLA yang baik? Jika Anda memberikan TLDR, maka SLA yang baik adalah dokumen yang mengatur hubungan antara dua entitas, yang memberikan salah satu pihak (pelanggan) kontrol maksimum atas proses. Yaitu, cara kerjanya di dunia nyata: ada dokumen yang menggambarkan proses interaksi global dan mengatur hubungan antara para pihak. Ini menetapkan batas-batas, aturan, dan dengan sendirinya menjadi tuas pengaruh yang dapat dimanfaatkan sepenuhnya oleh kedua belah pihak. Jadi, berkat SLA yang benar, pelanggan dapat dengan mudah membuat kontraktor bekerja sesuai kesepakatan, dan kontraktor dapat membantu melawan klien yang terlalu aktif yang tidak dibenarkan oleh kontrak. Kelihatannya seperti ini: "Dalam SLA kami ditulis dengan cara ini dan itu, pergi dari sini, kami melakukan semua yang disepakati."
Yaitu, “SLA yang benar” = “kontrak yang memadai untuk penyediaan layanan” dan memberikan kontrol atas situasi tersebut. Dan mungkin ini hanya ketika bekerja dengan pijakan yang sama.
Apa yang mereka tulis di situs dan apa yang menunggu dalam kenyataan adalah dua hal yang berbeda.
Secara umum, semua yang akan kita bahas lebih lanjut adalah tipuan pemasaran tipikal dan pemeriksaan untuk perhatian.
Jika kita mengambil host domestik populer, maka satu saran lebih indah daripada yang lain: dukungan 25/8, server uptime 99,9999999% dari waktu, sekelompok pusat datanya setidaknya di Rusia. Harap ingat momen tentang pusat data,
kami akan kembali lagi nanti . Sementara itu, mari kita bicara tentang statistik toleransi kesalahan ideal dan apa yang ditemui seseorang ketika servernya jatuh ke "0,0000001% macet".
Dengan indikator dari 98% ke atas, setiap penurunan adalah peristiwa di ambang kesalahan statistik. Peralatan kerja dan koneksi ada di sana atau tidak. Selama bertahun-tahun Anda dapat menggunakan hoster dengan tingkat “keandalan” 50% (sesuai dengan SLA-nya) tanpa satu masalah atau “jatuhkan” sebulan sekali selama beberapa hari di orang-orang di mana 99,99% dinyatakan.
Ketika saat musim gugur tiba (dan semuanya jatuh, kita ingat, suatu hari nanti), maka klien bertemu dengan mesin perusahaan internal yang disebut "dukungan", dan kontrak untuk penyediaan layanan dan SLA terungkap. Apa artinya ini:
- kemungkinan besar, untuk empat jam pertama downtime, Anda tidak akan dapat menyajikan apa pun, meskipun beberapa hosters mulai menghitung ulang tarif (membayar kompensasi) dari saat mereka jatuh.
- Jika server tidak tersedia untuk waktu yang lebih lama, Anda mungkin dapat mengajukan permintaan penghitungan ulang tarif.
- Dan ini asalkan masalah muncul melalui kesalahan pemasok.
- Jika masalah Anda muncul karena pihak ketiga (di jalan raya), sepertinya "tidak ada yang harus disalahkan" dan ketika masalah diselesaikan - pertanyaan tentang keberuntungan Anda.
Penting untuk dipahami bahwa Anda tidak pernah mendapatkan akses ke tim teknik, paling sering Anda dihentikan oleh dukungan lini pertama, yang sesuai dengan Anda, sementara insinyur nyata berusaha memperbaiki situasi. Skenario yang sudah biasa?
Di sini, banyak yang mengandalkan SLA, yang, tampaknya, harus melindungi Anda dari situasi seperti itu. Tetapi, pada kenyataannya, perusahaan jarang melampaui batas-batas dokumen mereka sendiri atau mampu mengubah situasi untuk meminimalkan biaya mereka sendiri. Tujuan utama dari SLA adalah untuk menidurkan kewaspadaan dan meyakinkan bahwa bahkan jika terjadi situasi yang tidak terduga, "semuanya akan baik-baik saja." Tugas kedua dari SLA adalah untuk membahas poin-poin penting utama dan memberikan ruang bagi penyedia layanan untuk bermanuver, yaitu, kemampuan untuk mengaitkan kegagalan dengan sesuatu yang penyedianya “tidak bertanggung jawab”.
Pada saat yang sama, pelanggan besar, pada kenyataannya, tidak peduli dengan kompensasi berdasarkan SLA. “Kompensasi oleh SLA” adalah pengembalian uang sesuai dengan tarif sesuai dengan waktu henti peralatan, yang tidak akan pernah mencakup bahkan 1% dari potensi kerugian uang tunai dan reputasi. Dalam hal ini, jauh lebih penting bagi klien bahwa masalahnya harus diperbaiki sesegera mungkin, daripada semacam “penghitungan tarif”.
"Banyak pusat data di seluruh dunia" - memprihatinkan
Kami telah menempatkan situasi dengan sejumlah besar pusat data di penyedia layanan dalam kategori terpisah, karena selain masalah komunikasi jelas yang dijelaskan di atas, masalah yang tidak jelas juga muncul. Misalnya, penyedia layanan Anda tidak memiliki akses ke pusat data "mereka".
Dalam artikel terakhir kami,
kami menulis tentang jenis program afiliasi dan menyebutkan model White Label , yang intinya adalah penjualan kembali kapasitas orang lain dengan kedoknya sendiri. Sebagian besar hoster modern yang mengklaim memiliki "pusat data mereka" di banyak daerah adalah reseller yang menggunakan model White Label. Artinya, secara fisik mereka tidak ada hubungannya dengan pusat data bersyarat di Swiss, Jerman atau Belanda.
Di sini tabrakan yang sangat menarik muncul. SLA Anda dengan penyedia layanan masih berfungsi dan operasional, tetapi penyedia tersebut tidak dapat secara radikal mempengaruhi situasi jika terjadi kecelakaan. Dia sendiri berada dalam posisi tergantung pada pemasoknya sendiri - pusat data, dari mana kapasitas rak untuk dijual kembali dibeli.
Jadi, jika tidak hanya kata-kata yang indah dalam perjanjian dan SLA tentang keandalan dan layanan penting bagi Anda, tetapi juga kemampuan penyedia layanan untuk dengan cepat menyelesaikan masalah, ada baiknya bekerja langsung dengan pemilik fasilitas. Bahkan, ini menyiratkan interaksi langsung secara langsung dengan pusat data.
Mengapa kita tidak mempertimbangkan opsi ketika banyak DC sebenarnya bisa menjadi milik satu perusahaan? Yah, ada sangat sedikit perusahaan semacam itu. Satu, dua, tiga pusat data kecil atau satu besar - ini nyata. Tetapi selusin DC, setengahnya berada di Federasi Rusia, dan yang kedua di Eropa hampir mustahil. Dan ini berarti ada lebih banyak perusahaan reseller daripada yang dapat Anda bayangkan. Ini adalah contoh sederhana:
Perkirakan jumlah pusat data layanan Google Cloud. Di Eropa hanya ada enam. Di London, Amsterdam, Brussels, Helsinki, Frankfurt dan Zurich. Yaitu, pada semua poin trunk utama. Karena pusat data adalah proyek yang mahal, rumit dan sangat besar. Sekarang ingat perusahaan hosting dari suatu tempat di Moskow dengan "selusin pusat data di seluruh Rusia dan Eropa."Tentu saja, tidak ada pemasok yang cukup baik yang memiliki mitra dalam program White Label, dan mereka menyediakan layanan terbaik. 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, dan sebagainya. Tetapi setelah terjadinya kasus-kasus yang dijelaskan dalam SLA, mereka menjadi sandera yang persis sama dengan Anda.
Ini sekali lagi mengingatkan kita bahwa SLA tidak berguna kecuali Anda memiliki petunjuk tentang struktur organisasi dan kemampuan vendor.
Apa hasilnya
Server crash selalu merupakan peristiwa yang tidak menyenangkan dan dapat terjadi pada siapa saja, di mana saja. Pertanyaannya adalah seberapa besar kendali atas situasi yang Anda inginkan. Sekarang pasar tidak memiliki terlalu banyak pemasok kapasitas secara langsung, dan jika kita berbicara tentang pemain besar, maka mereka memiliki, berdasarkan konvensi, hanya satu DC di suatu tempat di Moskow dari selusin di seluruh Eropa, yang dapat Anda akses.
Di sini, setiap klien harus memutuskan sendiri: Saya memilih kenyamanan sekarang atau menghabiskan waktu dan energi mencari pusat data di titik yang dapat diterima di Rusia atau Eropa, di mana saya dapat menempatkan peralatan saya atau membeli kapasitas. Dalam kasus pertama, solusi standar yang saat ini ada di pasaran akan dilakukan. Yang kedua - Anda harus berkeringat.
Pertama-tama, perlu untuk mengidentifikasi apakah penjual layanan adalah pemilik langsung dari fasilitas / pusat data. Banyak pengecer White Label menutupi status mereka dengan sekuat tenaga, dan dalam hal ini kita perlu melihat beberapa tanda tidak langsung. Misalnya, jika "DC Eropa mereka" memiliki beberapa nama dan logo tertentu yang berbeda dari nama perusahaan pemasok. Atau jika suatu tempat kata "mitra" berkedip. Mitra = Label Putih dalam 95% kasus.
Selanjutnya, Anda perlu membiasakan diri dengan struktur perusahaan, tetapi lebih baik untuk melihat peralatan secara langsung. Di antara pusat data, praktik kunjungan atau setidaknya artikel perjalanan di situs web atau blog mereka sendiri (kami menulis satu,
dua ) bukanlah hal baru, di mana mereka berbicara tentang pusat data mereka dengan foto dan deskripsi terperinci.
Dengan banyak pusat data, Anda dapat mengatur kunjungan pribadi ke kantor dan kunjungan singkat 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 mengatur kunjungan ke produksi jika Anda memerlukan satu server untuk 300 RUB / bulan, tetapi jika Anda membutuhkan kapasitas yang serius, departemen penjualan mungkin akan menemui Anda. Misalnya, kami melakukan kunjungan seperti itu.
Bagaimanapun, Anda harus dibimbing oleh akal sehat dan kebutuhan bisnis. Misalnya, jika Anda memerlukan infrastruktur terdistribusi (beberapa server di Federasi Rusia, yang kedua di UE), akan lebih mudah dan lebih menguntungkan untuk menggunakan layanan hoster yang memiliki kemitraan dengan DC Eropa sesuai dengan model White Label. Jika seluruh infrastruktur Anda terkonsentrasi di satu titik, yaitu di satu pusat data, maka Anda harus membayar waktu untuk masalah menemukan pemasok.
Karena SLA yang khas mungkin tidak akan membantu Anda. Tetapi bekerja dengan pemilik fasilitas, dan bukan pengecer, akan secara signifikan mempercepat solusi dari masalah yang mungkin terjadi.