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

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

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

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

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

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

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

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

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

Поддержка по заявкам и плановое сопровождение: в чем разница

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

• Администрирование хостинга. Сервер жив, диск не переполнен, домен и сертификат продлены. Работу запускает автоматика или хостер, человек подключается по аварии. Часов нет, вы платите за ресурсы.
• Поддержка по заявкам. Ошибки, правки, консультации. Инициатива всегда на стороне клиента: нет заявки, нет работы. Неиспользованные часы обычно сгорают в конце месяца.
• Плановое сопровождение. Те же заявки плюс работы по календарю подрядчика: обновления, проверка резервных копий, мониторинг, отчет, запас часов на доработки. Инициатива делится между клиентом и подрядчиком примерно поровну, часть неизрасходованных часов переносится с лимитом, который записан в договоре.

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

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

Перевод на новую ветку PHP стоит в годовом плане не случайно: он требует проверки совместимости модулей и кастомного кода, то есть это плановая работа на несколько часов, и переключением тумблера у хостера она не решается. На коробочном 1С-Битриксе к этому добавляется обновление ядра, которое разобрано отдельно в материале про обновление 1С-Битрикса без поломки сайта.

По часам плановая часть без правок и доработок занимает примерно 4–8 ч. в месяц для корпоративного сайта и 10–15 ч. для интернет-магазина с обменом данными и оплатами. Это наша оценка по типовым проектам, отраслевой статистикой она не является. Из нее следует неочевидный вывод: абонемент на 5 ч. для магазина не покрывает даже обязательную часть, поэтому обновления и проверки в нем просто не делаются. Такой договор создает ощущение защищенности, которого нет. При выборе тарифа смотрите, сколько часов останется на развитие после обязательных работ.

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

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 минут, стандартные — в течение часа.

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

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

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

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

Как читать эти цифры. Реакция за 15 минут означает, что задачу взял живой человек, она попала в очередь и вы узнали срок; срок самого восстановления по авариям фиксируется отдельной строкой, и путать их нельзя. Еще одна строка регламента, уже без цифры, — канал обращений. В договоре должен быть 1 основной канал с фиксацией: таск-трекер или почта на общий адрес. Заявка в личном сообщении менеджеру исчезает вместе с его отпуском, а по переписке в мессенджерах невозможно посчитать, сколько заявок было за квартал и сколько из них закрыто в срок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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