Az SLA, más néven „szolgáltatási szintű megállapodás”, egy garanciális megállapodás az ügyfél és a szolgáltató között arról, hogy az ügyfél mit kap a szolgáltatás tekintetében. A szállító hibájából bekövetkező leállás esetén kártérítést is előír, stb. Az SLA lényegében egy hitelesítő okirat, amellyel egy adatközpont vagy tárhelyszolgáltató meggyőzi a potenciális ügyfelet arról, hogy minden lehetséges módon kedvesen bánnak vele. A kérdés az, hogy bármit beírhat az SLA-ba, és az ebben a dokumentumban leírt események nem fordulnak elő túl gyakran. Az SLA messze nem irányadó az adatközpont kiválasztásában, és semmiképpen sem szabad rá hagyatkoznia.
Mindannyian megszoktuk, hogy olyan megállapodásokat írunk alá, amelyek bizonyos kötelezettségeket írnak elő. Ez alól az SLA sem kivétel – általában az elképzelhető legirreálisabb dokumentum. Az egyetlen dolog, ami valószínűleg haszontalanabb, az az NDA olyan joghatóságokban, ahol az „üzleti titok” fogalma valójában nem létezik. De az egész probléma az, hogy az SLA nem segíti az ügyfelet a megfelelő beszállító kiválasztásában, hanem csak port szúr a szemébe.
Mit írnak a házigazdák leggyakrabban az SLA nyilvános verziójába, amelyet a nyilvánosságnak mutatnak meg? Nos, az első sor a szolgáltató „megbízhatósága” kifejezés – ezek általában 98 és 99,999% közötti számok. Valójában ezek a számok csak a marketingesek gyönyörű találmányai. Valamikor, amikor a hosting fiatal és drága volt, és a felhők csak álmodtak a szakemberek számára (valamint a szélessávú hozzáférés mindenki számára), a hosting üzemidő mutatója rendkívül, rendkívül fontos volt. Most, amikor minden beszállító ugyanazt a berendezést használja, ugyanazon a gerinchálózaton ül, és ugyanazokat a szolgáltatási csomagokat kínálja, az üzemidő mutatója egyáltalán nem figyelemre méltó.
Létezik egyáltalán „helyes” SLA?
Természetesen vannak ideális változatai az SLA-nak, de mindegyik nem szabványos dokumentum, amelyet az ügyfél és a szállító manuálisan regisztrálnak és kötnek meg. Ezen túlmenően az ilyen típusú SLA leggyakrabban valamilyen szerződéses munkára vonatkozik, nem pedig szolgáltatásokra.
Mit kell tartalmaznia egy jó SLA-nak? TLDR-ként fogalmazva, a jó SLA két entitás közötti kapcsolatot szabályozó dokumentum, amely az egyik félnek (az ügyfélnek) maximális ellenőrzést biztosít a folyamat felett. Vagyis hogyan működik ez a való világban: létezik egy dokumentum, amely leírja a globális interakciós folyamatokat és szabályozza a felek közötti kapcsolatokat. Határokat, szabályokat szab, és önmagában is olyan befolyási kar lesz, amelyet mindkét fél maximálisan kihasználhat. Így a megfelelő SLA-nak köszönhetően a megrendelő egyszerűen rákényszerítheti a vállalkozót a megállapodás szerinti munkára, és ez segít a vállalkozónak leküzdeni a túlzottan aktív ügyfél szerződés által nem indokolt „kényszereit”. Így néz ki: "Az SLA-nk ezt-azt mond, menjen innen, mindent a megbeszéltek szerint csinálunk."
Vagyis „a helyes SLA” = „megfelelő szerződés a szolgáltatások nyújtására”, és kontrollt ad a helyzet felett. De ez csak akkor lehetséges, ha „egyenlőként” dolgozunk.
Az, amit a weboldalon írnak, és ami a valóságban vár, az két különböző dolog
Általánosságban elmondható, hogy minden, amit a továbbiakban tárgyalunk, tipikus marketingtrükkök és a figyelmesség próbája.
Ha a népszerű hazai hostereket vesszük, akkor az egyik ajánlat jobb, mint a másik: 25/8 támogatás, szerver üzemidő az esetek 99,9999999%-ában, egy rakás saját adatközpont legalább Oroszországban. Kérjük, ne feledje az adatközpontokkal kapcsolatos pontot, kicsit később visszatérünk rá. Addig is beszéljünk az ideális hibatűrési statisztikákról, és arról, hogy mivel kell szembenéznie az embernek, ha a szervere még mindig a „hibák 0,0000001%-ába” esik.
98%-os és afeletti mutatók esetén minden esés a statisztikai hiba határán álló esemény. A munkaeszközök és a csatlakozás vagy megvannak, vagy nincsenek. Egy 50%-os (saját SLA szerint) „megbízhatósági” besorolású tárhelyet évekig használhatsz probléma nélkül, vagy havonta egyszer pár napig „megbukhatsz” a 99,99%-ot igénylő srácokkal.
Amikor eljön a bukás pillanata (és emlékeztetünk arra, hogy egyszer mindenki elesik), akkor az ügyfél szembesül egy belső vállalati géppel, amelyet „támogatásnak” neveznek, és napvilágra kerül a szolgáltatási szerződés és az SLA. Mit jelent:
- Valószínűleg az állásidő első négy órájában semmit sem tud bemutatni, bár egyes házigazdák az összeomlás pillanatától kezdik újraszámolni a tarifát (a kártérítés kifizetését).
- Ha a szerver hosszabb ideig nem elérhető, akkor lehet, hogy kérelmet nyújthat be a tarifa újraszámítására.
- És ez feltéve, hogy a probléma a szállító hibájából merült fel.
- Ha a problémád egy harmadik fél miatt merült fel (az autópályán), akkor úgy tűnik, hogy „senki nem hibás”, és a probléma megoldása a szerencse kérdése.
Fontos azonban megérteni, hogy soha nem jut el a mérnöki csapathoz, leggyakrabban a támogatás első vonala áll meg, akik leveleznek veled, miközben az igazi mérnökök próbálják javítani a helyzetet. Ismerősen hangzik?
Itt sokan az SLA-ra hagyatkoznak, aminek úgy tűnik, meg kell védenie az ilyen helyzetektől. Valójában azonban a vállalatok ritkán lépik túl saját dokumentumuk határait, vagy képesek a helyzetet úgy fordítani, hogy saját költségeiket minimalizálják. Az SLA elsődleges feladata az éberség lecsillapítása és meggyőzése arról, hogy még egy előre nem látható helyzet esetén is „minden rendben lesz”. Az SLA második célja a főbb kritikus pontok kommunikálása, és mozgásteret ad a szolgáltatónak, vagyis képes a meghibásodást valaminek tulajdonítani, amiért a szállító „nem felelős”.
Ugyanakkor a nagy ügyfelek valójában egyáltalán nem törődnek az SLA-n belüli kompenzációval. Az „SLA kompenzáció” a tarifán belüli pénzvisszatérítés a berendezés leállásával arányosan, amely soha nem fedezi az esetleges pénzbeli és hírnévveszteségek 1%-át sem. Ebben az esetben az ügyfél számára sokkal fontosabb, hogy a problémák mielőbb megoldódjanak, mint valamiféle „tarifa-újrakalkuláció”.
„Sok adatközpont világszerte” aggodalomra ad okot
Külön kategóriába soroltuk a nagyszámú adatközpontot egy szolgáltatónál, mert a fentebb leírt nyilvánvaló kommunikációs problémákon túl nem nyilvánvaló problémák is felmerülnek. Például az Ön szolgáltatója nem fér hozzá „az ő” adatközpontjaihoz.
Legutóbbi cikkünkben , melynek lényege mások kapacitásainak továbbértékesítése saját leple alatt. A modern tárhelyszolgáltatók túlnyomó többsége, akik azt állítják, hogy számos régióban „saját adatközponttal” rendelkeznek, a White Label modellt használó viszonteladók. Vagyis fizikailag semmi közük a svájci, német vagy holland feltételes adatközponthoz.
Itt rendkívül érdekes ütközések keletkeznek. A szolgáltatóval kötött SLA továbbra is működik és érvényes, de a szállító nem tudja valamilyen módon radikálisan befolyásolni a helyzetet egy baleset esetén. Ő maga is függő helyzetben van a saját beszállítójától - az adatközponttól, ahonnan viszonteladás céljából megvásárolták a tápállványokat.
Ezért, ha a szerződésben és az SLA-ban nem csak a megbízhatóságról és a szolgáltatásról szóló szép megfogalmazást értékeli, hanem azt is, hogy a szolgáltató képes gyorsan megoldani a problémákat, akkor közvetlenül a létesítmény tulajdonosával kell együttműködnie. Valójában ez az adatközponttal való közvetlen interakciót foglalja magában.
Miért nem fontolgatjuk a lehetőségeket, amikor valójában sok DC tartozhat egy céghez? Nos, nagyon-nagyon kevés ilyen cég van. Egy, kettő, három kis adatközpont vagy egy nagy adatközpont lehetséges. De egy tucat DC, amelyek fele az Orosz Föderációban, a második pedig Európában található, szinte lehetetlen. Ez azt jelenti, hogy sokkal több viszonteladó cég van, mint gondolnád. Íme egy egyszerű példa:
Becsülje meg a Google Cloud szolgáltatás adatközpontjainak számát. Európában mindössze hat van belőlük. Londonban, Amszterdamban, Brüsszelben, Helsinkiben, Frankfurtban és Zürichben. Vagyis az összes főbb autópálya-ponton. Mert egy adatközpont drága, összetett és nagyon nagy projekt. Most emlékezzen a tárhelyszolgáltatókra valahonnan Moszkvából, ahol „egy tucat adatközponttal Oroszország és Európa szerte”.
Természetesen nincs jó beszállító, akinek partnere lenne a White Label programban, van elég, és a legmagasabb szintű szolgáltatást nyújtják. Lehetővé teszik a kapacitás bérlését az EU-ban és az Orosz Föderációban egyidejűleg ugyanazon a böngészőablakon keresztül, rubelben történő fizetést, de nem devizában stb. De amikor az SLA-ban leírt esetek előfordulnak, pontosan ugyanolyan túszaivá válnak a helyzetnek, mint te.
Ez ismét emlékeztet bennünket arra, hogy az SLA haszontalan, ha nem ismeri a szállító szervezeti felépítését és képességeit.
Aminek eredményeképpen a
A szerver összeomlás mindig kellemetlen esemény, és bárkivel, bárhol megtörténhet. A kérdés az, hogy mennyire akarod irányítani a helyzetet. Ma már nincs túl sok közvetlen kapacitásszállító a piacon, és ha már nagy szereplőkről beszélünk, akkor relatíve csak egy DC-vel rendelkeznek valahol Moszkvában a tucatnyi Európa-szerte elérhető DC-ből.
Itt minden ügyfélnek magának kell eldöntenie: most a kényelmet választom, vagy időt és energiát fordítok arra, hogy Oroszországban vagy Európában egy elfogadható helyen lévő adatközpontot keressek, ahol elhelyezhetem a berendezéseimet, vagy kapacitást vásárolhatok. Az első esetben a jelenleg piacon lévő szabványos megoldások megfelelőek. A másodikban izzadnia kell.
Mindenekelőtt meg kell határozni, hogy a szolgáltatás értékesítője-e a létesítmények/adatközpontok közvetlen tulajdonosa. Sok White Label modellt használó viszonteladó mindent megtesz, hogy álcázza státuszát, és ebben az esetben meg kell keresni néhány közvetett jelet. Például, ha „az európai DC-iknek” van néhány konkrét neve és logója, amelyek eltérnek a beszállító cég nevétől. Vagy ha valahol megjelenik a „partnerek” szó. Partnerek = White Label az esetek 95%-ában.
Ezután meg kell ismerkednie magával a vállalat felépítésével, vagy ami még jobb, személyesen nézze meg a berendezést. Az adatközpontok között nem új keletű a kirándulások gyakorlata, vagy legalábbis kirándulási cikkek írása saját weboldalukon, blogjukon (ilyet írtunk и ), ahol fotókkal és részletes leírásokkal beszélnek adatközpontjukról.
Számos adatközponttal megszervezhet személyes látogatást az irodában és egy mini kirándulást magába a DC-be. Ott felmérheti a rend mértékét, esetleg kommunikálhat valamelyik mérnökkel. Egyértelmű, hogy ha egy szerverre van szüksége 300 RUB/hó áron, akkor senki sem fogja bemutatni a termelést, de ha komoly kapacitásra van szüksége, akkor az értékesítési osztály találkozhat Önnel. Például ilyen kirándulásokat szervezünk.
Mindenesetre a józan észt és az üzleti igényeket kell használni. Például, ha elosztott infrastruktúrára van szüksége (a szerverek egy része az Orosz Föderációban, a másik az EU-ban található), könnyebb és jövedelmezőbb lesz olyan szolgáltatók szolgáltatásait igénybe venni, akik a White Label használatával partneri kapcsolatban állnak európai DC-kkel. modell. Ha a teljes infrastruktúra egy ponton, azaz egy adatközpontban összpontosul, akkor érdemes időt szánni a beszállító megtalálására.
Mert egy tipikus SLA valószínűleg nem fog segíteni. De a létesítmény tulajdonosával, és nem viszonteladóval való együttműködés jelentősen felgyorsítja a lehetséges problémák megoldását.
Forrás: will.com