Сравнение SLA игровых хостингов — на что смотреть в договоре

MAATRIX GAMES

Сервер лёг в субботу вечером, когда у тебя на сервере четверо друзей и рейд-ивент, а поддержка отвечает «принято в обработку» — знакомая ситуация. SLA (Service Level Agreement, соглашение об уровне обслуживания) — это как раз тот документ, который должен был расписать, что случится дальше: сколько хостинг обязан чинить, что тебе за это будет и, главное, в каких случаях он вообще ничего не должен. Проблема в том, что 99% арендаторов игровых серверов SLA не читают вообще, а зря — там обычно написано куда меньше, чем кажется из маркетингового «аптайм 99.9%» на главной странице.

Что такое SLA и почему это не то же самое, что реклама на сайте

SLA — это раздел договора или оферты, где хостинг фиксирует измеримые обязательства: доступность сервиса, время реакции поддержки, порядок компенсации при нарушении. Это не «мы стараемся работать стабильно», а формула с процентами и минутами.

Ключевая ловушка: цифра «99.9% uptime» на лендинге часто относится к дата-центру или к инфраструктуре хостинга в целом, а не лично к твоему серверу. Дата-центр может отчитаться о 99.99% доступности электропитания и сети — и при этом твой контейнер с Rust будет падать раз в неделю из-за перегруженной ноды или бага в панели управления. Поэтому первый вопрос при чтении SLA: к чему относится гарантия — к сети провайдера, к железу или к твоей виртуальной машине/контейнеру.

Второй момент — где физически лежит SLA. У многих игровых хостингов это не отдельный подписанный документ, а страница в публичной оферте. Юридически это тоже обязательство, но найти его нужно самому: ищи разделы «Уровень обслуживания», «Гарантии», «Ответственность сторон» или английские Service Level, Uptime Guarantee.

Гарантированный аптайм: 99%, 99.9%, 99.95% — в чём разница на практике

Разница между «99 с одной девяткой» и «99 с тремя девятками» выглядит как погрешность, но в минутах простоя это совершенно разные истории:

Это чистая математика, а не измеренные показатели конкретного провайдера — считай её ориентиром, а не гарантией результата.

Для игрового сервера на 10-20 слотов разница между 99% и 99.9% может быть не критична — час простоя ночью в будни никто не заметит. А вот для сообщества с расписанными ивентами, стримами или платным донатом на сервере даже 99% (те самые 7 часов в месяц) может означать сорванный турнир по CS2 или вайп-день на Rust-сервере, который все ждали неделю.

Смотри в договоре не только на саму цифру, но и на период измерения: «99.9% в месяц» и «99.9% в год» — разные обязательства. Годовая гарантия позволяет провайдеру «слить» весь допустимый простой в один плохой месяц и формально не нарушить SLA.

Как считается компенсация за простой и почему она почти никогда не покрывает реальный ущерб

Типичная формула компенсации в SLA выглядит так: за каждый час простоя сверх гарантированного порога — кредит на баланс в размере 1/720 (или 1/30) от ежемесячной оплаты за каждый час недоступности, иногда с потолком в 100% стоимости месяца.

Вот что важно понимать заранее:

• Компенсация — это кредит на счёт, а не деньги на карту. Почти всегда это бонусные дни или скидка на следующий период, а не возврат средств. Если ты уходишь от хостинга после инцидента, эта компенсация может просто сгореть.
• Нужно заявление. Автоматически компенсацию почти никто не начисляет — обычно требуется тикет в поддержку с указанием времени простоя, часто в течение ограниченного срока (например, 5-7 дней после инцидента).
• Провайдер сам считает простой. Часто именно хостинг, а не независимый мониторинг, определяет, был ли инцидент и сколько он длился, — и трактует пограничные случаи в свою пользу.
• Пример расчёта. Тариф 990 ₽/мес, простой сверх нормы — 3 часа. При формуле 1/720 за час это (990/720)×3 ≈ 4 ₽ компенсации. Даже при более щедрой формуле 1/30 за час простоя (не совсем корректной математически, но встречающейся) это (990/30)×3 = 99 ₽. В любом случае сумма символическая — SLA компенсирует не твой ущерб от простоя, а условно «недополученную услугу».

Вывод простой: не рассчитывай на SLA как на страховку от убытков. Это дисциплинирующий механизм для провайдера (ему невыгодно копить простои), а не источник компенсации, сопоставимой с реальными потерями — сорванным ивентом, оттоком игроков, репутацией сообщества.

Что SLA почти никогда не покрывает — читай исключения внимательнее самой гарантии

Раздел исключений («Force Majeure», «Плановые работы», «Действия пользователя») обычно длиннее самой гарантии, и именно там прячется реальный масштаб обязательств хостинга. Типичные исключения:

• Плановые технические работы, о которых провайдер предупредил заранее (обычно за 24-48 часов) — это время вообще не засчитывается в простой.
• DDoS-атаки и их отражение. Если во время атаки сервис недоступен, это часто выведено из-под SLA отдельным пунктом — формально хостинг не виноват, что кто-то атаковал именно тебя. Стоит уточнить, входит ли DDoS-защита в тариф и как она соотносится с гарантией доступности.
• Форс-мажор — сбои на стороне upstream-провайдеров, аварии в дата-центре, стихийные бедствия, действия третьих лиц.
• Ошибки самого арендатора — неправильная конфигурация сервера, самостоятельная установка модов/плагинов, которые уронили процесс, превышение лимитов RAM/CPU тарифа. Если Java-процесс упал по OutOfMemoryError из-за слишком тяжёлого модпака на маленьком тарифе — это не сбой хостинга, и SLA тут ни при чём.
• Простой панели управления при живом игровом процессе. Формально сервер игроков доступен, просто веб-панель недоступна — некоторые SLA этот случай не засчитывают как простой вообще.
• Бета/тестовые тарифы и пробный период. Часто отдельно прописано, что SLA не действует на пробный период или на акционные/демо-конфигурации.

Если в договоре список исключений явно шире самой гарантии — это не обязательно признак недобросовестности провайдера (у крупных облачных SLA список исключений тоже длинный), но это повод трезво оценивать, что именно тебе гарантируют на практике.

Время реакции поддержки — вторая половина SLA, о которой чаще всего забывают

Гарантия аптайма отвечает на вопрос «как часто может падать сервис», но не отвечает на вопрос «как быстро на это отреагируют». Смотри отдельно два показателя:

• Response time (время первой реакции) — за сколько минут/часов поддержка хотя бы ответит на тикет, подтвердив, что проблема принята в работу.
• Resolution time (время решения) — за сколько провайдер обязуется устранить проблему конкретного класса критичности.

Многие SLA делят инциденты по приоритету:

Critical (сервер полностью недоступен для всех игроков) — реакция до 30-60 минут
High (частичная деградация, лаги, крэши процесса) — реакция до 2-4 часов
Medium/Low (вопросы по конфигурации, некритичные баги) — реакция до 24 часов

Это условный пример структуры приоритетов, а не цитата конкретного провайдера — конкретные пороги времени всегда смотри в договоре нужного тебе хостинга. Важно понять логику: чем ближе твой кейс к «сервер лежит для всех», тем быстрее должна быть реакция по SLA, и именно этот пункт стоит проверять в первую очередь для игрового хостинга — там сбои обычно требуют не «письменного ответа за сутки», а живого перезапуска процесса в течение часа.

Отдельно уточни канал поддержки, к которому применяется SLA. Время реакции в тикет-системе и время ответа в публичном чате/соцсетях — обычно разные вещи, и договор регулирует только первое.

SLA для маленького сервера vs enterprise-хостинг: какие пункты реально применимы

Тут стоит трезво развести ожидания. Enterprise SLA (для крупного бизнеса, облачных провайдеров уровня AWS/Google Cloud) — это многостраничный документ с раздельными гарантиями на сеть, диск, гипервизор, поддержку, часто с юридически значимой неустойкой. Игровой хостинг для арендатора Minecraft- или Rust-сервера на 10-50 слотов — это чаще всего сокращённая версия того же принципа под массовый недорогой тариф.

Что из этого реально работает для небольшого сервера:

• Гарантия аптайма как ориентир качества инфраструктуры. Даже если компенсация символическая, сам факт, что провайдер публично называет цифру и обязуется её отслеживать, — сигнал зрелости сервиса. Хостинг без упоминания SLA в оферте — не обязательно плохой, но проверить его репутацию и аптайм по независимому мониторингу стоит отдельно.
• Время реакции поддержки — практически важнее процента аптайма для небольшого сервера, потому что типичная проблема арендатора 10-слотового сервера — это не глобальный сбой ЦОД, а зависший процесс, который нужно перезапустить руками.
• Компенсация — воспринимай как приятный бонус, не как страховку. На практике дешевле держать автобэкапы и план быстрого восстановления, чем рассчитывать на выплаты по SLA.
• Пункт о миграции при систематических нарушениях. Хорошая практика — когда прописано право бесплатно перенести сервер на другую ноду или локацию, если проблема повторяется на конкретном железе. Часто это работает лучше, чем разовая компенсация за час простоя.

Для тарифа за 300-500 ₽/мес разумно требовать внятное время реакции поддержки и понятную процедуру при сбое, а не судиться за неустойку в духе банковского договора.

Чек-лист: что проверить в договоре перед оплатой

Перед тем как платить за сервер, потрать пять минут и пройдись по пунктам:

1. К чему относится заявленный процент аптайма — к сети ЦОД, к железу или к твоему конкретному серверу/контейнеру.
2. Период измерения гарантии — месяц или год (месячная гарантия честнее к разовым сбоям).
3. Форма компенсации — кредит на баланс, бонусные дни или что-то ещё; есть ли верхний предел (потолок) выплаты.
4. Порядок обращения за компенсацией — куда писать, какой срок на подачу заявления, какие доказательства простоя нужны.
5. Список исключений — особенно пункты про DDoS, плановые работы и ошибки конфигурации со стороны пользователя.
6. Время реакции и решения по приоритетам инцидентов, и к какому каналу поддержки это относится.
7. Действует ли SLA на пробный период, демо-тариф или акционную конфигурацию.
8. Есть ли право на бесплатный перенос сервера при систематических (не разовых) сбоях на конкретном железе.

Красные флаги: SLA обещает 99.99% без единого исключения (так не бывает даже у гигантов облачного рынка), компенсация выплачивается «по решению администрации» без формулы, а раздел про поддержку вообще не содержит цифр по времени реакции — только общие слова вроде «в кратчайшие сроки».

Частые вопросы