Миф: SLA 99,99% гарантирует, что сайт будет доступен

MAATRIX

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

Что провайдер на самом деле обещает под цифрой SLA

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

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

Где заканчивается зона ответственности провайдера

Список того, что типично остаётся за пределами SLA хостинга, обычно шире, чем кажется на старте:

• баги и утечки памяти в вашем коде, из-за которых процесс падает или зависает;
• неправильные лимиты — переполненный пул PHP-FPM, исчерпанный max_connections в базе, упёршийся в потолок worker_connections в nginx;
• всплеск легитимного трафика (рекламная кампания, вирусный пост), с которым не справляется текущая конфигурация приложения;
• ошибка при деплое — выкатили миграцию, которая заблокировала таблицу, или конфиг, который уронил веб-сервер;
• истёкший TLS-сертификат, если продление настраивали и следили за ним вы, а не панель хостинга;
• проблемы на уровне DNS у регистратора домена — это отдельная организация с собственным (или отсутствующим) SLA;
• падение стороннего API или сервиса, от которого зависит ваше приложение (платёжный шлюз, внешняя аутентификация, CDN);
• человеческая ошибка — случайно удалённая таблица, неверно применённый iptables -F, забытый DROP DATABASE в проде вместо тестового стенда.

Ключевой момент: с точки зрения мониторинга провайдера сервер в этот момент полностью «жив» — VM запущена, сеть отвечает, гипервизор в порядке. Их SLA не нарушен ни на секунду. А для пользователя, который видит 502 или белый экран, сайт при этом полностью недоступен. Это два разных определения слова «доступность», и в договоре речь идёт только про первое.

Как читать формулировку «недоступности» в самом договоре

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

• Как измеряется простой — по какому протоколу и с какой точки. Проверка ICMP-пинга до узла и проверка TCP-соединения на 80/443 порт — разные вещи, и договор может ссылаться именно на первую, более мягкую.
• Откуда идёт измерение — с мониторинговых точек самого провайдера, зачастую расположенных внутри его же сети. Если проблема в маршрутизации между вами и дата-центром, а не в самом узле, по внутренним меткам провайдера инцидента может не быть вовсе.
• Окно агрегации — процент обычно считается за календарный месяц, а не скользящим окном. Несколько коротких сбоев, раскиданных по разным месяцам, могут по отдельности не выбить процент ни в одном из них.
• Что явно исключено — плановые технические работы (обычно анонсируются заранее и не считаются простоем), форс-мажор, действия самого клиента, атаки, проблемы на стороне сетей, не принадлежащих провайдеру.
• Что считается началом и концом инцидента — нужно ли вам подавать тикет, чтобы отсчёт вообще начался, или простой фиксируется автоматически их собственной системой мониторинга.

Эти детали решают, применим ли SLA вообще к конкретному вашему случаю простоя. Разбор того, как именно устроены типичные формулировки процентов и на что обращать внимание построчно, — в статье SLA в договоре: как читать проценты и компенсации.

Компенсация при нарушении — не то же самое, что возмещение убытков

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

Дополнительно стоит учитывать практическую сторону получения компенсации:

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

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

Арифметика 99,99%: сколько это в минутах и что она на самом деле означает

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

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

Ещё один нюанс арифметики: месячный процент считается суммарно, а не равномерно. 43 минуты простоя за месяц на уровне 99,9% — это на практике почти всегда один инцидент длиной в 40+ минут, а не десятки секундных сбоев, размазанных по неделям. Подробнее про эту особенность и почему «почти идеальный» процент субъективно ощущается как редкая, но заметная авария, — в статье Миф: 99,9% аптайма — это почти всегда.

Что реально снижает риск простоя именно вашего сервиса

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

• Собственный внешний мониторинг, который проверяет не «пингуется ли сервер», а конкретный бизнес-сценарий — например, HTTP-запрос к странице оформления заказа с проверкой кода ответа и наличия ожидаемого текста в теле. Мониторинг провайдера этого не делает и делать не обязан.
• Health-check эндпоинт, который реально проверяет зависимости приложения — соединение с базой, доступность кеша, а не просто отдаёт статичный 200 OK с любой открытой страницы.
• Автоперезапуск упавшего процесса — простой пример для сервиса под systemd:

[Service]
Restart=on-failure
RestartSec=5
StartLimitIntervalSec=60
StartLimitBurst=3

• Разумные лимиты вместо значений по умолчанию — pm.max_children в PHP-FPM, max_connections в PostgreSQL/MySQL, worker_connections в nginx, рассчитанные под доступную память, а не оставленные как в дефолтном конфиге дистрибутива.
• Стейджинг перед продакшеном — деплой и миграции сначала на копии окружения, а не сразу на боевой базе.
• Документированный план отката — понятная и проверенная процедура «откатить деплой за N минут», а не «разберёмся по ходу дела».
• Алерты в мессенджер, а не только в почту, которую никто не проверяет ночью.

Настройка внешнего мониторинга с алертами — отдельная практическая задача, которая закрывает ровно ту зону, которую не закрывает SLA. Пошаговая инструкция — в статье Мониторинг и алерт при падении сайта.

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