Я Максим, веб-разработчик. SLA (Service Level Agreement) — это договор, который фиксирует, что именно входит в поддержку сайта, за какое время вы реагируете на проблемы и какие гарантии даёте. Казалось бы, формальность. Но за годы работы я убедился: без SLA поддержка сайта превращается в хаос. Клиент ожидает «всё бесплатно и мгновенно», а подрядчик подразумевает «позвоните в понедельник». SLA ставит всё на свои места и превращает неопределённость в прозрачные правила игры.

Зачем нужен SLA: реальные ситуации

Вот типичная история. Сайт упал в пятницу вечером. Интернет-магазин, заказы перестали приходить. Клиент звонит разработчику в панике. Без SLA разработчик формально не обязан отвечать — рабочее время закончилось. Клиент злится, считает подрядчика безответственным. Подрядчик злится, потому что его отвлекают в нерабочее время. Конфликт, потеря доверия, иногда — разрыв отношений.

С SLA всё прозрачно. В документе написано: «Критические инциденты — реакция в течение 2 часов, включая выходные и праздники. Некритические — в течение 8 рабочих часов». Клиент знает, что его не бросят. Подрядчик знает, за что ему платят. Никаких обид и недопонимания.

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

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

Что включить в SLA: полная структура документа

Категории инцидентов

Не все проблемы одинаково критичны. SLA должен классифицировать инциденты по степени влияния на бизнес клиента.

Критический уровень. Сайт полностью недоступен, не работает приём оплаты, произошла утечка данных, взлом сайта. Бизнес теряет деньги каждую минуту. Это ситуации, когда нужно бросить всё и чинить.

Высокий уровень. Не работает форма заявки на главной странице, ошибки на ключевых посадочных страницах, не приходят уведомления о заказах, страница выдаёт 500-ю ошибку. Сайт формально работает, но ключевой бизнес-функционал нарушен.

Средний уровень. Косметические баги — поехала вёрстка на определённом устройстве, не загружается одно изображение, опечатка на второстепенной странице. Неприятно, но бизнес-процессы не пострадали.

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

Чёткая классификация избавляет от споров «а это разве не критично?!». Клиент видит таблицу и сам может определить категорию своей проблемы. А подрядчик — обосновать приоритет реакции.

Время реакции и время решения

Это два разных понятия, и их важно разделить в документе.

Время реакции — период от момента получения обращения до момента, когда подрядчик подтвердил, что видит проблему и взял её в работу. Это не решение, а просто «мы в курсе, работаем». По моему опыту, оптимальные значения: критический — 1–2 часа (включая нерабочее время); высокий — 4–8 рабочих часов; средний — 1–2 рабочих дня; низкий — 3–5 рабочих дней.

Время решения — период от взятия задачи в работу до фактического устранения проблемы. Здесь важно оговорить, что время решения может зависеть от сложности инцидента и наличия доступа к нужным сервисам (хостинг, DNS, база данных). Рекомендуемые сроки: критический — 4–8 часов; высокий — 1–2 рабочих дня; средний — 3–5 рабочих дней; низкий — по отдельному согласованию.

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

Гарантия доступности (uptime)

Один из ключевых пунктов SLA — гарантированный процент доступности сайта.

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

99,9 % — для интернет-магазинов и критичных бизнес-сервисов. Допускается примерно 43 минуты простоя в месяц. Требует качественного хостинга, мониторинга и резервирования.

99,99 % — для крупных e-commerce и финтех-проектов. Допускается около 4 минут простоя в месяц. Требует серьёзной инфраструктуры: балансировщики нагрузки, географически распределённые серверы, автоматический failover. Стоимость поддержки такого уровня — соответствующая.

Важно оговорить, что в расчёт uptime не входят: плановые технические работы (с предварительным уведомлением клиента), сбои на стороне хостинг-провайдера, форс-мажоры, действия третьих лиц (DDoS-атаки, блокировки провайдером). Без этих исключений вы рискуете нести ответственность за вещи, которые не контролируете.

Перечень включённых услуг

Чем конкретнее — тем меньше конфликтов. Вот что обычно я включаю в базовый пакет поддержки.

Мониторинг работоспособности сайта — автоматическая проверка доступности каждые 5 минут, уведомление подрядчика при сбоях. Я использую UptimeRobot или аналогичные сервисы, которые пингуют сайт и мгновенно оповещают при недоступности.

Резервное копирование — ежедневный бэкап базы данных и файлов, хранение копий за последние 30 дней. Это критически важный пункт, который спасает в самых тяжёлых ситуациях.

Обновление CMS, фреймворка и зависимостей — для WordPress это обновление ядра, плагинов и темы; для Next.js — обновление npm-пакетов, закрытие уязвимостей. Обновления делаю на тестовой копии, проверяю — и только потом накатываю на продакшн.

Исправление багов — устранение ошибок в работе сайта, возникших не по вине клиента.

Мелкие правки контента — замена текста, изображений, добавление новых элементов. Обычно я закладываю лимит: 2–4 часа в месяц на мелкие правки. Всё что сверх — оплачивается дополнительно.

Базовый мониторинг безопасности — проверка на наличие вредоносного кода, актуальность SSL-сертификата.

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

Порядок обращения

Клиент должен знать, как именно сообщить о проблеме. Я обычно предлагаю несколько каналов с разной скоростью реакции.

Трекер задач (Notion, Яндекс Трекер, простая Trello-доска) — основной канал для некритических обращений. Всё фиксируется, ничего не теряется, есть история.

Email на выделенный адрес поддержки — для формальных запросов и документирования.

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

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

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

Отчётность

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

Отчёт занимает 30–40 минут на подготовку, но даёт огромный вклад в удержание клиента. Человек видит, что поддержка — не абстрактная «страховка», а конкретная работа с измеримыми результатами.

Ценообразование: сколько стоит поддержка сайта по SLA

За годы работы я сформировал три типовых тарифа, которые покрывают потребности большинства клиентов.

Базовый (10 000–20 000 рублей в месяц). Мониторинг, бэкапы, обновления, исправление критических багов, 2 часа мелких правок. Реакция в рабочие часы. Подходит для корпоративных сайтов и визиток, которые не генерируют прямой доход.

Расширенный (30 000–60 000 рублей в месяц). Всё из базового + приоритетная реакция на критические инциденты (включая выходные), 4–6 часов мелких правок, мониторинг безопасности, оптимизация производительности. Подходит для сайтов услуг и каталогов с активным входящим трафиком.

Приоритетный (от 80 000 рублей в месяц). Реакция 24/7, гарантия uptime 99,9 %, выделенный канал связи, 8–12 часов работ в месяц, ежеквартальный аудит безопасности и производительности. Для интернет-магазинов и сервисов, где каждый час простоя — прямые финансовые потери.

Стоимость зависит от сложности сайта, технологического стека и объёма ответственности. Сайт на WordPress с парой десятков страниц — одна цена. Кастомная платформа на Next.js с интеграциями, API и личным кабинетом — совсем другая. При оценке стоимости я считаю: сколько времени в среднем занимает поддержка такого проекта в месяц, умножаю на свою часовую ставку и закладываю запас на непредвиденные ситуации.

Юридическое оформление

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

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

Отдельный пункт — порядок расторжения. Обычно 30 дней на уведомление, передача всех доступов и документации, финальный отчёт.

Типичные ошибки при составлении SLA

Обещания, которые невозможно выполнить. Гарантия реакции за 15 минут 24/7 при бюджете поддержки 15 000 рублей — это нереально. Не давайте обещаний, которые не можете выполнить. Лучше честно сказать «реакция в рабочие часы в течение 4 часов» и стабильно это выполнять.

Размытые формулировки. «Оперативная реакция на проблемы» — это не SLA. Сколько конкретно? Часы? Дни? Рабочие или календарные? Каждый пункт должен быть измеримым.

Отсутствие разделения на категории. Когда все обращения обрабатываются с одинаковым приоритетом — критические инциденты ждут в очереди за мелкими правками. Категоризация обязательна.

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

Подведу итог

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