Lad være med at tro, at SLA vil redde dig. Det er nødvendigt for at berolige og skabe en falsk tryghed.

Lad være med at tro, at SLA vil redde dig. Det er nødvendigt for at berolige og skabe en falsk tryghed.

SLA, også kendt som "service-level agreement", er en garantiaftale mellem kunden og serviceudbyderen om, hvad kunden vil modtage af service. Det fastsætter også kompensation i tilfælde af nedetid på grund af leverandørens fejl, og så videre. I bund og grund er en SLA en legitimation, ved hjælp af hvilken et datacenter eller hostingudbyder overbeviser en potentiel klient om, at han vil blive behandlet venligt på enhver mulig måde. Spørgsmålet er, at du kan skrive alt, hvad du vil i SLA'en, og de begivenheder, der er skrevet i dette dokument, forekommer ikke for ofte. SLA er langt fra en rettesnor i valg af datacenter, og du bør bestemt ikke stole på det.

Vi er alle vant til at underskrive en eller anden form for aftaler, der pålægger visse forpligtelser. SLA'en er ingen undtagelse - normalt det mest urealistiske dokument, man kan forestille sig. Det eneste, der nok er mere ubrugeligt, er en NDA i jurisdiktioner, hvor begrebet "forretningshemmelighed" ikke rigtig eksisterer. Men hele problemet er, at SLA'en ikke hjælper kunden med at vælge den rigtige leverandør, men kun kaster støv i øjnene.

Hvad skriver hostere oftest i den offentlige version af SLA'en, som de viser til offentligheden? Nå, den første linje er udtrykket "pålidelighed" for hosteren - disse er normalt tal fra 98 til 99,999%. Faktisk er disse tal bare en smuk opfindelse af marketingfolk. Engang, hvor hosting var ungt og dyrt, og skyer kun var en drøm for specialister (såvel som bredbåndsadgang for alle), var hosting-oppetidsindikatoren ekstrem, ekstrem vigtig. Nu, hvor alle leverandører bruger, plus eller minus, det samme udstyr, sidder på det samme backbone-netværk og tilbyder de samme servicepakker, er oppetidsindikatoren helt umærkelig.

Er der overhovedet en "korrekt" SLA?

Selvfølgelig er der ideelle versioner af SLA, men alle er ikke-standarddokumenter og registreres og indgås manuelt mellem kunden og leverandøren. Desuden vedrører denne type SLA oftest en form for kontraktarbejde frem for tjenester.

Hvad skal en god SLA indeholde? For at sige det TLDR, er en god SLA et dokument, der regulerer forholdet mellem to enheder, hvilket giver en af ​​parterne (kunden) maksimal kontrol over processen. Det vil sige, hvordan det fungerer i den virkelige verden: Der er et dokument, der beskriver globale interaktionsprocesser og regulerer forholdet mellem parterne. Det sætter grænser, regler og bliver i sig selv en indflydelsesstang, som begge parter kan bruge fuldt ud. Takket være den korrekte SLA kan kunden således blot tvinge entreprenøren til at arbejde som aftalt, og det hjælper entreprenøren med at bekæmpe en alt for aktiv bygherres "ønsker", som ikke er begrundet i kontrakten. Det ser sådan ud: "Vores SLA siger det og det, kom ud herfra, vi gør alt som aftalt."

Det vil sige "den korrekte SLA" = "en passende kontrakt for levering af tjenester" og giver kontrol over situationen. Men det er kun muligt, når man arbejder "som ligestillede".

Hvad der står på hjemmesiden og hvad der venter i virkeligheden er to forskellige ting

Generelt er alt, hvad vi vil diskutere yderligere, typiske marketingtricks og en test af opmærksomhed.

Hvis vi tager populære indenlandske hostere, så er det ene tilbud bedre end det andet: 25/8 support, serveroppetid 99,9999999% af tiden, en masse af deres egne datacentre i det mindste i Rusland. Husk punktet om datacentre, vi vender tilbage til det lidt senere. Lad os i mellemtiden tale om ideelle fejltolerancestatistikker og hvad en person står over for, når hans server stadig falder ind under "0,0000001% af fejlene."

Med indikatorer på 98 % og derover er ethvert fald en hændelse på randen af ​​statistiske fejl. Arbejdsudstyr og forbindelse er enten der, eller også er de ikke. Du kan bruge en hoster med en "pålidelighed"-vurdering på 50% (ifølge dens egen SLA) i årevis uden et eneste problem, eller du kan "fejle" en gang om måneden i et par dage med de fyre, der hævder 99,99%.

Når faldøjeblikket kommer (og vi minder dig om, at alle falder en dag), så står kunden over for en intern virksomhedsmaskine kaldet "support", og serviceaftalen og SLA bliver bragt frem i lyset. Hvad betyder det:

  • Mest sandsynligt vil du i de første fire timers nedetid ikke være i stand til at præsentere noget overhovedet, selvom nogle hostere begynder at genberegne taksten (betaling af kompensation) fra det øjeblik, hvor styrtet skete.
  • Hvis serveren ikke er tilgængelig i længere tid, kan du muligvis indsende en anmodning om en takstgenberegning.
  • Og dette er forudsat, at problemet opstod på grund af leverandørens skyld.
  • Hvis dit problem er opstået på grund af en tredjepart (på motorvejen), så ser det ud til, at "ingen er skyldig", og hvornår problemet er løst, er et spørgsmål om dit held.

Det er dog vigtigt at forstå, at du aldrig får adgang til ingeniørteamet, oftest bliver du stoppet af den første supportlinje, som korresponderer med dig, mens de rigtige ingeniører forsøger at rette op på situationen. Lyder det bekendt?

Her er mange mennesker afhængige af SLA, som, det ser ud til, burde beskytte dig mod sådanne situationer. Men faktisk går virksomheder sjældent ud over grænserne for deres eget dokument eller er i stand til at vende situationen på en sådan måde, at de minimerer deres egne omkostninger. Den primære opgave for en SLA er at dæmpe årvågenhed og overbevise om, at selv i tilfælde af en uforudset situation, "alt vil være godt." Det andet formål med en SLA er at kommunikere de vigtigste kritiske punkter og give tjenesteudbyderen spillerum, det vil sige evnen til at tilskrive en fejl til noget, som leverandøren "ikke er ansvarlig for."

Samtidig er store kunder faktisk slet ikke ligeglade med kompensation inden for SLA. "SLA-kompensation" er en tilbagebetaling af penge inden for tariffen i forhold til udstyrsnedetid, som aldrig vil dække selv 1 % af potentielle penge- og omdømmetab. I dette tilfælde er det meget vigtigere for kunden, at problemerne bliver løst så hurtigt som muligt end en form for "tarif-genberegning."

"Mange datacentre rundt om i verden" giver anledning til bekymring

Vi har placeret situationen med en lang række datacentre hos en tjenesteudbyder i en særskilt kategori, fordi der udover de åbenlyse kommunikationsproblemer beskrevet ovenfor også opstår uoplagte problemer. For eksempel har din tjenesteudbyder ikke adgang til "deres" datacentre.

I vores sidste artikel vi skrev om typerne af affiliate programmer og nævnte "White Label"-modellen, hvis essens er videresalg af andre menneskers kapaciteter under eget dække. Langt de fleste moderne hostere, der hævder at have "deres egne datacentre" i mange regioner, er forhandlere, der bruger White Label-modellen. Det vil sige, at de fysisk ikke har noget at gøre med det betingede datacenter i Schweiz, Tyskland eller Holland.

Her opstår ekstremt interessante kollisioner. Din SLA hos tjenesteudbyderen fungerer stadig og er gyldig, men leverandøren er ikke i stand til på en eller anden måde radikalt at påvirke situationen i tilfælde af en ulykke. Han er selv i en afhængig stilling af sin egen leverandør - datacentret, hvorfra strømstativerne er købt til videresalg.

Værdsætter du således ikke kun smukke formuleringer i kontrakten og SLA om pålidelighed og service, men også serviceudbyderens evne til hurtigt at løse problemer, bør du arbejde direkte med ejeren af ​​faciliteterne. Faktisk involverer dette direkte interaktion direkte med datacentret.

Hvorfor overvejer vi ikke muligheder, når mange DC'er faktisk kan tilhøre én virksomhed? Tja, der er meget, meget få sådanne virksomheder. Et, to, tre små datacentre eller et stort er muligt. Men et dusin DC'er, hvoraf halvdelen er i Den Russiske Føderation, og den anden i Europa, er næsten umuligt. Det betyder, at der er mange flere forhandlervirksomheder, end du måske forestiller dig. Her er et simpelt eksempel:

Lad være med at tro, at SLA vil redde dig. Det er nødvendigt for at berolige og skabe en falsk tryghed.
Estimer antallet af Google Cloud-tjenestedatacentre. Der er kun seks af dem i Europa. I London, Amsterdam, Bruxelles, Helsinki, Frankfurt og Zürich. Det vil sige på alle hovedvejspunkter. Fordi et datacenter er dyrt, komplekst og et meget stort projekt. Husk nu hostingvirksomhederne fra et sted i Moskva med "et dusin datacentre i hele Rusland og Europa."

Der er selvfølgelig ingen gode leverandører, der har partnere i White Label-programmet, der er nok, og de leverer tjenester på højeste niveau. De gør det muligt at leje kapacitet i EU og Den Russiske Føderation samtidigt gennem det samme browservindue, acceptere betaling i rubler, ikke i udenlandsk valuta, og så videre. Men når de tilfælde, der er beskrevet i SLA'en, opstår, bliver de nøjagtig de samme gidsler af situationen som dig.

Dette minder os endnu engang om, at en SLA er ubrugelig, hvis du ikke har en forståelse for leverandørens organisationsstruktur og muligheder.

Således at

Et servernedbrud er altid en ubehagelig begivenhed, og det kan ske for alle, hvor som helst. Spørgsmålet er, hvor meget kontrol over situationen, du ønsker. Nu er der ikke for mange direkte leverandører af kapacitet på markedet, og hvis vi taler om store spillere, så ejer de relativt set kun én DC et sted i Moskva ud af et dusin i hele Europa, som du kan få adgang til.

Her må hver kunde selv bestemme: skal jeg vælge komfort lige nu eller bruge tid og kræfter på at søge efter et datacenter på et acceptabelt sted i Rusland eller Europa, hvor jeg kan placere mit udstyr eller købe kapacitet. I det første tilfælde er standardløsninger, der i øjeblikket er på markedet, egnede. I den anden bliver du nødt til at svede.

Først og fremmest er det nødvendigt at fastslå, om servicesælgeren er den direkte ejer af faciliteterne/datacentret. Mange forhandlere, der bruger White Label-modellen, prøver deres bedste for at skjule deres status, og i dette tilfælde skal du kigge efter nogle indirekte tegn. For eksempel hvis "deres europæiske DC'er" har nogle specifikke navne og logoer, der adskiller sig fra navnet på leverandørvirksomheden. Eller hvis ordet "partnere" optræder et sted. Partnere = White Label i 95 % af tilfældene.

Dernæst skal du sætte dig ind i selve virksomhedens struktur, eller endnu bedre, se på udstyret personligt. Blandt datacentre er praksis med udflugter eller i det mindste udflugtsartikler på deres egen hjemmeside eller blog ikke ny (vi skrev f.eks. tid и два), hvor de fortæller om deres datacenter med billeder og detaljerede beskrivelser.

Med mange datacentre kan du arrangere et personligt besøg på kontoret og en mini-udflugt til selve DC. Der kan du vurdere graden af ​​orden, måske vil du kunne kommunikere med en af ​​ingeniørerne. Det er klart, at ingen vil give dig en rundvisning i produktionen, hvis du har brug for én server til 300 RUB/måned, men hvis du har brug for seriøs kapacitet, så kan salgsafdelingen godt møde dig. For eksempel gennemfører vi sådanne udflugter.

Under alle omstændigheder bør sund fornuft og forretningsmæssige behov bruges. For eksempel, hvis du har brug for en distribueret infrastruktur (nogle af serverne er i Den Russiske Føderation, den anden i EU), vil det være lettere og mere rentabelt at bruge tjenester fra hostere, der har partnerskaber med europæiske DC'er, der bruger White Label model. Hvis hele din infrastruktur vil være koncentreret på et tidspunkt, altså i ét datacenter, så er det værd at bruge lidt tid på at finde en leverandør.

Fordi en typisk SLA højst sandsynligt ikke vil hjælpe dig. Men at arbejde med ejeren af ​​faciliteterne og ikke en forhandler vil fremskynde løsningen af ​​mulige problemer markant.

Kilde: www.habr.com

Tilføj en kommentar