Техническая поддержка сайта — это не одна услуга и не дежурство разработчика «на всякий случай». В неё могут входить мониторинг, резервное копирование, исправление ошибок, обновление CMS, работа с интеграциями, развитие функциональности, техническое SEO и контроль выпуска изменений. Конкретный состав зависит от роли сайта в бизнесе, его архитектуры и согласованного уровня сервиса.
Для небольшого корпоративного сайта достаточно периодических проверок и нескольких доработок в месяц. Интернет-магазину нужны контроль заказов, оплаты, обмена с 1С и регулярное тестирование. Для B2B-портала критичны интеграции, права доступа, очереди обмена и документация. Поэтому полный перечень работ лучше использовать как конструктор, а не как обещание, что любой тариф автоматически включает всё без ограничений.
Содержание:
Основные направления технической поддержки
Работы удобно разделить на семь направлений. Такое деление помогает не смешивать обязательное обслуживание, развитие и аварийные задачи, а также заранее понимать, какие специалисты и доступы понадобятся.
| Направление | Что входит | Когда особенно важно |
|---|---|---|
| Работоспособность | Мониторинг доступности, форм, заказов и ключевых сценариев | Для сайтов, которые ежедневно получают заявки или оплату |
| Безопасность | Обновления, контроль уязвимостей, вредоносного кода и прав доступа | Для проектов с персональными данными и административными кабинетами |
| Резервирование | Создание, хранение и проверка восстановления копий | Перед обновлениями и для коммерчески критичных сайтов |
| Доработки | Исправление ошибок, новые блоки, функции и интеграции | Когда сайт постоянно развивается |
| Инфраструктура | Хостинг, сервер, домен, SSL, почта и CDN | Если проблемы могут возникать вне CMS |
| Качество | Тестирование релизов, мобильной версии и пользовательских сценариев | При изменениях корзины, оплаты, форм и кабинетов |
| Аналитика и SEO | Счётчики, события, индексация и технические требования | Когда сайт привлекает рекламный и поисковый трафик |
Мониторинг работоспособности
Проверка только главной страницы недостаточна. Сайт может открываться, но не отправлять заявки, не создавать заказы или не передавать их в CRM. Поэтому набор контролируемых сценариев определяется по бизнес-логике проекта.
- доступность сайта и отдельных критичных страниц;
- срок действия SSL-сертификата, домена и оплаченного хостинга;
- работа форм, уведомлений и корпоративной почты;
- создание заказа, применение промокода, расчёт доставки и переход к оплате;
- передача лидов и заказов в CRM, 1С и другие системы;
- появление ошибок PHP, JavaScript и ответов внешних API;
- место на диске, нагрузка сервера и выполнение фоновых заданий.
Автоматический мониторинг обнаруживает факт сбоя, но не всегда объясняет его причину. После сигнала специалист проверяет логи, последние изменения, состояние сервера и связанных сервисов. Важно заранее определить, какие события считаются критичными и кому отправляется уведомление.
Обновление CMS, модулей и окружения
WordPress, 1С-Битрикс, UMI.CMS, плагины, модули и серверное окружение необходимо обновлять, но автоматическое нажатие кнопки не является полноценной поддержкой. Новая версия может конфликтовать с темой, кастомным кодом, интеграцией или версией PHP.
Безопасный процесс включает резервную копию, проверку совместимости, обновление на тестовой копии, прохождение ключевых сценариев и только затем перенос на рабочий сайт. Для небольшого проекта часть этапов может быть упрощена, но возможность отката должна сохраняться.
Резервные копии и восстановление
Сам факт наличия бэкапа ещё не гарантирует восстановление. Копия должна включать актуальные файлы и базу данных, храниться отдельно от основного сервера и периодически проверяться. Также необходимо понимать допустимую потерю данных: для контентного сайта копии раз в сутки может быть достаточно, а магазину с постоянными заказами требуется более частая схема.
- автоматическое создание копий по расписанию;
- отдельное хранение файлов и базы данных;
- контроль успешного завершения копирования;
- проверка целостности и тестовое восстановление;
- создание точки восстановления перед обновлениями и крупными доработками;
- описанный порядок аварийного восстановления.
Исправление ошибок и аварийные работы
Ошибки делятся по влиянию на бизнес. Полное падение сайта, невозможность оформить заказ или утечка данных требуют немедленной реакции. Ошибка в отдельном браузере или некритичный визуальный дефект могут быть включены в плановый спринт.
Работа обычно состоит из воспроизведения проблемы, диагностики, локализации причины, подготовки исправления, тестирования и выпуска. Если источник находится в стороннем сервисе, команда связывается с провайдером и контролирует решение, но не может гарантировать срок исправления на чужой стороне.
Доработка функциональности и дизайна
Поддержка может включать не только устранение неисправностей, но и развитие: новые страницы, формы, фильтры, личные кабинеты, интеграции и изменения дизайна. В German Web разработка оценивается по ставке 2 300 ₽ в час, работа дизайнера — 2 000 ₽ в час. Итоговая оценка появляется после уточнения задачи.
- верстка новых блоков и посадочных страниц;
- изменение форм, калькуляторов и сценариев заказа;
- доработка каталога, фильтров и поиска;
- создание личных кабинетов и ролей пользователей;
- подключение платёжных систем, доставок, CRM и внешних API;
- адаптация дизайна и мобильной версии;
- рефакторинг проблемных участков кода.
Большую функцию не стоит начинать с устного описания в нескольких строках. Сначала фиксируются требования, ограничения, состояния интерфейса и критерии готовности. Это снижает риск, что доработка бесконечно расширяется уже в процессе.
Поддержка интеграций
Интеграция может перестать работать из-за изменений сайта, 1С, CRM, платёжного шлюза или API поставщика. Задача поддержки — определить границу сбоя, сохранить данные, повторить неуспешные операции и организовать взаимодействие со второй стороной.
Для диагностики нужны журналы обмена, тестовые доступы, контакты ответственных и понимание формата данных. Если интеграция создана без документации, первичное изучение её логики становится отдельной задачей.
Тестирование изменений
Даже небольшая правка может затронуть соседние функции. Изменение корзины требует проверки цены, скидок, доставки, оплаты, писем и передачи заказа. После обновления формы проверяются валидация, уведомления, CRM и цели аналитики.
Объём тестирования зависит от риска. Для текста или изображения достаточно визуальной проверки. Для оплаты, персональных данных и обмена с учётной системой нужен сценарный тест на копии и контроль после выпуска.
Техническое SEO и веб-аналитика
В поддержку часто входят задачи, которые не являются продвижением сами по себе, но влияют на трафик и измерение заявок: редиректы, sitemap.xml, robots.txt, canonical, микроразметка, устранение дублей, скорость загрузки, установка счётчиков и настройка событий.
После изменений структуры или URL важно проверить ответы сервера и переходы со старых адресов. После доработки формы — убедиться, что конверсии продолжают передаваться в аналитику и рекламные кабинеты.
Что обычно не входит автоматически
Абонентский договор не означает неограниченный объём любых работ. Отдельного согласования обычно требуют разработка крупного нового раздела, полный редизайн, миграция на другую CMS, круглосуточное дежурство, покупка лицензий и услуг третьих лиц, а также работы вне согласованного времени.
Чтобы избежать споров, в договоре или регламенте фиксируются доступный объём часов, рабочее время, каналы обращений, SLA, порядок оценки, перенос остатка и условия срочных работ.
Как формируется перечень работ для конкретного сайта
- проводится первичное знакомство с CMS, кодом и инфраструктурой;
- фиксируются критичные функции и интеграции;
- проверяются доступы, резервные копии и документация;
- составляется список текущих проблем и ближайших изменений;
- определяются приоритеты и допустимые сроки реакции;
- выбирается разовый или абонентский формат.
Если сайт небольшой и задачи появляются редко, постоянный пакет может быть избыточным. Когда проект получает заявки, принимает оплату и регулярно меняется, закреплённая команда снижает время на повторное знакомство и поиск исполнителей. Сравнение вариантов разобрано в статье о разовой доработке и абонентской поддержке.
Как начать техническую поддержку
Для первичной оценки достаточно ссылки на сайт, описания текущих проблем и ближайших задач. Затем команда уточнит CMS, хостинг, интеграции и необходимые доступы. Если проект сложный или состояние кода неизвестно, сначала может потребоваться платный аудит.
Условия работы German Web и варианты тарифов собраны на странице технической поддержки сайтов. Отдельно можно изучить материал о ценах и тарифах сопровождения.
Частые вопросы
Должна ли поддержка работать круглосуточно?
Не обязательно. Режим зависит от критичности сайта и договора. Для большинства проектов достаточно поддержки в рабочее время с заранее согласованным порядком обработки аварий.
Входит ли наполнение сайта контентом?
Может входить, если это зафиксировано в составе работ. Размещение материалов следует отделять от программирования и заранее определять объём, формат исходников и ответственность за содержание.
Кто отвечает за хостинг и сторонние сервисы?
Команда поддержки может диагностировать проблему и взаимодействовать с провайдером. Но сроки устранения сбоя на стороне хостинга, банка, CRM или другого сервиса зависят от его владельца.
Можно ли поддерживать сайт без документации?
Да, но сначала потребуется восстановить понимание архитектуры и интеграций. На сложном проекте такое знакомство может быть оформлено как отдельный аудит.
Как понять, что резервные копии действительно работают?
Нужно контролировать создание копий и периодически выполнять тестовое восстановление. Наличие файла в хранилище само по себе не подтверждает, что сайт можно вернуть в рабочее состояние.
Входит ли разработка новых функций?
Да, если она предусмотрена договором и укладывается в доступный объём. Крупные функции сначала оцениваются и при необходимости оформляются отдельным этапом.
