SLA, uga dikenal minangka "perjanjian tingkat layanan", minangka perjanjian jaminan antarane pelanggan lan panyedhiya layanan babagan apa sing bakal ditampa pelanggan babagan layanan. Iku uga stipulates ganti rugi ing cilik saka downtime amarga fault saka supplier, lan ing. Intine, SLA minangka kredensial kanthi bantuan pusat data utawa panyedhiya hosting ngyakinake klien potensial yen dheweke bakal dianggep apik ing kabeh cara. Pitakonan iku sampeyan bisa nulis apa wae sing dikarepake ing SLA, lan acara sing ditulis ing dokumen iki ora kerep banget. SLA adoh saka pedoman kanggo milih pusat data lan sampeyan mesthi ora ngandelake.
Kita kabeh wis biasa nandhatangani sawetara perjanjian sing ngetrapake kewajiban tartamtu. SLA ora ana sing istiméwa - biasane dokumen sing paling ora nyata sing bisa dibayangake. Siji-sijine perkara sing mbokmenawa luwih ora ana gunane yaiku NDA ing yurisdiksi ing ngendi konsep "rahasia dagang" ora ana. Nanging kabeh masalah iku SLA ora bantuan klien ing milih supplier tengen, nanging mung mbuwang bledug ing mripat.
Apa hoster paling kerep nulis ing versi umum saka SLA sing padha nuduhake kanggo umum? Inggih, baris pisanan istilah "reliabilitas" saka hoster - iki biasane nomer saka 98 kanggo 99,999%. Nyatane, angka kasebut mung minangka penemuan para pemasar sing apik. Biyen, nalika hosting isih enom lan larang, lan awan mung dadi impen kanggo spesialis (uga akses broadband kanggo kabeh wong), indikator uptime hosting pancen penting banget. Saiki, nalika kabeh supplier nggunakake, plus utawa minus, peralatan sing padha, njagong ing jaringan backbone sing padha lan nawakake paket layanan sing padha, indikator uptime pancen ora biasa.
Apa ana SLA sing "bener"?
Mesthi, ana versi becik SLA, nanging kabeh iku dokumen non-standar lan kadhaftar lan rampung antarane klien lan supplier kanthi manual. Kajaba iku, jinis SLA iki paling asring gegayutan karo sawetara jinis kerja kontrak tinimbang layanan.
Apa sing kudu kalebu SLA sing apik? Kanggo sijine iku TLDR, SLA apik document ngatur hubungan antarane loro entitas, kang menehi siji saka pihak (customer) kontrol maksimum liwat proses. Yaiku, cara kerjane ing jagad nyata: ana dokumen sing nggambarake proses interaksi global lan ngatur hubungan antarane pihak. Iku nyetel wates, aturan, lan dhewe dadi pengaruh pengaruh sing loro pihak bisa digunakake kanggo kebekan. Mangkono, thanks kanggo SLA sing bener, pelanggan mung bisa meksa kontraktor supaya bisa kerja kaya sing wis disepakati, lan mbantu kontraktor nglawan "kepengin" klien sing aktif banget sing ora dibenerake dening kontrak. Katon kaya mangkene: "SLA kita ujar iki lan iki, metu saka kene, kita nindakake kabeh kaya sing wis disepakati."
Yaiku, "SLA sing bener" = "kontrak sing nyukupi kanggo nyedhiyakake layanan" lan menehi kontrol babagan kahanan kasebut. Nanging iki mung bisa ditindakake nalika nggarap "padha".
Apa sing ditulis ing situs web lan apa sing dikarepake ing kasunyatan iku rong perkara sing beda
Umumé, kabeh sing bakal dibahas luwih lanjut yaiku trik marketing khas lan tes perhatian.
Yen kita njupuk hoster domestik populer, banjur siji tawaran luwih apik tinimbang liyane: 25/8 support, server uptime 99,9999999% wektu, Bunch saka pusat data dhewe ing paling ing Rusia. Mangga elinga titik babagan pusat data, kita bakal bali menyang sethitik mengko. Ing sawetoro wektu, ayo ngomong babagan statistik toleransi kesalahan sing cocog lan apa sing diadhepi wong nalika server isih ana "0,0000001% gagal."
Kanthi indikator 98% lan ndhuwur, penurunan apa wae minangka kedadeyan ing ambang kesalahan statistik. Peralatan lan sambungan sing bisa digunakake ana utawa ora ana. Sampeyan bisa nggunakake hoster karo rating "reliabilitas" 50% (miturut SLA dhewe) kanggo taun tanpa masalah siji, utawa sampeyan bisa "gagal" sapisan sasi kanggo saperangan dina karo wong lanang sing ngaku 99,99%.
Nalika wayahe tiba (lan, kita ngelingake sampeyan, saben wong tiba ing sawijining dina), banjur klien ngadhepi mesin perusahaan internal sing disebut "dukungan", lan persetujuan layanan lan SLA digawa menyang cahya. Iki artine apa:
- Paling kamungkinan, kanggo patang jam pisanan downtime sampeyan ora bakal bisa kanggo saiki apa-apa, sanajan sawetara hoster wiwit recalculating tariff (mbayar ganti rugi) saka wayahe kacilakan.
- Yen server ora kasedhiya kanggo wektu sing luwih suwe, sampeyan bisa ngirim panjalukan kanggo recalculation tarif.
- Lan iki kasedhiya yen masalah muncul amarga kesalahan saka supplier.
- Yen masalah sampeyan muncul amarga pihak katelu (ing dalan gedhe), mula kayane "ora ana sing kudu disalahake" lan nalika masalah dirampungake yaiku masalah nasib sampeyan.
Nanging, penting kanggo ngerti manawa sampeyan ora nate entuk akses menyang tim teknik, paling asring sampeyan mandhegake dhukungan baris pertama, sing cocog karo sampeyan nalika insinyur nyata nyoba ndandani kahanan kasebut. Muni akrab?
Ing kene, akeh wong sing ngandelake SLA, sing misale jek kudu nglindhungi sampeyan saka kahanan kaya ngono. Nanging, nyatane, perusahaan arang banget ngluwihi wates dokumen dhewe utawa bisa ngowahi kahanan kasebut kanthi cara kanggo nyuda biaya dhewe. Tugas utama SLA yaiku kanggo njaga kewaspadaan lan ngyakinake yen sanajan ana kahanan sing ora dikarepake, "kabeh bakal apik." Tujuan kaloro saka SLA yaiku kanggo komunikasi titik kritis utama lan menehi kamar panyedhiya layanan kanggo maneuver, yaiku, kemampuan kanggo ngubungake kegagalan kanggo soko sing supplier "ora tanggung jawab".
Ing wektu sing padha, klien gedhe, nyatane, ora peduli babagan ganti rugi ing SLA. "ganti rugi SLA" punika mbalekaken dhuwit ing tarif ing babagan kanggo downtime peralatan, kang ora bakal nutupi malah 1% saka potensial losses babakan dhuwit lan reputasi. Ing kasus iki, iku luwih penting kanggo klien sing masalah ditanggulangi sanalika bisa saka sawetara jinis "recalculation tarif".
"Akeh pusat data ing saindenging jagad" dadi kuwatir
Kita wis nyelehake kahanan kasebut kanthi akeh pusat data ing panyedhiya layanan ing kategori sing kapisah, amarga saliyane masalah komunikasi sing jelas ing ndhuwur, masalah sing ora jelas uga muncul. Contone, panyedhiya layanan sampeyan ora duwe akses menyang pusat data "dheweke".
Ing artikel pungkasan kita , intine yaiku adol maneh kapasitase wong liya kanthi kedok dhewe. Umume hoster modern sing ngaku duwe "pusat data dhewe" ing pirang-pirang wilayah yaiku pengecer nggunakake model Label Putih. Yaiku, kanthi fisik ora ana hubungane karo pusat data bersyarat ing Swiss, Jerman utawa Walanda.
Tabrakan sing menarik banget muncul ing kene. SLA sampeyan karo panyedhiya layanan isih bisa digunakake lan bener, nanging supplier ora bisa radikal malih pengaruhe kahanan nalika kacilakan. Dheweke dhewe ana ing posisi gumantung marang supplier dhewe - pusat data, saka ngendi rak daya dituku kanggo adol maneh.
Mangkono, yen sampeyan ora mung ngormati tembung sing apik ing kontrak lan SLA babagan linuwih lan layanan, nanging uga kemampuan panyedhiya layanan kanggo ngatasi masalah kanthi cepet, sampeyan kudu kerja langsung karo pemilik fasilitas kasebut. Nyatane, iki kalebu interaksi langsung langsung karo pusat data.
Apa kita ora nimbang opsi nalika akeh DC bener bisa dadi kagungane siji perusahaan? Inggih, ana banget, banget sawetara perusahaan kuwi. Siji, loro, telu pusat data cilik utawa siji gedhe bisa. Nanging rolas DC, setengah saka ing Federasi Rusia, lan kaloro ing Eropah, meh mokal. Iki tegese ana akeh perusahaan pengecer luwih akeh tinimbang sing sampeyan bayangake. Punika conto prasaja:
Taksiran jumlah pusat data layanan Google Cloud. Ing Eropah mung ana enem. Ing London, Amsterdam, Brussels, Helsinki, Frankfurt lan Zurich. Yaiku, ing kabeh titik dalan utama. Amarga pusat data larang, kompleks lan proyek sing gedhe banget. Saiki elinga perusahaan hosting saka ngendi wae ing Moskow kanthi "sepuluh pusat data ing saindenging Rusia lan Eropa."
Mesthi wae, ora ana pemasok sing apik sing duwe mitra ing program White Label, cukup, lan nyedhiyakake layanan sing paling dhuwur. Padha nggawe iku bisa kanggo nyewa kapasitas ing EU lan Federasi Rusia bebarengan liwat jendhela browser padha, nampa pembayaran ing rubles, ora ing itungan manca, etc. Nanging nalika kasus sing diterangake ing SLA kedadeyan, dheweke dadi sandera sing padha karo kahanan sampeyan.
Iki ngelingake maneh yen SLA ora ana gunane yen sampeyan ora duwe pangerten babagan struktur organisasi lan kemampuan supplier.
Apa ing pungkasan
Kacilakan server tansah dadi acara sing ora nyenengake lan bisa kedadeyan ing sapa wae, ing ngendi wae. Pitakonan yaiku carane ngontrol kahanan sing dikarepake. Saiki ana ora akeh banget supplier langsung saka kapasitas ing pasar, lan yen kita pirembagan bab pemain gedhe, banjur padha duwe, relatif ngandika, mung siji DC nang endi wae ing Moscow metu saka rolas saindhenging Eropah sing bisa diakses.
Ing kene, saben klien kudu mutusake dhewe: apa aku milih kepenak saiki utawa nglampahi wektu lan usaha nggoleki pusat data ing lokasi sing bisa ditampa ing Rusia utawa Eropa, ing ngendi aku bisa nyelehake peralatan utawa kapasitas tuku. Ing kasus sing sepisanan, solusi standar sing saiki ana ing pasar cocok. Ing kaloro, sampeyan kudu kringet.
Kaping pisanan, perlu kanggo nemtokake manawa penjual layanan minangka pemilik langsung fasilitas / pusat data. Akeh pengecer nggunakake model White Label nyoba sing paling apik kanggo nyamarake status, lan ing kasus iki sampeyan kudu nggoleki sawetara pratandha ora langsung. Contone, yen "DC Eropa" duwe sawetara jeneng lan logo tartamtu sing beda karo jeneng perusahaan supplier. Utawa yen tembung "mitra" katon nang endi wae. Mitra = Label Putih ing 95% kasus.
Sabanjure, sampeyan kudu familiarize dhewe karo struktur perusahaan dhewe, utawa luwih, katon ing peralatan ing wong. Antarane pusat data, praktik wisata utawa paling ora artikel wisata ing situs web utawa blog dhewe ora anyar (kita nulis и ), ing ngendi dheweke ngomong babagan pusat data kanthi foto lan deskripsi rinci.
Kanthi akeh pusat data, sampeyan bisa ngatur kunjungan pribadi menyang kantor lan mini-excursion menyang DC dhewe. Ing kana sampeyan bisa netepake tingkat urutan, mbok menawa sampeyan bisa komunikasi karo salah sawijining insinyur. Cetha yen ora ana sing bakal menehi demo produksi yen sampeyan butuh server siji kanggo 300 RUB / sasi, nanging yen sampeyan mbutuhake kapasitas serius, departemen sales bisa uga ketemu sampeyan. Contone, kita nganakake wisata kasebut.
Ing kasus apa wae, akal sehat lan kabutuhan bisnis kudu digunakake. Contone, yen sampeyan butuh infrastruktur sing disebarake (sawetara server ana ing Federasi Rusia, sing liyane ing EU), bakal luwih gampang lan luwih nguntungake nggunakake layanan hoster sing duwe kemitraan karo DC Eropa nggunakake Label Putih. model. Yen kabeh infrastruktur sampeyan bakal dikonsentrasi ing salah sawijining titik, yaiku, ing salah sawijining pusat data, mula kudu ngenteni sawetara wektu kanggo nemokake supplier.
Amarga SLA khas paling ora bakal mbantu sampeyan. Nanging nggarap pemilik fasilitas, lan dudu pengecer, bakal nyepetake resolusi masalah sing bisa ditindakake.
Source: www.habr.com