Какой SLA должен быть у компании, чтобы обеспечить 99.9% доступности сервиса в 2026 году?

99,9% доступности — это не проценты в договоре, а 8,8 часа простоя в год. Для сервиса, который приносит деньги, это ощутимо. Для лендинга-визитки — часто избыточно. Вопрос не в том, «какой SLA попросить», а в том, какой уровень вы готовы обслуживать своими процессами и финансировать. Спрос на «пять девяток» в 2026 году — маркетинговый шум. Реальность малого и среднего бизнеса в России — честные 99,5–99,9% с прописанной реакцией на инциденты.

Ниже — спецификация SLA, которую можно вставить в договор с подрядчиком или в техническое задание на разработку. Без воды, с критериями готовности и границами ответственности.

Что такое SLA на самом деле

Соглашение об уровне услуг (SLA) — это не «обещание работать без сбоев», а формальный договор, где описаны услуга, права сторон и измеримые показатели качества. Термин пришёл из ITIL, и там он означает именно контракт, а не абстрактное «мы будем стараться».

В SLA три слоя:

• Целевой уровень (SLO) — конкретная цель: «доступность 99,9% в месяц».
• Показатель (SLI) — как эту цель измеряем: «доля успешных HTTP-запросов к сайту за месяц».
• Условия применения — что считается инцидентом, что не считается, и какие штрафы или бонусы.

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

Первое правило: SLA без метрик — это мусор. Вы покупаете файл, а не решение.

Сколько девяток нужно именно вам

Разложим цифры по полочкам. 99,9% — это 43,8 минуты простоя в месяц или 8,8 часа в год. 99,5% — это 3,6 часа в месяц или 43,8 часа в год. 99,99% — это 4,4 минуты в месяц или 52,6 минуты в год.

Теперь честно ответьте на вопрос: что происходит, когда ваш сайт лежит ночью?

Сценарий «сайт лежал ночь, формы не ушли»:

• Если это лендинг для сбора заявок — вы потеряли несколько лидов. Обидно, но не смертельно. 99,5% хватит.
• Если это интернет-магазин с оплатой — вы потеряли деньги и доверие. 99,9% оправдано.
• Если это личный кабинет клиента с данными — вы рискуете репутацией и договорными штрафами. 99,9% минимум, лучше 99,95%.

Для 90% малого бизнеса в России 99,9% — это потолок разумного. Дальше начинается инженерия, которая стоит денег: кластеры, балансировщики, резервные дата-центры, дежурные инженеры. Вопрос не в том, «какой SLA у компании», а в том, «какой SLA вы готовы финансировать».

Правило: не платите за девятки, которые не приносят вам денег. 99,99% для визитки стоматологии — это выброшенные деньги.

Спецификация SLA: что должно быть в договоре

Ниже — готовая структура. Можете копировать в техническое задание или договор. Это не шаблон «для галочки», а рабочий чертёж.

1. Предмет и границы

Чётко определите, на что распространяется SLA. «Сайт работает» — это не определение. «Доступность главной страницы, страниц каталога и API для оформления заказа» — это определение.

Что обычно НЕ входит в SLA подрядчика:

• Сбои хостинга, если хостинг — отдельный провайдер (ваша зона ответственности).
• Проблемы с доменом или DNS, если домен зарегистрирован на вас.
• Сбои сторонних сервисов: платёжные шлюзы, SMS-шлюзы, CDN.
• Действия пользователей: кто-то залил 10 ГБ видео на хостинг и сайт лёг.

Пропишите это явно. Иначе подрядчик будет говорить «это не наша вина, это хостинг», и формально будет прав.

2. Метрики (SLI)

Определите, как измеряете доступность. Варианты:

• HTTP-проверка снаружи — мониторинг пингует сайт каждые 60 секунд из 2–3 точек. Считается простоем, если сайт недоступен более 3 минут подряд. Это стандарт.
• Внутренние метрики — аптайм сервера, нагрузка CPU, ошибки 5xx. Это для диагностики, но не для SLA.
• Скорость ответа — время ответа сервера. Для SLA обычно не критично, но можно добавить как цель: «95% запросов отвечают за 500 мс».

Важно: доступность считается в процентах от общего времени в месяце. Формула: (общее время — время простоя) / общее время × 100%. Пропишите, что считается «временем простоя»: только полная недоступность или также ошибки 5xx на 10% запросов.

3. Реакция на инциденты

Это важнее, чем проценты. Сайт может лежать 2 часа, но если подрядчик за 15 минут нашёл причину и за 30 минут восстановил — это хорошая работа. А если сайт лежал 40 минут (в пределах 99,9%), но подрядчик отвечал на тикеты 3 часа — это плохая работа.

Пропишите уровни критичности:

Время реакции — это время до первого ответа инженера. Время решения — до восстановления. Для P0 в рабочее и нерабочее время условия могут отличаться. Если ваш бизнес работает 24/7 — требуйте реакцию 24/7. Если только в будни с 9 до 18 — экономьте на ночной поддержке.

4. Штрафы и компенсации

Без штрафов SLA — это декларация о намерениях. Пропишите финансовую ответственность. Варианты:

• Процент от месячной оплаты — за каждый час простоя сверх нормы скидка 10% от месячного платежа. Потолок — 50%.
• Фиксированная сумма — за P0-инцидент с простоем более 4 часов — компенсация 10 000 ₽.
• Бонусы — если доступность 99,95% три месяца подряд — скидка 5% на следующий квартал.

Важно: штрафы должны быть соразмерны. Если вы платите подрядчику 30 000 ₽/мес, требовать штраф 100 000 ₽ за час простоя — нереалистично. Подрядчик либо откажется, либо заложит риски в цену.

5. Отчётность

Требуйте ежемесячный отчёт. В нём должно быть:

• Фактическая доступность за месяц (в процентах).
• Список инцидентов с датами, длительностью и причинами.
• Анализ корневых причин (RCA) для P0-инцидентов — что случилось и что сделали, чтобы не повторилось.
• План действий на следующий месяц.

Если подрядчик не может предоставить отчёт — значит, он не ведёт метрики. А если не ведёт метрики — его SLA ничего не стоит.

Где подрядчик срезает углы

Типичные уловки, которые обесценивают SLA:

• «Плановая недоступность». Подрядчик исключает из расчёта время на обновления и регламентные работы. Формально — 99,9%, фактически — сайт лежит каждую ночь с 2 до 4. Пропишите: плановые окна не должны превышать 4 часов в месяц и должны согласовываться за 48 часов.
• «Сбой хостинга — не наша вина». Если подрядчик сам выбирает хостинг и управляет им — это его зона ответственности. Если хостинг выбирали вы — это ваша проблема. Пропишите, кто отвечает за инфраструктуру.
• «DDoS-атака — форс-мажор». Частично правда, но подрядчик должен иметь базовую защиту. Пропишите: подрядчик обязан подключить минимальную защиту от DDoS (фильтрация на уровне хостинга или CDN).
• «Мониторинг с одного сервера». Если мониторинг пингует сайт из той же сети, что и хостинг, — при падении сети мониторинг «не заметит» проблемы. Требуйте внешний мониторинг из 2–3 точек.

Ещё одна уловка — «доступность API не входит в SLA». Если ваш сайт — это одностраничное приложение, которое работает через API, то недоступность API = недоступность сайта. Пропишите это явно.

Что делать, если SLA нет

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

Если SLA нет, но работать надо — сделайте свой мониторинг. Бесплатные инструменты (UptimeRobot, HetrixTools) пингуют сайт каждые 5 минут и шлют уведомления в Telegram. Это не заменит SLA, но даст вам факты для разговора с подрядчиком.

Сценарий «сайт лежал ночь, формы не ушли» без SLA:

1. Вы узнали о проблеме утром от клиента.
2. Подрядчик говорит «мы ничего не заметили».
3. Вы не можете доказать, что сайт лежал, потому что нет мониторинга.
4. Вы теряете заявки и нервы.

С мониторингом:

1. В 3:15 ночи вам пришло уведомление в Telegram.
2. Вы написали подрядчику (даже если он не в SLA, он ответит).
3. К 5:00 сайт подняли.
4. Утром у вас есть скриншоты простоя для разговора.

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

Практический сценарий: как внедрить SLA за квартал

Допустим, у вас сайт на WordPress или Tilda, подрядчик — небольшая студия. Вот план.

Неделя 1–2: аудит

• Зафиксируйте текущую доступность. Поставьте внешний мониторинг (UptimeRobot, бесплатный тариф).
• Соберите данные за 2 недели. Если доступность ниже 99% — это база для разговора.
• Определите, какие страницы критичны: главная, каталог, корзина, оплата.

Неделя 3–4: переговоры

• Подготовьте проект SLA на основе структуры выше.
• Начните с 99,5% и реакции в рабочее время. Это реалистично для большинства студий.
• Если подрядчик согласен на 99,9% — отлично, но требуйте метрики и отчётность.

Квартал: контроль

• Требуйте ежемесячный отчёт. Если не дают — напоминайте.
• Сверяйте отчёт с данными своего мониторинга. Расхождения — повод для разговора.
• Если SLA нарушается 2 месяца подряд — меняйте подрядчика или пересматривайте условия.

Это не «процесс ради процесса». Это способ получить предсказуемость. Вы платите за результат, а не за обещания.

Чек-лист: проверьте SLA перед подписанием

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

На этой неделе

1. Поставьте внешний мониторинг на сайт. Бесплатный тариф UptimeRobot или аналог. Настройте уведомления в Telegram.
2. Соберите данные о доступности за 7 дней. Если есть простои — зафиксируйте даты и время.
3. Напишите подрядчику письмо с вопросом: «Какой SLA вы можете предоставить?». Приложите данные мониторинга. Посмотрите на реакцию.

Это три действия, которые не требуют бюджета и дают фактуру для переговоров. Через месяц у вас будет либо нормальный SLA, либо понимание, что подрядчика пора менять.