SLA, известно още като „споразумение за ниво на услугата“, е гаранционно споразумение между клиента и доставчика на услуги относно това, което клиентът ще получи по отношение на услугата. Той също така предвижда обезщетение в случай на престой по вина на доставчика и т.н. По същество SLA е удостоверение, с помощта на което център за данни или хостинг доставчик убеждава потенциален клиент, че ще бъде третиран любезно по всякакъв възможен начин. Въпросът е, че можете да напишете всичко, което искате в SLA, а събитията, записани в този документ, не се случват твърде често. SLA далеч не е насока при избора на център за данни и със сигурност не трябва да разчитате на него.
Всички сме свикнали да подписваме някакви споразумения, които налагат определени задължения. SLA не е изключение - обикновено най-нереалистичният документ, който можете да си представите. Единственото нещо, което вероятно е по-безполезно, е NDA в юрисдикции, където концепцията за „търговска тайна“ всъщност не съществува. Но целият проблем е, че 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 всъщност могат да принадлежат на една компания? Е, има много, много малко такива фирми. Възможни са един, два, три малки центъра за данни или един голям. Но дузина DC, половината от които са в Руската федерация, а втората в Европа, е почти невъзможно. Това означава, че има много повече компании за дистрибутори, отколкото можете да си представите. Ето един прост пример:
Оценете броя на центровете за данни на услугата Google Cloud. В Европа има само шест от тях. В Лондон, Амстердам, Брюксел, Хелзинки, Франкфурт и Цюрих. Тоест на всички основни магистрални точки. Тъй като центърът за данни е скъп, сложен и много голям проект. Сега си спомнете хостинг компаниите от някъде в Москва с „дузина центрове за данни в цяла Русия и Европа“.
Разбира се, няма добри доставчици, които имат партньори в програмата White Label, има достатъчно и те предоставят услуги на най-високо ниво. Те дават възможност за наемане на капацитет в ЕС и Руската федерация едновременно през един и същ прозорец на браузъра, приемане на плащане в рубли, а не в чуждестранна валута и т.н. Но когато се случат описаните в SLA случаи, те стават точно същите заложници на ситуацията като вас.
Това ни напомня още веднъж, че SLA е безполезен, ако нямате разбиране за организационната структура и възможности на доставчика.
В резултат на което
Сривът на сървъра винаги е неприятно събитие и може да се случи на всеки и навсякъде. Въпросът е колко контрол върху ситуацията искате. Сега няма твърде много директни доставчици на капацитет на пазара и ако говорим за големи играчи, тогава те притежават, относително казано, само един DC някъде в Москва от дузина в цяла Европа, до които имате достъп.
Тук всеки клиент трябва да реши сам: дали да избера комфорта точно сега или да отделя време и усилия за търсене на център за данни на приемливо място в Русия или Европа, където мога да разположа оборудването си или да закупя капацитет. В първия случай са подходящи стандартни решения, които в момента са на пазара. Във втория ще трябва да се изпотите.
На първо място е необходимо да се определи дали продавачът на услугата е пряк собственик на съоръженията/центъра за данни. Много дистрибутори, използващи модела White Label, се опитват да прикрият статуса си и в този случай трябва да потърсите някои косвени признаци. Например, ако „техните европейски DC“ имат някои специфични имена и лога, които се различават от името на компанията доставчик. Или ако някъде се появи думата „партньори“. Партньори = White Label в 95% от случаите.
След това трябва да се запознаете със структурата на самата компания или още по-добре да разгледате оборудването лично. Сред центровете за данни практиката на екскурзии или поне статии за екскурзии на техния собствен уебсайт или блог не е нова (писахме такива и ), където те говорят за своя център за данни със снимки и подробни описания.
С много центрове за данни можете да организирате лично посещение в офиса и мини-екскурзия до самия DC. Там можете да оцените степента на ред, може би ще можете да общувате с някой от инженерите. Ясно е, че никой няма да ви даде обиколка на производството, ако имате нужда от един сървър за 300 RUB / месец, но ако имате нужда от сериозен капацитет, тогава отделът за продажби може да ви посрещне. Например, ние провеждаме такива екскурзии.
Във всеки случай трябва да се използва здрав разум и нужди на бизнеса. Например, ако имате нужда от разпределена инфраструктура (някои от сървърите са в Руската федерация, други в ЕС), ще бъде по-лесно и по-изгодно да използвате услугите на хостери, които имат партньорства с европейски DC, използващи White Label модел. Ако цялата ви инфраструктура ще бъде концентрирана в една точка, тоест в един център за данни, тогава си струва да отделите известно време за намиране на доставчик.
Тъй като типичното SLA най-вероятно няма да ви помогне. Но работата със собственика на съоръженията, а не с дистрибутор, значително ще ускори разрешаването на възможни проблеми.
Източник: www.habr.com