Как передать сайт новой команде на поддержку?

Перед передачей сайта важно:

• проверить, что доступы принадлежат компании-заказчику, а не отдельному сотруднику или подрядчику;

• собрать карту систем: CMS, сервер, домен, репозиторий, 1С, CRM, оплата, доставка и другие сервисы;

• зафиксировать критичные функции сайта;

• отозвать неактуальные доступы и заменить общие пароли персональными;

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

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

Что означает передача сайта на поддержку

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

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

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

Какие доступы и материалы нужно передать новой команде

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

Как принять сайт на поддержку от другого подрядчика

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

Обычно вход в проект состоит из пяти шагов:

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

2. Составить карту интеграций и определить ответственных за 1С, CRM, хостинг, оплату, доставку и другие связанные системы.

3. Зафиксировать критичные сценарии: заявка, заказ, оплата, авторизация, личный кабинет, обмен данными или публикация контента.

4. Провести первичную диагностику кода, инфраструктуры, обновлений, безопасности и накопленных ошибок.

5. Сформировать очередь: что нужно исправить сразу, что можно планировать, а что требует отдельного аудита или доработки.

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

Какие сценарии проверить до крупных изменений

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

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

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

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

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

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

Практический порядок действий:

1. Проверить, на кого зарегистрирован домен, и обратиться к регистратору от имени компании-владельца.

2. Восстановить доступ к хостингу через договор, корпоративную почту или платёжные документы компании.

3. Обратиться к администратору корпоративной почты, чтобы восстановить учётные записи, привязанные к сервисам.

4. Запросить права к репозиторию у владельца организации или администратора платформы хранения кода.

5. Связаться с владельцами CRM, 1С, платёжных и других сервисов для смены администратора и ключей доступа.

6. После восстановления контроля отключить старые учётные записи и создать персональные доступы для актуальных участников проекта.

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

Как проверить резервные копии и исходный код

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

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

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

Как передавать доступы безопасно

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

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

После передачи полезно проверить:

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

• заменены ли общие пароли;

• есть ли у компании доступ к домену, хостингу и резервным копиям;

• зафиксированы ли владельцы ключей для интеграций;

• понятен ли порядок выдачи временных доступов.

Управление доступами — часть поддержки, а не формальность при смене подрядчика. Без него невозможно безопасно передавать проект между командами и расследовать причину ошибки.

Как понять, что поддержка после передачи организована хорошо

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

Признаки зрелого процесса:

• заказчик знает критичные сценарии и правила эскалации;

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

• обновления и доработки проверяются до публикации на рабочем сайте;

• аварийные ошибки отделены от планового развития;

• после инцидентов и значимых изменений обновляется документация.

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

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

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