Как сменить подрядчика по сайту и сохранить контроль над проектом

1. Отделите передачу проекта от изменения сайта

Первый результат смены подрядчика — управляемая рабочая версия, а не немедленное обновление всего проекта. Не стоит в одно окно переносить сервер, менять CMS и отзывать все старые ключи: при сбое будет трудно понять причину. Зафиксируйте текущую версию и ограничения, получите доступы, проверьте резервное восстановление, затем планируйте развитие.

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

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

2. Заполните реестр сервисов и ответственных

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

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

Документация: OWASP: хранение, ротация и отзыв секретов;

3. Проверьте доступы действием, а не скриншотом

Проверку выполняет назначенный сотрудник компании со своей учётной записью. Начинают с безопасных действий: просмотр настроек, получение репозитория, открытие резервной копии, вход в тестовую CMS. Изменение DNS или боевых реквизитов оплаты не подходит для демонстрации наличия прав.

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

Документация: GitHub Docs: передача репозитория другому владельцу; Google Search Console: владельцы, пользователи и разрешения;

4. Примите рабочую версию и эксплуатационные инструкции

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

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

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

• Версия: учебный релиз release-2026-09, дата выгрузки и контрольная сумма архива записаны в протоколе.
• Запуск: тестовая копия открывается, администратор меняет и возвращает тестовый текст.
• Данные: сверены 32 страницы и 120 позиций каталога; вложения открываются у 8 выбранных товаров.
• Обращения: HAND-022 проходит от формы до CRM; менеджер подтверждает получение.
• Восстановление: копия базы и файлов поднята отдельно; время и найденные ограничения записаны.
• Ограничения: обмен запускается только служебным аккаунтом; его замена входит в план смены секретов.

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

5. Передайте незавершённые работы с доказательствами

Переписка «это почти готово» не помогает новому исполнителю. Каждую задачу переводят в понятное состояние: что было согласовано, где лежит результат, что проверено и что осталось. Не объединяйте подтверждённую ошибку и пожелание по развитию — они требуют разных решений и могут иметь разные условия оплаты.

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

6. Завершите смену доступов и подтвердите передачу

Составьте список секретов и подключений, которые известны прежнему исполнителю: служебные пароли, ключи API, SSH-ключи, токены развёртывания и восстановления. Для каждого сначала подготовьте замену и проверку зависимости, затем выполните согласованное переключение и отзыв старого значения. Простая смена пароля CMS не отключает все остальные способы входа.

Пример: выпускается новый ключ передачи заявок с необходимыми правами, он устанавливается в защищённых настройках сайта, тест HAND-023 доходит в CRM. После проверки отзывается прежний ключ и повторяется тест HAND-024. Если сервис не допускает двух действующих ключей, согласуют короткое окно и надёжное сохранение обращений на время переключения.

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

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

Документация: OWASP: хранение, ротация и отзыв секретов;