Slutt å tro at SLA vil redde deg. Det er nødvendig for å berolige og skape en falsk følelse av trygghet.

Slutt å tro at SLA vil redde deg. Det er nødvendig for å berolige og skape en falsk følelse av trygghet.

SLA, også kjent som «service-level agreement», er en garantiavtale mellom kunden og tjenesteleverandøren om hva kunden vil motta av service. Den fastsetter også kompensasjon ved driftsstans på grunn av feil fra leverandøren, og så videre. I hovedsak er en SLA en legitimasjon ved hjelp av hvilken et datasenter eller vertsleverandør overbeviser en potensiell klient om at han vil bli behandlet vennlig på alle mulige måter. Spørsmålet er at du kan skrive hva du vil i SLA, og hendelsene som er skrevet i dette dokumentet forekommer ikke for ofte. SLA er langt fra en retningslinje for valg av datasenter, og du bør absolutt ikke stole på det.

Vi er alle vant til å signere en slags avtaler som pålegger visse forpliktelser. SLA er intet unntak - vanligvis det mest urealistiske dokumentet man kan tenke seg. Det eneste som sannsynligvis er mer ubrukelig er en NDA i jurisdiksjoner der konseptet om en "forretningshemmelighet" egentlig ikke eksisterer. Men hele problemet er at SLA ikke hjelper oppdragsgiver med å velge riktig leverandør, men bare kaster støv i øynene.

Hva skriver hostere oftest i den offentlige versjonen av SLA som de viser til offentligheten? Vel, den første linjen er begrepet "pålitelighet" til hosteren - dette er vanligvis tall fra 98 til 99,999%. Faktisk er disse tallene bare en vakker oppfinnelse av markedsførere. En gang i tiden, da hosting var ungt og dyrt, og skyer bare var en drøm for spesialister (så vel som bredbåndstilgang for alle), var vertsoppetidsindikatoren ekstremt, ekstremt viktig. Nå, når alle leverandører bruker, pluss eller minus, det samme utstyret, sitter på samme stamnettverk og tilbyr de samme tjenestepakkene, er oppetidsindikatoren helt umerkelig.

Finnes det til og med en "riktig" SLA?

Selvfølgelig finnes det ideelle versjoner av SLA, men alle er ikke-standard dokumenter og registreres og avsluttes manuelt mellom oppdragsgiver og leverandør. Dessuten dreier denne typen SLA oftest en slags kontraktsarbeid i stedet for tjenester.

Hva bør en god SLA inneholde? For å si det TLDR, en god SLA er et dokument som regulerer forholdet mellom to enheter, som gir en av partene (kunden) maksimal kontroll over prosessen. Det vil si hvordan det fungerer i den virkelige verden: det finnes et dokument som beskriver globale samhandlingsprosesser og regulerer relasjonene mellom partene. Det setter grenser, regler, og blir i seg selv en innflytelsesspak som begge parter kan bruke til det fulle. Dermed, takket være riktig SLA, kan kunden ganske enkelt tvinge entreprenøren til å jobbe som avtalt, og det hjelper entreprenøren til å bekjempe "ønsker" til en altfor aktiv klient som ikke er rettferdiggjort av kontrakten. Det ser slik ut: "Vår SLA sier det og det, kom deg ut herfra, vi gjør alt som avtalt."

Det vil si "den riktige SLA" = "en tilstrekkelig kontrakt for levering av tjenester" og gir kontroll over situasjonen. Men dette er bare mulig når du jobber "som likeverdige".

Hva som står på nettsiden og hva som venter i virkeligheten er to forskjellige ting

Generelt er alt vi vil diskutere videre typiske markedsføringstriks og en test av oppmerksomhet.

Hvis vi tar populære innenlandske hostere, så er det ene tilbudet bedre enn det andre: 25/8-støtte, serveroppetid 99,9999999 % av tiden, en haug med egne datasentre i det minste i Russland. Husk poenget om datasentre, vi kommer tilbake til det litt senere. I mellomtiden, la oss snakke om ideell feiltoleransestatistikk og hva en person står overfor når serveren hans fortsatt faller inn under "0,0000001% av feilene."

Med indikatorer på 98 % og over, er ethvert fall en hendelse på grensen til statistisk feil. Arbeidsutstyr og tilkobling er enten der eller ikke. Du kan bruke en hoster med en "pålitelighet"-vurdering på 50% (i henhold til dens egen SLA) i årevis uten et eneste problem, eller du kan "feile" en gang i måneden i et par dager med gutta som hevder 99,99%.

Når falløyeblikket kommer (og vi minner deg om at alle faller en dag), så står klienten overfor en intern bedriftsmaskin kalt "support", og serviceavtalen og SLA blir brakt frem i lyset. Hva betyr det:

  • Mest sannsynlig, for de første fire timene med nedetid vil du ikke kunne presentere noe i det hele tatt, selv om noen hostere begynner å beregne tariffen (utbetaling av kompensasjon) på nytt fra øyeblikket av krasjet.
  • Hvis serveren er utilgjengelig over en lengre periode, kan det hende du kan sende inn en forespørsel om omberegning av tariff.
  • Og dette forutsatt at problemet oppsto på grunn av feil fra leverandøren.
  • Hvis problemet ditt oppsto på grunn av en tredjepart (på motorveien), virker det som "ingen har skylden", og når problemet er løst er et spørsmål om flaksen din.

Det er imidlertid viktig å forstå at du aldri får tilgang til ingeniørteamet, oftest blir du stoppet av den første støttelinjen, som korresponderer med deg mens de virkelige ingeniørene prøver å fikse situasjonen. Høres kjent ut?

Her er det mange som stoler på SLA, som ser ut til å beskytte deg mot slike situasjoner. Men faktisk går selskaper sjelden utover grensene for sitt eget dokument eller klarer å snu situasjonen på en slik måte at de minimerer sine egne kostnader. Den primære oppgaven til en SLA er å svekke årvåkenhet og overbevise at selv i tilfelle en uforutsett situasjon, "alt vil være bra." Det andre formålet med en SLA er å kommunisere de viktigste kritiske punktene og gi tjenesteleverandøren manøvreringsrom, det vil si muligheten til å tilskrive en feil til noe som leverandøren "ikke er ansvarlig for."

Samtidig bryr seg faktisk ikke store kunder i det hele tatt om kompensasjon innenfor SLA. "SLA-kompensasjon" er en refusjon av penger innenfor tariffen i forhold til utstyrets nedetid, som aldri vil dekke til og med 1 % av potensielle penge- og omdømmetap. I dette tilfellet er det mye viktigere for klienten at problemene løses så snart som mulig enn en form for «tariffomberegning».

"Mange datasentre rundt om i verden" er en grunn til bekymring

Vi har plassert situasjonen med et stort antall datasentre hos en tjenesteleverandør i en egen kategori, for i tillegg til de åpenbare kommunikasjonsproblemene beskrevet ovenfor, oppstår det også uopplagte problemer. Tjenesteleverandøren din har for eksempel ikke tilgang til "deres" datasentre.

I vår siste artikkel vi skrev om typene tilknyttede programmer og nevnte "White Label"-modellen, hvis essens er videresalg av andres kapasitet under sin egen dekke. Det store flertallet av moderne hostere som hevder å ha "sine egne datasentre" i mange regioner er forhandlere som bruker White Label-modellen. Det vil si at de fysisk ikke har noe med det betingede datasenteret i Sveits, Tyskland eller Nederland å gjøre.

Det oppstår ekstremt interessante kollisjoner her. Din SLA hos tjenesteleverandøren fungerer fortsatt og er gyldig, men leverandøren er ikke i stand til på en eller annen måte å påvirke situasjonen radikalt i tilfelle en ulykke. Selv er han i en avhengig posisjon av sin egen leverandør – datasenteret, som strømstativene ble kjøpt fra for videresalg.

Så hvis du verdsetter ikke bare vakre formuleringer i kontrakten og SLA om pålitelighet og service, men også tjenesteleverandørens evne til raskt å løse problemer, bør du jobbe direkte med eieren av anleggene. Dette innebærer faktisk direkte interaksjon direkte med datasenteret.

Hvorfor vurderer vi ikke alternativer når mange DC-er faktisk kan tilhøre ett selskap? Vel, det er veldig, veldig få slike selskaper. Ett, to, tre små datasentre eller ett stort er mulig. Men et dusin DC-er, hvorav halvparten er i Den russiske føderasjonen, og den andre i Europa, er nesten umulig. Dette betyr at det er mange flere forhandlerselskaper enn du kanskje forestiller deg. Her er et enkelt eksempel:

Slutt å tro at SLA vil redde deg. Det er nødvendig for å berolige og skape en falsk følelse av trygghet.
Anslå antall Google Cloud-tjenestedatasentre. Det er bare seks av dem i Europa. I London, Amsterdam, Brussel, Helsinki, Frankfurt og Zürich. Det vil si på alle hovedveipunkter. Fordi et datasenter er dyrt, komplekst og et veldig stort prosjekt. Husk nå vertsselskapene fra et sted i Moskva med "et dusin datasentre over hele Russland og Europa."

Det er selvfølgelig ingen gode leverandører som har partnere i White Label-programmet, det er nok, og de leverer tjenester på høyeste nivå. De gjør det mulig å leie kapasitet i EU og Den russiske føderasjonen samtidig gjennom samme nettleservindu, akseptere betaling i rubler, ikke i utenlandsk valuta, og så videre. Men når tilfellene beskrevet i SLA oppstår, blir de nøyaktig de samme gislene for situasjonen som deg.

Dette minner oss nok en gang om at en SLA er ubrukelig hvis du ikke har forståelse for leverandørens organisasjonsstruktur og muligheter.

Med det resultat at

Et serverkrasj er alltid en ubehagelig hendelse, og det kan skje hvem som helst, hvor som helst. Spørsmålet er hvor mye kontroll over situasjonen du ønsker. Nå er det ikke så mange direkte leverandører av kapasitet på markedet, og hvis vi snakker om store aktører, så eier de relativt sett bare én DC et sted i Moskva av et dusin i hele Europa som du har tilgang til.

Her må hver klient selv bestemme: velger jeg komfort akkurat nå eller bruker tid og krefter på å søke etter et datasenter på et akseptabelt sted i Russland eller Europa, hvor jeg kan plassere utstyret mitt eller kjøpe kapasitet. I det første tilfellet er standardløsninger som for tiden er på markedet egnet. I den andre må du svette.

Først av alt er det nødvendig å fastslå om tjenesteselgeren er den direkte eieren av anleggene/datasenteret. Mange forhandlere som bruker White Label-modellen prøver sitt beste for å skjule statusen deres, og i dette tilfellet må du se etter noen indirekte tegn. For eksempel hvis "deres europeiske DC-er" har noen spesifikke navn og logoer som avviker fra navnet på leverandørselskapet. Eller hvis ordet "partnere" dukker opp et sted. Partnere = White Label i 95 % av tilfellene.

Deretter må du gjøre deg kjent med strukturen til selve selskapet, eller enda bedre, se på utstyret personlig. Blant datasentre er praksisen med utflukter eller i det minste ekskursjonsartikler på deres egen nettside eller blogg ikke ny (vi skrev slike tid и два), hvor de snakker om datasenteret sitt med bilder og detaljerte beskrivelser.

Med mange datasentre kan du arrangere et personlig besøk på kontoret og en mini-utflukt til selve DC. Der kan du vurdere graden av orden, kanskje vil du kunne kommunisere med en av ingeniørene. Det er klart at ingen vil gi deg en omvisning i produksjonen hvis du trenger en server for 300 RUB/måned, men hvis du trenger seriøs kapasitet, kan salgsavdelingen godt møte deg. For eksempel gjennomfører vi slike ekskursjoner.

I alle fall bør sunn fornuft og forretningsbehov brukes. For eksempel, hvis du trenger en distribuert infrastruktur (noen av serverne er i Russland, den andre i EU), vil det være enklere og mer lønnsomt å bruke tjenestene til vertsleverandører som har partnerskap med europeiske DC-er som bruker White Label modell. Hvis hele infrastrukturen din vil være konsentrert på ett punkt, det vil si i ett datasenter, så er det verdt å bruke litt tid på å finne en leverandør.

Fordi en typisk SLA mest sannsynlig ikke vil hjelpe deg. Men å jobbe med eieren av fasilitetene, og ikke en forhandler, vil gjøre løsningen av mulige problemer betydelig raskere.

Kilde: www.habr.com

Legg til en kommentar