Поддержка — самая непрозрачная из услуг в разработке. Сайт сделали, передали, дальше начинается месячный платёж, за которым стоит непонятно что: вроде ничего не ломается, правок почти нет, а счёт приходит. Или наоборот: сайт лежит третий час, а подрядчик отвечает, что заявок в очереди много. Разберём, из чего вообще состоит поддержка и как сформулировать её так, чтобы обе стороны понимали, за что платят.
Постоянная часть: то, что делается без заявок
Это та часть, которую клиент не видит, и именно из-за неё возникает ощущение, что в тихий месяц деньги уходят зря. На самом деле тихий месяц — это и есть результат работы.
- Мониторинг доступности: проверка каждые несколько минут из внешней точки, уведомление в мессенджер при падении. Проверять надо не только главную, но и каталог, корзину и ответ API, если он есть
- Мониторинг содержимого, а не только кода ответа: страница может отдавать 200 и при этом показывать пустой каталог, если обмен с учётной системой обнулил остатки
- Срок действия SSL-сертификата и домена. Просроченный домен — самая обидная из возможных аварий, потому что она на сто процентов предсказуема
- Свободное место на диске и в базе, размер логов, рост директории с кешем
- Время ответа сервера в динамике: деградация обычно наступает постепенно, и поймать её можно только на графике
- Состояние очереди обмена: когда последний раз проходила выгрузка, сколько позиций обработано, были ли ошибки
Разница между поддержкой и ремонтом по вызову в том, что о половине проблем клиент не узнаёт. Если он узнаёт обо всём первым — поддержки нет, есть абонентская плата за готовность отвечать на звонки.
Резервные копии: проверяется только восстановлением
Бэкап, который никто ни разу не разворачивал, бэкапом не является. Самые частые находки в момент, когда он понадобился: копия лежит на том же диске, что и сайт; база копируется, а файлы нет; дамп обрывается на середине, потому что скрипту не хватало памяти; копий всего две, а проблему заметили через неделю.
- База — ежедневно, файлы — еженедельно плюс перед каждым обновлением
- Хотя бы одна копия вне сервера: другой провайдер или объектное хранилище. Копия рядом с сайтом спасает от ошибки в коде, но не от потери сервера
- Глубина хранения: суточные за две недели, недельные за пару месяцев. Иначе поломка, замеченная поздно, уже везде
- Шифрование, если в базе есть персональные данные, и ограниченный доступ к хранилищу
- Проверка восстановлением раз в квартал на тестовом контуре, с замером времени: сколько минут занимает подъём сайта из копии — это и есть реальное время простоя в худшем случае
Обновления: порядок важнее частоты
Обновлять сразу на боевом сервере нельзя, не обновлять нельзя тоже: дыры в популярных CMS и плагинах эксплуатируются массово и автоматически, через считанные дни после публикации уязвимости. Единственный рабочий вариант — тестовый контур, копия боевого сайта.
- Снять копию базы и файлов, развернуть на тестовом домене, закрытом от индексации и от посторонних
- Обновить там, пройти проверочный список: каталог, фильтр, карточка, корзина, оформление заказа, формы, админка, обмен с учётной системой
- Посмотреть журнал ошибок PHP после прохода — часть поломок не видна глазом, но пишется в лог
- Только потом обновлять боевой сайт, с бэкапом прямо перед обновлением и в часы низкой нагрузки
- Отдельно держать список доработок, сделанных поверх ядра и плагинов: именно они ломаются при обновлении
Платформы ведут себя по-разному. В 1С-Битрикс обновление ядра и обновление модулей — разные операции, и при активной лицензии ядро обновляется часто; больно обычно бывает с кастомизированными компонентами, скопированными в локальную папку. В WordPress главный риск не само ядро, а плагины: несовместимость двух из них проявляется не сразу, а на конкретном сценарии вроде оформления заказа. Про PHP отдельно: мажорная версия обновляется не по расписанию, а отдельной задачей с прогоном всего кода на совместимость.
Безопасность в повседневном режиме
- Доступ в админку ограничен или хотя бы прикрыт вторым фактором; учётные записи уволившихся сотрудников отключаются сразу, а не когда вспомнят
- Защита от перебора паролей: ограничение числа попыток, блокировка по IP на уровне сервера
- Права на файлы: записываемыми должны быть загрузки, кеш и логи, а не вся директория сайта
- Заголовки безопасности, HTTPS без смешанного содержимого, валидный сертификат с автопродлением
- Периодическая проверка на изменения в файлах: внезапно появившийся PHP-файл в папке загрузок — это почти всегда то, чем он выглядит
- Отдельные учётные записи для подрядчиков вместо общего пароля администратора на всех
Время реакции и время решения — это разные вещи
В договорах обычно фигурирует одно число, и из-за этого возникает основная часть недовольства. Реакция — это когда подрядчик подтвердил, что задачу видит, и сказал, что с ней будет. Решение — когда работает. Для опечатки в тексте эти сроки почти совпадают, для сложной поломки обмена могут отличаться на порядок.
Разумная схема — разделить обращения на классы и для каждого задать своё время.
- Авария: сайт недоступен, не оформляется заказ, не проходит оплата, не идёт обмен с учётом. Реакция в пределах часа, работа без очереди, вне зависимости от остатка часов в пакете
- Сбой без остановки продаж: не работает один фильтр, не отправляется одна форма, криво отображается раздел. Реакция в течение рабочего дня
- Обычная задача: правка текста, баннер, новая страница, выгрузка. Реакция в течение дня, срок согласуется
- Доработка: новая функциональность. Оценивается отдельно и в поддержку по умолчанию не входит
Отдельно стоит проговорить режим: рабочие часы, выходные, праздники. Круглосуточное дежурство стоит денег и нужно не всем, но магазину с основным оборотом в выходные оно нужно точно. Что из этого попадает в договор и какими словами — разбирали в статье про договор на разработку, там же про акты и приёмку.
Часы: что считается и что переносится
Самая частая модель — пакет часов в месяц. Чтобы она не превращалась в источник споров, на старте проговариваются три вещи.
- Что входит в час: только работа по задаче или ещё обсуждение, тестирование и выкладка. Честный ответ — всё перечисленное, потому что выкатить правку без проверки нельзя
- Единица округления. Пятиминутная правка, округлённая до часа, — способ быстро потратить пакет впустую
- Переносятся ли неизрасходованные часы и на сколько месяцев. Без переноса в тихие месяцы клиент платит за воздух, с бесконечным переносом у подрядчика копится неподъёмный долг
- Входит ли в часы постоянная часть — мониторинг, бэкапы, обновления. Обычно нет: это фиксированная услуга, а часы расходуются на задачи
- Что происходит при превышении: докупка часов по той же ставке или ожидание следующего месяца
Отчёт в конце месяца должен позволять сверить это самостоятельно: список задач, затраченное время по каждой, остаток. Строка «работы по поддержке — 10 часов» отчётом не является.
Доступы, которые должны быть у обеих сторон
Проверять это надо не в момент аварии. Минимальный набор, который должен быть у клиента на руках и лежать в его собственном хранилище паролей.
- Домен: регистратор, личный кабинет, привязка к почте компании, а не к личной почте бывшего сотрудника
- Хостинг или сервер: панель, SSH, доступ к базе
- Администратор CMS с полными правами
- Репозиторий с кодом и доступ к истории изменений
- Метрика, Вебмастер, рекламные кабинеты — на аккаунт компании, с выдачей прав подрядчику, а не наоборот
- Почтовый сервис, через который сайт отправляет письма
Сайт, доступы к которому есть только у подрядчика, — это риск, не зависящий от его добросовестности: подрядчик может просто перестать отвечать. Обратное тоже верно: подрядчику для нормальной работы нужен доступ к серверу, а не только к админке, иначе половину задач он решать не сможет и будет каждый раз просить кого-то нажать кнопку.
Как ставить задачу, чтобы она не вернулась с вопросами
- Адрес страницы целиком, а не «на странице услуг»
- Что ожидали увидеть и что увидели вместо этого
- Браузер, устройство, был ли вход в админку — половина «ошибок» видна только авторизованным
- Скриншот целиком, с адресной строкой, а не вырезанный фрагмент
- Воспроизводится ли повторно и с какого момента замечено
- Для правок текста — готовый текст, а не описание, какой он должен быть
Задача, описанная так, занимает у клиента лишние три минуты и экономит подрядчику полчаса переписки — то есть в прямом смысле оплаченное время из пакета.
Что в поддержку обычно не входит
- Новая функциональность: личный кабинет, новый тип каталога, интеграция с ещё одной системой. Это проект со сметой
- Редизайн и смена шаблона
- Наполнение каталога и написание текстов, если это не оговорено отдельно
- SEO-продвижение и ведение рекламы — смежные услуги с другой логикой оплаты
- Восстановление после взлома сайта, который до этого не был на поддержке: объём работ там непредсказуем
Отдельно про скорость. Разовая работа с Core Web Vitals — это не поддержка, а проект с замерами до и после: ускорение сайта. В поддержке разумно держать контроль за тем, чтобы достигнутые показатели не деградировали обратно после десятка правок.
Как понять, что поддержка работает
- Вы знаете, сколько минут сайт был недоступен за месяц, и это не оценка на глаз
- Вы хотя бы раз видели, как разворачивается резервная копия
- Обновления происходят, и вы узнаёте о них из отчёта, а не из сломавшейся корзины
- По каждой задаче видно, сколько времени она заняла
- Аварии решаются вне очереди и без обсуждения остатка часов
- Раз в квартал кто-то смотрит на сайт целиком, а не только на входящие заявки
Мы берём на сопровождение и свои проекты, и чужие — с аудитом на входе, потому что принимать незнакомый сайт вслепую нельзя: поддержка сайта пакетами часов. Серверная часть — мониторинг, резервные копии, обновления окружения, SSL — выделена в администрирование, и для магазина с обменом она обычно нужна вместе с поддержкой, а не вместо неё. Если сайт уже лежит или ведёт себя странно, начинать стоит с разбора состояния, а не с подписания абонемента.
Как принять одну задачу в рамках поддержки
Опишите задачу через исходное и ожидаемое поведение. Например: «После выбора пункта выдачи итоговая сумма должна обновиться без потери введённых контактов». Такая формулировка позволяет проверить исправление на том же сценарии, а не принимать работу по сообщению «готово».
- В заявке: URL, устройство, шаги повторения, ожидаемый результат и влияние ошибки на заказы.
- До работ: согласованные часы или стоимость, что входит в задачу и кто принимает результат.
- До переноса: проверка на тестовой копии, актуальная резервная копия и порядок возврата изменений.
- После переноса: контрольный сценарий на рабочем сайте и запись того, что изменено. Для магазина — проверка корзины, оформления и уведомлений в затронутой части.
Проверку обновлений сначала на тестовой копии и резервное копирование рекомендует сама документация WooCommerce. Копия файлов и копия базы решают разные части восстановления; это также поясняет WordPress.
Пример передачи чужого проекта — Brushes Paints: магазин приняли незавершённым, довели до запуска и продолжили поддержку. Если нужна одна правка, можно начать с разовой задачи, а регулярный объём согласовать после знакомства с проектом.
Если нужна разовая задача, посмотрите из чего складывается стоимость доработки сайта: как сравнить оценки и согласовать проверяемый результат.
