SLA хостинг-провайдера: як читати дрібний шрифт, що визначає долю вашого стартапу
Уявіть: ви запустили MVP, перші користувачі прийшли, продукт почав набирати трекшн - і раптом сайт лягає. На годину. На три. На шість. Ви пишете в підтримку хостера, а вам відповідають: "Ми гарантуємо 99.9% uptime, і ваш простій вкладається в допустимі межі". Знайоме? Більшість фаундерів підписують SLA (Service Level Agreement) не читаючи, як ліцензійну угоду iTunes. А потім дивуються, що "гарантія" виявилася набором красивих цифр без реальної відповідальності. Давайте розберемо цей документ по кісточках - так, щоб ви більше ніколи не потрапили в цю пастку.
Що насправді означають ці красиві дев'ятки
Маркетологи хостинг-провайдерів обожнюють числа на кшталт 99.9%, 99.95%, 99.99%. Виглядає солідно. Але ось що ці цифри означають у реальному часі:
| Гарантія uptime | Допустимий простій на місяць | Допустимий простій на рік |
|---|---|---|
| 99.0% | 7 годин 18 хвилин | 3 дні 15 годин |
| 99.5% | 3 години 39 хвилин | 1 день 19 годин |
| 99.9% | 43 хвилини | 8 годин 46 хвилин |
| 99.95% | 21 хвилина | 4 години 23 хвилини |
| 99.99% | 4 хвилини | 52 хвилини |
Бачите різницю між 99.9% і 99.0%? Це не "якась десята відсотка". Це різниця між 43 хвилинами і 7 годинами простою щомісяця. Для стартапу, який тільки набирає аудиторію, кожна година недоступності - це користувачі, які більше ніколи не повернуться. Перше враження можна справити лише один раз.
Анатомія SLA: де ховається диявол
Я бачив десятки SLA різних провайдерів, і у кожного є свої "фокуси". Документ зазвичай містить кілька ключових блоків, і в кожному може чекати неприємний сюрприз.
- Визначення "доступності" - деякі провайдери рахують downtime тільки коли сервер фізично не відповідає. Якщо він працює, але загружає сторінку 30 секунд - формально все ок.
- Виключення - планове обслуговування, DDoS-атаки, проблеми з DNS, форс-мажори. Іноді виключень так багато, що гарантія перетворюється на порожнє місце.
- Процедура фіксації інциденту - якщо ви не відкрили тікет протягом 24 годин, простій "не рахується". Серйозно. Такі пункти зустрічаються частіше, ніж ви думаєте.
- Компенсація - найцікавіше. Зазвичай це кредит на рахунок (не гроші назад!), і рідко перевищує вартість одного місяця хостингу.
- Порядок ескалації - скільки часу у провайдера на відповідь, на початок роботи над проблемою, на повне відновлення.
Ось вам реальний кейс. Один з моїх знайомих фаундерів обрав хостинг з гарантією 99.95% uptime. Коли сервер лежав 4 години через "планове обслуговування", про яке повідомили за 12 годин електронним листом (що потрапив у спам), провайдер відмовив у компенсації. Формально все за договором.
"SLA - це не обіцянка, а юридичний документ. Якщо ви не розумієте кожен пункт, ви не маєте SLA - ви маєте ілюзію безпеки." - Марк Бургесс, автор книги "In Search of Certainty" та творець CFEngine
Що саме перевіряти перед підписанням
Коли ви обираєте хостинг для стартапу, SLA - це не та річ, яку варто проскролити до кнопки "Прийняти". Ось чекліст, який збереже вам нерви та гроші:
- Як саме вимірюється uptime - чи включає час відповіді (latency), чи тільки фізичну доступність сервера
- Список виключень - чим він коротший, тим чесніший провайдер
- Формат компенсації - кредит на рахунок чи реальне повернення коштів, та який максимум
- Час реакції підтримки - різниця між "відповімо протягом 15 хвилин" та "протягом 24 годин" може коштувати вашому стартапу тисячі доларів
- Хто несе відповідальність за збитки - спойлер: у 90% SLA відповідь "ніхто, крім вас"
Зверніть увагу на формулювання. "Ми докладаємо комерційно обґрунтовані зусилля" - це зовсім не те саме, що "Ми гарантуємо". Перше - це побажання. Друге - зобов'язання. Якщо у тексті SLA більше "зусиль" ніж "гарантій" - тікайте.
Хостинг за $10 і хостинг за $100: де SLA насправді працює
Давайте будемо чесними. На shared-хостингу за $5-10 на місяць SLA - це скоріше декорація. Провайдер фізично не може забезпечити серйозні гарантії, коли ваш сайт ділить ресурси з сотнями інших проєктів. Це як вимагати гарантію тиші в хостелі на 50 ліжок.
Реальні SLA починають працювати на рівні VPS і вище. Ось як це виглядає на практиці:
На shared-хостингу SLA зазвичай обіцяє 99.9% uptime, але компенсація - це пропорційний кредит. Ваш сайт лежав 5 годин? Ось вам $0.07 на рахунок. Дякуємо за розуміння.
На VPS та хмарних серверах ситуація краща. AWS, Google Cloud, DigitalOcean мають чіткі SLA з прозорим розрахунком кредитів. Наприклад, AWS EC2 обіцяє 99.99% для кожного регіону, і при порушенні - повертає до 30% місячного рахунку.
На виділених серверах з managed-підтримкою SLA часто включає конкретні часові рамки відновлення: RTO (Recovery Time Objective) і RPO (Recovery Point Objective). Це вже серйозна розмова.
Для стартапу на ранній стадії золота середина - managed VPS або хмарний хостинг з SLA не нижче 99.95% і часом реакції підтримки не більше 30 хвилин. Так, це дорожче. Але порахуйте, скільки коштує одна година простою, коли ваш продукт вперше згадали у великому медіа.
RTO і RPO: два терміни, що рятують бізнес
Більшість SLA концентруються на uptime, але для стартапу набагато важливіші два інші показники, про які чомусь рідко говорять.
RTO (Recovery Time Objective) - максимальний час, за який провайдер зобов'язується відновити роботу після збою. Не "почати працювати над проблемою", а повністю відновити.
RPO (Recovery Point Objective) - максимальний обсяг даних, який ви можете втратити. Якщо RPO = 1 година, значить бекапи робляться щогодини, і при збої ви втратите максимум годину даних.
Уявіть: у вас SaaS-стартап, 200 активних користувачів щодня вносять дані. Сервер падає о 15:00, останній бекап був о 03:00. Ви щойно втратили 12 годин даних двохсот людей. Якщо у вашому SLA не прописані RTO і RPO - ви граєте в рулетку з даними клієнтів.
Вимагайте конкретні цифри. "Ми робимо регулярні бекапи" - це не RPO. "Бекап кожні 4 години з гарантованим відновленням протягом 30 хвилин" - ось це вже розмова.
Ваш власний SLA: внутрішня угода, про яку всі забувають
Ось що мене завжди дивує. Стартапи вичитують SLA хостера до коми, але при цьому не мають власної внутрішньої угоди. Хто відповідає за моніторинг? Хто отримує алерти вночі? Скільки часу команда має на реакцію?
Навіть найкращий SLA провайдера не врятує вас, якщо:
- Ніхто в команді не налаштував моніторинг (UptimeRobot, Pingdom - це безкоштовно!)
- Алерти приходять на email, який ніхто не перевіряє у вихідні
- Немає задокументованого плану дій на випадок інциденту
- Доступ до панелі хостингу має тільки CTO, який поїхав у Карпати без інтернету
Створіть простий одностoрінковий документ: хто, що, коли. Це займе годину, але одного разу збереже ваш бізнес. Я не перебільшую.
Провайдер відповідає за інфраструктуру. За ваш код, ваші дані, вашу репутацію - відповідаєте ви. І ніякий SLA у світі цього не змінить.
Наступного разу, коли будете обирати хостинг для стартапу, відкрийте SLA до того, як подивитесь на ціну. Перечитайте виключення. Знайдіть слово "компенсація" і прочитайте, що стоїть після нього. А потім задайте собі одне просте питання: якщо мій сервер ляже на 6 годин у день запуску - що мені реально дасть цей документ? Якщо відповідь "кредит $2 на рахунок" - можливо, варто пошукати далі.