SLA виртуального сервера: как проверить обещания провайдера на прочность

SLA (Service Level Agreement) — это соглашение об уровне обслуживания, в котором провайдер фиксирует конкретные обязательства: сколько времени сервер будет доступен, как быстро отреагирует техподдержка и что будет, если условия нарушены. Для бизнеса это единственный документ, который переводит маркетинговые обещания в цифры и штрафы.

Что такое SLA простыми словами и зачем он бизнесу?

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

Без SLA бизнес полагается только на слова менеджера по продажам. С SLA — на юридически закреплённые условия, которые можно предъявить в случае спора. Это особенно важно, если на сервере крутится интернет-магазин, база 1С или сайт, приносящий заявки: каждый час простоя стоит реальных денег.

Что означают проценты вроде 99,9% и 99,99% — сколько это часов простоя?

Проценты в SLA — это не абстракция, а конкретное время простоя в год, которое посчитать несложно. Если взять год за 8760 часов, то:

• 99% доступности — это около 87 часов простоя в год, то есть больше трёх суток;
• 99,9% — уже около 8,7 часа в год, чуть больше одного рабочего дня;
• 99,99% — примерно 52 минуты в год;
• 99,999% — около 5 минут в год, так называемая «пятерка девяток», стандарт для критически важных систем связи.

Разница между 99% и 99,9% кажется небольшой на бумаге, но на практике это разница между «сервер иногда подвисает» и «сервер практически не замечает нагрузок». Чем выше требуемая планка, тем дороже и сложнее инфраструктура, которая её обеспечивает: резервирование каналов связи, дублирование оборудования, автоматическое переключение на резерв.

Что обычно входит в SLA виртуального сервера, а что нет?

Классический SLA для VPS или облачного сервера обычно описывает доступность самой инфраструктуры: работу гипервизора, сети, электропитания и охлаждения в дата-центре. Провайдер отвечает за то, чтобы «железо» и виртуализация функционировали стабильно.

А вот за что провайдер, как правило, не отвечает:

• сбои в приложениях и коде, который развёрнут на сервере клиентом;
• ошибки конфигурации, допущенные пользователем;
• простой из-за DDoS-атаки на уровне приложения, если это отдельно не прописано;
• плановые технические работы, о которых заранее предупредили.

Поэтому важно читать не только итоговый процент, но и раздел «зона ответственности». Иногда за красивой цифрой 99,99% скрывается оговорка, что она касается только сетевой доступности, а не работы диска или процессора.

Как проверить, действительно ли провайдер выполняет свои обещания?

Самый простой способ — независимый мониторинг доступности. Существуют внешние сервисы, которые с определённой периодичностью «пингуют» сервер и фиксируют время реакции и падения. Это позволяет собрать собственную статистику, не полагаясь только на отчёты провайдера.

Полезно также изучить историю статуса сервиса — многие провайдеры ведут публичную страницу инцидентов, где фиксируют аварии, их причины и время устранения. Отсутствие такой страницы или её постоянная «пустота» при известных проблемах — повод насторожиться. Ещё один сигнал — как быстро и открыто провайдер сообщает о сбоях: честное признание проблемы обычно говорит о зрелости компании больше, чем идеальные цифры в рекламе.

Что происходит, если провайдер нарушил SLA — компенсации реальны?

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

Обычно для получения компенсации нужно самостоятельно зафиксировать инцидент и обратиться в поддержку в установленный срок — задним числом такие вопросы решаются редко. Поэтому имеет смысл держать под рукой собственные логи мониторинга: они станут аргументом в диалоге с провайдером.

На что ещё смотреть в договоре, кроме процента аптайма?

Процент — это только вершина айсберга. Важно обратить внимание на:

• время реакции техподдержки на обращение — от него часто зависит, как быстро устранят проблему;
• наличие резервного питания и дублирующих каналов связи в дата-центре;
• условия проведения плановых работ — предупреждают ли заранее и как часто это случается;
• прозрачность расчёта простоя — считается ли время реакции на инцидент, диагностики и устранения.

Если в договоре нет конкретики, а есть только общие фразы вроде «мы стремимся обеспечить максимальную доступность», это не SLA в юридическом смысле, а декларация о намерениях.

Как SLA связан с безопасностью и резервным копированием?

SLA обычно описывает именно доступность, а не сохранность данных — это разные вещи. Сервер может быть доступен 99,99% времени, но если на нём случится сбой диска без бэкапов, доступность не спасёт от потери информации. Поэтому SLA стоит рассматривать вместе с политикой резервного копирования и защиты от атак: это дополняющие друг друга слои надёжности, а не взаимозаменяемые гарантии.

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

Как выбрать SLA под реальные задачи бизнеса, а не переплачивать за лишнее?

Не всякому проекту нужна «пятерка девяток». Для внутреннего тестового сервера или сайта-визитки достаточно стандартных гарантий, а вот для интернет-магазина с постоянным потоком заказов или сервера с базой 1С, от которой зависит бухгалтерия компании, стоит выбирать более высокий уровень доступности и внимательно читать зону ответственности провайдера.

Главное правило простое: чем критичнее сервис для бизнеса, тем внимательнее нужно изучать не рекламные цифры, а конкретные пункты договора — что считается простоем, кто и как его фиксирует, и какая компенсация предусмотрена. Тогда SLA перестаёт быть просто строчкой в прайсе и становится реальным инструментом защиты бизнеса.