SLA в поддержке сайта - это раздел договора со сроками: в какие часы вас обслуживают, за сколько подрядчик отвечает на обращение, за какое время устраняет аварию и что будет, если сроки нарушены. Без этих цифр договор поддержки ничем не подкреплён.
Коротко: SLA (Service Level Agreement) в поддержке сайта - это раздел договора, в котором зафиксировано не «что мы делаем», а «за какое время и с какой гарантией». Рабочий SLA всегда отвечает на четыре вопроса: в какие часы вас обслуживают, за сколько минут или часов подрядчик отвечает на обращение, за какое время устраняет проблему каждого уровня критичности и что происходит, если сроки нарушены. Всё остальное в договоре поддержки - объём работ и цена. Без SLA договор превращается в обещание «постараемся ответить побыстрее», которое ничем не подкреплено.
Актуально на август 2026 года. По опыту Honey Hunters Digital, 8 из 10 договоров на сопровождение сайта, которые приносят нам клиенты при переходе от прежнего подрядчика, вообще не содержат сроков реакции. В них есть перечень работ, есть абонентская плата, есть реквизиты - и нет ни одной цифры про время. Именно поэтому история «сайт лежал двое суток, а подрядчик отвечал в чате смайликами» юридически заканчивается ничем. Ниже разберём, из чего состоит нормальный SLA, какие сроки считаются рыночной нормой и на какие формулировки в договоре смотреть до подписания.
Что такое SLA в поддержке сайта простыми словами
SLA - это измеримые обязательства подрядчика по скорости и качеству обслуживания, вынесенные в отдельный раздел договора или приложение к нему. В отличие от описания услуг, SLA оперирует цифрами: часы работы, минуты до ответа, часы до восстановления, процент доступности сайта за месяц.
Проще всего понять разницу на примере. Формулировка «подрядчик осуществляет техническую поддержку сайта заказчика» - это не SLA, это описание предмета договора. Формулировка «при полной недоступности сайта исполнитель приступает к работам в течение 1 часа с момента обращения в рабочее время и восстанавливает работоспособность в течение 4 часов» - это SLA. Первую нельзя нарушить, вторую можно, и именно поэтому вторая работает.
SLA нужен не только для того, чтобы кого-то наказать. Его главная функция - совместить ожидания. Владелец сайта считает, что «срочно» значит «через двадцать минут», подрядчик считает, что «в течение рабочего дня». Пока это не записано, каждый прав по-своему, и конфликт неизбежен при первой же аварии.
Из чего состоит рабочий SLA: обязательные пункты
Полноценный SLA в договоре на поддержку сайта состоит из шести блоков. Если какого-то из них нет, договор придётся дополнять по факту первого же спорного случая, а это всегда происходит в худший момент.
- Часы обслуживания. Например, «пн-пт с 9:00 до 18:00 по московскому времени, кроме государственных праздников». Отдельно оговаривается, есть ли дежурство в нерабочее время и на каких условиях.
- Каналы обращений. Один-два официальных канала, по которым обращение считается зарегистрированным: почта поддержки, таск-трекер, отдельный чат. Сообщение в личку менеджеру в мессенджере обращением не считается - и это должно быть написано прямо.
- Классификация обращений по критичности. Обычно 3-4 уровня: авария, серьёзная ошибка, обычная задача, доработка. Для каждого уровня - свои сроки.
- Время реакции и время решения по каждому уровню критичности.
- Порядок эскалации. Кому и как писать, если по обращению нет движения: имя, телефон, срок, после которого можно поднимать вопрос выше.
- Последствия нарушения сроков. Скидка на следующий месяц, компенсация часов, право расторгнуть договор без штрафа. Пункт, который чаще всего отсутствует.
Отдельно стоит зафиксировать и обязанности заказчика: SLA работает в обе стороны. Если подрядчик ждёт доступ к хостингу трое суток, время ожидания не должно засчитываться ему в просрочку - это нормальная и честная оговорка.
Время реакции и время решения: в чём разница
Время реакции - это срок, за который подрядчик подтверждает получение задачи и берёт её в работу. Время решения - срок, за который проблема устранена. Это две разные цифры, и подмена одной другой - самая частая уловка в договорах поддержки.
Договор, где написано только «время реакции - 2 часа», формально выполняется, даже если сайт лежит неделю: ответ ведь был дан вовремя. Поэтому в SLA обязаны стоять обе цифры, причём время решения - хотя бы для критичных инцидентов. Для обычных задач вместо жёсткого срока решения допустим срок «взять в работу и согласовать плановую дату» - это честно, потому что заранее оценить доработку невозможно.
Третья полезная цифра - время обхода (workaround). Иногда быстро починить нельзя, но можно вернуть сайту работоспособность временным решением: откатить обновление, отключить сбойный модуль, поднять сайт из резервной копии. Хороший SLA разрешает подрядчику закрыть аварию обходным решением, а полное исправление вынести в отдельную задачу с плановым сроком.
Какие сроки реакции считаются нормальными
Рыночная норма для абонентской поддержки сайта в рабочее время - от 15 минут до 2 часов на реакцию в зависимости от критичности и от 2 до 8 часов на восстановление при аварии. Ниже - ориентиры, на которые можно опираться при чтении чужого договора.
- Уровень 1, авария. Сайт полностью недоступен, не работает оплата или приём заявок, видны следы взлома. Реакция - 15-60 минут в рабочее время, восстановление - 2-8 часов.
- Уровень 2, серьёзная ошибка. Сайт работает, но сломан важный сценарий: не отправляется форма, не открывается раздел каталога, ошибка в корзине на одном из шагов. Реакция - до 4 часов, решение - 1-2 рабочих дня.
- Уровень 3, обычная задача. Поправить текст, заменить баннер, добавить страницу, обновить прайс. Реакция - в течение рабочего дня, выполнение - 1-3 рабочих дня или по согласованной очереди.
- Уровень 4, доработка. Новый функционал, интеграция, переделка раздела. Реакция - оценка трудозатрат в течение 2-3 рабочих дней, срок выполнения согласуется отдельно.
Круглосуточная поддержка 24/7 с реакцией в 15 минут технически возможна, но стоит принципиально других денег: она требует дежурной смены. Для большинства корпоративных сайтов и небольших магазинов достаточно рабочих часов плюс отдельной «красной кнопки» для настоящих аварий. Если подрядчик обещает 24/7 внутри базового тарифа за небольшую сумму - это почти всегда означает, что ночью вам просто ответят утром.
Что входит в оплаченные часы, а что считается отдельно
В абонентскую плату обычно входит оговорённый объём человеко-часов и регламентные работы, а всё, что выходит за этот объём, оплачивается по часовой ставке. Главное, что нужно понять до подписания: как именно считаются часы и что происходит с неизрасходованными.
Три вопроса, ответы на которые должны быть в договоре чёрным по белому:
- Переносятся ли неиспользованные часы на следующий месяц. В базовых пакетах чаще всего нет, в крупных - да. Это не хитрость, а разная экономика: маленький пакет резервирует специалиста, большой продаёт объём.
- Каков минимальный тарифицируемый интервал. Если любая задача округляется до часа, «поправить телефон в шапке» съест полный час из пакета. Нормальная практика - округление до 15 минут.
- Что не входит в часы вообще. Обычно за периметром остаются лицензии CMS и модулей, хостинг, домен, работы сторонних подрядчиков и восстановление после действий третьих лиц, у которых тоже были доступы.
Регламентные работы стоит перечислить отдельным списком: мониторинг доступности, резервное копирование и проверка копий, обновления CMS и модулей, продление сертификата, проверка форм и почты. Если этих пунктов нет, поддержка де-факто превращается в режим «сломалось - позвоните», а профилактики не будет. Подробный перечень мы разбирали в материале что входит в техническую поддержку сайта, его удобно использовать как основу приложения к договору.
Чек-лист: на что смотреть в договоре до подписания
Проверить договор поддержки можно за 20 минут по девяти пунктам. Если хотя бы четыре из них не находятся в тексте, документ стоит дорабатывать.
- Указаны часы обслуживания с часовым поясом, а не «в рабочее время».
- Перечислены официальные каналы обращений и момент, с которого считается срок.
- Есть классификация обращений по критичности с примерами, а не абстрактное «срочные задачи».
- Для каждого уровня указано и время реакции, и время решения (или порядок согласования срока).
- Прописан объём часов в месяц, ставка сверх пакета и правило переноса остатка.
- Указан минимальный тарифицируемый интервал.
- Есть перечень регламентных работ и их периодичность.
- Описан порядок эскалации с контактами ответственного.
- Зафиксированы последствия нарушения SLA и порядок расторжения с передачей доступов и материалов.
Девятый пункт часто недооценивают, а он самый дорогой. Договор должен предусматривать, что при расторжении подрядчик передаёт все доступы, исходники, схему инфраструктуры и актуальную резервную копию в разумный срок - например, 5 рабочих дней. Без этого пункта расставание превращается в переговоры с позиции слабого. Как выглядит полный набор передаваемого, мы описывали в статье как передать сайт новому подрядчику.
Красные флаги: формулировки, которые лучше исправить
Есть несколько типовых формулировок, которые выглядят безобидно, но на практике полностью обнуляют SLA. Их стоит переписать до подписания, а не после первой аварии.
- «В разумные сроки», «в кратчайшие сроки», «оперативно». Юридически это ноль. Требуйте цифру.
- «Исполнитель не несёт ответственности за работоспособность сайта». В таком виде пункт снимает ответственность вообще за всё. Ограничение ответственности нормально, но оно должно касаться внешних причин: аварий хостинга, действий заказчика, форс-мажора.
- Время реакции без времени решения. Разобрали выше: договор выполняется, сайт лежит.
- Отсутствие учёта часов. Если нет отчёта о потраченном времени, проверить расход пакета невозможно. Отчёт раз в месяц с расшифровкой задач - обязательное приложение.
- Автопролонгация без права выхода. Договор, который нельзя расторгнуть с уведомлением за 30 дней, - плохой договор независимо от цены.
- Доступы только у подрядчика. Владельцем аккаунтов хостинга, домена и систем аналитики должен быть заказчик. Подрядчик получает доступ, а не собственность.
Как мы фиксируем условия в Honey Hunters Digital
Наши тарифы на сопровождение построены вокруг объёма часов и правил их расходования - именно эти пункты чаще всего становятся предметом спора, поэтому мы выносим их в договор явно.
- Базовый тариф - от 15 000 ₽ в месяц. Включает 4 часа работ и «Красную кнопку» - канал для аварийных обращений. Неизрасходованные часы на следующий месяц не переносятся.
- Тариф 51 000 ₽ в месяц. Стоимость часа - 3 000 ₽, неизрасходованные часы переносятся на следующий месяц.
- Тариф 96 000 ₽ в месяц. Стоимость часа - 2 900 ₽, часы также переносятся.
Логика простая: чем больше объём, тем ниже цена часа и тем гибче правила переноса. К любому из тарифов прикладывается перечень регламентных работ и порядок обращений, чтобы «поддержка» не оставалась словом с плавающим значением. Подробнее об услуге - на странице развития и поддержки сайтов, а как формируется цена в целом по рынку, мы разбирали в материале сколько стоит обслуживание сайта в месяц.
Если вы сейчас держите в руках чужой договор и не понимаете, что в нём не так, - пришлите его нам, посмотрим вместе и скажем прямо, каких пунктов не хватает и чем это грозит. Написать можно через форму на странице контактов. А чтобы такие разборы попадались вам чаще, заглядывайте в наш телеграм «Тусовка владельцев сайтов» - t.me/sitetusovka: там мы без купюр обсуждаем договоры, подрядчиков и сайты, которые внезапно перестали работать.
Частые вопросы
Обязателен ли SLA в договоре на поддержку сайта?
Юридически нет - договор действителен и без него. Практически без SLA у заказчика нет ни одного измеримого основания предъявить претензию по срокам, поэтому раздел со сроками стоит требовать всегда, даже при небольшом абонентском платеже.
Чем SLA отличается от списка работ по поддержке?
Список работ отвечает на вопрос «что делают», SLA - на вопрос «за какое время и с какой гарантией». Это разные приложения к договору, и одно не заменяет другое.
Что такое «время реакции» и почему его мало?
Время реакции - срок, за который подрядчик подтверждает получение задачи и берёт её в работу. Само по себе оно ничего не гарантирует: формально ответить за час и чинить неделю - это соблюдённый SLA. Нужна вторая цифра, время решения.
Какая доступность сайта считается нормальной в SLA?
Для обычного корпоративного сайта на рынке фиксируют доступность 99-99,5% в месяц, что допускает от 3,5 до 7 часов простоя. Важно смотреть, чью зону ответственности покрывает цифра: доступность обеспечивает в первую очередь хостинг, а подрядчик отвечает за скорость реакции и восстановления.
Что делать, если подрядчик нарушил сроки по SLA?
Зафиксировать нарушение в официальном канале обращений, направить претензию со ссылкой на пункт договора и потребовать предусмотренную компенсацию: скидку, возврат часов или расторжение без штрафа. Если санкции в договоре не описаны, добиться чего-либо будет практически невозможно - поэтому этот пункт и проверяют до подписания.
Дата публикации: 2026-08-30






