Что входит в сопровождение сайта и чем оно отличается от поддержки

«Сопровождение» и «поддержка» в договорах означают у всех разное, и проверить это можно одним вопросом менеджеру. Что реально входит в услугу: плановые работы, обновления платформы, резервные копии, SLA и часы на развитие. Плюс чек-лист из 10 пунктов, который стоит пройти до подписания.

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

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

Дальше начинается неприятное. Ни в законодательстве, ни в отраслевых стандартах эти 2 слова не закреплены. Один подрядчик называет сопровождением абонемент на 10 ч. правок, другой — полный цикл технического обслуживания с мониторингом и дежурством. Оба формально правы, потому что термин свободный.

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

Почему одно и то же слово означает у всех разное

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

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

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

Что входит в сопровождение сайта

Ниже состав, который мы в Design Lab считаем минимально осмысленным. Если какого-то блока нет, услуга неполная, и это не повод от нее отказываться — это повод понимать, кто закрывает недостающее.

Наблюдение за доступностью и ошибками

Базовая часть: сайт проверяется автоматически с внешней точки, при недоступности приходит уведомление. Хорошая проверка смотрит не только на код ответа главной страницы. Сайт может отдавать 200 и при этом не принимать заказы: отвалился платежный шлюз, перестала уходить почта с формы, сломался поиск по каталогу.

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

Отдельно — журналы ошибок. Скачок 500-х ответов после обновления виден в логах за минуты, а по обращениям клиентов — через несколько дней, когда часть покупателей уже ушла.

Обновления платформы и окружения

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

С коробочным 1С-Битриксом все упирается в активность лицензии. По правилам вендора продлить обновления льготно, за 22% стоимости редакции, можно в течение 30 дней после окончания периода активности. Дальше только стандартный вариант — 60% стоимости редакции. Льготно продлить ключ можно только 1 раз в год. Пропущенный срок превращает рядовой платеж в сумму почти втрое больше, и это самая обидная строка расходов из всех возможных: деньги потеряны буквально из-за незакрытой задачи в календаре.

Второе — версия PHP. По графику поддержки на php.net ветка 8.2 получает только исправления безопасности и теряет и их 31 декабря 2026 года. Ветка 8.1 не поддерживается уже сейчас. Сайт на неподдерживаемой версии продолжает работать ровно до первой публичной уязвимости, после которой закрывать ее будет некому. Перевод на актуальную ветку требует проверки совместимости модулей и кастомного кода, то есть это плановая работа на несколько часов, а не переключение тумблера у хостера.

Если платформа у вас та же, детали обновления ядра разобраны отдельно в материале про обновление 1С-Битрикса без поломки сайта.

Безопасность и обязательства перед законом

Сайт, который принимает заявки с именем и телефоном, делает вас оператором персональных данных со всеми вытекающими. И утечка здесь — не только репутационная история.

С 30 мая 2025 года в КоАП действуют отдельные составы за утечки: 3–5 млн руб. за данные от 1000 человек, 5–10 млн при масштабе от 10 000, 10–15 млн при утечке данных более чем 100 000 человек и специальных категорий, 15–20 млн за биометрию. Повторная утечка переводит штраф в оборотный: 1–3% годовой выручки, с нижней границей 15 млн руб. и верхней 500 млн руб. Сроки уведомления Роскомнадзора жесткие: 24 ч. на сообщение о самом факте и 72 ч. на результаты внутреннего расследования (ст. 21 152-ФЗ).

Практический смысл для сопровождения простой. Уложиться в 24 ч. можно только тогда, когда есть логи, есть кому их прочитать и заранее известно, кто именно подписывает уведомление. Договориться об этом в момент инцидента невозможно физически.

Ко второй половине блока относятся сертификаты. CA/Browser Forum утвердил поэтапное сокращение срока жизни TLS-сертификатов: с 15 марта 2026 года максимум 200 дней вместо прежних 398, с 15 марта 2027 года — 100 дней, с 15 марта 2029 года — 47 дней. Ручное продление раз в год еще как-то держалось на памяти администратора. При выпуске раз в 100 дней это гарантированный отказ в самый неудобный момент, поэтому автопродление и проверка его работоспособности переезжают в обязательные плановые работы.

Резервные копии, которые кто-то проверял

Копия, которую ни разу не разворачивали, копией не является. Это архив с неизвестным содержимым.

В регламенте должны быть 4 ответа. Как часто снимается копия. Сколько копий хранится и как долго. Где они лежат физически — на том же сервере копия бесполезна, потому что при отказе диска или блокировке аккаунта у хостера теряется вместе с сайтом. И главное: как часто проводится тестовое восстановление на отдельный контур.

Тестовое восстановление — тот пункт, который в регламентах пишут реже всего, а стоит он дешевле любого другого. Развернуть последнюю копию на технический домен и открыть 5 страниц занимает меньше часа. У нас в Design Lab эта проверка стоит в графике с конкретной датой, наравне с обновлениями, именно потому что без даты ее всегда есть куда отложить.

Мелкие правки контента и верстки

Обновить цену, поменять баннер, добавить сотрудника в раздел о компании, поправить съехавший блок на мобильном. Работы простые, но именно из-за них сопровождение чаще всего и покупают: держать штатного разработчика ради 3 правок в месяц бессмысленно.

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

Часы на развитие

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

Ключевой пункт договора — судьба неизрасходованных часов. Варианты бывают разные: сгорают, переносятся полностью, переносятся с лимитом (например, не более 50% месячной нормы и не дольше квартала). Любой из них рабочий, если написан явно. Хуже всего, когда об этом не сказано ничего: в этом случае решение принимается в момент спора, и принимает его не клиент.

Что в сопровождение обычно не входит

Список ограничений — признак честного предложения. Если в КП нет раздела с исключениями, скорее всего его напишут задним числом, когда вы попросите что-то крупное.

• Редизайн и новые крупные разделы. Это проектная работа со своим ТЗ, сроками и бюджетом. Из абонемента она оплачиваться не может по объему.
• Интеграции с нуля. Настройка обмена с учетной системой, подключение новой CRM, разработка личного кабинета — отдельные проекты. В абонемент попадает их поддержка после запуска.
• Лицензии, хостинг и домены. Подрядчик может их администрировать и оплачивать по вашей доверенности, но стоимость самих лицензий в абонемент не входит и меняется по прайсу вендора.
• Продвижение и реклама. Технические работы влияют на SEO, однако семантика, контент-план и контекст живут в другой услуге и с другой командой.
• Наполнение каталога и объемный копирайтинг. Загрузка 500 товаров руками — почасовая работа контент-менеджера, а не правка.
• Устранение последствий взлома чужого периода. Если сайт заражен до начала договора, лечение считается отдельной работой. Оценить ее заранее невозможно, пока не сделан аудит.

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

4 параметра SLA, о которых спорят задним числом

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

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

И про каналы. Требование писать в одно место выглядит бюрократией, пока не понадобится посчитать, сколько заявок было за квартал и сколько из них закрыто в срок. По переписке в мессенджерах это не считается никак.

Как выглядит обычный месяц сопровождения

Календарь работ объясняет услугу лучше любого списка возможностей. Ниже типовой график для корпоративного сайта или небольшого магазина.

1. Ежедневно. Автоматические проверки доступности, контроль отправки писем с форм, просмотр журнала критических ошибок.
2. Раз в неделю. Ручной прогон ключевых сценариев по чек-листу, проверка свежести резервных копий, разбор накопившихся обращений, установка мелких обновлений модулей.
3. Раз в месяц. Обновление ядра платформы на тестовом контуре и перенос на боевой, проверка скорости ключевых страниц, отчет клиенту с перечнем сделанного и потраченных часов.
4. Раз в квартал. Тестовое восстановление резервной копии на отдельный домен, ревизия прав доступа и учетных записей, проверка сроков лицензий и сертификатов на горизонте 6 мес.
5. Раз в год. Продление лицензий, планирование обновления версии PHP и серверного окружения, оценка накопленного технического долга.

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

Сколько часов на это уходит

Цифры ниже — наша оценка по типовым проектам, отраслевой статистикой они не являются. Плановые работы без учета правок и доработок занимают примерно 4–8 ч. в месяц для корпоративного сайта и 10–15 ч. для интернет-магазина с обменом данными и оплатами. Сверху добавляются заявки, и вот их объем предсказать заранее нельзя: в спокойный месяц их может не быть вовсе, в месяц запуска акции набегает больше, чем плановых работ.

Из этого следует неочевидное. Абонемент на 5 ч. в месяц для магазина не покрывает даже обязательную часть, поэтому обновления и проверки в нем просто не делаются — их не на что делать. Такой договор создает ощущение защищенности, которого нет. Реалистичный минимум для магазина начинается от 10 ч. И считать при выборе тарифа лучше не цену часа: смотрите, сколько часов останется на развитие после обязательных работ.

Развернутые ориентиры по деньгам и форматам оплаты собраны в отдельном материале о том, сколько стоит обслуживание сайта. Специфика коробочной платформы, где к работам добавляются продления и обновления ядра, разобрана в статье про поддержку сайта на 1С-Битриксе.

Что проверить в договоре до подписания

Короткий чек-лист. Пройтись по нему быстрее, чем потом выяснять отношения.

1. Приложение с перечнем работ. Есть ли документ, где работы перечислены поименно, с указанием периодичности. Формулировка «техническое обслуживание сайта» без расшифровки не значит ничего.
2. Плановые работы отдельно от заявок. Видно ли, что подрядчик делает по своей инициативе. Если такого списка нет, вы покупаете поддержку.
3. Сроки реакции и решения по категориям. Отдельно для аварии, ошибки и правки. Хотя бы 2 категории, иначе SLA декоративный.
4. Судьба неизрасходованных часов. Сгорают, переносятся, переносятся с лимитом. Любой вариант, но написанный.
5. Регламент резервного копирования. Частота, срок хранения, место хранения вне основного сервера, периодичность тестового восстановления.
6. Раздел с исключениями. Что в абонемент не входит. Его отсутствие означает отложенный спор.
7. Доступы и их владелец. На кого оформлены домен, хостинг и лицензия. Домен должен быть зарегистрирован на вас, иначе смена подрядчика превращается в переговоры.
8. Порядок передачи дел. Что подрядчик обязан отдать при расторжении: доступы, актуальную резервную копию, документацию по кастомным доработкам.
9. Форма отчета. Что именно вы получаете каждый месяц. Лучше приложить к договору образец.
10. Реакция на инцидент с персональными данными. Кто готовит данные для уведомления регулятора и в какой срок передает их вам.

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

Кому сопровождение не нужно

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

Сайт-визитка на конструкторе, где платформа обновляется на стороне сервиса, а контент вы меняете сами. Здесь платить ежемесячно не за что: обновлять нечего, резервные копии делает сама платформа, доработок вы не заказываете. Разумнее держать контакт подрядчика на случай разовой правки.

Внутренний ИТ-специалист, который уже занимается сервером и сайтом. Дублировать его внешним абонементом смысла нет. Полезнее разовый аудит раз в год как взгляд со стороны и договоренность о подстраховке на время отпуска.

Сайт, который вы собираетесь переделывать в ближайшие 2–3 мес. Вкладываться в обновления и техдолг перед заменой платформы бессмысленно. Здесь нужен минимум: работоспособность, резервные копии и безопасность, а все остальное подождет нового проекта.

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

Что с этим делать

Если договор уже подписан, откройте его и найдите ответ на 1 вопрос: какие работы подрядчик обязан выполнить в месяц, когда вы не написали ни одной заявки. Ответ на него сразу показывает, что вы купили и совпадает ли это с вашими ожиданиями.

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

Мы в Design Lab перед началом сопровождения смотрим сайт, окружение и историю доработок, а потом уже называем состав работ и объем часов. Иногда по итогам осмотра честный ответ звучит так: сначала техдолг, потом абонемент. Это неприятно слышать, зато избавляет от договора, который не выполняется с первого месяца.