Техническое сопровождение сайта - это не разовый созвон в духе «что-то сломалось, почините», а системная работа по регламенту: кто и как быстро реагирует на инциденты, что проверяется каждую неделю, а что раз в квартал, и кто отвечает за сбой - хостинг, разработчик или сторонний сервис вроде эквайринга. На практике большинство конфликтов между заказчиком и подрядчиком возникает не из-за качества кода, а из-за того, что эти границы никто не прописал заранее.
Что входит в техническое сопровождение сайта
Список работ у каждого разработчика свой, но база одинаковая для Tilda, WordPress и кастомных веб-сервисов:
- мониторинг доступности сайта и ключевых сценариев (оформление заказа, оплата, форма заявки);
- обновление CMS, плагинов и зависимостей;
- резервное копирование базы данных и файлов;
- устранение уязвимостей и реакция на инциденты безопасности;
- поддержка интеграций - эквайринг, СДЭК, CRM, Telegram-боты;
- мелкие доработки по мере роста проекта.
На проектах, которые я веду на постоянной основе, типичная заявка выглядит так: «перестал работать промокод на Tilda» или «не приходят уведомления в Telegram-бот на aiogram после обновления библиотеки». Второе - классический случай, когда код не менялся, а сломалась внешняя зависимость: обновилась библиотека aiogram, изменился формат ответа Telegram API, и бот падает с ошибкой при следующем перезапуске контейнера. Формально это не баг разработчика, но без сопровождения никто не заметит проблему, пока не начнут жаловаться клиенты.
Отдельная категория - автоматизации на n8n. Сценарий, который два месяца стабильно передавал заказы из формы в CRM и дублировал уведомление в Telegram, может тихо остановиться из-за смены токена, лимита запросов или изменения структуры вебхука на стороне СДЭК или эквайринга. Без регулярной проверки логов workflow такие сбои обнаруживаются только тогда, когда менеджер спрашивает, почему неделю нет новых заказов.
Регламент работ: что делать и с какой периодичностью
Регламент - это таблица «что, когда, кто» применительно к конкретному сайту. Она нужна еще на этапе подписания договора на сопровождение, потому что без нее обе стороны спорят, входит очередная задача в подписку или нет.
| Периодичность | Работы |
|---|---|
| Ежедневно | Резервное копирование базы и файлов, мониторинг аптайма и ключевых сценариев |
| Еженедельно | Обновление плагинов и зависимостей, проверка логов ошибок, проверка платежных и логистических интеграций |
| Ежемесячно | Аудит скорости загрузки, отчет по инцидентам и выполненным работам |
| Ежеквартально | Аудит безопасности, обновление major-версий CMS и фреймворков, ревизия неиспользуемого кода |
По моей практике, критичные патчи безопасности для WordPress (например, обновление уязвимого плагина эквайринга или формы обратной связи) нужно закрывать в течение 24 часов с момента публикации патча, а не ждать плановое еженедельное окно. Резервные копии я храню по принципу 3-2‑1: три копии, на двух разных носителях, одна вне основного сервера, глубина хранения не меньше 30 дней - этого достаточно, чтобы откатиться, даже если проблему заметили не сразу.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
SLA: сроки реакции и восстановления
SLA описывает не «мы быстро всё чиним», а два конкретных срока для каждого уровня критичности: время реакции (когда специалист берет заявку в работу) и время устранения (когда проблема закрыта).
| Уровень критичности | Пример | Время реакции | Время устранения |
|---|---|---|---|
| Критичный | Сайт недоступен, не проходят платежи через T‑Bank | до 1 часа | до 4 часов |
| Серьезный | Не работает зона доставки в Tilda, ошибка в форме заказа | до 4 часов | 1 рабочий день |
| Некритичный | Опечатка, косметическая правка верстки | 1 рабочий день | 3-5 рабочих дней |
Обязательство по аптайму сайта в целом отдельно от SLA на реакцию разработчика: 99,5-99,9% - это зона ответственности хостинга или облачного провайдера, а не подрядчика по коду. Смешивать эти два показателя в одном пункте договора - частая ошибка, из-за которой заказчик потом требует от разработчика компенсацию за падение сервера, к которому тот не имеет отношения.
Зона ответственности: где заканчивается работа разработчика
Разделение ответственности стоит прописывать по компонентам, а не общими словами «разработчик отвечает за сайт»:
- код, конфигурация CMS и написанные интеграции - зона разработчика;
- стабильность сервера, сеть, физическое резервирование - зона хостинга;
- работоспособность API эквайринга, СДЭК, Telegram - зона соответствующего сервиса, разработчик отвечает только за то, чтобы интеграция корректно обрабатывала их ответы и ошибки;
- контент, тексты, изображения - обычно зона заказчика, если отдельно не согласована передача этих задач подрядчику.
На практике границы размываются на стыках. Если интеграция T‑Bank на WooCommerce перестала принимать платежи из-за изменения формата ответа в их API - это моя зона: я слежу за changelog эквайринга и обновляю модуль. Если легла база данных на дешевом shared-хостинге из-за перегрузки соседей по серверу - это зона хостинга, и правильная реакция подрядчика здесь не чинить чужой сервер, а посоветовать переезд на более стабильный тариф или VPS. Такие случаи я фиксирую в отчете отдельным пунктом, чтобы заказчик видел причину сбоя, а не решил, что сопровождение работает плохо.
Если сопровождение ведется без регламента и SLA вообще, любая задержка превращается в спор «а вы обещали быстро». Поэтому для проектов, где простой стоит денег - интернет-магазины, сервисы с оплатой, воронки с ботами - я предлагаю оформлять техническую поддержку отдельным договором с фиксированными сроками реакции, а не устной договоренностью «напишите, если что».
Сравнение форматов технической поддержки сайта
Три формата закрывают разные сценарии, и путать их не стоит уже на этапе выбора подрядчика.
| Формат | Что входит | Скорость реакции | Кому подходит |
|---|---|---|---|
| Разовые доработки | Правки по конкретной заявке, без регламента | без гарантии SLA, по очереди | сайтам с редкими изменениями, визиткам |
| Абонентское сопровождение | Регламент работ, приоритетная очередь заявок, ежемесячный отчет | 1 рабочий день | активным коммерческим сайтам |
| Сопровождение с приоритетным SLA | Мониторинг 24/7, фиксированные сроки по уровням критичности | 1-4 часа для критичных инцидентов | интернет-магазинам, сервисам с онлайн-оплатой |
На рынке разовая доработка часто стоит дешевле подписки в моменте, но при частоте обращений от двух-трех задач в месяц абонентское сопровождение выходит выгоднее и предсказуемее по срокам, чем поиск свободного часа у фрилансера каждый раз заново.
Как оформить регламент сопровождения в договоре
В договор или приложение к нему стоит вносить не общие фразы, а конкретные пункты:
- перечень работ, которые входят в подписку, и явное указание, что не входит - например, разработка новой функциональности оплачивается отдельно;
- периодичность плановых работ из регламента;
- критерии уровней критичности и сроки SLA по каждому;
- каналы связи для заявок - телеграм, почта, таск-трекер - и время реакции по каждому каналу;
- состав ежемесячного отчета: что сделано, какие инциденты были и как закрыты.
Для проектов с автоматизациями в n8n или ботами на aiogram отдельно фиксирую, какие сценарии и интеграции находятся на сопровождении, потому что сторонние API - Telegram, СДЭК, платежные шлюзы - меняют форматы ответов без предупреждения, и workflow может остановиться без единой ошибки в собственном коде. Без явного перечня в договоре такие сбои легко пропустить, потому что формально «код не менялся».
Частые вопросы
Чем техническое сопровождение отличается от разовых доработок?
Разовая доработка закрывает конкретную задачу без обязательств по срокам и без регулярных проверок между заявками. Сопровождение - это регламент: плановые работы по расписанию, мониторинг, приоритетная очередь заявок и фиксированные сроки реакции на инциденты, даже если заказчик сам ничего не заметил и не обратился.
Что делать, если сайт не входит ни в один SLA и просто ломается?
Сначала выяснить причину - код, хостинг или сторонний сервис вроде эквайринга или СДЭК, потому что от этого зависит, кто чинит и в какие сроки. Если сайт критичен для бизнеса (принимает оплату, обрабатывает заказы), имеет смысл сразу переводить его на сопровождение с SLA, а не чинить точечно после каждого падения.
Нужно ли отдельное сопровождение для Tilda-скриптов и интеграций?
Да, если скрипты завязаны на внешние API - расчет доставки, промокоды, конвертация валют, интеграция с эквайрингом. Tilda обновляет платформу без предупреждения разработчиков сторонних скриптов, и после очередного релиза кастомный код иногда перестает работать без единой ошибки в консоли. Регулярная проверка таких скриптов - часть регламента, а не разовая правка постфактум.
Сколько стоит техническое сопровождение сайта?
У меня техподдержка начинается от 15 000 ₽ в месяц - в эту сумму входит регламент плановых работ и приоритетная реакция на заявки. Итоговая стоимость зависит от количества интеграций, объема мониторинга и требуемых сроков SLA, поэтому финальная цифра считается после короткого аудита текущего состояния сайта.