Покупаем чужой проект: что проверить в инфраструктуре до того, как платить

MAATRIX

Вам показывают демо, красивую панель аналитики и договариваются о цене — а всё, что стоит за этим экраном: сервер, версии софта, аккаунты, от которых зависит запуск, реальные счета за инфраструктуру, — остаётся на слово продавца. Юридическая сторона сделки — предмет отдельного разговора с юристом и не тема этой статьи. Но есть техническая часть due diligence, которую можно и нужно сделать своими руками или руками инженера ещё до того, как деньги перешли из рук в руки: заглянуть под капот и понять, что вы реально покупаете — рабочий актив или отложенный на будущее ремонт. Ниже — практический план такой проверки.

Реальное состояние сервера: версии и давность обновлений

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

Если вам дали хотя бы временный SSH-доступ (о том, как его запросить, — ниже), несколько команд быстро покажут реальную картину без домыслов:

# дистрибутив и версия ядра
cat /etc/os-release
uname -r

# сколько пакетов скопилось на обновление
apt list --upgradable 2>/dev/null | wc -l

# дата последнего apt update/upgrade
grep -E "upgrade|install" /var/log/apt/history.log | tail -20

# для systemd — сколько сервисов включено и что реально запущено
systemctl list-unit-files --state=enabled

Если доступа нет и не будет до сделки, спросите прямо: какая версия ОС, СУБД, языкового рантайма (PHP/Node/Python и т.д.), когда последний раз обновлялся стек целиком. Ответ «не помню» или «этим занимался подрядчик, он уже не работает с нами» — сам по себе информация: значит, у текущего владельца нет актуальной картины состояния системы, и вы покупаете чёрный ящик даже с точки зрения продавца.

Отдельно стоит спросить дату EOL (end of life) ключевых компонентов — версии дистрибутива, СУБД, фреймворка. Если версия уже вышла из поддержки или выйдет в ближайшие месяцы, миграция на актуальную версию — это не гипотетическая задача на когда-нибудь, а конкретный проект, который вам придётся делать почти сразу после покупки, с бюджетом времени и денег, о котором стоит знать заранее, а не узнавать постфактум.

Реальная стоимость содержания: не то, что говорит продавец, а то, что в счетах

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

• аренду сервера или нескольких серверов (прод, стейджинг, бэкап-хранилище);
• CDN и защиту от DDoS, если трафик того требует;
• платные SaaS-интеграции — почтовую рассылку, аналитику, платёжный шлюз, мониторинг, систему поддержки;
• домен и SSL-сертификаты, если они не входят в хостинг;
• лицензии на коммерческий софт — панели управления, антивирус, специализированные библиотеки;
• резервное хранилище отдельно от основного сервера, если бэкапы вообще вынесены наружу.

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

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

Зависимость от продавца: на чьих аккаунтах держится инфраструктура

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

• на чей email и чью карту зарегистрирован домен, и у кого сейчас доступ к аккаунту регистратора;
• на чей аккаунт оформлен хостинг или облачный провайдер — это личный кабинет продавца или отдельная организация;
• через чей личный email проходит восстановление доступа ко всем перечисленным сервисам (это часто упускают даже при формальной передаче логина и пароля — код восстановления всё равно уйдёт на старую почту);
• используются ли личные API-ключи продавца в интеграциях (платёжный шлюз, почтовая рассылка, аналитика) — если да, при отзыве этих ключей после сделки часть функциональности может просто перестать работать;
• есть ли двухфакторная аутентификация, привязанная к личному телефону продавца, которую нужно будет перевыпускать.

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

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

Скрытый технический долг: костыли, о которых не расскажут добровольно

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

Вопросы, которые стоит задать конкретно, а не в общей форме «есть ли технический долг»:

• Есть ли в системе места, куда изменения вносятся вручную на сервере, а не через код в репозитории («так исторически сложилось», «этот скрипт правили прямо на проде»)?
• Что происходит, если перезапустить сервер прямо сейчас — все сервисы поднимутся сами по расписанию или часть требует ручного вмешательства после перезагрузки?
• Есть ли зависимости от конкретной версии стороннего API или библиотеки, обновление которой ломает интеграцию (и почему обновление до сих пор не сделано)?
• Есть ли данные или конфигурация, которые существуют только на одном сервере и нигде не задокументированы и не воспроизводимы с нуля?
• Кто, кроме продавца, вообще понимает, как устроена система целиком — если ответ «никто», вы покупаете не только код, но и полную зависимость от одного человека на переходный период.

Стоит попросить показать (не рассказать, а именно показать на экране) деплой — как выкладывается новая версия кода в прод. Ответ «через FTP, вручную» или «заходим по SSH и правим файл» вместо предсказуемого пайплайна — прямой индикатор, что документированной, воспроизводимой инфраструктуры под капотом нет, каким бы отполированным ни выглядел фронтенд. То же касается конфигурации: если она нигде не хранится версионированно, а существует только «в голове у продавца» и в текущем состоянии сервера, вы принимаете на себя риск того, что воссоздать систему с нуля при аварии будет невозможно — только чинить то, что есть, пока оно живо.

Бэкапы на словах и бэкапы на деле

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

Если вам дали доступ для аудита, не верьте факту существования файлов — запросите реальное тестовое восстановление на отдельном сервере или хотя бы контрольную распаковку и проверку целостности архива:

# базовая проверка, что архив вообще целый
gzip -t backup.sql.gz && echo "архив не повреждён"

# для дампа БД — проверка, что внутри валидный SQL, а не пустышка
zcat backup.sql.gz | head -50

# дата и размер последних бэкапов — резкое отклонение размера от нормы тоже сигнал
ls -lh /path/to/backups/ | tail -10

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

Как запросить доступ для аудита, не выглядя параноиком

Главное практическое препятствие на пути технической проверки — не техника, а психология: покупателю неловко просить доступ до того, как деньги переданы, а продавцу может быть неловко его давать, потому что запрос читается как недоверие. На деле всё наоборот: запрос временного ограниченного доступа для технического аудита — стандартная и ожидаемая часть due diligence при покупке любого технологического актива, и отказ в таком доступе — куда более тревожный сигнал, чем сам факт запроса.

Практические принципы, которые снимают неловкость с обеих сторон:

• Просите минимально достаточный доступ, а не полный контроль. Отдельный SSH-пользователь с ограниченными правами для чтения конфигураций и логов, доступ только на чтение к панели хостинга и биллингу, временный аккаунт в системе аналитики — этого обычно достаточно, чтобы провести проверку, не получая возможности что-либо менять в чужой боевой системе до завершения сделки.
• Ограничивайте доступ по времени явно. Согласуйте конкретный срок (несколько дней или неделя аудита) и попросите продавца отозвать доступ сразу после — это снимает у продавца опасение, что доступ «зависнет» и станет проблемой безопасности с его стороны, если сделка вдруг не состоится.
• Фиксируйте находки письменно по ходу проверки, а не только в финальном отчёте себе — если аудит выявит существенные расхождения с тем, что заявлял продавец (устаревший стек, нерабочие бэкапы, зависимость от личных аккаунтов), это становится предметным аргументом в переговорах о цене или условиях, а не смутным ощущением «что-то не так».
• Если продавец отказывает в любом доступе под предлогом безопасности — это не всегда попытка что-то скрыть, иногда действительно есть разумные причины (чувствительные данные пользователей, NDA с третьими лицами). Но в этом случае разумно попросить провести аудит совместно, глядя в один экран через созвон с демонстрацией, а не отказываться от проверки вовсе.

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

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