SLA, познат и како „договор на ниво на услуга“, е гарантен договор помеѓу клиентот и давателот на услугата за тоа што ќе добие клиентот во однос на услугата. Со него се предвидува и компензација во случај на застој по вина на добавувачот и сл. Во суштина, SLA е акредитив со чија помош центарот за податоци или хостинг провајдер го убедува потенцијалниот клиент дека ќе биде третиран љубезно на секој можен начин. Прашањето е дека можете да напишете што сакате во SLA, а настаните напишани во овој документ не се случуваат премногу често. SLA е далеку од упатство при изборот на центар за податоци и секако не треба да се потпрете на него.
Сите сме навикнати да потпишуваме некакви договори кои наметнуваат одредени обврски. SLA не е исклучок - обично најнереалниот документ што може да се замисли. Единственото нешто што е веројатно побескорисно е НДА во јурисдикции каде што концептот на „трговска тајна“ навистина не постои. Но, целиот проблем е што SLA не му помага на клиентот во изборот на вистинскиот добавувач, туку само фрла прашина во очи.
Што најчесто пишуваат хостерите во јавната верзија на SLA што ја прикажуваат на јавноста? Па, првата линија е терминот „сигурност“ на хостерот - ова се обично бројки од 98 до 99,999%. Всушност, овие бројки се само прекрасен изум на маркетерите. Некогаш, кога хостирањето беше младо и скапо, а облаците беа само сон за специјалисти (како и широкопојасен пристап за секого), индикаторот за време на работа на хостинг беше исклучително, исклучително важен. Сега, кога сите добавувачи користат, плус или минус, иста опрема, седат на истите основни мрежи и ги нудат истите пакети на услуги, индикаторот за време на работа е апсолутно незабележителен.
Дали има дури и „точен“ SLA?
Се разбира, постојат идеални верзии на SLA, но сите тие се нестандардни документи и се регистрирани и склучени помеѓу клиентот и добавувачот рачно. Покрај тоа, овој тип на SLA најчесто се однесува на некаква договорна работа, а не на услуги.
Што треба да вклучува добар SLA? Да се стави TLDR, добар SLA е документ кој го регулира односот помеѓу два ентитета, кој на една од страните (клиентот) и дава максимална контрола врз процесот. Односно, како функционира во реалниот свет: постои документ кој ги опишува глобалните процеси на интеракција и ги регулира односите меѓу страните. Таа поставува граници, правила и само по себе станува лост на влијание што двете страни можат да го искористат максимално. Така, благодарение на правилната SLA, клиентот може едноставно да го принуди изведувачот да работи како што е договорено, а тоа му помага на изведувачот да се избори со „желбите“ на премногу активниот клиент што не се оправдани со договорот. Изгледа вака: „Нашата SLA вели вака и онака, оди одовде, правиме сè како што е договорено“.
Односно, „точниот SLA“ = „соодветен договор за давање услуги“ и дава контрола врз ситуацијата. Но, ова е можно само кога се работи „како еднакви“.
Она што е напишано на веб-страницата и она што го чека во реалноста се две различни работи
Во принцип, сè што ќе разговараме понатаму се типични маркетинг трикови и тест на внимание.
Ако земеме популарни домашни хостери, тогаш едната понуда е подобра од другата: поддршка 25/8, време на работа на серверот 99,9999999% од времето, еден куп сопствени центри за податоци барем во Русија. Ве молиме запомнете ја поентата за центрите за податоци, ќе се вратиме на тоа малку подоцна. Во меѓувреме, ајде да зборуваме за идеална статистика за толеранција на грешки и со што се соочува човекот кога неговиот сервер сè уште паѓа во „0,0000001% од дефекти“.
Со показатели од 98% и повеќе, секој пад е настан на работ на статистичка грешка. Работната опрема и приклучокот или ги има или ги нема. Можете да користите хостер со оцена за „сигурност“ од 50% (според сопствената SLA) со години без ниту еден проблем, или можете да „не успевате“ еднаш месечно неколку дена со момците кои тврдат 99,99%.
Кога ќе дојде моментот на паѓање (и, потсетуваме, сите некогаш паѓаат), тогаш клиентот се соочува со внатрешна корпоративна машина наречена „поддршка“, а договорот за услуги и SLA се изнесени на виделина. Што значи тоа:
- Најверојатно, за првите четири часа од застојот нема да можете да презентирате ништо, иако некои хостери почнуваат повторно да ја пресметуваат тарифата (плаќање компензација) од моментот на падот.
- Ако серверот е недостапен подолг временски период, можеби ќе можете да поднесете барање за повторна пресметка на тарифата.
- И ова е под услов проблемот да настане по вина на добавувачот.
- Ако вашиот проблем настанал поради трето лице (на автопат), тогаш се чини дека „никој не е виновен“ и кога проблемот ќе се реши е прашање на вашата среќа.
Сепак, важно е да разберете дека никогаш не добивате пристап до инженерскиот тим, најчесто ве запира првата линија на поддршка, која кореспондира со вас додека вистинските инженери се обидуваат да ја поправат ситуацијата. Звучи познато?
Овде, многу луѓе се потпираат на SLA, што, се чини, треба да ве заштити од такви ситуации. Но, всушност, компаниите ретко ги надминуваат границите на сопствениот документ или се способни да ја свртат ситуацијата на таков начин што ќе ги минимизираат сопствените трошоци. Примарната задача на SLA е да ја смири будноста и да убеди дека дури и во случај на непредвидена ситуација, „сè ќе биде добро“. Втората цел на SLA е да ги пренесе главните критични точки и да му даде простор за маневрирање на давателот на услуги, односно способноста да се припише неуспех на нешто за кое добавувачот „не е одговорен“.
Во исто време, големите клиенти, всушност, воопшто не се грижат за компензацијата во рамките на SLA. „SLA компензација“ е враќање на парите во рамките на тарифата пропорционално на времето на прекин на опремата, кое никогаш нема да покрие дури 1% од потенцијалните парични загуби и загуби на угледот. Во овој случај, за клиентот е многу поважно проблемите да се решат што е можно поскоро отколку некој вид „повторна пресметка на тарифата“.
„Многу центри за податоци ширум светот“ е причина за загриженост
Ситуацијата со голем број центри за податоци кај давател на услуги ја сместивме во посебна категорија, бидејќи покрај очигледните комуникациски проблеми опишани погоре, се јавуваат и неочигледни проблеми. На пример, вашиот давател на услуги нема пристап до „нивните“ центри за податоци.
Во нашата последна статија , чија суштина е препродажба на туѓите капацитети под своја маска. Огромното мнозинство на модерни хостери кои тврдат дека имаат „сопствени центри за податоци“ во многу региони се препродавачи кои го користат моделот White Label. Односно, тие физички немаат никаква врска со условниот центар за податоци во Швајцарија, Германија или Холандија.
Овде се појавуваат исклучително интересни судири. Вашиот SLA кај давателот на услугата сè уште работи и е валиден, но добавувачот не е во можност некако радикално да влијае на ситуацијата во случај на несреќа. Самиот тој е во зависна позиција од сопствениот добавувач - центарот за податоци, од кој се купени решетките за напојување за препродажба.
Така, ако ја цените не само убавата формулација во договорот и SLA за доверливост и услуга, туку и способноста на давателот на услугата брзо да ги решава проблемите, треба да работите директно со сопственикот на објектите. Всушност, ова вклучува директна интеракција директно со центарот за податоци.
Зошто не ги разгледуваме опциите кога многу DC всушност можат да припаѓаат на една компанија? Па, има многу, многу малку такви компании. Можни се еден, два, три мали центри за податоци или еден голем. Но, десетина ДЦ, од кои половина се во Руската Федерација, а втората во Европа, е речиси невозможна. Ова значи дека има многу повеќе компании за препродавачи отколку што може да замислите. Еве едноставен пример:
Проценете го бројот на центри за податоци на услугата Google Cloud. Во Европа ги има само шест. Во Лондон, Амстердам, Брисел, Хелсинки, Франкфурт и Цирих. Односно, на сите главни автопатски пунктови. Бидејќи центарот за податоци е скап, сложен и многу голем проект. Сега запомнете ги хостинг компаниите од некаде во Москва со „дузина центри за податоци низ Русија и Европа“.
Се разбира, нема добри добавувачи кои имаат партнери во програмата White Label, ги има доволно, а тие обезбедуваат услуги од највисоко ниво. Тие овозможуваат изнајмување капацитети во ЕУ и Руската Федерација истовремено преку истиот прозорец на прелистувачот, прифаќаат плаќање во рубли, а не во странска валута итн. Но, кога ќе се случат случаите опишани во SLA, тие стануваат исти заложници на ситуацијата како и вие.
Ова уште еднаш нè потсетува дека SLA е бескорисен ако немате разбирање за организациската структура и можностите на добавувачот.
Со тоа што
Падот на серверот е секогаш непријатен настан и може да му се случи на секого, секаде. Прашањето е колкава контрола над ситуацијата сакате. Сега нема премногу директни добавувачи на капацитет на пазарот, и ако зборуваме за големи играчи, тогаш тие поседуваат, релативно кажано, само еден DC некаде во Москва од десетина низ Европа до кои можете да пристапите.
Овде, секој клиент мора сам да одлучи: дали избирам удобност во моментов или трошам време и напор барајќи центар за податоци на прифатлива локација во Русија или Европа, каде што можам да ја ставам мојата опрема или да купам капацитет. Во првиот случај, соодветни се стандардните решенија кои моментално се на пазарот. Во втората, ќе мора да се испотите.
Пред сè, потребно е да се утврди дали продавачот на услуги е директен сопственик на објектите/центарот за податоци. Многу препродавачи кои го користат моделот White Label се трудат максимално да го прикријат својот статус, а во овој случај треба да барате некои индиректни знаци. На пример, ако „нивните европски DC“ имаат одредени специфични имиња и логоа што се разликуваат од името на компанијата добавувач. Или ако зборот „партнери“ се појави некаде. Партнери = Бела ознака во 95% од случаите.
Следно, треба да се запознаете со структурата на самата компанија, или уште подобро, лично да ја погледнете опремата. Меѓу центрите за податоци, практиката на екскурзии или барем написи за екскурзија на сопствената веб-страница или блог не е нова (напишавме такви и ), каде зборуваат за нивниот центар за податоци со фотографии и детални описи.
Со многу центри за податоци, можете да организирате лична посета на канцеларијата и мини-екскурзија до самиот DC. Таму можете да го процените степенот на ред, можеби ќе можете да комуницирате со некој од инженерите. Јасно е дека никој нема да ви направи турнеја на производството ако ви треба еден сервер за 300 RUB/месечно, но ако ви треба сериозен капацитет, тогаш одделот за продажба можеби ќе ви излезе во пресрет. На пример, спроведуваме такви екскурзии.
Во секој случај, треба да се искористи здравиот разум и деловните потреби. На пример, ако ви треба дистрибуирана инфраструктура (некои од серверите се во Руската Федерација, другиот во ЕУ), ќе биде полесно и попрофитабилно да ги користите услугите на хостери кои имаат партнерства со европските DC користејќи ја Белата етикета. модел. Ако целата ваша инфраструктура ќе биде концентрирана во една точка, односно во еден центар за податоци, тогаш вреди да потрошите малку време за да пронајдете добавувач.
Бидејќи типичен SLA најверојатно нема да ви помогне. Но, работата со сопственикот на објектите, а не со препродавач, значително ќе го забрза решавањето на можните проблеми.
Извор: www.habr.com