«Хостинг часто покупают по привычке, как подписку. SLA, это не просто бумажка с гарантиями. Это инструмент, который либо работает на тебя, либо просто съедает бюджет. Большая часть текста бесполезна, настоящая цена скрывается в деталях, о которых ты, скорее всего, даже не подумал.»
Что на самом деле покупают, когда берут хостинг
При выборе хостинга обычно смотрят на три вещи: цена, расположение дата-центров и базовые технические параметры вроде типа процессора и объёма RAM. SLA в лучшем случае пролистывают взглядом на предмет упоминания «99,9% доступности». Этого достаточно, чтобы считать обязанности поставщика выполненными. Но так ли это?
SLA, это не проценты на красивой странице. Это юридически обязывающий документ, который определяет, за что конкретно ты платишь и что получишь в случае проблем. Разница между ожиданием и реальностью часто возникает из-за неверного понимания двух ключевых аспектов: что именно считается «простоем» и как считается компенсация.
Доступность 99,9% не означает доступность 99,9%
Первая и самая распространённая ловушка. Провайдер обещает 99,9% аптайма в месяц. Это примерно 43 минуты простоя в месяц, что кажется приемлемым. Но как считается этот простой? Чаще всего — по данным мониторинга самого провайдера с его собственных точек контроля внутри сети. Если твой сервер «висит», но внутренняя инфраструктура поставщика (роутеры, каналы) отвечает, инцидент могут не засчитать. Простой начинает течь только с момента регистрации тикета в поддержке и до момента восстановления. Твои собственные мониторинги, фиксирующие проблему на 20 минут раньше, в расчёт не идут.
Кроме того, во многих SLA есть длинный список исключений, которые не считаются простоем: плановые работы (о которых могли предупредить за 24 часа письмом на корпоративную почту, которую никто не проверяет), проблемы, вызванные действиями клиента, DDoS-атаки ниже определённого порога, форс-мажорные обстоятельства с предельно широкой трактовкой.
Компенсация, которая не компенсирует
Вторая ловушка — механизм компенсации. Типичная формула: за каждый полный час превышения допустимого простоя клиент получает 5-10% стоимости услуги за данный месяц. Звучит как страховка. На практике: если месячная плата за сервер составляет 10 000 рублей, а простой составил 10 часов сверх нормы, компенсация может быть 10% * 10 000 = 1 000 рублей. Убытки бизнеса от 10 часов простоя почти всегда на порядки выше этой суммы. Компенсация по SLA, это символическая скидка на следующий месяц, а не возмещение реального ущерба. Её главная функция для поставщика — ограничить свою финансовую ответственность.
Скрытые расходы, которые вырастают из нечитанного SLA
Цена в прайсе, это лишь входной билет. Реальные расходы формируются механиками, описанными в SLA, о которых не говорят менеджеры по продажам.
Резервное копирование: бесплатное и дорогое
Многие провайдеры включают «бесплатные» бэкапы раз в сутки с хранением 7-30 дней. В SLA к этому прилагаются важные оговорки. Восстановление данных из такого бэкапа почти всегда является платной услугой, причём стоимость работы инженера может быть фиксированной и высокой. Сами бэкапы часто хранятся в том же дата-центре, что и основная виртуальная машина, что сводит на нет их ценность при физических проблемах с ЦОДом. Гарантия целостности данных в бэкапе обычно отсутствует — провайдер обязуется только попытаться восстановить.
Исходящий трафик и DDoS-защита
Тарифы с «безлимитным трафиком» почти всегда имеют ограничение по исходящему каналу (например, 100 Мбит/с на виртуальную машину). Превышение этого лимита либо блокируется, либо переводит сервер на более дорогой тариф. В SLA это прописано мелким шрифтом. То же с DDoS: базовый уровень защиты может срабатывать только на атаки определённого типа и объёма. При более мощной атаке применяется «blackholing» — трафик на твой IP-адрес просто отбрасывается на границе сети провайдера, вызывая тот самый простой, который, однако, может попасть под исключение по «действиям третьих лиц».
Плата за ресурсы, которые ты не используешь
Виртуальные машины почасовой или помесячной оплаты часто имеют жёсткую привязку к конфигурации. Уменьшить количество vCPU или объём RAM без пересоздания сервера обычно нельзя. Если ты взял мощную конфигурацию «на пик», а потом нагрузка упала, ты продолжаешь платить за неиспользуемые ресурсы полную стоимость. Некоторые провайдеры предлагают гибкое масштабирование, но эта опция требует отдельного SLA и стоит дороже базового тарифа.
SLA и регуляторика: где пересекаются обязательства
Для компаний, работающих под 152-ФЗ, выбор хостинга и анализ его SLA перестаёт быть только финансовой задачей. Провайдер становится оператором персональных данных. Его SLA, это часть доказательной базы для регулятора о том, что ты принял достаточные меры для обеспечения безопасности и доступности ПДн.
Ключевые моменты для проверки:
- Физическая безопасность ЦОДов. В SLA должно быть явное указание на соответствие дата-центров требованиям ФСТЭК. Расплывчатые формулировки вроде «соответствует современным стандартам» не подходят.
- Локализация данных. Гарантирует ли провайдер, что данные хранятся и обрабатываются исключительно на территории РФ? Это должно быть не просто декларацией, а механизмом, описанным в SLA, с указанием ответственности за нарушение.
- Уведомление об инцидентах. Сроки и каналы уведомления клиента о любых инцидентах, влияющих на конфиденциальность или доступность данных. По 152-ФЗ, оператор ПДн обязан сообщить в Роскомнадзор об утечке в течение 24 часов. Если провайдер уведомит тебя с опозданием, ты нарушишь сроки.
- Аудит и предоставление отчётности. Имеешь ли ты право на проведение аудита инфраструктуры провайдера или хотя бы на получение заключений по модели угроз и аттестата соответствия? Если нет, доказать регулятору adequacy выбранных мер защиты будет сложно.
Частая ошибка — считать, что если провайдер имеет аттестат ФСТЭК на облако, то этого достаточно. Аттестат покрывает типовую инфраструктуру. Твоя конкретная конфигурация, способы доступа и управления должны быть отдельно оценены на соответствие. Провайдер по SLA может снять с себя ответственность, если инцидент произошёл из-за неправильной настройки твоих служб или использования неподдерживаемого ПО.
Как читать SLA: практический алгоритм
Чтение 50-страничного документа — не самая увлекательная задача. Фокусируйся не на всем тексте, а на конкретных разделах. Вот на что смотреть в первую очередь:
- Определения (Definitions). Найди и выпиши, как определены ключевые термины: «Сервис», «Простой», «Работоспособность», «Инцидент». Это основа для всех дальнейших трактовок.
- Метрики и мониторинг (Service Level Indicators). Как именно измеряется доступность? С каких точек? С какой периодичностью? Где можно посмотреть эти данные?
- Исключения (Exclusions). Полный список ситуаций, когда SLA не применяется. Особое внимание на пункты про плановые работы, действия клиента и «обстоятельства непреодолимой силы».
- Процедура заявки на компенсацию (Service Credit Request). Часто компенсация не начисляется автоматически. Требуется подать заявку в строго определённый срок (например, в течение 30 дней после инцидента) по определённой форме. Пропустил срок — потерял право на компенсацию.
- Прекращение действия (Termination). Имеешь ли ты право расторгнуть договор без штрафных санкций, если провайдер многократно нарушает SLA? Многие договоры такой возможности не дают.
Составь таблицу с ключевыми параметрами из SLA разных провайдеров. Сравнивать цифры без контекста их измерения — бессмысленно.
Стратегия переговоров: как изменить SLA в свою пользу
Стандартное SLA всегда составлено в пользу поставщика. Но его можно и нужно обсуждать, особенно для корпоративных клиентов или при размещении критичной инфраструктуры.
- Запрос кастомизированных метрик. Можно договориться, чтобы доступность измерялась не только с внутренних точек провайдера, но и с внешних, независимых сервисов мониторинга, или по конкретному порту/пути на твоём сервере.
- Сокращение времени на плановые работы. Стандартное уведомление за 24-72 часа можно попробовать увеличить до 7-10 дней, а также договориться о проведении работ исключительно в низконагруженное ночное время.
- Ужесточение компенсационной модели. Вместо процента от месячной платы можно попробовать зафиксировать сумму компенсации за час простоя, более адекватную потенциальным бизнес-потерям. Альтернатива — накопительные компенсации, дающие право на существенную скидку или бесплатный период обслуживания после нескольких инцидентов.
- Включение регуляторных гарантий. Прямые формулировки о хранении данных только в юрисдикции РФ, обязывающие провайдера предоставлять все необходимые документы для проверок ФСТЭК и Роскомнадзора, четкие сроки уведомления об инцидентах безопасности.
Любые изменения в SLA должны быть внесены в договор в виде отдельного приложения или спецификации. Устные договорённости с менеджером не имеют юридической силы.
Что делать, если SLA уже нарушено
Если произошёл инцидент, который, по твоему мнению, подпадает под нарушение SLA, действуй по инструкции:
- Немедленно зафиксируй факт проблемы: скриншоты мониторингов, логи ошибок, время отсутствия отклика. Важно иметь временные метки.
- Открой тикет в поддержке. Фиксируй время отправки. Это будет официальной точкой отсчёта простоя для провайдера.
- После решения проблемы запроси у провайдера отчёт об инциденте (Root Cause Analysis, RCA). Сравни его данные со своими.
- Если видишь несоответствие и уверен в своей правоте, подготовь официальный запрос на компенсацию, ссылаясь на конкретные пункты SLA. Приложи все собранные доказательства.
Отношения с провайдером, это партнёрство, где твоя главная валюта — внимательность к документам. SLA, которое лежит в столе и никем не читается, это просто статья расходов. SLA, которое понимают и используют, становится инструментом управления рисками и затратами. Разница между этими двумя состояниями часто и есть те самые «переплаты», которые можно было избежать.