Поддержка и сопровождение сайта: полный гайд для бизнеса

Сайт умирает не в день запуска, а когда его перестают обслуживать

Сайт может выглядеть современно и принимать заявки, но без регулярной поддержки постепенно перестаёт быть рабочим инструментом. Плагин конфликтует с обновлением PHP, форма перестаёт передавать лиды в CRM, заканчивается SSL-сертификат, а свободное место на сервере съедают старые логи. Обычно это замечают не по дашборду, а по сообщению клиента: «у вас не отправляется заявка».

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

Ниже разберём состав работ, уровни обслуживания, SLA, ориентиры по стоимости и признаки, что поддержка нужна уже сейчас. О техническом фундаменте подробнее рассказываем в статье про DevOps, мониторинг и бэкапы, а о передаче лидов читайте в материале про интеграцию CRM и сайта.

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

Конкретный состав зависит от CMS, кода, хостинга, интеграций и критичности сайта. Но базовый договор должен фиксировать не абстрактные «часы», а перечень работ и результат.

• Мониторинг. Проверка доступности, времени ответа, SSL, форм, API и критичных страниц с алертами ответственному.
• Обновления. Обновление CMS, модулей, библиотек и серверного ПО через staging, с бэкапом и планом отката.
• Безопасность. Управление доступами, закрытие известных уязвимостей, контроль прав, журналирование и базовая защита от типовых атак.
• Резервные копии. Копии файлов, базы данных и конфигурации по расписанию, хранение вне основного сервера и тестовое восстановление.
• Исправление инцидентов. Реакция на ошибки 5xx, падение сайта, проблемы с оплатой, формами, почтой или обменом с CRM.
• Плановые доработки. Контентные правки, новые блоки, аналитика, формы, интеграции и небольшие улучшения UX по согласованному backlog.

Если сайт был сделан «с нуля», поддержка включает контроль зависимостей и релизов. Если он работает на CMS, особенно важны обновления ядра и плагинов. Как выбрать устойчивую архитектуру ещё до запуска, читайте в статье «Сайт на CMS или с нуля».

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

Регламент и SLA: как поддержка становится управляемой

SLA (Service Level Agreement) - это измеримое соглашение о сервисе, а не обещание «быть на связи». В нём фиксируют часы обслуживания, каналы обращений, приоритеты инцидентов, время первой реакции и целевое время восстановления.

Для SLA также нужны RTO и RPO. RTO отвечает, за какое время сервис должны поднять, а RPO показывает, какой объём данных бизнес готов потерять. Например, RTO 4 часа и RPO 24 часа означают: сайт восстанавливают в течение четырёх часов, а допустимая потеря данных ограничена последними сутками.

Уровни поддержки сайта и стоимость

Диапазоны приведены как ориентир для стартапов и малого бизнеса. Начать поддержку можно с минимального пакета за 8 000-15 000 ₽/месяц. Они не включают крупные разработки, лицензии, хостинг и платные сервисы, если это не указано в договоре.

Для небольших проектов на простых CMS (например, WordPress или Tilda) базовый пакет поддержки может стоить от 8 000 ₽/месяц — это регулярные бэкапы, контроль доступности и обновления. По мере роста бизнеса подключаются мониторинг форм, интеграции и SLA.

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

Когда поддержка сайта нужна обязательно

Сайт принимает деньги, заявки или персональные данные

У интернет-магазина, B2B-портала и сайта с CRM-интеграцией стоимость простоя измеряется не только репутацией: пропадают заказы, лиды и данные. Здесь минимум: мониторинг ключевых сценариев, бэкапы и ответственный за инциденты.

Контент и реклама меняются регулярно

Акции, статьи, новые посадочные и аналитика требуют безопасного процесса правок. Без staging и контроля версий быстрая правка может сломать действующую кампанию. При планировании роста органики полезен материал про SEO при разработке сайта.

Есть CMS, плагины или несколько подрядчиков

У CMS есть обновления и зависимости; у нескольких исполнителей есть риск неясной ответственности. Регламент доступа, журнал изменений и единая точка входа для тикетов здесь важнее, чем разовые «срочные» правки.

Сайт уже переживал сбои

Если форма молча не работала, сайт падал после обновления или бэкап никто не восстанавливал, это не отдельная неприятность, а сигнал отсутствия процесса.

Типовые инциденты: что происходит и как их решают

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

Типичные ошибки в обслуживании сайтов

Ошибка 1. Считать поддержкой только правки контента

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

Ошибка 2. Делать бэкап, но не проверять восстановление

Архив на том же сервере не спасёт при сбое диска. Нужны внешняя копия и регулярный restore-тест.

Ошибка 3. Не разделять инциденты и плановые задачи

Если падение сайта стоит в общей очереди вместе с правкой баннера, SLA не работает. Приоритеты и канал эскалации должны быть заранее известны.

Ошибка 4. Давать доступы «всем, кому нужно»

Общие пароли и неотозванные учётные записи превращают смену подрядчика или случайную ошибку в риск безопасности.

Вымышленный кейс: как «ТехноСнаб» перестал терять заявки ночью

Кейс вымышленный, но построен на типовых ситуациях из сопровождения B2B-сайтов.

Ситуация. У поставщика промышленного оборудования сайт на CMS, каталог на 8 000 позиций и интеграция с CRM. После ночного обновления модуля формы продолжали показывать «Спасибо», но API возвращал ошибку. За двое суток отдел продаж не получил 27 обращений.

Что сделали.

1. Настроили мониторинг доступности, SSL, формы и ответа CRM API с алертами в Telegram.
2. Ввели staging, Git и обязательный бэкап перед обновлением.
3. Разделили заявки в трекере на P1-P3, назначили владельца и SLA для критичных сценариев.
4. Добавили ежедневные offsite-бэкапы и ежеквартальное восстановление на тестовом контуре.

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

Бюджет базового пакета поддержки для этого проекта составил 25 000 ₽/месяц — это позволило компании избежать потери лидов на сотни тысяч рублей.

Чек-лист: готов ли сайт к нормальному сопровождению

1. Назначен владелец сайта и человек, принимающий решения по инцидентам.
2. Есть актуальный список доступов к домену, хостингу, CMS, почте и внешним сервисам.
3. Настроен мониторинг доступности и алерты минимум для главной страницы и формы.
4. Контролируется срок SSL-сертификата и регистрация домена.
5. Бэкапы файлов и базы создаются по расписанию, хотя бы одна копия хранится offsite.
6. Восстановление из бэкапа проверялось на тестовом окружении.
7. Обновления CMS, плагинов и зависимостей проходят через staging или по чек-листу.
8. Код и конфигурация не хранятся только на компьютере подрядчика.
9. Для P1-P3 зафиксированы время реакции, каналы связи и порядок эскалации.
10. Есть прозрачный backlog: что исправляется срочно, а что планируется на следующий спринт.

Четыре и более ответов «нет» это повод начать с аудита и базового контура, а не ждать следующего простоя.

Если вы ответили «нет» на 4 и более пунктов, не откладывайте — начните с аудита. Многие проблемы можно предотвратить за 8 000-15 000 ₽/месяц базовой поддержки.

Часто задаваемые вопросы (FAQ)

Сколько стоит поддержка небольшого корпоративного сайта?

Обычно базовый пакет начинается от 8 000-15 000 ₽ в месяц для простых проектов и от 15 000-25 000 ₽ для сайтов на популярных CMS с интеграциями: бэкапы, контроль доступности и SSL, регламентные обновления, небольшой объём правок. Итог зависит от CMS, числа интеграций, хостинга и требуемого SLA.

Поддержка и DevOps - это одно и то же?

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

Нужен ли SLA, если сайт не работает круглосуточно?

Да, но он может быть рабочим: например, реакция на P1 в течение часа в будни. Главное не копировать «24/7» без реальной дежурной команды, а согласовать обязательства с рисками бизнеса.

Можно ли поддерживать сайт, который сделал другой подрядчик?

Да, после технического аудита и передачи доступов. Сначала оценивают стек, лицензии, качество бэкапов, уязвимости, документацию и критичные интеграции; затем согласуют план стабилизации.

Заключение: поддержка - это страховка работающего канала продаж

Сайт не остаётся «готовым» после запуска: меняются браузеры, CMS, зависимости, требования безопасности, контент и бизнес-процессы. Регулярное сопровождение превращает эти изменения из аварий в плановую работу с понятной ответственностью.

Начните с базовых вещей: проверьте бэкапы восстановлением, настройте мониторинг ключевых сценариев, назначьте владельца инцидентов. Базовый пакет поддержки обойдётся значительно дешевле простоя сайта — от 8 000 ₽/месяц. Если нужна разработка и поддержка сайта в одном контуре, обратитесь в Rogitel: обсудим состав работ, приоритеты и реалистичный бюджет.