Техподдержка сайта — это не разовая услуга «на всякий случай», а регламент регулярных работ по расписанию плюс реакция на инциденты по приоритету. В техподдержку сайта с SLA и регламентом входят: мониторинг доступности, обновление CMS и модулей, резервное копирование, защита от взлома, устранение инцидентов и ежемесячный отчёт о сделанном. Ниже — таблица регламента по периодам, разбор частых инцидентов и то, как выбрать формат договора под размер бизнеса.
Что входит: регламент по периодам
Хорошая техподдержка работает по календарю, а не только когда что-то уже сломалось. Ниже — минимальный регламент для среднего коммерческого сайта; конкретные сроки и часы согласуются в договоре.
| Период | Что делают | Кто отвечает |
| Ежедневно | Мониторинг доступности и скорости, проверка статуса платёжного провайдера у интернет-магазинов | Дежурный по мониторингу |
| Еженедельно | Резервное копирование и проверку резервной копии на восстанавливаемость — без тестового разворота бэкап остаётся недоказанным | Разработчик |
| Ежемесячно | Обновление CMS, плагинов и модулей, разбор отчёта по инцидентам за месяц | Разработчик |
| Ежеквартально | Проверку сайта по 152-ФЗ: политика обработки данных, согласия, размещение серверов | Разработчик + юрист |
| Перед сезоном пиковых продаж | Подготовку магазина к распродажам: нагрузочный тест, проверка платёжного пути, заморозка релизов на неделю пика | Разработка + маркетинг |
| Инфраструктура (разово, при смене или проверке) | Выбор хостинга под текущую нагрузку: лимиты CPU и памяти, условия масштабирования | Разработчик + хостинг |
Пропуск любой строки этой таблицы не проходит бесследно: незакрытая уязвимость в старой версии ядра CMS — самая частая причина взлома, а не изощрённая атака. Просроченная резервная копия превращает сбой из перезапуска на 15–30 минут в потерю данных за недели.
У этих работ разная цена ошибки. Пропущенное ежедневное обновление статуса мониторинга почти всегда не критично — его заметят на следующей проверке. Пропущенная еженедельная проверка бэкапа критична всегда. Разница в том, что второе вскрывается только в момент, когда копия уже нужна, и вдруг оказывается нерабочей.
Инциденты: что закрывает регламент, а что — нет
Регламент снижает частоту инцидентов, но не отменяет их полностью. Для двух самых частых сценариев есть отдельный порядок действий, который регламентом не заменить.
Взлом или пометка сайта опасным. Самый тяжёлый инцидент из тех, что случаются на живом сайте. Пароли, код, возможно, данные пользователей — уже скомпрометированы. Первые часы решают всё: перезапуск с чистой копии или недели восстановления доверия. Что делать в первые сутки после взлома, по приоритетам и шагам, — в отдельном материале.
DDoS-атака. Внешне похожа на резкий рост нагрузки от распродажи или маркетинговой кампании. Профиль трафика другой: запросы идут с узкого набора адресов, и рост заказов в аналитике не поспевает следом. Как понять, что сайт под DDoS-атакой, и что делать в первый час, разобрано в отдельном материале.
Оба сценария объединяет одно: без свежей проверенной резервной копии и без заранее прописанного в договоре времени реакции решение инцидента растягивается на часы, которых у бизнеса чаще всего нет.
Как выбрать формат и договор
Формат поддержки выбирают по цене часа простоя, а не по размеру компании сам по себе. Разовые обращения к фрилансеру подходят сайту-визитке без критичной нагрузки: риск в отсутствии гарантированного времени реакции. Абонемент на пакет часов в месяц закрывает регулярный поток мелких задач и мониторинг инцидентов — разумный вариант для среднего бизнес-сайта. Полное SLA с закреплённой командой нужно интернет-магазинам и сервисам, где час простоя обходится в ощутимую сумму. Круглосуточный мониторинг и приоритетная реакция здесь — не роскошь. Это условие, при котором бизнес продолжает принимать заказы ночью и в выходные.
Что именно прописать в договоре — часы, SLA по приоритетам P1–P4, доступы и порядок расторжения — разобрано по пунктам, с шаблоном-оглавлением на 12 позиций: что прописать в договоре на техподдержку.
Типичные ошибки
Компании чаще всего экономят на регулярности, а не на составе работ. Обновление ядра CMS занимает минуты. Восстановление взломанного сайта — дни. Разница в цене между профилактикой и аварийным восстановлением почти всегда не в пользу экономии. Вторая ошибка — устная договорённость «мы быстро реагируем» вместо письменного SLA. Она ничего не гарантирует. Сверяться не с чем, если что-то пошло не так. Третья — обещание «оперативно» без цифры. Без часов и минут в тексте договора это просто слово.
Для интернет-магазинов формат поддержки особенно важен: e-commerce не может позволить себе часы недоступности в разгар трафика. Этот сценарий закрывает техподдержка интернет-магазина в пиковые дни с отдельной линией на инциденты, а состав работ по конкретным угрозам — заражение вредоносным кодом — закрывает удаление вирусов и лечение сайта.
Частые вопросы
Во сколько обходится техподдержка сайта в месяц?
От 70 000 ₽ за пакет 20 часов, от 165 000 ₽ за 50 часов, от 310 000 ₽ за 100 часов — цены Toimi на 29.09.2026, без НДС. Точная сумма зависит от объёма сайта и потока задач.
Чем техподдержка отличается от администрирования сайта?
Техподдержка закрывает контент, доработки и реакцию на инциденты. Администрирование — это работа с сервером: обновления окружения, мониторинг ресурсов, настройка инфраструктуры. На небольшом проекте это может делать один подрядчик, на крупном роли иногда разделяют.
Что случится, если сайт не обслуживать вообще?
Растёт риск взлома через незакрытые уязвимости в старой версии CMS. Копится техдолг, который дороже чинить одним махом, чем регулярными мелкими правками. При сбое нет резервной копии для быстрого восстановления. Для бизнеса это прямые потери заказов и репутации, а не абстрактный пункт в чек-листе.
Как часто нужно обновлять CMS и плагины?
Критические обновления безопасности — сразу после выхода, плановые — не реже раза в месяц. Более частые проверки нужны сайтам на популярных CMS вроде WordPress и OpenCart, где новые уязвимости находят регулярно.
Нужен ли отдельный договор на техподдержку, если сайт сделан на заказ у той же студии?
Да. Разработка и поддержка — разные договоры с разным предметом: один закрывает создание сайта, второй — его дальнейшую жизнь, SLA и резервные копии. Смешение условий в одном документе усложняет расторжение любого из них по отдельности.
Кто должен проверять резервную копию — разработчик или хостинг?
Разработчик. Хостинг хранит файл копии, но не обязан знать, разворачивается ли она в рабочий сайт. Ответственность за тестовое восстановление закрепляют в договоре на техподдержку, а не оставляют на усмотрение хостинг-провайдера.