В статье
Если разработчик ушёл, сначала сохраните управление приложением: проверьте владельцев учётных записей, доступ к коду, рабочим данным и резервным копиям. Затем подтвердите, что другой специалист способен запустить продукт и восстановить его в отдельном окружении. Переписывать приложение до этой проверки обычно рано.
Важно разделить ситуацию «никто не берёт новые задачи» и ситуацию «продукт уже недоступен или данные под угрозой». Во втором случае сначала нужна управляемая помощь по инциденту. В первом можно спокойно собрать сведения и определить объём принятия на сопровождение. Отсутствие документации неприятно, но ещё не доказывает необходимость новой разработки.
Что сделать до любых крупных изменений
Назначьте ответственного со стороны компании и составьте перечень известных проблем. Зафиксируйте, какие операции сейчас работают и что нельзя прерывать: приём заказов, обмен с учётной системой, отправку документов или расчёты.
Попросите нового специалиста сначала описать риски и порядок обследования. Массовая смена настроек или обновление всех зависимостей без понимания связей может остановить работающую часть продукта. Изменения должны иметь понятную цель, возможность проверки и план возврата.
Если прежний разработчик доступен, организуйте ограниченную передачу знаний по списку вопросов. Полезнее попросить показать запуск и объяснить зависимость, чем получить большой архив без пояснений. Рабочие секреты не должны становиться частью общего документа передачи.
Проверьте, чем управляет компания
Начните с реестра: репозиторий кода, домены, серверы, базы данных, файловое хранилище, сервис отправки сообщений, интеграции, платёжные и другие внешние кабинеты. Для каждого пункта нужны владелец, администраторы, назначение и порядок восстановления доступа.
Проверьте также оплату и контакт для важных уведомлений. Приложение может работать, пока не закончится оплаченный период в личном кабинете ушедшего сотрудника. Это организационная зависимость, которую нельзя исправить одной копией исходного кода.
Доступ к репозиторию не равен юридическому праву использовать любой находящийся там компонент. Условия передачи, лицензии и отношения с исполнителем проверяются по документам. Если управляемого доступа нет, восстановление выполняется через уполномоченного владельца и процедуры поставщика, а не через обход ограничений.
Передавайте доступы, а не общий пароль
Новому специалисту выдают персональные приглашения с необходимыми правами. Для критичных аккаунтов определяют владельца со стороны компании, резервный способ восстановления и многофакторную защиту, где она поддерживается. Общая учётная запись затрудняет контроль и последующий отзыв доступа.
GitHub рекомендует организациям назначать нескольких владельцев. Применительно к бизнесу важен принцип непрерывности управления, а конкретные роли зависят от используемой платформы.
Секретные ключи передаются через согласованный защищённый механизм с ограниченным доступом. Их нельзя публиковать в задачах, пересылать в общем чате или помещать в репозиторий. Порядок замены и отзыва нужно согласовать так, чтобы не оборвать действующие интеграции. OWASP описывает управление жизненным циклом секретов, включая доступ, замену и отзыв.
Сопоставьте код с работающим продуктом
Попросите установить, какая версия кода запущена и как из неё собирается приложение. Наличие папки с исходниками не подтверждает, что это актуальный продукт. Изменения могли остаться на отдельном сервере или в личной копии разработчика.
Следующий результат обследования — воспроизводимый запуск в отдельном окружении с безопасными тестовыми данными. Не нужно проверять неизвестный процесс развёртывания непосредственно на рабочей системе. Сначала уточняются зависимости, параметры окружения и последовательность запуска.
Если инструкции нет, новый специалист восстанавливает её по конфигурации, коду и наблюдениям. Это отдельная работа с проверяемым результатом. Требуйте не обещание «теперь всё понятно», а документированный порядок, который можно повторить.
Резервная копия должна восстанавливаться
Разделите код, базу данных, пользовательские файлы и настройки. Копия репозитория не заменяет копию рабочих данных. Уточните, что включено в существующие архивы, когда они создавались, где хранятся и кто вправе ими управлять.
В документации GitHub о резервировании репозитория прямо различаются варианты копирования и состав сохраняемой информации. Для приложения к этому добавляются собственные данные и инфраструктурные зависимости.
Проверка восстановления проводится отдельно от рабочей системы. Её цель — подтвердить пригодность копии и понять, сколько данных может быть потеряно и сколько времени требуется на возврат. Эти значения нельзя обещать до проверки только на основании расписания резервирования.
Условный пример приёма приложения
Представим личный кабинет, в котором заказчики видят документы. Репозиторий принадлежит компании, но файлы находятся в хранилище, оплата которого связана с бывшим исполнителем. Новый разработчик сначала фиксирует эту зависимость и порядок законной передачи управления.
Затем он запускает тестовую копию кабинета, проверяет доступ пользователей к документам и восстановление файлов. После этого можно планировать смену учётных записей и обновления. Немедленный перенос на другой сервер без проверки хранилища создал бы риск потери доступа к документам.
Это условная ситуация, а не история клиента. Её смысл — принять продукт как цепочку зависимостей, а не как архив кода.
Что включить в план стабилизации
- Критичные риски доступа, данных и непрерывности работы.
- Подтверждённый запуск и восстановление тестовой копии.
- Мониторинг важных операций и ответственных за уведомления.
- Исправления, которые блокируют нормальную эксплуатацию.
- Документацию, порядок обновлений и список технического долга.
Разделите срочное и плановое. Если приложение недоступно, есть признаки постороннего доступа или не выполняется критичный обмен, нужна оперативная техническая оценка и согласованный порядок действий. Если проблема только в накопившихся пожеланиях, аварийный режим не поможет расставить приоритеты.
После стабилизации определите условия регулярного сопровождения. Перечень того, что передаётся при завершении разработки, можно дополнительно сверить со статьёй о выборе разработчика и приёмке.
Новый подрядчик не должен обещать полную надёжность до изучения продукта. Для собственника первый результат — восстановленное управление, подтверждённые возможности запуска и список рисков. Если нужно обсудить передачу продукта, используйте обращение Передать продукт на сопровождение. Начните с перечня систем, известных проблем и доступных документов, без пересылки паролей в описании обращения.