Что входит в техническую поддержку сайта

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

20 августа наш собственный сайт лежал около 10 минут. Причина обидная: фоновая установка зависимостей прямо на боевом сервере съела всю оперативную память, VPS с 1,8 ГБ ушел в OOM, машину пришлось перезагружать. Ошибку допустили мы сами, на своем же проекте. В тот же день в регламент добавилось жесткое правило: сборка фронтенда идет только локально, на прод уезжает готовый бандл. Настоящая техническая поддержка сайта примерно из этого и состоит — из регламентов, написанных по следам аварий.

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

Техподдержка, сопровождение, обслуживание: почему за одним словом стоит разное

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

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

Мы в Design Lab делим все, что происходит с сайтом после запуска, на 3 категории. Первая: поддержание работоспособности — то, без чего сайт перестанет открываться или начнет терять данные. Вторая: реакция на инциденты — что происходит, когда сайт уже сломался. Третья: развитие — новые разделы, интеграции, редизайн. Технической поддержкой мы считаем первые 2 категории, развитие оформляем часами сверху. Такая же логика удобна и заказчику: становится видно, за что платятся деньги каждый месяц независимо от количества задач.

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

6 групп работ, из которых состоит техническая поддержка

Это тот минимум, который должен быть в договоре. Если какой-то группы нет — задайте прямой вопрос, кто ее закрывает: вы, хостер или никто.

1. Обновления платформы, модулей и окружения

Ядро CMS, коммерческие модули, PHP, MySQL, библиотеки фронтенда. Обновления бывают двух видов: функциональные, которые можно откладывать, и безопасные, которые откладывать нельзя. На практике самая болезненная разновидность — смена версий серверного окружения: она затрагивает сразу весь код проекта.

Свежий пример из нашей практики: 1С-Битрикс прекращает поддержку старых версий MySQL, и проекты, которые годами работали на MySQL 5.7, пришлось переводить на восьмую версию с проверкой всех кастомных запросов. Работа на 8–20 ч. в зависимости от объема самописного кода, и она не терпит режима «сделаем в пятницу вечером».

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

2. Резервное копирование и проверка восстановления

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

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

3. Мониторинг доступности и ошибок

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

Важный момент, о котором редко думают до первого случая: мониторинг должен ловить не только полное падение, но и «сайт открывается, а форма заявки молча не отправляется». Такие поломки живут неделями, потому что визуально с сайтом все в порядке. Проверять отправку писем с форм стоит отдельным тестом.

4. Безопасность

Сюда входят закрытие известных уязвимостей CMS и модулей, ограничение доступа в административную панель, контроль прав пользователей, защита форм от спама, регулярное сканирование файлов на предмет изменений и разбор подозрительной активности в логах. Плюс продление SSL-сертификата и контроль настроек сервера.

Отдельная строка — соответствие сайта требованиям закона. Политика обработки данных, чекбоксы согласия на формах, уведомление об использовании cookie. Формально это юридический вопрос, фактически правки делает разработчик, и логично, что они идут через поддержку.

5. Устранение инцидентов

Инцидент — это любое отклонение от нормальной работы: сайт не открывается, каталог отдает ошибку, письма не уходят, оплата не проходит, обмен с 1С встал. Здесь важны не столько сами работы, сколько скорость: время реакции и время восстановления. О них подробно в разделе про регламент.

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

6. Мелкие доработки по заявкам

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

Граница между «мелкой доработкой» и «разработкой» всегда спорная. Разумный критерий — трудоемкость: задачи до 2–4 ч. идут в поддержку без отдельного согласования сметы, все, что дольше, оценивается отдельно и попадает в план работ.

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

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

Список короче, но именно из-за него возникают конфликты на второй-третий месяц работы.

• Разработка нового функционала. Личный кабинет, конфигуратор, новая интеграция — это проектная работа со своей сметой и сроками, даже если подрядчик тот же.
• Редизайн и новая верстка разделов. Поправить съехавшую кнопку — поддержка. Переделать главную страницу — проект.
• Наполнение контентом. Загрузка 500 товаров с описаниями и фотографиями не поместится в абонемент, рассчитанный на технические задачи.
• Продвижение и реклама. Отдельная услуга с отдельными KPI, к работоспособности сайта отношения не имеет.
• Стоимость лицензий и хостинга. Продление лицензии CMS, оплата сервера, домена и внешних сервисов — это ваши прямые расходы. Подрядчик может их администрировать, но платите вы.
• Восстановление после действий третьих лиц. Если в админку зашел сторонний подрядчик и что-то сломал, разбор последствий обычно тарифицируется как обычные часы.

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

Регламент: время реакции, время восстановления и окна работ

Это самая содержательная часть договора и одновременно та, которую чаще всего не читают. В регламенте должны быть 4 цифры.

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

Время восстановления. За какой срок подрядчик обязуется вернуть сайт в рабочее состояние при критическом сбое. Тут честный ответ всегда с оговоркой: если проблема на стороне хостинга или магистрального провайдера, сроки зависят не от подрядчика. Формулировка «приложим усилия» без цифр означает отсутствие обязательств.

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

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

Приоритеты задач тоже стоит развести заранее, иначе все заявки окажутся срочными. Рабочая схема простая: критический уровень — сайт недоступен или не принимает заказы; высокий — не работает важная функция, но есть обходной путь; обычный — все остальное.

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

Абстрактные списки работ плохо помогают понять, за что уходят деньги. Ниже распределение часов по типовому корпоративному сайту среднего размера на абонементе в 20 ч./мес. Цифры усредненные, конкретный месяц может выглядеть иначе.

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

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

Сколько часов в месяц нужно вашему сайту

Универсального ответа нет, но есть ориентиры, от которых можно считать.

Сайт-визитка или небольшой корпоративный сайт без интеграций: 5–10 ч./мес. Этого хватает на обновления, мониторинг и редкие правки. Если задач не возникает вообще, разумнее вообще не брать абонемент и платить за разовые работы.

Корпоративный сайт с формами, интеграцией с CRM и регулярными новостями: 10–25 ч./мес. Основная нагрузка — контентные и мелкие функциональные задачи.

Интернет-магазин с обменом с 1С, оплатами и доставками: от 25 ч./мес. и выше. Здесь появляется постоянная работа с обменом, ценами, остатками и заказами, а каждый сбой сразу стоит денег.

Высоконагруженный проект или B2B-портал с личными кабинетами: от 50 ч./мес. Фактически это выделенная часть команды, а не абонемент в привычном смысле.

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

Форматы оплаты: разовые работы или абонемент

Форматов на рынке 3, и выбор между ними определяется не размером сайта, а тем, сколько стоит для бизнеса час простоя.

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

Абонемент с пакетом часов. Фиксированный минимум часов в месяц по сниженной ставке, за это вы получаете гарантированное время реакции, мониторинг и персонального менеджера. Наши ставки: 3500 руб./ч. при минимуме 10 ч./мес. и 3000 руб./ч. при минимуме 50 ч./мес. При оплате сразу за 6 мес. действует скидка 5%, за год — 10%. Часы сверх минимума считаются по ставке тарифа.

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

Мое мнение как технического директора: почасовая модель честнее для обеих сторон. Она заставляет подрядчика показывать, куда ушло время, а заказчика — видеть реальную стоимость своих запросов. Фиксированная сумма выглядит удобнее ровно до первого месяца, когда работы оказалось вдвое больше.

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

4 признака, что поддержка существует только на бумаге

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

• Нет отчета о затраченных часах. Не сводка «работы выполнены», а список задач с временем по каждой. Если такого документа не существует, проверить объем услуги невозможно в принципе.
• Платформа не обновлялась полгода. Спросите номер текущей версии CMS и дату последнего обновления. Отставание на год и больше означает, что кто-то просто получает деньги раз в месяц.
• Восстановление из копии никто не проверял. Задайте прямой вопрос: когда в последний раз разворачивали бэкап и сколько времени это заняло. Ответ «бэкапы делает хостинг» равнозначен ответу «никогда».
• О падении сайта вы узнаете от клиентов. Самый показательный симптом: мониторинга либо нет, либо уведомления уходят в никуда.

Ни один из этих пунктов не требует технической экспертизы. Достаточно задать вопрос и посмотреть, насколько конкретный ответ приходит.

Что спросить у подрядчика до подписания договора

Список вопросов, ответы на которые лучше получить письменно.

1. Что именно входит в ежемесячную плату, а что тарифицируется отдельно? Нужен перечень, а не общая формулировка.
2. Какое время реакции и какое время восстановления вы гарантируете по критическим инцидентам?
3. Работаете ли ночью и в выходные, и что считается критическим инцидентом?
4. Как хранятся резервные копии, где они лежат и когда в последний раз проверялось восстановление?
5. Кто конкретно будет вести проект и что произойдет, если этот человек в отпуске?
6. Переносятся ли неизрасходованные часы на следующий месяц?
7. Как оформляются задачи сверх пакета и кто согласует их стоимость?
8. Кому принадлежат доступы к хостингу, домену и репозиторию кода?
9. Что произойдет с проектом при расторжении договора: передаете ли документацию и доступы?

Последний вопрос неудобный, поэтому его почти никогда не задают. И зря: именно на выходе из договора чаще всего выясняется, что домен зарегистрирован на подрядчика, а исходников верстки нет ни у кого. Мы ведем по каждому проекту паспорт с документацией и историей изменений — в том числе чтобы этот вопрос закрывался за 5 минут.

Первый шаг, если поддержки сейчас нет

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

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

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