Поддержка и развитие сайта после запуска: что входит и как договориться об SLA

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

Сайт или веб-сервис запущен, акты подписаны, команда разработки переключилась на другие задачи. Через месяц перестаёт отправляться форма заявки — никто не замечает неделю. Через три месяца истекает SSL-сертификат, и браузеры начинают показывать посетителям предупреждение об опасности. Через полгода в устаревшем плагине находят уязвимость, и сайт начинает рассылать спам. Каждая из этих историй типична, и каждая происходит не из-за плохой разработки, а из-за того, что после запуска сайтом никто систематически не занимается. Сайт — не документ, который можно сделать и положить на полку. Это программная система, работающая в меняющейся среде: обновляются браузеры, библиотеки, серверное ПО, появляются новые уязвимости, меняются внешние сервисы, с которыми сайт связан, растёт нагрузка. Ниже — что входит в техническую поддержку, чем поддержка отличается от развития, как описать уровень сервиса в соглашении, какие бывают модели оплаты и как понять, что подрядчик действительно поддерживает сайт, а не просто получает ежемесячный платёж. Поддержка и развитие — разные вещи Путаница между этими понятиями — главный источник конфликтов после запуска. Поддержка — сохранение работоспособности того, что уже сделано: мониторинг, обновления, резервное копирование, исправление ошибок, реакция на сбои, продление сертификатов и доменов. Развитие — изменения и новые возможности: новые разделы и страницы, доработки функций, интеграции, редизайн, оптимизация конверсии. Если в договоре написано просто «сопровождение сайта», заказчик ожидает, что туда входят и доработки, а подрядчик считает, что только работоспособность. Эти работы нужно разделить явно: что входит в фиксированный ежемесячный объём, а что оценивается и согласуется отдельно. Что входит в техническую поддержку Мониторинг Доступность. Внешняя проверка каждые несколько минут: открывается ли сайт, отвечает ли он корректным кодом, укладывается ли время ответа в норму. Ключевые сценарии. Проверка не только главной страницы, но и того, что приносит деньги: отправка формы, оформление заказа, вход в личный кабинет, оплата. Сайт может открываться, а заявки при этом не доходить. Ошибки. Сбор ошибок сервера и ошибок в браузерах пользователей с оповещением при всплеске. Ресурсы. Место на дисках, загрузка процессора и памяти, размер базы данных, очереди. Сроки. Окончание срока SSL-сертификатов, регистрации доменов, оплаченных услуг внешних сервисов. Мониторинг бесполезен без оповещений, которые получает конкретный человек, и без регламента, что он делает, получив оповещение. Резервное копирование Регулярные копии кода, базы данных и загруженных файлов, хранящиеся отдельно от основного сервера. Важнейшая и чаще всего пропускаемая часть — периодическая проверка восстановления. Резервная копия, из которой ни разу не пробовали восстановиться, — надежда, а не страховка. В соглашении стоит зафиксировать, как часто делаются копии, сколько хранятся, где хранятся и за какое время сайт восстанавливается из копии. Обновления серверное ПО и операционная система; система управления контентом, плагины, модули; библиотеки и зависимости приложения; срочные обновления безопасности — вне планового графика. Обновление без тестирования может сломать сайт, отказ от обновлений — сделать его уязвимым. Нормальный процесс: обновление сначала на тестовой копии, проверка ключевых сценариев, затем выкладка с возможностью отката. Безопасность отслеживание уязвимостей в используемых компонентах; защита административной части, управление доступами, отзыв доступов уволенных сотрудников и бывших подрядчиков; защита от автоматизированных атак и спама на формах; проверка сайта на заражение и нежелательные изменения; обработка персональных данных в соответствии с требованиями — подробно о них в статье о 152-ФЗ для сайтов . Исправление ошибок Ошибки в работе реализованных функций: форма не отправляется в определённом браузере, неверно считается скидка, ломается вёрстка на новых моделях телефонов. Исправление ошибок отличается от доработок: ошибка — это когда сделанное не работает так, как было задумано и принято. Интеграции Внешние сервисы меняют свои API, условия, способы авторизации. Платёжный провайдер обновил протокол, служба доставки перешла на новую версию интерфейса, CRM изменила формат данных. Поддержка отслеживает такие изменения и адаптирует интеграции до того, как они перестанут работать. Производительность Контроль скорости загрузки и показателей Core Web Vitals, реакция на их ухудшение. Со временем сайты медленно тяжелеют: добавляются изображения без оптимизации, счётчики, виджеты. Если никто не следит, через год быстрый сайт становится медленным. Консультации Ответы на вопросы сотрудников заказчика о работе с административной частью, помощь при нестандартных ситуациях. SLA: как договориться об уровне сервиса Соглашение об уровне сервиса — SLA — описывает, что считается проблемой, насколько быстро подрядчик на неё реагирует и в какие сроки решает. Без него любое ожидание субъективно: для заказчика неработающая форма — пожар, для подрядчика — одна из задач в очереди. Уровни критичности Обращения делятся по влиянию на бизнес. Типичная шкала: Критический. Сайт недоступен, не работают оплата или приём заявок, утечка данных, взлом. Бизнес теряет деньги прямо сейчас. Высокий. Не работает важная функция, но есть обходной путь или затронута часть пользователей: не отправляется одна из форм, ошибка в личном кабинете у пользователей определённого браузера. Средний. Ошибка, заметная пользователям, но не мешающая основным сценариям: сломана вёрстка второстепенной страницы, неверный текст. Низкий. Мелкие недочёты и консультации. Определения уровней нужно формулировать через последствия для бизнеса, с примерами, а не через технические термины. Иначе каждое обращение будет сопровождаться спором о его уровне. Время реакции и время решения Время реакции — за сколько подрядчик подтверждает обращение и начинает работу. Автоответ робота реакцией не считается. Время решения — за сколько проблема устранена или применено временное решение, возвращающее работоспособность. Для каждого уровня критичности указываются оба значения. Разумно разделять временное решение — например, откат к предыдущей версии — и окончательное исправление: для критической проблемы важнее быстро вернуть работу, чем сразу найти корневую причину. Часы работы Круглосуточная поддержка с реакцией в выходные и ночью стоит заметно дороже поддержки в рабочие часы. Нужна она не всем: корпоративному сайту B2B-компании, заявки с которого обрабатываются в рабочее время, часто достаточно рабочих часов для большинства обращений и дежурства для критических. Интернет-магазину или сервису, который работает круглосуточно и принимает оплаты, — нет. Доступность Целевая доля времени, когда сайт доступен, считается за месяц. Важно договориться, как именно она измеряется — каким мониторингом, с какой частотой проверок, — и что исключается: плановые работы, согласованные заранее, сбои внешних сервисов вне контроля подрядчика. Разница между уровнями доступности, которые кажутся близкими, в часах простоя может быть большой: в месяце около 720 часов, и каждая десятая доля процента — это примерно 43 минуты. Каналы обращений Как заказчик сообщает о проблеме: система заявок, почта, телефон для критических ситуаций. Обращение в личный мессенджер конкретного разработчика — не канал поддержки: оно теряется, когда человек в отпуске. Отчётность Ежемесячный отчёт: доступность, число и уровни обращений, соблюдение сроков реакции и решения, выполненные работы по обслуживанию — обновления, проверка резервных копий, — и найденные риски. Отчёт превращает поддержку из абстрактного платежа в видимую работу. Последствия нарушений Что происходит, если сроки не соблюдены: снижение оплаты за месяц, право на расторжение при систематических нарушениях. Без последствий SLA остаётся пожеланием. Образец описания уровней в SLA Ниже — условный пример для интернет-магазина, который принимает оплаты круглосуточно. Значения иллюстративные: для корпоративного сайта B2B-компании они будут мягче, для платёжного сервиса — строже. Критический — сайт недоступен, не проходит оформление заказа или оплата, признаки взлома или утечки. Реакция — 15 минут круглосуточно. Временное решение, возвращающее работоспособность, — до 2 часов. Разбор причин — в течение двух рабочих дней после инцидента. Высокий — не работает важная функция у части пользователей или есть обходной путь: не применяются промокоды, ошибка оплаты одним из способов, не приходят письма о заказе. Реакция — 1 час в рабочее время. Решение — до конца следующего рабочего дня. Средний — заметная ошибка без влияния на заказы: сломан фильтр в одной категории, неверно отображается страница на части устройств. Реакция — 4 рабочих часа. Решение — до 5 рабочих дней. Низкий — косметические недочёты, консультации. Реакция — 1 рабочий день. Решение — по согласованному плану. К этому добавляются: целевая доступность за месяц и способ её измерения, перечень исключений, каналы обращений для каждого уровня, состав ежемесячного отчёта и последствия нарушения сроков. Если обращение отнесено к уровню спорно, в соглашении стоит заранее указать, чьё решение окончательное — обычно уровень определяет заказчик, а подрядчик может его оспорить после устранения проблемы. Что происходит после оповещения SLA описывает сроки, а регламент реакции — последовательность действий. Без него даже быстрая реакция превращается в хаос. Подтверждение. Дежурный подтверждает получение оповещения и берёт инцидент на себя, чтобы не было ситуации, когда проблему ждут от других. Оценка. Что затронуто, сколько пользователей, какой уровень критичности. При критическом уровне сразу уведомляется ответственный со стороны заказчика. Восстановление. Приоритет — вернуть работоспособность: откатить последнее изменение, переключить на резервный ресурс, отключить сломанную функцию. Поиск корневой причины — после. Коммуникация. Заказчик получает короткие обновления через согласованные интервалы, даже если новостей нет. Молчание во время инцидента воспринимается хуже самой проблемы. Закрытие. Подтверждение, что работоспособность восстановлена и проверена по ключевым сценариям. Разбор. Что произошло, почему мониторинг или проверки не предотвратили, что изменить. Разбор без поиска виноватых, с конкретными задачами по итогам. Модели оплаты Фиксированный ежемесячный платёж за определённый объём: мониторинг, обновления, резервное копирование, исправление ошибок и лимит часов на мелкие задачи. Предсказуемо для заказчика и подрядчика. Нужно чётко определить, что происходит с неиспользованными часами и что делать при превышении лимита. Почасовая оплата по факту. Подходит для сайтов, где обращений мало. Риск — отсутствие проактивной работы: без обращения никто не проверяет обновления и резервные копии. Комбинированная модель. Фиксированный платёж за обязательное обслуживание и дежурство плюс почасовая оплата доработок по согласованной ставке. Самый распространённый и обычно самый честный вариант. Выделенная команда. Для крупных продуктов, где поддержка и развитие идут непрерывно, — постоянная команда с оплатой её времени и планированием работ по итерациям. Как понять, что поддержка работает Самая большая проблема поддержки — её не видно, когда она хорошая. Признаки реальной работы: о проблемах сайта подрядчик сообщает раньше, чем их замечает заказчик или клиенты; ежемесячный отчёт содержит конкретные выполненные работы, а не только число закрытых обращений; версии системы управления, плагинов и библиотек не отстают от актуальных на годы; подрядчик может показать дату последней проверки восстановления из резервной копии; доступы к сайту, серверу и сервисам есть у заказчика, а их перечень актуален; сертификаты и домены ни разу не истекали неожиданно; подрядчик сам предлагает устранить риски: устаревший компонент, медленную страницу, растущую базу. Если о падении сайта заказчик узнаёт от клиентов, а на вопрос о резервных копиях получает «должны быть», поддержка существует только в договоре. Когд