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

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

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

Ниже о том, что входит в поддержку и что в неё обычно не входит, какие бывают форматы договора, что проверить у подрядчика и как заранее подготовиться к четырём типовым авариям.

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

Как в офисном здании: управляющая компания следит, чтобы работали свет, лифт и отопление, а ремонт идёт отдельным договором.

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

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

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

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

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

Есть простое правило 3-2-1: три копии данных, в двух разных хранилищах, одна из них вне основного сервера. Частота зависит от того, сколько данных не жалко потерять. Если на сайте каждый день оформляют заказы, база копируется минимум раз в сутки. Для сайта-визитки, который меняется раз в месяц, хватит еженедельных копий. И раз в квартал стоит устраивать учебное восстановление: развернуть копию на отдельном сервере и убедиться, что сайт открывается и данные на месте.

Многие до сих пор уверены, что о падении сайта предупредит Яндекс Метрика. Но мониторинга доступности с оповещениями по SMS и почте в ней сейчас нет. Если вы на него рассчитываете, оповещения вам просто не приходят.

У Яндекс Директа есть собственная проверка: если главная страница недоступна больше 15 минут, показы объявлений останавливаются и потом сами возобновляются. Это бережёт рекламный бюджет, но мониторингом не является. Директ смотрит только на главную и всего несколько раз в день, частоту настроить нельзя.

Нормальный мониторинг проверяет сайт снаружи раз в одну-пять минут и пишет в мессенджер конкретному человеку. И проверяет не только главную: главная может открываться, пока обработчик форм или каталог лежат. Для сайтов с интеграциями полезно следить ещё и за свежестью данных. На сайте центра йоги «Прана» расписание подтягивается из 1С каждые 10 минут. Если такой обмен остановится, сайт продолжит открываться, а расписание начнёт тихо устаревать. Этот сбой поймает только проверка вида «когда данные обновлялись последний раз».

Сертификат отвечает за замочек в адресной строке. Когда он истекает, браузер показывает посетителю тревожное предупреждение, и почти никто не нажимает «всё равно перейти». Сроки жизни сертификатов в отрасли постепенно сокращают, так что продлевать их вручную раз в год больше не выйдет: продление должно быть автоматическим. Бесплатные сертификаты Let's Encrypt живут 90 дней и писем о скором окончании не присылают. Значит, нужна своя проверка срока, хотя бы в том же мониторинге.

С доменом история похожая, только последствия тяжелее. Когда заканчивается срок регистрации домена .ru, его делегирование приостанавливается: перестают работать и сайт, и почта на этом домене. Дальше есть 30 дней, в которые прежний владелец ещё может домен продлить. Не успели, и его может зарегистрировать кто угодно, включая перекупщиков.

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

Безопасность складывается из скучных вещей: обновления, сложные пароли, двухфакторный вход в админку, отдельные учётные записи для каждого сотрудника и подрядчика, удаление доступов у тех, кто ушёл. Для закрытых разделов полезно ограничивать вход по IP-адресам и автоматически блокировать подозрительную активность. Так, например, устроен кабинет дилеров MMB Russia с IP-контролем и автобаном.

Самые неприятные взломы те, которых не видит владелец. Вредоносный код перенаправляет на чужие сайты только посетителей со смартфонов, пришедших из поиска. Владелец заходит с компьютера по закладке, у него всё в порядке. Узнают о таком из раздела «Безопасность и нарушения» в Яндекс Вебмастере или от клиентов.

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

Поэтому защита должна стоять на сервере, а не только в браузере. Проверки в браузере бот обходит, потому что браузер он не открывает.

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

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

Чтобы не было обид с обеих сторон, полезно заранее знать, что в стандартную поддержку обычно не входит:

• новые разделы, функции и интеграции;
• редизайн и переработка страниц;
• SEO-продвижение и ведение рекламы;
• наполнение сайта текстами и товарами в больших объёмах;
• системное ускорение сайта.

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

Услуги технической поддержки сайта продают в трёх основных форматах. Условия у всех разные, а логика одна.

SLA расшифровывается как Service Level Agreement, соглашение об уровне сервиса. На практике это таблица: что считается аварией, а что мелочью, и за какое время подрядчик обязан отреагировать и починить. Например: «сайт не открывается» относится к критическому приоритету с реакцией за полчаса в любое время суток, а «опечатка на странице» к низкому, с исправлением за пару рабочих дней.

Обратите внимание на разницу между временем реакции и временем решения. Реакция означает, что задачу кто-то взял в работу. Решение означает, что всё починили. В хорошем договоре есть оба срока, хотя бы для критических задач.

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

Запрос «техническая поддержка сайтов договор» обычно ищут, когда договор уже прислали и нужно понять, всё ли в нём на месте. Вот что там должно быть.

Пункт про персональные данные часто пропускают. Если подрядчик имеет доступ к базе, где лежат заявки и контакты клиентов, по 152-ФЗ он обрабатывает эти данные по вашему поручению, и условия такого поручения нужно прописать. Формулировки лучше сверить с юристом.

Служба технической поддержки сайта у подрядчика не обязательно отдел из десяти человек. Но несколько вещей стоит проверить до подписания, вопросами, а не по презентации.

Хорошая проверка: спросите, что подрядчик сделает, если в пятницу в девять вечера сайт перестанет открываться. Внятный ответ звучит как шаги с именами и сроками. Если слышите «позвоните, разберёмся», так оно и будет.

Большинство аварий повторяются от сайта к сайту. Хорошая новость в том, что к каждой можно подготовиться заранее.

Как выглядит: сайт не открывается или отдаёт ошибку 502 или 503. Причины разные: закончилось место на диске, сервер не выдержал нагрузки, упала база данных, у хостинга проблемы.

Как подготовиться: внешний мониторинг с оповещением, копии вне основного сервера и понятная инструкция, как развернуть сайт на новом месте. Задайте подрядчику вопрос заранее: сколько часов уйдёт на переезд на другой сервер, если текущий не поднимется совсем? Если ответ «не знаем», это и есть задача на ближайший месяц.

Как выглядит: сайт не открывается ни у кого, письма на корпоративную почту не доходят. Частая причина банальна: карту, к которой было привязано автопродление, перевыпустили.

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

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

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

Как выглядит: всё работает, но заявок меньше обычного или ноль. Причин много. Письма с сайта попадают в спам, потому что у домена не настроены записи SPF и DKIM, которые подтверждают почтовым сервисам подлинность письма. После обновления сломался скрипт отправки. У интеграции с CRM истёк ключ доступа. Новая капча блокирует заодно и людей.

Как подготовиться: заявка сохраняется в базе сайта, даже если письмо не ушло, и дублируется в CRM или мессенджер. Мониторинг раз в день отправляет тестовую заявку и проверяет, что она дошла. А в отделе продаж знают, сколько заявок в день нормально, и поднимают тревогу, если их подозрительно мало.

Половина времени в аварии уходит не на ремонт, а на поиски: где зарегистрирован домен, у кого пароль от хостинга, кто вообще делал этот сайт. Поэтому полезно один раз собрать аварийную карточку и хранить её там, где её найдёт руководитель, а не только разработчик.

Пересматривайте карточку раз в полгода и после смены подрядчика или ответственного сотрудника.

Не каждому сайту нужен договор с ежемесячной оплатой.

Сайт на конструкторе. Сервер, обновления и сертификат там на стороне платформы. На вас остаются домен, формы и интеграции. Хватит своего мониторинга и тестовой заявки раз в неделю.

Простая визитка без форм и интеграций. Хватит проверки раз в квартал и автопродления домена. Договор ради трёх задач в год заключать мало смысла.

Свой разработчик в штате. Тогда вопрос не в подрядчике, а в том, кто подменит этого человека в отпуске или на больничном и есть ли у кого-то ещё доступы и описание того, как устроен сайт.

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

Техническая поддержка сайта нужна не потому, что сайт сломан, а чтобы он не ломался тихо. Её основа: обновления через тестовую копию, проверенные резервные копии, внешний мониторинг, контроль сроков домена и сертификата и защита форм. Формат договора выбирайте по тому, насколько болезнен для вас час простоя, а подрядчика проверяйте неудобными вопросами. Аварийную карточку можно собрать уже сегодня.