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

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

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

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

Что входит в техническую поддержку сайта, а что оплачивается отдельно

Абонентская плата покрывает регулярную работу, которая держит сайт в том виде, в каком его приняли. Это обновления, копии, наблюдение за доступностью, исправление поломок и отчёт. Всё, что сайт меняет (новый раздел, форма, интеграция, дизайн, тексты), считается доработкой, её оценивают и согласуют до начала работы, даже если платят из часов пакета. Граница должна стоять в договоре перечнем. Иначе её будут проводить заново при каждом споре о счёте.

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

Версии PHP и CMS: кто обновляет и к какому сроку

В договоре должен быть назван ответственный за версии ядра CMS, модулей и PHP, а рядом срок обновления. Разумное правило требует обновиться не позже, чем ветка выйдет из поддержки разработчиков. Без этого пункта обновление идёт «по необходимости», и необходимость обычно наступает в день инцидента, когда сайт уже взломан или перестал открываться.

У PHP понятный календарь. По данным php.net, каждая ветка два года получает полную поддержку, затем ещё два года только исправления критических уязвимостей, после чего поддержка заканчивается. Ветка 8.2 получает исправления безопасности до 31 декабря 2026 года.

Для сайтов на Битриксе эта дата важна вдвойне. На странице системных требований «1С-Битрикс: Управление сайтом» минимальной версией PHP названа 8.2. Сайт, который держится на минимуме, после 31 декабря окажется на ветке без исправлений безопасности. WordPress рекомендует PHP 8.3 или новее и про старые версии пишет прямо, что они вышли из поддержки и могут открыть сайт уязвимостям.

Что записать в договор. Версии CMS и PHP на дату подписания, срок перехода на поддерживаемую ветку и порядок обновления. Руководство разработчиков WordPress советует делать копию базы регулярно и всегда перед обновлением, поэтому обновление идёт через копию и тестовую площадку и только потом попадает на рабочий сайт. Как обновить PHP и что делать при свежих уязвимостях, мы разбирали в статье про уязвимость PHP2Shell.

Резервные копии: где лежат и кто проверял восстановление

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

Ориентиры дают открытые руководства. Руководство разработчиков WordPress делит копию на две части, базу и файлы, и для полного восстановления нужны обе. Небольшой сайт там советуют копировать раз в неделю, сайт с большим числом публикаций ежедневно. Хранить предлагают не меньше 3-5 свежих копий в разных местах, например на хостинге, в облаке и на своём компьютере.

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

Как это выглядит в жизни, показывает история на Хабре 2024 года. Хостер удалил сервер пользователя после просрочки оплаты, и автор пишет, что вместе с ним пропали «все бэкапы, лежавшие на холодном хранилище». Это рассказ одной стороны, но урок для договора ясен. Копии должны лежать отдельно от сайта, а за сроками оплаты хостинга и домена кто-то обязан следить по договору.

Американское агентство кибербезопасности CISA в руководстве по защите от программ-вымогателей советует держать офлайн-копии и регулярно проверять их доступность и целостность в сценарии восстановления. Если копии ведёт подрядчик, CISA предлагает убедиться, что он следует этим практикам, и закрепить требования формулировками договора. Это ровно ваш случай.

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

Что считается аварией и сколько ждать реакции

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

Границу критического класса удобно взять у Яндекса. В блоге для вебмастеров компания пишет, что статусы 5XX означают нарушение работоспособности сайта. Там же сказано, что такие статусы робот воспринимает как признак серверных ошибок с нагрузкой, и это может снизить скорость обхода сайта и обновления его контента. В Яндекс Вебмастере для этого есть отдельное оповещение «Некоторые страницы сайта часто отвечают HTTP-кодом 5хх».

Google в справке Search Central описывает похожую механику. Ошибки 5xx заставляют его роботов временно замедлить обход. Уже проиндексированные страницы сначала остаются в индексе, но если ошибка сервера держится, их со временем удаляют. В блоге Яндекса, на который мы опираемся, речь идёт о скорости обхода, а Google прямо пишет и об удалении из индекса. Для договора вывод общий. Долгая ошибка сервера бьёт и по заявкам, и по поиску.

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

Доступы и персональные данные: на кого они оформлены

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

Разработчики на Хабр Q&A, обсуждая передачу интернет-магазина заказчику, сходятся в том же. Один из отвечающих пишет, что это «единственно верная практика, так как все доступы и финансовая ответственность должны быть у заказчика». Это мнение практика, нормой закона оно не является, и всё же возразить ему трудно.

Если через сайт идут заявки, подрядчик поддержки почти всегда видит имена и телефоны клиентов. Закон о персональных данных (152-ФЗ, статья 6) позволяет оператору поручить обработку другому лицу на условиях, которые в нём перечислены. В таком поручении определяют перечень данных, действия с ними, цели обработки и обязанность соблюдать конфиденциальность, а также требования к защите данных. Ответственность с заказчика при этом не снимается. В части 5 той же статьи, в действующей редакции, сказано, что «ответственность перед субъектом персональных данных за действия указанного лица несет оператор».

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

Ответственность в SLA: где искать потолок

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

Как выглядит такой предел, видно в той же истории на Хабре. Автор приводит условие хостера, по которому заказчику «компенсируется документально подтвержденный ущерб, но не более стоимости услуг за 12 месяцев». Это договор хостинга и пересказ одной стороны спора, а договоры поддержки устроены похоже.

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

Ежемесячный отчёт: как принять и когда вернуть

Отчёт за месяц принимают по содержанию, объём тут ничего не доказывает. В нём должны быть версии CMS и PHP до и после, дата последней копии и последнего теста восстановления, доступность за месяц со списком простоев и инциденты против сроков договора. Без этих четырёх пунктов акт оказанных услуг не подписывайте, верните отчёт с вопросами.

Полный список вопросов к отчёту:

1. Версии. CMS, PHP и ключевые модули «было, стало» с датой. Ветка PHP должна быть в поддержке по календарю php.net.
2. Копии. Дата последней, где лежит, дата последнего теста восстановления.
3. Доступность. Процент за месяц, простои с началом и концом, чем измерено.
4. Инциденты. Срок реакции и решения по факту рядом со сроком из договора.
5. Часы. Что сделано, кем, сколько времени, номер заявки, остаток пакета.
6. Сроки. Ближайшие даты продления SSL, домена и хостинга.
7. Пропуски. Что не сделано и почему.
8. Предложения. Что сделать в следующем месяце и сколько это стоит, отдельно от пакета.

Одну проверку сделайте сами. Попросите доступ на чтение в Яндекс Вебмастер и раз в месяц смотрите, нет ли оповещения о частых ошибках 5хх. Мониторинг она не заменит, зато даёт взгляд со стороны поиска, независимый от подрядчика. Похожий подход к приёмке работ по скорости разобран в статье о том, что поручить подрядчику, чтобы сайт стал быстрее.

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

Как сменить подрядчика без торга за доступы

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

В статье 782 Гражданского кодекса сказано, что «заказчик вправе отказаться от исполнения договора возмездного оказания услуг при условии оплаты исполнителю фактически понесенных им расходов». Как это сочетается со сроком уведомления, авансом и другими условиями вашего договора, разберите с юристом.

Опись передачи, которую стоит приложить к договору:

1. Реестр доступов: регистратор домена, хостинг и панель управления, FTP и SSH, база данных, админка CMS, почта, счётчики и Вебмастер.
2. Смена всех паролей по реестру, включая пароль базы в конфигурации сайта. Одного пароля от хостинга мало, старые учётные записи FTP удаляют.
3. Полная копия файлов и базы с проверкой восстановления на площадке нового подрядчика.
4. Документация и список нестандартных доработок, особенно правок в ядре и модулях.
5. Перенос мониторинга и оповещений на новые контакты.
6. Акт передачи с перечнем переданного.
7. Неделя параллельной работы старого и нового подрядчика.

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

Перечень пунктов договора на техподдержку для юриста

Ниже двенадцать пунктов, которые стоит проверить в договоре до подписания или при продлении. Распечатайте перечень и пройдите его вместе с юристом и подрядчиком. Там, где назван тревожный признак, формулировка оставляет вас без способа проверить работу.

На этой неделе хватит трёх действий. Найдите договор и проверьте, на кого оформлены домен и хостинг. Спросите подрядчика о дате последнего восстановления из копии. Запросите в ближайший отчёт версии CMS и PHP. По ответам станет ясно, с какого пункта перечня начинать.