Как передать сайт другому разработчику: доступы к сайту, код, акт

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

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

План перехода к новому разработчику: 6 этапов

Ориентир: сама передача — от уведомления старого подрядчика до аудита — занимает от 2 до 6 недель в зависимости от сложности проекта, ещё до месяца уходит на стабилизацию. Самая частая ошибка — сжать всё в один звонок «скиньте пароли». Рабочая последовательность выглядит так:

Как уведомить старого подрядчика и договориться о передаче

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

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

Последний пункт важен. Передача проекта — работа: выгрузить код, описать окружение, ответить на вопросы нового разработчика. Если в договоре она не предусмотрена, заложите ориентировочно 5–15 часов по ставке подрядчика. Это снимает конфликт интересов: человек, которому платят за передачу, передаёт добросовестно.

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

Инвентаризация: полный список доступов к сайту

В реестр входят: домен и DNS, хостинг или сервер с SSH, панель управления сервером, база данных, админка CMS, репозиторий, CI/CD, корпоративная почта, Метрика и Вебмастер, рекламные кабинеты, CRM и обмен с 1С, эквайринг, сторонние API, лицензии и SSL-сертификат. Для каждой позиции фиксируйте, на кого сервис оформлен сейчас и на кого должен быть оформлен после передачи.

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

Отдельно пройдитесь по «невидимым» зависимостям: крон-задачи на сервере, внешние скрипты виджетов, сторонние CDN, сервисы уведомлений. Именно они чаще всего ломаются через месяц после смены подрядчика, когда истекает оплаченный кем-то тариф или удаляется чужой аккаунт.

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

Пароли в чате мессенджера, почте или файле «доступы.docx» живут годами и доступны каждому, кто получит переписку. Нормальная практика выглядит так:

1. Менеджер паролей. Заведите корпоративное хранилище — Passwork, KeePassXC с общей базой или развёрнутый у себя Vaultwarden. Старый подрядчик вносит доступы туда, новый получает их оттуда. Хранилище принадлежит вам, не исполнителю.
2. Персональные учётные записи. Вместо передачи чужого пароля создавайте новому разработчику свою учётку в админке, панели и репозитории, а на сервере — вход по его SSH-ключу. Так по журналам всегда видно, кто что делал.
3. Двухфакторная аутентификация. Включите её на регистраторе, хостинге, Яндекс ID, репозитории и в платёжных кабинетах. Резервные коды храните в том же менеджере паролей, а привязанный номер телефона — сотрудника компании, а не подрядчика.
4. Минимальные права. Верстальщику не нужен доступ к эквайрингу, а маркетологу — root. Доступ выдаётся под задачу.

Отзыв доступов старого подрядчика

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

• смените пароли от всех кабинетов из реестра, включая root и пользователя базы данных;
• удалите чужие SSH-ключи из authorized_keys и deploy-ключи в репозитории;
• перевыпустите секреты из .env: ключи API, токены интеграций, соль и ключи шифрования CMS, где это безопасно для работы сайта;
• удалите или заблокируйте учётки подрядчика в админке, CRM, Метрике, Вебмастере и рекламных кабинетах;
• проверьте, не осталось ли FTP-пользователей, почтовых пересылок и вебхуков на чужие адреса.

Смена ключей эквайринга и интеграций с 1С требует аккуратности: новый ключ нужно сразу прописать в конфигурации сайта, иначе платежи или обмен остановятся. В ЮKassa после перевыпуска секретного ключа старый работает ещё 48 часов, а подтверждение приходит по SMS на телефон, привязанный к кабинету. В Т-Банке после смены пароля терминала интеграции нужно переподключить сразу. Делайте это в спокойное время и с проверкой тестовым заказом.

Документация и знания: что попросить описать

Код без контекста — половина проекта. Попросите старого подрядчика подготовить краткое, но конкретное описание:

• архитектура: CMS и версия, фреймворки, версии PHP или Node.js, база данных, кеширование;
• как развернуть проект локально и как выкатывать изменения на прод;
• где лежат бэкапы, как часто делаются, как из них восстановиться;
• кастомные доработки и изменения ядра CMS — особенно правки, которые затрутся при обновлении;
• интеграции: что с чем обменивается, по какому расписанию, что делать при сбое;
• известные проблемы, «костыли» и незавершённые задачи;
• список регулярных работ: продление домена и лицензий, обновления, ручные операции.

Хорошая форма — созвон на 1–2 часа между старым и новым разработчиком с записью. За это время снимается больше вопросов, чем за неделю переписки.

Акт приёма-передачи сайта: что в нём указать

Акт фиксирует, что и в каком состоянии вы получили, и закрывает отношения со старым подрядчиком. Юридическую сторону прав на код мы разбирали в соседней статье, здесь — практический состав документа:

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

Первые 30 дней после передачи: аудит и мониторинг

Месяц после смены подрядчика — период повышенного риска: новый человек ещё не знает проект, а все «сюрпризы» вылезают при первых доработках.

Неделя 1: развернуть и снять копии

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

Недели 2–3: технический аудит

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

Неделя 4: стабилизация

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

Типичные ошибки при смене разработчика

• Отключить старого подрядчика до проверки. Через неделю выясняется, что нет доступа к DNS или актуального кода, а связь уже испорчена.
• Передать доступы, но не переоформить. Новый разработчик работает в кабинете хостинга, который по-прежнему оформлен на прежнего исполнителя.
• Забыть о «мелких» сервисах. Ключ карт, SMS-шлюз или капча на чужом аккаунте отключаются без предупреждения.
• Принять код из архива, а не с сервера. В репозитории может лежать версия полугодовой давности.
• Не сменить пароли после передачи. Формально проект ушёл, фактически у прежнего исполнителя остался полный доступ.
• Сразу ставить новые задачи. Без аудита новый разработчик правит незнакомый код вслепую, и первые доработки ломают соседний функционал.

Чек-лист передачи сайта другому разработчику

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

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