SLA, també conegut com a "acord de nivell de servei", és un acord de garantia entre el client i el proveïdor de serveis sobre el que el client rebrà en termes de servei. També estipula una compensació en cas d'inactivitat per culpa del proveïdor, etc. En essència, un SLA és una credencial amb l'ajuda de la qual un centre de dades o proveïdor d'allotjament convenç a un client potencial que serà tractat amablement de totes les maneres possibles. La qüestió és que podeu escriure tot el que vulgueu al SLA i els esdeveniments escrits en aquest document no es produeixen massa sovint. L'SLA està lluny de ser una pauta a l'hora de seleccionar un centre de dades i, certament, no hauríeu de confiar-hi.
Tots estem acostumats a signar algun tipus d'acords que imposen determinades obligacions. El SLA no és una excepció, normalment el document més irreal que es pugui imaginar. L'únic que probablement és més inútil és un NDA en jurisdiccions on el concepte de "secret comercial" no existeix realment. Però tot el problema és que el SLA no ajuda el client a escollir el proveïdor adequat, sinó que només llança pols als ulls.
Què escriuen els hosters amb més freqüència a la versió pública de l'SLA que mostren al públic? Bé, la primera línia és el terme "fiabilitat" de l'hoster: solen ser números del 98 al 99,999%. De fet, aquests números són només un bonic invent dels venedors. Hi havia una vegada, quan l'allotjament era jove i car, i els núvols eren només un somni per als especialistes (així com l'accés de banda ampla per a tothom), l'indicador de temps d'activitat de l'allotjament era extremadament important. Ara, quan tots els proveïdors utilitzen, més o menys, el mateix equip, s'asseuen a les mateixes xarxes troncals i ofereixen els mateixos paquets de serveis, l'indicador de temps de funcionament és absolutament insignificant.
Hi ha fins i tot un SLA "correcte"?
Per descomptat, hi ha versions ideals de SLA, però tots són documents no estàndard i es registren i conclouen manualment entre el client i el proveïdor. A més, aquest tipus de SLA sovint es refereix a algun tipus de treball contractat en lloc de serveis.
Què ha d'incloure un bon SLA? Per dir-ho TLDR, un bon SLA és un document que regula la relació entre dues entitats, que dóna a una de les parts (el client) el màxim control sobre el procés. És a dir, com funciona en el món real: hi ha un document que descriu els processos d'interacció global i regula les relacions entre les parts. Estableix límits, regles i en si mateix es converteix en una palanca d'influència que ambdues parts poden utilitzar al màxim. Així, gràcies a l'SLA correcte, el client pot simplement obligar el contractista a treballar com s'ha acordat, i ajuda al contractista a combatre els "desitjos" d'un client massa actiu que no estan justificats pel contracte. Sembla així: "El nostre SLA diu això i allò, sortiu d'aquí, fem tot com s'ha acordat".
És a dir, “el SLA correcte” = “un contracte adequat per a la prestació de serveis” i dóna control de la situació. Però això només és possible quan es treballa "com a igual".
El que està escrit al lloc web i el que espera en realitat són dues coses diferents
En general, tot el que parlarem més endavant són trucs de màrqueting típics i una prova d'atenció.
Si prenem hosts nacionals populars, una oferta és millor que l'altra: assistència 25/8, temps d'activitat del servidor el 99,9999999% del temps, un munt de centres de dades propis almenys a Rússia. Recordeu el punt sobre els centres de dades, hi tornarem una mica més tard. Mentrestant, parlem de les estadístiques ideals de tolerància a errors i de què s'enfronta una persona quan el seu servidor encara cau en el "0,0000001% de fallades".
Amb uns indicadors del 98% i superiors, qualsevol caiguda és un esdeveniment al límit de l'error estadístic. L'equip de treball i la connexió hi són o no hi són. Podeu utilitzar un hoster amb una qualificació de "fiabilitat" del 50% (segons el seu propi SLA) durant anys sense cap problema, o podeu "fallir" un cop al mes durant un parell de dies amb els nois que reclamen el 99,99%.
Quan arriba el moment de la caiguda (i us recordem, tothom cau algun dia), aleshores el client s'enfronta a una màquina corporativa interna anomenada "suport" i es treu a la llum l'acord de servei i el SLA. Què vol dir:
- El més probable és que durant les primeres quatre hores d'inactivitat no podreu presentar res, tot i que alguns hosters comencen a recalcular la tarifa (pagament de la compensació) des del moment de l'accident.
- Si el servidor no està disponible durant un període de temps més llarg, és possible que pugueu enviar una sol·licitud de recàlcul de la tarifa.
- I això sempre que el problema hagi sorgit per culpa del proveïdor.
- Si el teu problema va sorgir a causa d'un tercer (a l'autopista), llavors sembla que "ningú té la culpa" i quan el problema es soluciona és qüestió de la teva sort.
No obstant això, és important entendre que mai no s'accedeix a l'equip d'enginyeria, la majoria de vegades et detenen la primera línia de suport, que es correspon amb tu mentre els enginyers reals intenten solucionar la situació. Sona familiar?
Aquí, molta gent confia en SLA, que, segons sembla, hauria de protegir-vos d'aquestes situacions. Però, de fet, les empreses poques vegades superen els límits del seu propi document o són capaços de capgirar la situació de manera que minimitzin els seus propis costos. La tasca principal d'un SLA és calmar la vigilància i convèncer que fins i tot en cas d'una situació imprevista, "tot anirà bé". El segon propòsit d'un SLA és comunicar els principals punts crítics i donar marge de maniobra al proveïdor de serveis, és a dir, la capacitat d'atribuir una fallada a alguna cosa de la qual el proveïdor "no és responsable".
Al mateix temps, als grans clients, de fet, no els importa gens la compensació dins del SLA. La "compensació SLA" és un reemborsament de diners dins de la tarifa en proporció al temps d'inactivitat de l'equip, que mai cobrirà ni tan sols l'1% de les pèrdues monetàries i de reputació potencials. En aquest cas, és molt més important per al client que els problemes es resolguin el més aviat possible que una mena de "recàlcul de tarifes".
"Molts centres de dades arreu del món" és un motiu de preocupació
Hem situat la situació amb un gran nombre de centres de dades en un proveïdor de serveis en una categoria a part, perquè a més dels problemes de comunicació evidents descrits anteriorment, també sorgeixen problemes no evidents. Per exemple, el vostre proveïdor de serveis no té accés als "els seus" centres de dades.
En el nostre últim article , l'essència de la qual és la revenda de les capacitats d'altres persones sota la seva pròpia disfressa. La gran majoria dels hosts moderns que afirmen tenir "els seus propis centres de dades" a moltes regions són distribuïdors que utilitzen el model White Label. És a dir, físicament no tenen res a veure amb el centre de dades condicional a Suïssa, Alemanya o els Països Baixos.
Aquí sorgeixen col·lisions extremadament interessants. El vostre SLA amb el proveïdor de serveis encara funciona i és vàlid, però el proveïdor no pot influir d'alguna manera radicalment en la situació en cas d'accident. Ell mateix es troba en una posició dependent del seu propi proveïdor: el centre de dades, des del qual es van comprar els bastidors d'alimentació per a la seva revenda.
Per tant, si valoreu no només les belles paraules del contracte i el SLA sobre la fiabilitat i el servei, sinó també la capacitat del proveïdor de serveis per resoldre problemes ràpidament, haureu de treballar directament amb el propietari de les instal·lacions. De fet, això implica una interacció directa directament amb el centre de dades.
Per què no considerem les opcions quan molts DC poden pertànyer realment a una empresa? Bé, hi ha molt, molt poques empreses d'aquest tipus. És possible un, dos, tres centres de dades petits o un de gran. Però una dotzena de DC, la meitat dels quals a la Federació Russa i el segon a Europa, és gairebé impossible. Això vol dir que hi ha moltes més empreses distribuïdores de les que us imagineu. Aquí teniu un exemple senzill:
Estimar el nombre de centres de dades del servei de Google Cloud. Només n'hi ha sis a Europa. A Londres, Amsterdam, Brussel·les, Hèlsinki, Frankfurt i Zuric. És a dir, a tots els punts principals de la carretera. Perquè un centre de dades és car, complex i un projecte molt gran. Ara recordeu les empreses d'allotjament d'algun lloc de Moscou amb "una dotzena de centres de dades a tot Rússia i Europa".
Per descomptat, no hi ha bons proveïdors que tinguin socis en el programa White Label, n'hi ha prou, i ofereixen serveis del més alt nivell. Permeten llogar capacitat a la UE i a la Federació Russa simultàniament a través de la mateixa finestra del navegador, acceptar pagaments en rubles, no en moneda estrangera, etc. Però quan es produeixen els casos descrits a l'SLA, es converteixen exactament en els mateixos ostatges de la situació que tu.
Això ens recorda una vegada més que un SLA és inútil si no entenem l'estructura organitzativa i les capacitats del proveïdor.
Amb el resultat que
Un error del servidor és sempre un esdeveniment desagradable i li pot passar a qualsevol i a qualsevol lloc. La pregunta és quant de control sobre la situació voleu. Ara no hi ha massa proveïdors directes de capacitat al mercat, i si parlem de grans jugadors, aleshores posseeixen, relativament parlant, només un DC en algun lloc de Moscou d'una dotzena d'Europa a què es pot accedir.
Aquí, cada client ha de decidir per si mateix: trio la comoditat ara mateix o dedico temps i esforç a buscar un centre de dades en una ubicació acceptable a Rússia o Europa, on pugui col·locar el meu equip o comprar capacitat. En el primer cas, són adequades les solucions estàndard que hi ha actualment al mercat. En el segon, hauràs de suar.
En primer lloc, cal determinar si el venedor del servei és el propietari directe de les instal·lacions/centre de dades. Molts distribuïdors que utilitzen el model White Label fan tot el possible per dissimular el seu estat, i en aquest cas cal buscar alguns signes indirectes. Per exemple, si "els seus DC europeus" tenen alguns noms i logotips específics que difereixen del nom de l'empresa proveïdora. O si la paraula "socis" apareix en algun lloc. Socis = Marca Blanca en el 95% dels casos.
A continuació, heu de familiaritzar-vos amb l'estructura de l'empresa en si, o millor encara, mirar l'equip en persona. Entre els centres de dades, la pràctica d'excursions o, almenys, d'articles d'excursions al seu propi lloc web o bloc no és nova (hem escrit и ), on parlen del seu centre de dades amb fotos i descripcions detallades.
Amb molts centres de dades, podeu organitzar una visita personal a l'oficina i una mini-excursió al mateix DC. Allà podràs valorar el grau d'ordre, potser podràs comunicar-te amb algun dels enginyers. Està clar que ningú us donarà un recorregut per la producció si necessiteu un servidor per 300 RUB/mes, però si necessiteu una capacitat seriosa, és possible que el departament de vendes us conegui. Per exemple, fem aquestes excursions.
En qualsevol cas, cal utilitzar el sentit comú i les necessitats empresarials. Per exemple, si necessiteu una infraestructura distribuïda (alguns dels servidors es troben a la Federació Russa, l'altre a la UE), serà més fàcil i rendible utilitzar els serveis d'hosters que tinguin col·laboracions amb DC europeus mitjançant l'etiqueta blanca. model. Si tota la vostra infraestructura es concentrarà en un punt, és a dir, en un centre de dades, val la pena dedicar-vos una estona a trobar un proveïdor.
Perquè un SLA típic probablement no us ajudarà. Però treballar amb el propietari de les instal·lacions, i no amb un distribuïdor, accelerarà significativament la resolució de possibles problemes.
Font: www.habr.com