Зачем поддержка нужна даже тогда, когда на сайте ничего не меняется
Частое заблуждение владельцев бизнеса звучит так: «Сайт готов, работает, зачем платить кому-то ещё?» Проблема в том, что сайт — это не памятник, который стоит неизменным, а система, встроенная в постоянно меняющуюся среду. Даже если вы не добавляете новые разделы и не переписываете тексты, вокруг сайта продолжает происходить движение, и от него нельзя откупиться разовым платежом за разработку.
Во-первых, CMS и подключённые модули регулярно выходят с обновлениями — часть из них закрывает уязвимости, часть чинит совместимость с новыми версиями PHP или браузеров. Если обновления не ставить, через полгода-год сайт рискует превратиться в мишень для автоматических сканеров, которые ищут именно старые версии популярных движков и плагинов. Это не гипотетический риск: массовые взломы сайтов на популярных CMS почти всегда происходят не через целенаправленную атаку на конкретную компанию, а через автоматический перебор известных уязвимостей в старых версиях — сканер не выбирает жертву осознанно, он просто находит первый неотпатченный сайт.
Во-вторых, безопасность — это не разовая настройка, а процесс: нужно отслеживать попытки взлома, подозрительную активность в логах, вовремя менять скомпрометированные пароли и закрывать дыры, о которых стало известно уже после релиза сайта.
В-третьих, есть хостинг: у него заканчиваются ресурсы под возросшую нагрузку, истекают сертификаты, случаются сбои на стороне провайдера. И, наконец, мониторинг аптайма — единственный способ узнать о падении сайта раньше, чем об этом сообщит рассерженный клиент в директ.
Что обычно входит в SLA техподдержки
SLA (service level agreement) — это не формальность для договора, а конкретный набор обязательств, который можно измерить. Если в документе нет цифр, это не SLA, а красиво оформленное намерение. В нормальном SLA обычно фиксируются четыре блока.
- Время реакции на инциденты — сколько максимум пройдёт с момента обращения (или автоматического алерта о падении сайта) до того, как специалист начнёт разбираться в проблеме. Для критичных инцидентов это часы, а не дни.
- Часы консультаций и правок в месяц — пул времени на мелкие доработки, тексты, настройки, которые не тянут на отдельный проект, но регулярно нужны бизнесу.
- Резервное копирование — с какой периодичностью снимаются бэкапы базы данных и файлов, где они хранятся и как быстро можно восстановиться из них при аварии.
- Мониторинг скорости и доступности — регулярные проверки времени отклика страниц и аптайма, чтобы деградацию производительности замечали до того, как она повлияет на конверсию.
Форматы оплаты: что выгоднее в вашей ситуации
На рынке встречаются три основные модели, и универсально «лучшей» среди них нет — вопрос в том, насколько предсказуема нагрузка на поддержку у конкретного сайта.
Почасовая оплата подходит стабильным проектам, где правки случаются редко и непредсказуемо: сайт-визитка, лендинг, который живёт без активных изменений. Здесь платить абонемент невыгодно — часы просто будут простаивать.
Пакет часов в месяц — самый распространённый формат для действующего интернет-магазина или корпоративного сайта с регулярными правками: обновление каталога, баннеры к акциям, мелкие доработки форм. Пакет дисциплинирует: если часы не используются, их обычно можно частично перенести на следующий месяц, но переплаты за «страховку» здесь минимальны.
Фиксированный абонемент с гарантированным SLA имеет смысл там, где простой сайта напрямую бьёт по выручке: крупный интернет-магазин, сервис с онлайн-записью, сайт с высоким трафиком в пиковые часы. Здесь вы платите не столько за часы работы, сколько за гарантию, что в критический момент разработчик будет доступен немедленно, а не «в порядке живой очереди».
Как отличить адекватный SLA от красивых слов на бумаге
Главный признак несерьёзного предложения — обтекаемые формулировки вроде «оперативно решим», «быстро отреагируем», «поддержка в приоритете». Ни одна из этих фраз не даёт вам права предъявить претензию, если что-то пошло не так, потому что она ничего конкретного не обещает.
Адекватный SLA всегда содержит измеримые метрики: время реакции (например, «не более 2 часов в рабочее время для критичных инцидентов»), время восстановления работоспособности (RTO — «сайт возвращается в строй не позднее чем через 4 часа»), а также описание, что происходит, если эти сроки не соблюдены — перерасчёт стоимости, компенсация часами, эскалация на более старшего специалиста. Если подрядчик не готов зафиксировать конкретные цифры в договоре, это повод насторожиться: скорее всего, ответственность за простой сайта в итоге ляжет только на вас.
Полезная проверка при выборе подрядчика — попросить показать реальный пример отчёта о инциденте за прошлый месяц: если компания действительно работает по SLA, у неё найдётся запись о времени поступления заявки, начале работы и закрытии тикета. Отсутствие такой истории при громких обещаниях — верный сигнал, что заявленные сроки реакции существуют только на бумаге.
Что происходит, если поддержки нет вообще
Экономия на техподдержке обычно выглядит рационально ровно до первого серьёзного инцидента. На практике отсутствие сопровождения приводит к одному и тому же набору проблем, повторяющемуся из проекта в проект. Сайт «падает» именно в момент пиковой нагрузки — во время рекламной кампании, распродажи или сезонного всплеска спроса, — потому что никто заранее не следил за ресурсами хостинга и не настраивал кэширование под рост трафика. Уязвимости, о которых давно есть публичные патчи, остаются открытыми месяцами, пока сайт не попадает в выдачу поисковика с пометкой о заражении или не начинает рассылать спам с чужого имени. А мелкие правки — поменять телефон в шапке, обновить цену, исправить опечатку — копятся неделями, потому что обратиться попросту не к кому: разработчик, который делал сайт, давно занят другими проектами.
Разумный выход — не пытаться закрыть все эти риски своими силами, а с самого начала выстроить регулярное сопровождение с понятными обязательствами. В Evaris для этого есть сопровождение сайта в Evaris: конкретные метрики реакции и восстановления, прозрачный пул часов на доработки и мониторинг, который не даёт узнать о проблеме последними. Если сайт уже запущен, но поддержки по нему пока нет — лучше обсудить формат SLA сейчас, а не после того, как что-то сломается в самый неподходящий момент.