Сайт после запуска: сколько стоит поддержка и что прописать в SLA

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

Разберём, какие расходы появляются после релиза, что на самом деле означает слово «поддержка» в коммерческом предложении и какие пункты стоит закрепить в договоре, чтобы через год не спорить, кто и за что отвечает.

Обязательные расходы, которые есть у любого сайта

Есть платежи, без которых сайт просто перестанет открываться. Они не зависят от подрядчика и обычно невелики, но их легко пропустить, если оплата привязана к чужой карте или чужой почте.

• Домен. Продление раз в год. Если домен зарегистрирован на сотрудника или на студию, это первая вещь, которую нужно исправить: администратором домена должна быть компания.
• Хостинг или сервер. Виртуальный хостинг для сайта-визитки, VPS или облако для CRM и интернет-магазина. Подробно варианты мы разбирали в статье про выбор хостинга.
• SSL-сертификат. Бесплатные сертификаты продлеваются автоматически, но автоматика тоже ломается — например, после переноса сервера или смены DNS.
• Почта и рассылки. Корпоративная почта, сервис транзакционных писем для форм и уведомлений, SMS-шлюз, если он есть.
• Платные компоненты. Лицензии на шрифты, карты, виджеты, платные плагины CMS, сервисы капчи или геокодирования.

Хорошая практика — свести всё это в одну таблицу: сервис, кто владелец аккаунта, на какую карту идёт оплата, дата продления и кто получает напоминания. Эта таблица занимает полчаса и закрывает самый неприятный сценарий, когда сайт отключился из-за неоплаченного счёта, о котором никто не знал.

Что подрядчики называют поддержкой

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

1. Эксплуатация

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

2. Обновления

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

3. Исправление дефектов

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

4. Развитие

Новые страницы, поля в форме, отчёты, интеграции. Это обычная разработка, просто небольшими порциями. Её разумно планировать отдельно от эксплуатации, чтобы мелкие хотелки не съедали часы, отведённые на мониторинг и обновления.

Как прикинуть бюджет на год

Точная сумма зависит от сложности системы, но структура расходов почти всегда одинаковая. Ниже — условный пример для корпоративного сайта с формами и интеграцией с CRM и для небольшой собственной CRM на 15 пользователей. Цифры ориентировочные, их задача — показать соотношение статей, а не заменить смету.

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

Что должно быть в SLA

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

1. Классы инцидентов. Например: «критичный» — сайт или оформление заказа недоступны; «высокий» — не работает важная функция, но есть обходной путь; «обычный» — всё остальное. Без классов любое обращение становится срочным.
2. Время реакции и время восстановления для каждого класса. Это разные вещи: реакция — когда инженер взялся за проблему, восстановление — когда система снова работает. Обещание «ответим за 15 минут» без срока восстановления мало что значит.
3. Часы работы. Круглосуточная реакция стоит заметно дороже, чем реакция в рабочее время. Для сайта услуг обычно хватает рабочего времени плюс автоматического мониторинга с оповещениями; для интернет-магазина с ночными продажами — нет.
4. Канал обращения. Один понятный канал — тикет-система, отдельный чат или почта — вместо личных сообщений менеджеру, который может уйти в отпуск.
5. Что входит в абонентскую плату, а что оплачивается отдельно, и по какой ставке.
6. Резервные копии: как часто делаются, сколько хранятся, где лежат и как часто проводится пробное восстановление.
7. Отчётность. Короткий ежемесячный отчёт: какие инциденты были, что обновили, сколько часов потрачено и на что.
8. Порядок прекращения сотрудничества: передача доступов, кода, документации и копий данных. Подробный список того, что должно остаться у владельца, есть в статье о приёмке веб-проекта.

Мониторинг: узнавать о проблеме раньше клиента

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

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

Пример: как выглядит месяц сопровождения

Чтобы абстрактные часы стали понятнее, вот как обычно распределяется работа по сопровождению небольшой CRM на 15 пользователей в спокойный месяц, без крупных доработок.

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

Итого около 10–12 часов. В месяцы с обновлением фреймворка или переездом на новый сервер нагрузка выше, в спокойные — ниже. Поэтому разумная схема — фиксированная плата за базовый объём и отдельная оплата крупных работ по согласованию.

Как понять, что подрядчик справляется

Сопровождение — работа, которую плохо видно. Если всё хорошо, кажется, что ничего не происходит. Несколько признаков помогают отличить нормальную работу от формальной.

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

Если за полгода вы ни разу не получили ни одного предупреждения и ни одного разбора, это повод спросить, что именно делается в рамках оплаченных часов.

Где обычно переплачивают

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

Где экономить опасно

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

Чек-лист перед подписанием договора на сопровождение

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

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