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

📅 Опубликовано:
техническая поддержка сайтасопровождение сайтаИИ-ассистентчат-ботRAG
Техническая поддержка сайта: что входит в работы и почему сайт ломается без неё

Коротко: Техническая поддержка сайта — это регулярные работы, которые держат ресурс живым: обновления CMS и плагинов, бэкапы с проверкой восстановления, мониторинг доступности и скорости, правки контента, доработки форм и интеграций. Без неё сайт не «ломается вдруг» — он деградирует постепенно: истекает сертификат, отваливается платёжный модуль, устаревает версия PHP. Отдельный слой — поддержка ИИ-функций: чат-бот, RAG-база, ИИ-ассистент. У нас интеграция ассистента стартует от 90 000 ₽, стоимость чат-бота для бизнеса считается отдельно, и оба решения требуют сопровождения после запуска.

Содержание

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

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

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

Блок работЧто делаетсяЧто сломается без этого
Платформа и безопасностьОбновление CMS, модулей, библиотек, версии PHP; закрытие известных уязвимостейСайт застревает на версии, которую перестают чинить; растёт риск заражения
Резервное копированиеАвтобэкапы файлов и БД, хранение копий вне сервера, тестовое восстановлениеКопии есть, а развернуть их не получается — узнаёте в худший день
МониторингПроверка доступности, скорости ответа, срока сертификата и домена, ошибок 5xxО падении сообщает клиент или отдел продаж, а не система
Контент и вёрсткаПравки текстов, картинок, карточек, баннеров, мелкие стилевые фиксыСтраницы «подтекают»: битые блоки, старые цены, съехавшая мобильная вёрстка
ФункционалФормы, фильтры, корзина, личный кабинет, поиск, экспорт заявокФорма молча перестаёт отправлять письма — заявки уходят в никуда
ИнтеграцииCRM, телефония, платёжный модуль, склад, API внешних сервисов, ИИ-модулиМеняется чужой API — связка рвётся без предупреждения

Седьмой блок мы выделяем отдельно, потому что он появился недавно и ведёт себя иначе, — сопровождение ИИ-функций. О нём будет отдельный раздел ниже.

Хороший индикатор зрелой поддержки: у подрядчика есть не только бэкапы, но и дата последней проверки восстановления. Копия, которую ни разу не разворачивали, — это не страховка, а надежда.
План статьи: Техническая поддержка сайта: что входит в работы и почему сайт ломается без неё

Почему сайт ломается, если его просто не трогать?

Потому что сайт — не картина на стене, а программа, которая живёт в чужой изменяющейся среде. Меняются браузеры, версии PHP на хостинге, API платёжных систем, требования поисковых систем, версии CMS. Сайт стоит на месте, а земля под ним движется.

Типичный сценарий деградации выглядит скучно и поэтому опасно:

  1. Хостинг объявляет об отказе от старой версии PHP. Письмо приходит на почту, которую никто не читает.
  2. Версию поднимают принудительно — часть плагинов перестаёт работать, вылетает белый экран или ошибка 500.
  3. Владелец узнаёт об этом не сразу, потому что заходит на главную, а сломался оформление заказа.
  4. Бэкап последний раз делался вручную год назад, и в нём нет новых товаров.
  5. Восстановление превращается в отдельный мини-проект, который обходится заметно дороже профилактики.

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

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

Мы в DS495 формулируем так: поддержка стоит денег, отсутствие поддержки стоит тех же денег, только неожиданно и в неудобный момент.

Чем поддержка сайта с ИИ-функциями отличается от обычной?

Отличается тем, что у ИИ-модуля нет состояния «работает / не работает» — у него есть качество ответов, которое плавает. Обычный код либо выполняется, либо падает с ошибкой. Чат-бот же может отвечать мгновенно и при этом давать неверную цену, потому что документ в базе знаний устарел.

Когда на сайте стоит ИИ-ассистент, в регламент поддержки добавляются задачи, которых нет в классическом сопровождении:

  • Актуализация базы знаний. Если ассистент работает по схеме RAG, он отвечает по вашим документам. Поменялся прайс или условия доставки — надо переиндексировать источник, иначе нейросеть уверенно повторит прошлогоднюю версию.
  • Контроль расхода токенов. Диалоги удлиняются, промпт разрастается, счёт за API растёт незаметно. Это отдельная строка мониторинга, как трафик или место на диске.
  • Версии моделей. Провайдеры выпускают новые модели и выводят старые. Подъём версии GPT или Claude — не «галочка в настройках»: поведение меняется, промпты приходится перепроверять.
  • Разбор плохих ответов. Логи диалогов читают руками: где ассистент выдумал, где ушёл от темы, где надо было передать оператору. Это входной материал для правки промптов и подсказок.
  • Обработка ошибок провайдера. Внешний API отвечает не всегда. Нужен внятный фолбэк: форма обратной связи, контакт менеджера, сообщение вместо крутящегося индикатора.

Механику самой интеграции мы подробно разбирали в материале про интеграцию ИИ-ассистента на сайт за 7 этапов, а специфику поиска по товарному каталогу — в статье про RAG-систему для e-commerce. Здесь важно другое: запуск — это старт обслуживания, а не финиш проекта.

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

Нужна помощь с этой задачей? Команда DS495 решит её под ключ. Обсудить проект →
Раздел статьи: Техническая поддержка сайта: что входит в работы и почему сайт ломается без неё

Сколько стоит поддержка и из чего складывается цена?

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

Форматы оплаты на рынке сводятся к трём моделям:

МодельКак считаетсяКому подходитСлабое место
Абонентская плата с пакетом часовФиксированная сумма за N часов в месяц + регламентные работыСайтам, где правки идут постоянноНеизрасходованные часы обычно не переносятся
Почасовая оплата по фактуОплачивается только фактическое времяСтабильным сайтам без активного развитияРегламент и мониторинг легко «забываются»
Оплата за инцидентРазовая заявка, разовый счётРазовым срочным задачамОбычно самая дорогая модель в пересчёте на год

Условный пример расчёта нагрузки. Допущения задаём явно: корпоративный сайт на популярной CMS, две формы, интеграция с CRM, пакет 10 часов в месяц.

  • Регламент (обновления, проверка бэкапов, мониторинг, отчёт) — около 3 часов.
  • Контентные правки (тексты, баннеры, карточки) — около 4 часов.
  • Мелкие доработки и разбор обращений — около 3 часов.

Это иллюстрация распределения, а не прайс: у конкретного сайта пропорции сместятся. Цифры по ИИ-модулям мы публикуем отдельно — например, в разборе, сколько стоит чат-бот для бизнеса и как считать токены. Считать поддержку ИИ-функции по тем же ставкам, что правку баннера, — распространённая ошибка сметы: там другая природа работ.

И главный принцип: сравнивайте не суммы, а содержание. Два предложения с одинаковой ценой могут отличаться тем, что в одном есть тестовое восстановление бэкапа и время реакции в договоре, а в другом — только «консультации по электронной почте».

Какие сайты и CMS берут на сопровождение и что проверить перед передачей?

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

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

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

Пошагово: как передать сайт на техподдержку без сюрпризов

  1. Соберите доступы. Панель хостинга, FTP/SSH, админка CMS, база данных, регистратор домена, почтовый сервис, репозиторий, аналитика. Доступ к домену — критичнее всего: без него сайт вам не принадлежит.
  2. Зафиксируйте текущее состояние. Полный бэкап файлов и БД до того, как кто-либо что-то тронет. Это точка отката.
  3. Проведите технический аудит. Версии CMS, модулей и PHP, скорость загрузки, ошибки в логах, срок сертификата и домена, работоспособность форм и интеграций.
  4. Составьте список известных болячек. Всё, что «давно криво, но руки не доходили». Честный список экономит недели.
  5. Разверните тестовую копию. Обновления и доработки сначала едут туда, на бой — после проверки.
  6. Согласуйте регламент и приоритеты. Что считается аварией, что плановой задачей, через какой канал приходят заявки.
  7. Закройте старые доступы. Учётки предыдущих подрядчиков и уволившихся сотрудников отзываются в тот же день.

Если сайт отдают без пункта 5, с высокой вероятностью однажды обновление приедет сразу в продакшен. Дальше — как повезёт.

Как устроен процесс: приоритеты, сроки реакции, отчётность?

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

Приоритеты нужны, чтобы правка запятой не конкурировала с упавшей корзиной. Типовая градация:

УровеньЧто этоПримерыЛогика реакции
АварияСайт или деньги недоступныСайт не открывается, не проходит оплата, не отправляются заявкиБерут в работу вне очереди, включая нерабочее время, если это в договоре
Серьёзная ошибкаФункция работает неверно, но обходной путь естьФильтр выдаёт не те товары, ассистент отвечает по устаревшему прайсуВ ближайший рабочий интервал
Плановая задачаПравка или доработка без срочностиНовый раздел, смена баннера, доработка формыВ очереди по согласованному сроку
РегламентПрофилактика по календарюОбновления, проверка копий, аудит скоростиПо расписанию, без заявки

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

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

Чек-лист регламентных работ: что делать каждый день, месяц и квартал

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

Ежедневно (автоматика):

  • Доступность сайта и ключевых страниц: главная, каталог, корзина, оформление заказа.
  • Ошибки сервера в логах, всплески 5xx.
  • Время ответа сервера — не абсолютное значение, а отклонение от нормы.
  • Доступность внешних API, включая провайдера модели, если на сайте работает ИИ-ассистент.

Еженедельно:

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

Ежемесячно:

  • Сроки домена и SSL-сертификата — с запасом, а не за день до окончания.
  • Свободное место на диске и рост базы данных.
  • Скорость загрузки ключевых страниц на мобильных.
  • Ревизия пользователей админки: кто заходил, у кого какие права.
  • Расход токенов ИИ-модулей и его динамика.

Ежеквартально:

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

Какие ошибки владельцев сайта обходятся дороже всего?

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

  • Домен оформлен на подрядчика или бывшего сотрудника. Пока отношения хорошие, проблемы нет. Когда они заканчиваются, у вас остаётся сайт без адреса. Домен должен быть на юрлице или собственнике бизнеса.
  • Бэкапы «включены на хостинге». Копия, лежащая на том же сервере, не спасает от отказа этого сервера и от блокировки аккаунта. Нужна вторая площадка и хотя бы одно успешное восстановление.
  • Правки сразу на живом сайте. Классика: обновили плагин в пятницу вечером, магазин лёг на выходные. Тестовый контур дешевле одного такого эпизода.
  • «Обновим, когда сломается». Накопленный разрыв версий превращает рутинное обновление в миграцию с переписыванием шаблонов.
  • Один общий логин администратора на всех. После инцидента невозможно понять, кто что сделал. Учётки должны быть персональными, а права — минимально необходимыми.
  • Чат-бот запустили и забыли. Через полгода он бодро рассказывает про прошлогоднюю акцию. Для ИИ-функций отсутствие поддержки означает не падение, а тихую потерю доверия.
  • Нет ответственного на стороне заказчика. Заявки прилетают от пяти человек, приоритеты противоречат друг другу, согласование зависает. Один владелец процесса снимает значительную часть организационных проблем.

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

Частые вопросы

В: Чем техническая поддержка отличается от доработки сайта?

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

В: Нужна ли поддержка сайту-визитке без интернет-магазина?

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

В: Что делать, если прежний подрядчик не отдаёт доступы?

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

В: Как часто нужно обновлять CMS и модули?

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

В: Что входит в поддержку чат-бота и ИИ-ассистента на сайте?

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

В: Можно ли перевести сайт на поддержку, если его делала другая команда?

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

В: Как понять, что поддержка работает, а не просто выставляет счета?

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

Читайте также

Нужна помощь с этим? Обсудить проект с DS495 →

Материал подготовил Альберт К.