SLA, воно ж "service-level agreement" - угода-гарантія між замовником і постачальником послуг про те, що отримає клієнт у плані обслуговування. Також у ньому обумовлюються компенсації у разі простоїв з вини постачальника тощо. По суті 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 про надійність та сервіс, але й здатність постачальника послуг оперативно вирішувати проблеми, варто безпосередньо працювати з власником потужностей. Насправді це передбачає пряму взаємодію безпосередньо з дата-центром.
Чому ми не розглядаємо варіанти, коли безліч ДЦ насправді може належати до однієї компанії? Ну таких компаній дуже і дуже небагато. Один, два, три невеликі дата-центри або один великий — це реально. Але десяток ДЦ, половина з яких у РФ, а друга на території Європи практично неможливо. А це означає, що компаній-перекупників набагато більше, ніж можна собі уявити. Ось простий приклад:
Оцініть кількість дата-центрів Google Cloud. У Європі їх лише шість. У Лондоні, Амстердамі, Брюсселі, Гельсінкі, Франкфурті та Цюріху. Тобто, на всіх основних магістральних точках. Тому що дата-центр це дорого, складно і дуже великий проект. А тепер згадайте хостингові компанії звідкись із Москви з «десятком дата-центрів по всій Росії та Європі».
Ні, звичайно, добрих постачальників, які мають партнерів за програмою White Label, достатньо, і вони надають послуги з вищого розряду. Вони дають можливість орендувати потужності в ЄС і РФ одночасно через те саме вікно браузера, приймають оплату в рублях, а не у валюті, і так далі. Але при настанні випадків, описаних у SLA, вони стають такими самими заручниками ситуації, як і ви.
Це ще раз нагадує нам, що SLA марна, якщо ви не маєте уявлення про структуру організації та потужностей постачальника.
Що в підсумку
Падіння серверів - це завжди неприємна подія і статися вона може з будь-ким і будь-де. Питання, який ступінь контролю за ситуацією ви хочете. Зараз на ринку не дуже багато прямих постачальників потужностей, а якщо говорити про великих гравців, то їм належить, умовно, лише один ДЦ десь у Москві з десятка по всій Європі, до яких ви можете отримати доступ.
Тут кожен клієнт повинен сам собі вирішувати: я вибираю комфорт прямо зараз або витрачаю час і сили на пошук дата-центру в прийнятній точці Росії або Європи, де зможу розмістити своє обладнання або купити потужності. У першому випадку підійдуть стандартні рішення, які зараз є на ринку. У другому доведеться попітніти.
Насамперед потрібно виявити, чи є продавець послуг безпосереднім власником потужностей/дата-центру. Дуже багато перекупників за моделлю White Label щосили маскують свій статус і в цьому випадку треба дивитися на якісь непрямі ознаки. Наприклад, якщо «їхні європейські ДЦ» мають якісь специфічні назви та логотипи, що відрізняються від назви компанії-постачальника. Або якщо десь миготить слово «партнери». Партнери = White Label у 95% випадків.
Далі необхідно ознайомитися із самою структурою компанії, а краще наживо подивитися на обладнання. Серед дата-центрів не нова практика екскурсій або, як мінімум, екскурсійних статей на власному сайті або в блозі (ми такі писали, и ), де вони розповідають про свій дата-центр із фотографіями та докладними описами.
З багатьма дата-центрами можна домовитися про особистий візит до офісу та міні-екскурсії до самої ДЦ. Там можна оцінити рівень порядку, можливо, вдасться поспілкуватися з кимось з інженерів. Зрозуміло, що ніхто не влаштовуватиме вам екскурс на виробництво, якщо вам потрібен один сервер за 300 RUB/місяць, але якщо вам потрібні серйозні потужності, то відділ продажу цілком може піти вам на зустріч. Ми, наприклад, такі екскурсії проводимо.
У будь-якому випадку слід керуватися здоровим глуздом та потребами бізнесу. Наприклад, за потреби розподіленої інфраструктури (частина серверів у РФ, друга — в ЄС), простіше і вигідніше скористатися послугами хостерів, які мають партнерські відносини з європейськими ДЦ за моделлю White Label. Якщо ж вся ваша інфраструктура буде сконцентрована в одній точці, тобто в одному дата-центрі, варто приділити питання пошуку постачальника деякий час.
Тому що типовий SLA вам, швидше за все, не допоможе. А ось робота з власником потужностей, а не перекупником значно прискорить вирішення можливих проблем.
Джерело: habr.com