SLA, "zerbitzu-mailako akordioa" izenez ere ezagutzen dena, bezeroaren eta zerbitzu-hornitzailearen arteko berme-akordioa da, bezeroak zerbitzu moduan jasoko duenari buruz. Era berean, hornitzailearen erruagatik geldiune-denbora gertatuz gero kalte-ordainak ezartzen ditu, eta abar. Funtsean, SLA bat kredentzial bat da, zeinaren laguntzarekin datu-zentro edo ostalaritza-hornitzaile batek bezero potentzial bat modu egokian tratatuko duela konbentzitzen duela. Galdera da SLAn nahi duzun guztia idatz dezakezula, eta dokumentu honetan idatzitako gertaerak ez dira askotan gertatzen. SLA datu-zentro bat hautatzeko jarraibidetik urrun dago eta, zalantzarik gabe, ez zenuke horretan fidatu behar.
Denok ohituta gaude betebehar batzuk ezartzen dituzten hitzarmen mota batzuk sinatzera. SLA ez da salbuespena - normalean imajina daitekeen dokumenturik irrealena. Ziurrenik alferrikakoa den gauza bakarra NDA bat da "sekretu komertzial" kontzeptua benetan existitzen ez den jurisdikzioetan. Baina arazo osoa da SLAk ez diola bezeroari laguntzen hornitzaile egokia aukeratzen, baizik eta hautsa begietara botatzen duela.
Zer idazten dute gehien ostalariek publikoari erakusten dioten SLAren bertsio publikoan? Beno, lehen lerroa ostalariaren "fidagarritasuna" terminoa da - normalean 98tik 99,999ra bitarteko zenbakiak dira. Izan ere, zenbaki hauek merkatarien asmakizun eder bat besterik ez dira. Garai batean, hostinga gaztea eta garestia zenean, eta hodeiak espezialistentzako amets bat besterik ez zirenean (baita banda zabaleko sarbidea denontzat ere), hostingaren funtzionamenduaren adierazlea oso, oso garrantzitsua zen. Orain, hornitzaile guztiek, gehi edo ken, ekipamendu bera erabiltzen dutenean, bizkarrezurreko sare berdinetan esertzen direnean eta zerbitzu pakete berdinak eskaintzen dituztenean, denboraren adierazlea guztiz ez da nabarmena.
Ba al dago SLA "zuzena" ere?
Jakina, SLAren bertsio idealak daude, baina guztiak ez-estandar dokumentuak dira eta bezeroaren eta hornitzailearen artean eskuz erregistratu eta egiten dira. Gainera, SLA mota hau zerbitzuei baino gehiago kontratu-lanei buruzkoa da gehienetan.
Zer sartu behar du SLA on batek? TLDR esateko, SLA on bat bi entitateen arteko harremana arautzen duen dokumentua da, eta horrek alderdietako bati (bezeroari) prozesuaren gaineko kontrol handiena ematen dio. Hau da, nola funtzionatzen duen mundu errealean: interakzio prozesu globalak deskribatzen dituen eta alderdien arteko harremanak arautzen dituen dokumentu bat dago. Mugak, arauak ezartzen ditu, eta berez bi aldeek ahalik eta gehien erabil dezaketen eragin-palanka bilakatzen da. Horrela, SLA zuzenari esker, bezeroak kontratistak hitzartutako moduan lan egitera behartu besterik ez du egin, eta kontratuak justifikatzen ez dituen bezero aktiboegi baten "nahiei" aurre egiten laguntzen dio. Honela dirudi: "Gure SLAk hau eta bestea esaten du, alde egin hemendik, dena hitzartutako moduan egiten dugu".
Hau da, “SLA zuzena” = “zerbitzuak emateko kontratu egokia” eta egoeraren kontrola ematen du. Baina hori "berdin gisa" lan egiten denean bakarrik da posible.
Webgunean idatzitakoa eta errealitatean zain dagoena bi gauza ezberdin dira
Oro har, gehiago eztabaidatuko dugun guztia marketing trikimailu tipikoak eta arreta proba bat dira.
Etxeko ostalari ezagunak hartzen baditugu, eskaintza bat bestea baino hobea da: 25/8 laguntza, zerbitzariaren funtzionamendu-denbora denboraren % 99,9999999, euren datu-zentro mordoa gutxienez Errusian. Mesedez, gogoratu datu-zentroei buruzko puntua, beranduago itzuliko gara. Bitartean, hitz egin dezagun hutsegite-tolerantzia estatistiko idealei buruz eta zerbitzariak oraindik "hutseten % 0,0000001"-ean jaisten denean pertsona batek jasaten duenari buruz.
% 98ko eta hortik gorako adierazleekin, edozein jaitsiera akats estatistikorako zorian dagoen gertaera da. Lan-ekipoa eta konexioa hor daude edo ez daude. % 50eko "fidagarritasuna" balorazioa duen ostalari bat (bere SLAren arabera) urtez erabil dezakezu arazorik gabe, edo hilean behin "porrot" egin dezakezu egun pare batean % 99,99 erreklamatzen duten mutilekin.
Erortzeko unea iristen denean (eta, gogorarazten dizugu, denak noizbait erortzen direla), orduan bezeroak "laguntza" izeneko barne-makina korporatibo baten aurrean jartzen du eta zerbitzu-akordioa eta SLA argitaratzen dira. Zer esan nahi du:
- Seguruenik, geldialdiaren lehen lau orduetan ezingo duzu ezer aurkeztu, nahiz eta ostalari batzuk istripuaren momentutik tarifa berriro kalkulatzen hasten diren (kalte-ordaina ordaintzea).
- Zerbitzaria denbora-tarte luzeagoan erabilgarri ez badago, baliteke tarifak birkalkulatzeko eskaera bidaltzea.
- Eta hori baldin eta arazoa hornitzailearen erruagatik sortu dela.
- Zure arazoa hirugarren baten ondorioz sortu bada (autobidean), badirudi "inork ez duela errurik" eta arazoa konpontzen denean zure zorte kontua da.
Hala eta guztiz ere, garrantzitsua da ulertzea inoiz ez duzula ingeniaritza taldean sartzea, gehienetan lehen laguntza-lerroak gelditzen zaituzte, zurekin harremanetan jartzen direnak benetako ingeniariak egoera konpontzen saiatzen diren bitartean. Ezaguna al zaizu?
Hemen, jende askok SLAn oinarritzen du, eta, antza, horrelako egoeretatik babestu beharko zaitu. Baina, izatez, enpresek oso gutxitan doaz beren dokumentuaren mugetatik haratago edo gai dira egoerari buelta emateko, beren kostuak gutxitzeko moduan. SLA baten zeregin nagusia zaintza baretzea eta ustekabeko egoeraren bat gertatuz gero ere "dena ondo egongo dela" sinestea da. SLA baten bigarren helburua puntu kritiko nagusiak jakinaraztea eta zerbitzu hornitzaileari maniobrarako tartea ematea da, hau da, hornitzailea "erantzule ez den" hutsegite bat egozteko gaitasuna.
Aldi berean, bezero handiei, izan ere, ez zaie batere axola SLAren barruan kalte-ordainak. "SLA konpentsazioa" tarifaren barruan dagoen dirua itzultzea da ekipoen geldialdiaren proportzioan, eta horrek ez du inoiz estaliko diru- eta ospe-galeren potentzialaren %1 ere. Kasu honetan, bezeroarentzat askoz ere garrantzitsuagoa da arazoak ahalik eta azkarren konpontzea "tarifak birkalkulatzea" baino.
"Mundu osoko datu-zentro asko" kezkatzeko arrazoia da
Zerbitzu-hornitzaile bateko datu-zentro ugariren egoera aparteko kategoria batean kokatu dugu, goian azaldutako komunikazio-arazo nabariez gain, agerikoak ez diren arazoak ere sortzen direlako. Adibidez, zure zerbitzu-hornitzaileak ez du "bere" datu-zentroetarako sarbiderik.
Gure azken artikuluan , zeinaren funtsa besteen gaitasunak bere itxurapean birsaltzea da. Eskualde askotan "bere datu-zentroak" dituztela dioten ostalari modernoen gehiengo zabala White Label eredua erabiltzen duten saltzaileak dira. Hau da, fisikoki ez dute zerikusirik Suitza, Alemania edo Herbehereetako baldintzapeko datu-zentroarekin.
Talka oso interesgarriak sortzen dira hemen. Zerbitzu-hornitzailearekin duzun SLA oraindik funtzionatzen du eta balio du, baina hornitzaileak ezin du istripu bat gertatuz gero egoeran nolabait errotik eragiteko. Bera bere hornitzailearen menpeko posizioan dago: datu-zentroa, bertatik erosi ziren potentzia-rack-ak birsaltzeko.
Horrela, fidagarritasunari eta zerbitzuari buruzko kontratuan eta SLAn hitz ederrak ez ezik, zerbitzu hornitzaileak arazoak azkar konpontzeko duen gaitasuna ere baloratzen badituzu, instalazioen jabearekin zuzenean lan egin beharko zenuke. Izan ere, horrek datu-zentroarekin zuzeneko interakzioa dakar.
Zergatik ez ditugu aukerak kontuan hartzen DC asko enpresa batekoak izan daitezkeenean? Bada, oso-oso enpresa gutxi daude. Bat, bi, hiru datu-zentro txiki edo handi bat posible da. Baina dozena bat DC, erdia Errusiako Federazioan eta bigarrena Europan, ia ezinezkoa da. Horrek esan nahi du imajina dezakezuna baino askoz enpresa saltzaile gehiago daudela. Hona hemen adibide sinple bat:
Kalkulatu Google Cloud zerbitzuko datu-zentroen kopurua. Europan sei besterik ez daude. Londresen, Amsterdamen, Bruselan, Helsinkin, Frankfurten eta Zurichen. Hau da, autobide puntu nagusi guztietan. Datu zentro bat garestia, konplexua eta oso proiektu handia delako. Orain gogoratu Moskuko nonbaiteko ostalaritza enpresak "Errusia eta Europan zehar dozena bat datu-zentro" dituztenak.
Ez dago, noski, Etiketa Zuria programan bazkideak dituen hornitzaile onak, nahikoak daude, eta maila goreneko zerbitzuak eskaintzen dituzte. EBn eta Errusiar Federazioan aldi berean edukiera alokatzea ahalbidetzen dute arakatzailearen leiho beraren bidez, ordainketa errublotan onartzen dute, ez atzerriko monetan, etab. Baina SLAn deskribatutako kasuak gertatzen direnean, zure egoeraren bahitu berdinak bihurtzen dira.
Honek berriro ere gogorarazten digu SLA batek ez duela ezertarako balio hornitzailearen antolaketa-egitura eta gaitasunak ulertzen ez badituzu.
Emaitza duten
Zerbitzariaren hutsegite bat gertaera desatsegina da beti eta edonori gerta dakioke, edonon. Kontua da egoeraren gaineko zenbat kontrola nahi duzun. Orain ez dago ahalmenaren hornitzaile zuzen gehiegi merkatuan, eta jokalari handiei buruz hitz egiten badugu, orduan, nahiko hitz eginda, DC bakarra dute nonbait Moskuko Europa osoko dozena batetik sar zaitezke.
Hemen, bezero bakoitzak bere kabuz erabaki behar du: erosotasuna aukeratzen dudan une honetan ala denbora eta esfortzua ematen al dut Errusian edo Europan toki onargarri batean datu-zentro bat bilatzen, non nire ekipamendua jarri edo edukiera erosteko. Lehenengo kasuan, gaur egun merkatuan dauden soluzio estandarrak egokiak dira. Bigarrenean, izerditan egin beharko duzu.
Lehenik eta behin, zerbitzu-saltzailea instalazioen/datu-zentroaren jabe zuzena den zehaztu behar da. Marka Zuriaren eredua erabiltzen duten saltzaile asko beren egoera mozorrotzen saiatzen dira, eta kasu honetan zeharkako seinale batzuk bilatu behar dituzu. Esaterako, "euren Europako DCek" enpresa hornitzailearen izenetik desberdinak diren izen eta logotipo zehatz batzuk badituzte. Edo nonbait "bazkide" hitza agertzen bada. Bazkideak = Marka Zuria kasuen %95ean.
Ondoren, enpresaren egitura bera ezagutu behar duzu, edo hobeto esanda, ekipamendua pertsonalki begiratu. Datu-zentroen artean, txangoen praktika edo, gutxienez, txangoen artikuluak euren webgunean edo blogean praktikatzea ez da berria (hala idatzi genuen и ), non euren datu-zentroari buruz hitz egiten duten argazkiekin eta deskribapen zehatzekin.
Datu-zentro askorekin, bulegora bisita pertsonal bat eta DCra bertara joateko mini-txango bat antolatu dezakezu. Bertan ordenaren maila ebaluatu dezakezu, agian ingeniariren batekin komunikatzeko aukera izango duzu. Argi dago inork ez dizula produkzioan bira bat emango 300 RUB/hileko zerbitzari bat behar baduzu, baina ahalmen handia behar baduzu, salmenta-sailak ondo ezagutuko zaitu. Adibidez, horrelako txangoak egiten ditugu.
Nolanahi ere, zentzua eta negozio beharrak erabili behar dira. Adibidez, banatutako azpiegitura bat behar baduzu (zerbitzari batzuk Errusiako Federazioan daude, bestea EBn), errazagoa eta errentagarriagoa izango da Europako DCekin lankidetzak dituzten ostalarien zerbitzuak erabiltzea Marka Zuria erabiliz. eredua. Zure azpiegitura osoa une batean kontzentratzen bada, hau da, datu-zentro batean, merezi du denbora pixka bat hornitzaile bat aurkitzeko.
SLA tipiko batek ziurrenik ez dizulako lagunduko. Baina instalazioen jabearekin lan egiteak, eta ez birsaltzaile batekin, arazo posibleen konponbidea nabarmen azkartuko du.
Iturria: www.habr.com