Техническая поддержка сайта: что входит, SLA и как организовать процесс

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

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

Чем техническая поддержка отличается от «починить по звонку»

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

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

Если смотреть шире, техподдержка — слой стабильности внутри годового плана поддержки. Контент, SEO и A/B живут поверх него: нет смысла гонять трафик на сайт, который периодически «ложится» без мониторинга.

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

Состав зависит от договора, но рабочий минимум для бизнес-сайта выглядит так.

Мониторинг и инциденты

Контроль доступности ключевых URL (главная, формы, корзина, запись).
Реакция на падения и критические ошибки по согласованному SLA.
Диагностика типовых сбоев: хостинг, CMS, интеграции, SSL, DNS.
Эскалация: кому звонить ночью, кто принимает решение о откате.

Без мониторинга вы узнаёте о проблеме от клиента или из рекламного кабинета — когда заявки уже потеряны. Про ошибки 502/503 мы писали отдельно: часто это следствие нагрузки, деплоя или защиты, а не «магия сервера».

Обновления и совместимость

Плановые обновления CMS, плагинов, тем в окне обслуживания.
Проверка критичных сценариев после обновления (формы, оплата, авторизация).
Откат, если обновление ломает прод.

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

Бэкапы и восстановление

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

Бэкап «где-то на хостинге», который никто не проверял год, — ложное спокойствие.

Базовое администрирование в рамках поддержки

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

Отчётность

Минимум раз в месяц: что мониторили, какие инциденты закрыли, какие обновления поставили, какие риски остались. Без отчёта «поддержка» легко превращается в чёрный ящик.

SLA: как договориться о скорости реакции

SLA (Service Level Agreement) — не маркетинговый лозунг «мы всегда на связи», а измеримые сроки.

Типовая схема для сайта с заявками:

Приоритет	Пример	Время реакции
Критический	Сайт недоступен, форма записи/оплаты не работает	до 1 часа
Высокий	Часть страниц с ошибкой, сильное падение скорости	в тот же рабочий день
Обычный	Плановая правка, обновление, не срочный баг	по очереди в спринте

Важно зафиксировать:

что считается «критическим»;
рабочие часы vs 24/7;
каналы эскалации (тикет, мессенджер, телефон);
что не входит в SLA (хостинг-провайдер, сторонние API вне вашего контроля — с оговоркой, как вы помогаете диагностировать).

В модуле поддержки 24/7 у Webbes на критические инциденты заложено SLA до 1 часа — именно потому, что для клиник, магазинов и записи простой бьёт по выручке сразу.

Доступы и регламент: без этого поддержки не будет

Чтобы техническая поддержка сайта работала, нужны доступы — и порядок их выдачи.

Обычно достаточно:

панель хостинга / облака или SSH;
админка CMS;
DNS (хотя бы на чтение / делегирование при необходимости);
доступы к аналитике и почте для алертов (по согласованию).

Правила безопасности:

отдельные учётки или общий защищённый vault, а не пароль в чате;
минимально необходимые права;
журнал: кто и когда получил доступ;
отзыв доступов при смене подрядчика.

Если доступы «размазаны» по фрилансерам прошлых лет, первый шаг поддержки — инвентаризация, а не «почините кнопку».

Как организовать процесс внутри компании

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

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

Типовой ритм:

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

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

Когда выгоднее внешняя команда

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

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

Имеет смысл сравнить: стоимость простоя + нервы + поиск исполнителя vs фиксированная подписка с понятным составом. Для многих бизнесов стартовая точка — модуль мониторинга и поддержки, а контент, SEO и доработки подключаются отдельно.

Частые ошибки при заказе техподдержки

«Всё включено» без границ. Без списка «что не входит» любая крупная задача превращается в конфликт.
Нет SLA. «Посмотрим по возможности» — это не поддержка критичного канала продаж.
Нет бэкапов с проверкой. Пока не проверили restore, бэкапа по сути нет.
Смешение поддержки и развития. Новая интеграция на 40 часов не должна «съедать» абонемент тишины на инциденты.
Нулевая отчётность. Если вы не видите, что делали за месяц, вы покупаете ощущение спокойствия, а не процесс.

Краткий чек-лист перед подключением

Есть ли список критичных URL и сценариев?
Согласован ли SLA по приоритетам?
Выданы ли доступы по регламенту?
Есть ли окно для обновлений и правило отката?
Кто внутри компании принимает отчёт и эскалации?
Где граница между поддержкой и доработками?

Если ответы пустые — сначала соберите рамку, потом выбирайте подрядчика. Иначе даже сильная команда будет работать в тумане.