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

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

Назначьте владельца передачи

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

На время передачи полезно зафиксировать:

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

Соберите карту цифровых активов

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

Минимальная карта включает:

• регистратора домена и контакт владельца;
• DNS-зону и текущие записи;
• хостинг или VPS/VDS;
• репозиторий исходного кода;
• базу данных и файловые хранилища;
• административную панель сайта;
• сервис отправки почты;
• аналитику и панели вебмастеров;
• CDN, защиту и резервные копии;
• CRM, платежи, доставку и другие API.

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

Верните ключевые аккаунты под контроль компании

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

Проверьте:

1. 1Корпоративная ли почта указана владельцем аккаунта.
2. 2Доступен ли способ восстановления без участия прежнего подрядчика.
3. 3Включена ли двухфакторная защита.
4. 4Есть ли резервный администратор со стороны компании.
5. 5Можно ли отозвать доступ конкретного пользователя, не меняя пароль всем.

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

Зафиксируйте рабочую версию проекта

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

Нужно сохранить:

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

Проверка восстановления важнее факта создания архива. Подробный подход описан в материале о резервных копиях сайта и сервера.

Передайте историю и незавершенные задачи

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

Передаются:

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

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

Введите короткий период стабилизации

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

Безопасная последовательность:

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

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

Что должно остаться после передачи

Итогом становится не папка с паролями, а рабочий контур управления:

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

Частые вопросы

Можно ли принять сайт без связи с прежним подрядчиком?

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

Нужно ли останавливать сайт на время передачи?

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

Когда отключать доступ старой команды?

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

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

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