Ärge arvake, et SLA päästab teid. Seda on vaja rahustamiseks ja vale turvatunde tekitamiseks.

Ärge arvake, et SLA päästab teid. Seda on vaja rahustamiseks ja vale turvatunde tekitamiseks.

SLA, tuntud ka kui "teenusetaseme leping", on kliendi ja teenusepakkuja vaheline garantiileping selle kohta, mida klient teenuse osas saab. See näeb ette ka hüvitise tarnija süül tekkinud seisaku korral jne. Sisuliselt on SLA volikiri, mille abil andmekeskus või hostingu pakkuja veenab potentsiaalset klienti, et teda koheldakse igal võimalikul viisil sõbralikult. Küsimus on selles, et SLA-sse võid kirjutada kõike, mida soovid ja selles dokumendis kirja pandud sündmusi ei esine liiga sageli. SLA ei ole kaugeltki andmekeskuse valimise juhis ja kindlasti ei tohiks te sellele loota.

Me kõik oleme harjunud sõlmima mingisuguseid lepinguid, mis panevad teatud kohustused. SLA pole erand – tavaliselt kõige ebareaalsem dokument, mida ette kujutada saab. Ainus, mis on ilmselt kasutum, on NDA jurisdiktsioonides, kus ärisaladuse mõistet tegelikult ei eksisteeri. Kuid kogu probleem on selles, et SLA ei aita klienti õige tarnija valikul, vaid loobib ainult tolmu silma.

Mida majutajad kõige sagedamini SLA avalikus versioonis kirjutavad, mida nad avalikkusele näitavad? Noh, esimene rida on hosti termin "usaldusväärsus" - need on tavaliselt numbrid vahemikus 98 kuni 99,999%. Tegelikult on need numbrid lihtsalt turundajate ilus leiutis. Kunagi, kui hostimine oli noor ja kallis ning pilved olid spetsialistide jaoks vaid unistus (nagu ka lairibajuurdepääs kõigile), oli hostimise tööaja indikaator ülimalt-äärmiselt oluline. Nüüd, kui kõik tarnijad kasutavad pluss või miinus samu seadmeid, istuvad samades magistraalvõrkudes ja pakuvad samu teenusepakette, on tööaja indikaator täiesti märkamatu.

Kas on isegi "õige" SLA?

Loomulikult on SLA ideaalseid versioone, kuid kõik need on mittestandardsed dokumendid ning registreeritakse ja sõlmitakse kliendi ja tarnija vahel käsitsi. Pealegi puudutavad seda tüüpi SLAd enamasti pigem lepingulist tööd kui teenuseid.

Mida peaks hea SLA sisaldama? TLDR-i öeldes on hea SLA kahe olemi vahelisi suhteid reguleeriv dokument, mis annab ühele osapoolest (kliendile) protsessi üle maksimaalse kontrolli. Ehk kuidas see reaalses maailmas toimib: on olemas dokument, mis kirjeldab globaalseid suhtlusprotsesse ja reguleerib osapoolte vahelisi suhteid. See seab piirid, reeglid ja muutub iseenesest mõjuhoovaks, mida mõlemad osapooled saavad täiel rinnal kasutada. Seega saab tellija tänu korrektsele SLA-le lihtsalt sundida töövõtjat kokkulepitud viisil töötama ning see aitab töövõtjal tõrjuda liiga aktiivse kliendi lepinguga mitteõigustatud “soove”. See näeb välja selline: "Meie SLA ütleb seda ja seda, minge siit minema, me teeme kõik nii, nagu kokku lepitud."

See tähendab, et "õige SLA" = "adekvaatne leping teenuste osutamiseks" ja annab kontrolli olukorra üle. Kuid see on võimalik ainult siis, kui töötatakse "võrdväärsena".

See, mis kodulehel kirjas ja mis tegelikkuses ees ootab, on kaks erinevat asja

Üldiselt on kõik, mida me edasi arutame, tüüpilised turundusnipid ja tähelepanelikkuse test.

Kui võtta populaarsed kodumaised hostid, siis üks pakkumine on parem kui teine: 25/8 tugi, serveri tööaeg 99,9999999% ajast, hunnik oma andmekeskusi vähemalt Venemaal. Pidage meeles andmekeskuste kohta käivat punkti, tuleme selle juurde veidi hiljem tagasi. Vahepeal räägime ideaalsest tõrketaluvuse statistikast ja sellest, millega inimene silmitsi seisab, kui tema server langeb endiselt "0,0000001% rikete hulka".

Kui näitajad on 98% ja rohkem, on iga langus statistilise vea piiril sündmus. Töövahendid ja ühendus kas on olemas või ei ole. Saate kasutada hosterit, mille "usaldusväärsus" on 50% (vastavalt selle enda SLA-le), aastaid ilma ühegi probleemita või korra kuus paar päeva "ära kukkuda" koos kuttidega, kes nõuavad 99,99%.

Kui kukkumise hetk saabub (ja tuletame meelde, et kõik kukuvad kunagi), seisab klient silmitsi ettevõttesisese masinaga, mida nimetatakse "toetuseks" ning päevavalgele tuuakse teenindusleping ja SLA. Mida see tähendab:

  • Tõenäoliselt ei saa te seisaku esimese nelja tunni jooksul üldse midagi esitada, kuigi mõned hostijad hakkavad tariifi (hüvitise maksmist) ümber arvutama alates krahhi hetkest.
  • Kui server pole pikemat aega saadaval, võib teil olla võimalik esitada tariifi ümberarvutamise taotlus.
  • Ja seda eeldusel, et probleem tekkis tarnija süül.
  • Kui teie probleem tekkis kolmanda osapoole tõttu (maanteel), siis tundub, et "keegi pole süüdi" ja probleemi lahendamine on teie õnne küsimus.

Siiski on oluline mõista, et te ei pääse kunagi insenerimeeskonna juurde, enamasti peatab teid esimene tugiliin, kes teiega suhtleb, samal ajal kui tõelised insenerid üritavad olukorda parandada. Kõlab tuttavalt?

Siin loodavad paljud inimesed SLA-le, mis näib teid selliste olukordade eest kaitsma. Kuid tegelikult väljuvad ettevõtted harva oma dokumendi piire või suudavad olukorra ümber pöörata nii, et enda kulud oleksid minimaalsed. SLA peamine ülesanne on summutada valvsust ja veenda, et isegi ettenägematute olukordade korral on kõik korras. SLA teine ​​​​eesmärk on edastada peamised kriitilised punktid ja anda teenusepakkujale manööverdamisruum, st võimalus omistada rike millelegi, mille eest tarnija "ei vastuta".

Samal ajal ei huvita suurkliendid SLA raames hüvitamisest üldse. “SLA hüvitis” on tariifi piires raha tagastamine proportsionaalselt seadmete seisakutega, mis ei kata kunagi isegi 1% võimalikest rahalistest ja mainekahjust. Sel juhul on kliendi jaoks palju olulisem probleemide võimalikult kiire lahendamine kui mingisugune “tariifi ümberarvutamine”.

„Paljud andmekeskused üle maailma” on murettekitav

Olukorra, kus on palju andmekeskusi teenusepakkuja juures, oleme paigutanud omaette kategooriasse, sest lisaks ülalkirjeldatud ilmsetele sideprobleemidele kerkivad esile ka mitteilmsed probleemid. Näiteks ei ole teie teenusepakkujal juurdepääsu „oma” andmekeskustele.

Meie viimases artiklis kirjutasime sidusprogrammide tüüpidest ja mainisime "White Label" mudelit, mille sisuks on teiste inimeste võimete edasimüümine selle enda varjus. Valdav enamus kaasaegsetest hostijatest, kes väidavad, et neil on paljudes piirkondades "oma andmekeskused", on edasimüüjad, kes kasutavad White Labeli mudelit. See tähendab, et neil pole füüsiliselt mingit pistmist Šveitsi, Saksamaa või Hollandi tingimusliku andmekeskusega.

Siin tekivad ülimalt huvitavad kokkupõrked. Teie SLA teenusepakkujaga töötab ja kehtib endiselt, kuid tarnija ei suuda õnnetuse korral olukorda kuidagi radikaalselt mõjutada. Ta ise on sõltuvas olukorras oma tarnijast – andmekeskusest, kust riiulid edasimüügiks osteti.

Seega, kui hindate mitte ainult ilusat sõnastust lepingus ja SLA-s usaldusväärsuse ja teeninduse kohta, vaid ka teenusepakkuja võimet probleeme kiiresti lahendada, peaksite tegema koostööd otse rajatiste omanikuga. Tegelikult hõlmab see otsest suhtlust andmekeskusega.

Miks me ei kaalu võimalusi, kui paljud DC-d võivad tegelikult kuuluda ühele ettevõttele? No selliseid ettevõtteid on väga-väga vähe. Võimalik on üks, kaks, kolm väikest andmekeskust või üks suur. Kuid kümmekond DC-d, millest pooled asuvad Vene Föderatsioonis ja teine ​​Euroopas, on peaaegu võimatu. See tähendab, et edasimüüjaid on palju rohkem, kui võite ette kujutada. Siin on lihtne näide:

Ärge arvake, et SLA päästab teid. Seda on vaja rahustamiseks ja vale turvatunde tekitamiseks.
Hinnake Google'i pilveteenuse andmekeskuste arvu. Euroopas on neid vaid kuus. Londonis, Amsterdamis, Brüsselis, Helsingis, Frankfurdis ja Zürichis. See tähendab kõigis peamistes maanteede punktides. Sest andmekeskus on kallis, keeruline ja väga mahukas projekt. Pidage meeles hostimisettevõtteid kusagilt Moskvast, kus on kümmekond andmekeskust kogu Venemaal ja Euroopas.

Muidugi pole häid tarnijaid, kellel oleks White Label programmis partnereid, neid on piisavalt ja nad pakuvad kõrgeimal tasemel teenuseid. Need võimaldavad rentida samaaegselt sama brauseriakna kaudu võimsust EL-is ja Vene Föderatsioonis, aktsepteerida makseid rublades, mitte välisvaluutas jne. Kuid kui SLA-s kirjeldatud juhtumid esinevad, saavad neist täpselt samasugused olukorra pantvangid nagu teiegi.

See tuletab meile veel kord meelde, et SLA on kasutu, kui te ei mõista tarnija organisatsioonilist struktuuri ja võimalusi.

Mille tulemusena

Serveri krahh on alati ebameeldiv sündmus ja see võib juhtuda igaühega ja igal pool. Küsimus on selles, kui palju te olukorra üle kontrolli soovite. Nüüd pole turul liiga palju otseseid võimsuse tarnijaid ja kui rääkida suurtest tegijatest, siis neile kuulub suhteliselt üks DC kuskil Moskvas tosinast kogu Euroopast, millele pääsete ligi.

Siin peab iga klient ise otsustama: kas valin kohe mugavuse või kulutan aega ja vaeva, otsides Venemaal või Euroopas vastuvõetavas kohas andmekeskust, kuhu saaksin paigutada oma seadmed või osta võimsust. Esimesel juhul sobivad praegu turul olevad standardlahendused. Teises peate higistama.

Kõigepealt tuleb kindlaks teha, kas teenuse müüja on rajatiste/andmekeskuse otsene omanik. Paljud White Label mudelit kasutavad edasimüüjad püüavad oma staatust varjata ja sel juhul peate otsima kaudseid märke. Näiteks kui "nende Euroopa DC-del" on mõned konkreetsed nimed ja logod, mis erinevad tarnija ettevõtte nimest. Või kui kusagil esineb sõna “partnerid”. Partnerid = White Label 95% juhtudest.

Järgmiseks tuleb end kurssi viia ettevõtte enda struktuuriga või veel parem – seadmeid isiklikult vaadata. Andmekeskuste seas ei ole ekskursioonide või vähemalt ekskursiooniartiklite tava veebilehel või ajaveebis uus (me kirjutasime sellise aeg и два), kus nad räägivad oma andmekeskusest koos fotode ja üksikasjalike kirjeldustega.

Paljude andmekeskustega saate korraldada isikliku külastuse kontorisse ja miniekskursiooni DC-sse. Seal saate hinnata korra astet, võib-olla saate mõne inseneriga suhelda. On selge, et keegi ei tee teile tootmisringi, kui vajate ühte serverit hinnaga 300 RUB/kuus, kuid kui vajate tõsist võimsust, võib müügiosakond teile hästi vastu tulla. Näiteks viime selliseid ekskursioone läbi.

Igal juhul tuleks lähtuda tervest mõistusest ja ärilistest vajadustest. Näiteks kui vajate hajutatud infrastruktuuri (mõned serverid asuvad Vene Föderatsioonis, teised EL-is), on lihtsam ja tulusam kasutada nende hostide teenuseid, kellel on White Label'i abil partnerlussuhted Euroopa DC-dega. mudel. Kui kogu teie infrastruktuur koondub ühte punkti ehk ühte andmekeskusesse, siis tasub tarnija leidmisele veidi aega kulutada.

Kuna tüüpiline SLA teid tõenäoliselt ei aita. Kuid koostöö rajatiste omanikuga, mitte edasimüüjaga, kiirendab oluliselt võimalike probleemide lahendamist.

Allikas: www.habr.com

Lisa kommentaar