Как принять сайт на техническую поддержку: чек-лист веб-студии

3 августа 2026 · 13 мин чтения

Принять сайт на поддержку — не значит получить пароль от административной панели и добавить клиента в рабочий чат.

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

Нормальный приём сайта заканчивается не фразой «доступ получили», а пятью результатами:

1. понятно, за что отвечает студия и что остаётся на стороне клиента;
2. собран паспорт сайта и всех критических зависимостей;
3. проверены доступы, резервные копии и возможность восстановления;
4. зафиксировано исходное техническое состояние;
5. критические функции поставлены под наблюдение.

Ниже — порядок, который можно использовать как внутренний регламент веб-студии.

Коротко: что сделать до начала поддержки

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

Почему нельзя начинать с исправлений

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

До фиксации исходного состояния студия не знает:

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

Первое действие новой команды — не изменение, а создание карты реальности.

Шаг 1. Определите границы ответственности

Обсудите ответственность до технического аудита. Иначе студия проверит то, за что никто не собирался платить, а клиент будет ожидать то, что не входило в услугу.

Минимально нужно ответить на вопросы:

Объект	Кто владеет	Кто оплачивает	Кто изменяет	Кто контролирует срок и состояние
Домен	Клиент / другое лицо	Клиент	Уполномоченный сотрудник	Студия или клиент
DNS	Клиент / хостинг / CDN	Клиент	Студия по согласованию	Студия
Хостинг или сервер	Клиент	Клиент	Студия / администратор	Студия
SSL	Клиент / хостинг	По тарифу	Студия / автообновление	Студия
CMS и модули	Клиент	По договору	Студия	Студия
Платёжная система	Клиент	Клиент	Клиент + студия	Обе стороны
Корпоративная почта	Клиент	Клиент	Назначенный администратор	По договору
Обмен с 1С	Клиент	По договору	Интегратор / студия	Назначенный владелец
Аналитика и реклама	Клиент	Клиент	Маркетолог	Клиент

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

Формулировка «доменом занимается клиент» недостаточна. Нужны имя или роль, канал связи и порядок действий, если этот человек не отвечает.

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

Шаг 2. Создайте паспорт сайта

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

Шаблон паспорта

# Паспорт клиентского сайта

Клиент: [название и юридическое лицо]
Сайт: [основной URL]
Назначение: [магазин / заявки / личный кабинет / корпоративный сайт]
Критичность: [высокая / средняя / низкая]

## Ответственные

- Владелец со стороны клиента: [имя, роль, контакты]
- Операционный контакт: [имя, роль, контакты]
- Ответственный студии: [имя, роль]
- Техническая эскалация: [имя или команда]
- Согласование аварийных изменений: [имя или роль]

## Инфраструктура

- Регистратор домена: [название]
- Владелец домена: [организация / физическое лицо]
- Дата окончания домена: [дата]
- DNS: [провайдер]
- Хостинг / сервер: [провайдер и проект]
- CDN / WAF: [если используется]
- SSL: [способ выпуска и продления]
- Репозиторий: [ссылка]
- Production-ветка: [название]
- Тестовый контур: [URL / отсутствует]

## Приложение

- CMS и версия: [значение]
- Критические модули: [список]
- PHP / runtime: [версия]
- База данных: [тип и версия]
- Фоновые задачи: [где описаны]
- Почтовая доставка: [провайдер / SMTP]
- Интеграции: [1С, CRM, оплата, доставка, телефония]

## Резервное копирование

- Что копируется: [файлы / база / конфигурация]
- Расписание: [значение]
- Где хранится: [отдельное хранилище]
- Срок хранения: [значение]
- Последнее успешное восстановление: [дата / не проверялось]
- Ответственный: [роль]

## Критические бизнес-функции

1. [Функция и критерий успеха]
2. [Функция и критерий успеха]
3. [Функция и критерий успеха]

## Каналы

- Рабочие задачи: [Helpdesk / трекер]
- Критические инциденты: [Telegram / телефон]
- Статус-страница: [URL / не настроена]
- Плановые работы: [канал и срок предупреждения]

Не храните пароли и токены прямо в этой карточке. В паспорте должны быть ссылки или идентификаторы записей в менеджере секретов.

Шаг 3. Примите доступы безопасно

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

• регистратор домена;
• DNS и CDN;
• хостинг или облачный кабинет;
• SSH/SFTP;
• панель управления сервером;
• административную панель CMS;
• базу данных;
• репозиторий и CI/CD;
• резервное хранилище;
• почтовый сервис;
• платёжный кабинет;
• CRM, доставку и обмен с 1С;
• аналитику и tag manager;
• мониторинг и статус-страницу.

Правила приёма доступов

1. Не просите отправлять пароль в общем Telegram-чате.
2. По возможности создавайте отдельную учётную запись студии, а не используйте логин владельца.
3. Выдавайте минимальные права, необходимые для конкретной работы.
4. Включайте двухфакторную аутентификацию там, где она доступна.
5. Фиксируйте владельца каждой учётной записи.
6. Не храните единственную копию секрета у одного сотрудника.
7. После передачи согласуйте отзыв доступов бывшего подрядчика.
8. Для аварийного доступа определите отдельную процедуру и журналирование.

Не нужно получать полный доступ «на всякий случай». Если студия только наблюдает за сайтом, ей не обязательно иметь возможность изменять сервер. Разделение наблюдения и управления уменьшает последствия компрометации одного инструмента. Подробнее этот принцип разобран в материале Pingvera о мониторинге без входящего доступа.

Шаг 4. Зафиксируйте исходное состояние

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

Внешняя проверка

Проверьте:

• открывается ли сайт по основному адресу;
• корректно ли работают перенаправления между HTTP/HTTPS и версиями домена;
• действителен ли SSL и полна ли цепочка сертификата;
• когда заканчивается домен;
• как сайт отвечает из основных регионов аудитории;
• нет ли неожиданных редиректов;
• доступны ли robots.txt и sitemap.xml;
• не закрыты ли важные страницы через noindex;
• работают ли ключевые страницы, а не только главная;
• не возвращает ли красивую заглушку CDN поверх сломанного приложения.

Проверка CMS и приложения

Зафиксируйте:

• версию CMS и критических модулей;
• неподдерживаемые или уязвимые компоненты;
• ошибки встроенной диагностики;
• неизвестных администраторов;
• состояние очередей и фоновых задач;
• способ отправки почты;
• журналы последних ошибок;
• заполнение диска и основные серверные показатели;
• наличие тестового контура;
• способ выпуска изменений.

Не исправляйте всё в процессе фиксации. Сначала сформируйте список:

• критично до начала поддержки;
• нужно исправить в первый месяц;
• плановое улучшение;
• принято как известное ограничение.

Шаг 5. Пройдите бизнес-пути

Код ответа 200 OK не доказывает, что сайт выполняет свою работу.

Для каждого проекта выберите от трёх до семи критических путей.

Тип сайта	Что проверить	Критерий успеха
Корпоративный сайт	Форма заявки	Тестовое сообщение дошло в согласованный ящик или CRM
Интернет-магазин	Корзина и оформление	Заказ создан, сумма и доставка рассчитаны правильно
Интернет-магазин	Оплата	Боевой способ не находится в тестовом режиме; контроль выполняется без раскрытия платёжных данных
Личный кабинет	Авторизация	Тестовый пользователь вошёл и видит разрешённые данные
Сайт с 1С	Обмен	Цены и остатки обновлены в ожидаемый срок
Контентный проект	Публикация	Новая запись появляется по расписанию и доступна читателю
Любой проект	Почта	Служебное письмо действительно доставлено, а не только принято формой

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

Шаг 6. Проверьте резервное копирование

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

Нужно установить:

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

Не проводите первый тест восстановления поверх production. Разверните отдельную изолированную среду и зафиксируйте:

• время восстановления;
• недостающие секреты и зависимости;
• действия, которые пришлось выполнять вручную;
• способ проверки данных и бизнес-функций.

Если бэкап запускается через cron, поставьте под наблюдение не только факт старта, но и успешное завершение. Pingvera описывает такую схему в руководстве по мониторингу фоновых задач.

Шаг 7. Настройте наблюдение до первого инцидента

Минимальный набор зависит от риска проекта.

Для любого коммерческого сайта

• доступность основной страницы;
• доступность критических маршрутов;
• срок SSL;
• срок домена;
• неожиданные редиректы;
• поисковые ограничения ключевых страниц;
• доставка основной формы;
• резервный канал оповещения.

Для магазина

Добавьте:

• страницу оформления заказа;
• поток заказов и несостоявшиеся оплаты;
• боевой или тестовый режим платёжного способа;
• обмен с 1С;
• критические фоновые задачи;
• серверные ресурсы;
• состояние CMS.

Контроль магазина изнутри и его честные ограничения разобраны в статье о тихих поломках checkout.

До включения алерта ответьте

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

Монитор без владельца создаёт шум, а не контроль.

Шаг 8. Согласуйте порядок изменений

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

Зафиксируйте:

1. где готовится изменение;
2. кто его проверяет;
3. кто разрешает публикацию;
4. когда допустимо техническое окно;
5. как выполняется резервная копия;
6. как откатить изменение;
7. какие проверки запускаются после релиза;
8. сколько продолжается усиленное наблюдение.

Для срочного исправления может существовать сокращённый маршрут. Но «аварийный» не должен означать «без записи и без проверки».

Шаг 9. Зафиксируйте известные дефекты

Итоговый список должен различать факт, риск и рекомендацию.

Плохо:

Сайт старый и небезопасный.

Лучше:

CMS работает на неподдерживаемой версии. Автоматическое обновление без тестового контура создаёт риск несовместимости двух пользовательских модулей. Рекомендуем сначала развернуть копию, проверить обновление и согласовать отдельную смету.

Для каждой находки укажите:

• наблюдаемый факт;
• возможное влияние;
• срочность;
• предлагаемое действие;
• кто принимает решение;
• входит ли работа в абонентский договор.

Шаг 10. Подпишите акт исходного состояния

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

Копируемый шаблон

# Исходное состояние сайта при передаче на поддержку

Клиент: [название]
Сайт: [URL]
Дата обследования: [дата и часовой пояс]
Период наблюдения: [если применимо]

## Принято под контроль

- [компонент / функция]
- [компонент / функция]

## Ответственность клиента

- [домен / оплата хостинга / согласование изменений]

## Ответственность студии

- [мониторинг / реакция / работы по договору]

## Проверено

- Доступность: [результат]
- SSL и домен: [результат]
- Форма: [результат / не подключена]
- Заказ и оплата: [результат / не применимо]
- Резервное копирование: [результат]
- Восстановление: [проверено / не проверялось]
- CMS и сервер: [краткий результат]

## Известные дефекты и риски

| Находка | Возможное влияние | Приоритет | Решение |
|---|---|---|---|
| [факт] | [влияние] | [P1/P2/P3] | [действие] |

## Не проверено или не предоставлено

- [доступ / система / функция]

## План первого месяца

1. [действие, владелец, срок]
2. [действие, владелец, срок]

Если система не проверена, пишите «не проверено», а не ставьте зелёную галочку.

План первых 30 дней

Первая неделя

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

Вторая неделя

• настроить процесс релиза;
• составить инструкции для повторяющихся аварий;
• проверить фоновые задачи и интеграции;
• согласовать статус-страницу или шаблоны сообщений.

Третья неделя

• разобрать полученные предупреждения;
• убрать неактуальные алерты;
• определить базовые показатели скорости и ресурсов;
• закрыть доступы бывших участников проекта.

Четвёртая неделя

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

Когда не стоит сразу брать сайт на абонентскую поддержку

Сначала предложите отдельный платный аудит или этап стабилизации, если:

• клиент не может подтвердить владение доменом;
• нет доступа к хостингу и резервным копиям;
• production изменяется несколькими подрядчиками без журнала;
• нет возможности безопасно проверить восстановление;
• сайт уже показывает признаки компрометации;
• клиент требует гарантировать отсутствие любых сбоев;
• ответственность за оплату, данные и инфраструктуру не определена;
• известные критические дефекты предлагается «просто не замечать».

Отказ от мгновенной абонентки в такой ситуации защищает обе стороны.

Как здесь помогает Pingvera

После фиксации критических функций Pingvera можно использовать как независимый слой наблюдения:

• проверять доступность из нескольких точек;
• контролировать SSL и срок домена;
• следить за формами, редиректами и поисковыми ограничениями;
• принимать сигналы от cron-задач;
• получать данные WordPress, 1С-Битрикс и серверных агентов;
• отправлять события в Telegram, email, MAX или вебхук;
• собирать факты в клиентский отчёт и статус-страницу.

Pingvera обнаруживает и фиксирует состояние. Исправления выполняет студия своими доступами и по согласованной процедуре.

Начните с пяти самых важных объектов: основной сайт, заявка или заказ, SSL, домен и главная фоновая задача. Создать бесплатные проверки в Pingvera.

Часто задаваемые вопросы

Сколько времени занимает приём сайта на поддержку?

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

Обязательно ли менять все пароли?

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

Должна ли студия оплачивать домен и хостинг клиента?

Только если это прямо входит в договор. Но даже когда платит клиент, студии полезно контролировать срок и заранее напоминать ответственному. Наблюдение за риском и финансовая ответственность — разные вещи.

Что делать, если резервная копия есть, но её никогда не восстанавливали?

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

Можно ли сначала начать поддержку, а аудит провести позже?

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

Главное

Приём сайта на поддержку — это передача не паролей, а управляемой ответственности.

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

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

Источники и дополнительное чтение

• Pingvera: мониторинг, который не заходит на сервер клиента
• Pingvera: крон молчит — мониторинг фоновых задач
• Pingvera: магазин работает, а заказов нет
• Atlassian Incident Management Handbook

Следующий материал: «Регламент мониторинга сайтов клиентов для веб-студии».

Читайте также: Что входит в техническую поддержку сайта: чек-лист абонентки · Передача сайта другой студии: полный чек-лист · Поддержка 10, 50 и 100 сайтов: система студии · Мониторинг как код для веб-студии: руководство · Бесплатно проверить сайт.