SLA, poznat i kao "ugovor o razini usluge", jamstveni je ugovor između korisnika i pružatelja usluge o tome što će korisnik dobiti u smislu usluge. Također predviđa naknadu u slučaju zastoja zbog krivnje dobavljača i sl. U biti, SLA je vjerodajnica uz pomoć koje podatkovni centar ili hosting provider uvjerava potencijalnog klijenta da će biti tretiran ljubazno na sve moguće načine. Pitanje je da u SLA možete napisati što god želite, a događaji napisani u ovom dokumentu se ne događaju prečesto. SLA je daleko od smjernice pri odabiru podatkovnog centra i svakako se ne biste trebali oslanjati na njega.
Svi smo navikli potpisivati nekakve ugovore koji nameću određene obveze. SLA nije iznimka - obično najnerealniji dokument koji se može zamisliti. Jedina stvar koja je vjerojatno beskorisnija je NDA u jurisdikcijama gdje koncept "poslovne tajne" zapravo ne postoji. Ali cijeli problem je u tome što SLA ne pomaže klijentu u odabiru pravog dobavljača, već samo baca prašinu u oči.
Što hosteri najčešće napišu u javnoj verziji SLA koju pokazuju javnosti? Pa, prvi red je izraz "pouzdanost" hostera - to su obično brojevi od 98 do 99,999%. Zapravo, ove brojke samo su prekrasan izum trgovaca. Nekad davno, dok je hosting bio mlad i skup, a oblaci bili samo san za stručnjake (kao i širokopojasni pristup za sve), indikator uptime hostinga bio je iznimno, iznimno važan. Sada, kada svi dobavljači koriste, plus ili minus, istu opremu, nalaze se na istim glavnim mrežama i nude iste pakete usluga, indikator vremena neprekidnog rada je apsolutno neupadljiv.
Postoji li uopće "ispravan" SLA?
Naravno, postoje idealne verzije SLA-a, ali sve su to nestandardni dokumenti i registriraju se i sklapaju između naručitelja i dobavljača ručno. Štoviše, ova vrsta SLA-a najčešće se odnosi na neku vrstu ugovorenog posla, a ne na usluge.
Što treba sadržavati dobar SLA? Rečeno TLDR, dobar SLA je dokument koji regulira odnos između dva subjekta, koji jednoj od strana (kupcu) daje maksimalnu kontrolu nad procesom. Odnosno, kako to funkcionira u stvarnom svijetu: postoji dokument koji opisuje globalne interakcijske procese i regulira odnose između strana. Postavlja granice, pravila i sama po sebi postaje poluga utjecaja koju obje strane mogu maksimalno iskoristiti. Dakle, zahvaljujući ispravnom SLA-u, kupac može jednostavno prisiliti izvođača da radi kako je dogovoreno, a pomaže izvođaču da se izbori s "željama" pretjerano aktivnog klijenta koje nisu opravdane ugovorom. To izgleda ovako: “Naš SLA kaže to i to, bježite odavde, mi radimo sve kako je dogovoreno.”
Odnosno, “ispravan SLA” = “adekvatan ugovor o pružanju usluga” i daje kontrolu nad situacijom. Ali to je moguće samo kada radimo "kao jednaki".
Ono što piše na web stranici i ono što čeka u stvarnosti dvije su različite stvari
Općenito, sve o čemu ćemo dalje razgovarati tipični su marketinški trikovi i test pažnje.
Ako uzmemo popularne domaće hostere, onda je jedna ponuda bolja od druge: podrška 25/8, vrijeme rada poslužitelja 99,9999999% vremena, hrpa vlastitih podatkovnih centara barem u Rusiji. Zapamtite točku o podatkovnim centrima, vratit ćemo se na to malo kasnije. U međuvremenu, razgovarajmo o idealnoj statistici tolerancije na greške i s čime se osoba suočava kada njegov poslužitelj još uvijek spada u "0,0000001% kvarova".
S pokazateljima od 98% i više, svaki pad je događaj na rubu statističke pogreške. Oprema za rad i priključak ili postoje ili ih nema. Možete koristiti hoster s ocjenom "pouzdanosti" od 50% (prema vlastitom SLA) godinama bez ikakvih problema, ili možete "podbaciti" jednom mjesečno na nekoliko dana s dečkima koji tvrde 99,99%.
Kada ipak dođe trenutak pada (a, podsjećamo, svatko kad-tad padne), tada se klijent suočava s internim korporativnim strojem zvanim “support”, a na vidjelo izlazi ugovor o usluzi i SLA. Što to znači:
- Najvjerojatnije, prva četiri sata zastoja nećete moći ništa prezentirati, iako neki hosteri počinju preračunavati tarifu (plaćanje naknade) od trenutka pada.
- Ako poslužitelj nije dostupan dulje vrijeme, možda možete podnijeti zahtjev za preračun tarife.
- I to pod uvjetom da je problem nastao krivnjom dobavljača.
- Ako je vaš problem nastao zbog treće strane (na autocesti), onda vam se čini kao da "nitko nije kriv", a kada će problem biti riješen, stvar je vaše sreće.
Međutim, važno je shvatiti da nikad ne dobijete pristup inženjerskom timu, najčešće vas zaustavi prva linija podrške, koja se dopisuje s vama dok pravi inženjeri pokušavaju popraviti situaciju. Zvuči poznato?
Ovdje se mnogi ljudi oslanjaju na SLA, koji bi vas, čini se, trebao zaštititi od takvih situacija. No, zapravo, tvrtke rijetko izlaze izvan granica vlastitog dokumenta ili su u stanju preokrenuti situaciju na takav način da minimiziraju vlastite troškove. Primarni zadatak SLA-a je uspavati budnost i uvjeriti da će čak i u slučaju nepredviđene situacije "sve biti u redu". Druga svrha SLA-a je komuniciranje glavnih kritičnih točaka i davanje manevarskog prostora pružatelju usluga, odnosno mogućnost pripisivanja kvara nečemu za što dobavljač "nije odgovoran".
Pritom veliki klijenti, zapravo, uopće ne mare za kompenzacije unutar SLA. “SLA kompenzacija” je povrat novca unutar tarife proporcionalno zastoju opreme, koji nikada neće pokriti ni 1% potencijalnih novčanih i reputacijskih gubitaka. Klijentu je u ovom slučaju puno važnije da se problemi riješe što prije nego neka vrsta “preračunavanja tarifa”.
"Mnogi podatkovni centri diljem svijeta" razlog su za zabrinutost
Situaciju s velikim brojem podatkovnih centara kod davatelja usluga stavili smo u zasebnu kategoriju, jer uz očite komunikacijske probleme opisane gore, javljaju se i neočiti problemi. Na primjer, vaš davatelj usluga nema pristup "svojim" podatkovnim centrima.
U našem prošlom članku , čija je suština preprodaja tuđih kapaciteta pod svojom krinkom. Velika većina modernih hostera koji tvrde da imaju "vlastite podatkovne centre" u mnogim regijama su preprodavači koji koriste model White Label. Odnosno, oni fizički nemaju nikakve veze s uvjetnim podatkovnim centrom u Švicarskoj, Njemačkoj ili Nizozemskoj.
Ovdje nastaju iznimno zanimljive kolizije. Vaš SLA s pružateljem usluga i dalje funkcionira i vrijedi, ali dobavljač ne može radikalno utjecati na situaciju u slučaju nezgode. On sam je u ovisnom položaju o vlastitom dobavljaču - podatkovnom centru od kojeg su nabavljeni regali za preprodaju.
Stoga, ako ne cijenite samo lijepe formulacije u ugovoru i SLA o pouzdanosti i usluzi, već i sposobnost pružatelja usluge da brzo riješi probleme, trebali biste surađivati izravno s vlasnikom objekata. Zapravo, to uključuje izravnu interakciju izravno s podatkovnim centrom.
Zašto ne razmotrimo mogućnosti kada mnogi DC-ovi zapravo mogu pripadati jednoj tvrtki? Pa takvih je tvrtki jako, jako malo. Moguć je jedan, dva, tri mala podatkovna centra ili jedan veliki. Ali desetak DC-ova, od kojih je polovica u Ruskoj Federaciji, a druga u Europi, gotovo je nemoguće. To znači da postoji mnogo više prodajnih tvrtki nego što možete zamisliti. Evo jednostavnog primjera:
Procijenite broj podatkovnih centara usluge Google Cloud. U Europi ih je samo šest. U Londonu, Amsterdamu, Bruxellesu, Helsinkiju, Frankfurtu i Zürichu. Odnosno, na svim glavnim točkama autoceste. Zato što je podatkovni centar skup, složen i vrlo velik projekt. Sjetite se sada hosting tvrtki iz Moskve s "desetak podatkovnih centara diljem Rusije i Europe".
Nema, naravno, dobrih dobavljača koji imaju partnere u White Label programu, ima ih dovoljno, a pružaju usluge na najvišoj razini. Omogućuju istovremeno iznajmljivanje kapaciteta u EU i Ruskoj Federaciji kroz isti prozor preglednika, prihvaćaju plaćanje u rubljima, a ne u stranoj valuti i tako dalje. Ali kada se dogode slučajevi opisani u SLA, oni postaju potpuno isti taoci situacije kao i vi.
Ovo nas još jednom podsjeća da je SLA beskoristan ako ne razumijete dobavljačevu organizacijsku strukturu i mogućnosti.
S rezultatom da
Pad poslužitelja uvijek je neugodan događaj i može se dogoditi bilo kome, bilo gdje. Pitanje je koliku kontrolu nad situacijom želite. Sada na tržištu nema previše izravnih dobavljača kapaciteta, a ako govorimo o velikim igračima, onda oni posjeduju, relativno govoreći, samo jedan DC negdje u Moskvi od desetak diljem Europe kojima možete pristupiti.
Ovdje svaki klijent mora sam odlučiti: želim li odabrati udobnost odmah ili potrošiti vrijeme i trud tražeći podatkovni centar na prihvatljivoj lokaciji u Rusiji ili Europi, gdje mogu smjestiti svoju opremu ili kupiti kapacitet. U prvom slučaju prikladna su standardna rješenja koja su trenutno na tržištu. U drugom ćete se morati oznojiti.
Prije svega, potrebno je utvrditi je li prodavatelj usluga izravni vlasnik objekata/podatkovnog centra. Mnogi preprodavači koji koriste model White Label daju sve od sebe kako bi prikrili svoj status, au ovom slučaju morate tražiti neke neizravne znakove. Na primjer, ako "njihovi europski DC-ovi" imaju neke specifične nazive i logotipe koji se razlikuju od naziva tvrtke dobavljača. Ili ako se negdje pojavi riječ "partneri". Partneri = White Label u 95% slučajeva.
Zatim se morate upoznati sa strukturom same tvrtke, ili još bolje, osobno pogledati opremu. Među podatkovnim centrima praksa ekskurzija ili barem članaka o ekskurzijama na vlastitoj web stranici ili blogu nije novost (pisali smo takve и ), gdje uz fotografije i detaljne opise govore o svom podatkovnom centru.
Uz mnoge podatkovne centre, možete organizirati osobni posjet uredu i mini-izlet do samog DC-a. Tamo možete procijeniti stupanj reda, možda ćete moći komunicirati s jednim od inženjera. Jasno je da vam nitko neće dati obilazak proizvodnje ako vam treba jedan poslužitelj za 300 RUB/mjesečno, ali ako vam je potreban ozbiljan kapacitet, onda bi vam odjel prodaje mogao izaći u susret. Na primjer, mi provodimo takve izlete.
U svakom slučaju treba koristiti zdrav razum i poslovne potrebe. Na primjer, ako vam je potrebna distribuirana infrastruktura (neki od poslužitelja su u Ruskoj Federaciji, drugi u EU), bit će lakše i isplativije koristiti usluge hostera koji imaju partnerstva s europskim DC-ovima koji koriste White Label model. Ako će vaša cjelokupna infrastruktura biti koncentrirana u jednoj točki, odnosno u jednom podatkovnom centru, onda je vrijedno potrošiti neko vrijeme na pronalazak dobavljača.
Budući da vam tipični SLA najvjerojatnije neće pomoći. Ali suradnja s vlasnikom objekata, a ne preprodavačem, značajno će ubrzati rješavanje mogućih problema.
Izvor: www.habr.com