Система без документации: что делать, если разработчик ушёл

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

Что собрать за первую неделю

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

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

Доступы: что должно оказаться у вас

Начинаю с вопроса «кто владелец записи». Домен, аккаунт платформы, токен бота, облачный кабинет: каждая запись должна быть оформлена на вас или вашу компанию. Если на разработчика, это первая задача, раньше любых доработок. История с доменом, записанным на частное лицо, разобрана в моём кейсе про возврат домена у бывшего разработчика, а общий порядок есть в статье как вернуть домен компании. Если разработчик ещё отвечает, просите передачу прав, пока он на связи. Что именно требовать, я перечислил в статье про доступы, репозиторий и документацию, а базовые понятия про домен и хостинг лежат в материале хостинг и домен простыми словами.

Пароли складывайте в менеджер паролей, а не в письмо и мессенджер. Один из вариантов на своём сервере описан в статье про Passbolt.

Что запущено и что запускается само

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

Расписания ищу в двух местах. На сервере с Linux это планировщик cron: по описанию crontab задания лежат в каталоге пользовательских таблиц, в файле /etc/crontab и в каталоге /etc/cron.d. Для Telegram-бота полезно спросить у самого Telegram: метод getWebhookInfo возвращает адрес, на который бот отправляет обновления, число необработанных сообщений и текст последней ошибки доставки. Он показывает, живёт ли бот там, где вы думаете. Загляните и в раздел «задания» или «планировщик» панели хостинга.

Ключи, интеграции и платные подписки

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

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

Где лежат данные и копии

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

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

Карта системы на одной странице

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

Сверка карты с живой системой часто находит старое рядом с новым. В кейсе про склад хранения вики, финансовый учёт и корпоративный портал не заводились на PHP 8.3, и рядом пришлось поставить PHP 7.4. Ветка 7.4 по данным php.net закрыта с 28 ноября 2022 года, то есть исправления безопасности для неё не выходят. На карте такие места помечаются как долг: работает сегодня, чинить придётся отдельным проектом. Но до разбора версию не поднимают.

Что трогать нельзя до разбора

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

Последний пункт у меня из практики: на общем сервере склада панель хостинга перезаписала мой конфиг файлом с тем же именем.

Что можно делать с чужой системой

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

Чего я не делаю

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

Как я это делаю

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

Этот разбор можно заказать отдельно: технический аудит и IT-разбор входит в мои услуги.

Когда звать специалиста

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

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

Сколько это стоит

Цены у меня такие. Технический аудит от 50 000 ₽, срок от 1 недели: паспорт, карта, список рисков и план первых действий. Поддержка после разбора (исправления, обновления, мониторинг) от 20 000 ₽/мес. Доработки и починки по часам от 3 000 ₽/час. Окончательную цену называю после короткого знакомства с системой, потому что от количества кабинетов и серверов объём меняется сильно. Общий прайс есть на странице цен.

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

Можно ли разобраться самому, без программиста?

Паспорт доступов, список подписок и карту владельцев вы соберёте сами: это не требует кода. Программист нужен для сверки с живой системой, проверки копий и оценки рисков.

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

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

Сколько времени занимает разбор?

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

Нужно ли сразу переписывать систему?

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

Коротко о главном

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

Если у вас осталась система без разработчика и документов, напишите мне в Telegram кодовое слово «РАЗБОР», и я расскажу, с какого шага начать именно в вашем случае.