Due diligence по серверам: десять вопросов продавцу, которые сбивают цену

MAATRIX

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

Деньги без оценок и скрытые персональные зависимости

Вопрос 1. Сколько инфраструктура стоила в содержании за последние несколько месяцев — по реальным счетам, а не «на глаз»?

Просите не оценку, а сумму, которую можно свести со скриншотами биллинга хостинга, CDN, мониторинга, платных API и лицензий. «Где-то в районе...» — это не цифра, это отговорка, даже если человек не хочет специально ничего скрыть, а просто никогда не считал. Расхождение между озвученной суммой и реальными счетами на 20-30% — обычное дело для проектов, где расходами занимался не тот, кто их платил. Расхождение в разы уже говорит либо о забытых платных сервисах, которые вы унаследуете вместе с проектом, либо о том, что часть инфраструктуры вообще не входит в озвученную картину. Честный ответ — это ссылка на биллинг или экспорт счетов; уклончивый — округлённая цифра без источника.

Вопрос 2. Есть ли зависимости от личных аккаунтов продавца, которые нельзя передать напрямую?

Это один из самых частых источников проблем после закрытия сделки. Домен зарегистрирован на личную почту, SSL-сертификат выпущен через личный аккаунт у провайдера, API-ключи платёжной системы привязаны к физическому лицу, лицензия на платный плагин куплена с личной карты, доступ к DNS живёт в аккаунте, который продавец не готов передать «просто так» из-за других своих проектов внутри того же аккаунта. Каждая такая зависимость — это либо процедура переоформления (с простоем и риском), либо согласие продавца оставаться формальным владельцем ресурса неопределённо долго, что само по себе риск для вас. Хороший ответ — список из двух-трёх пунктов с готовым планом переноса. Плохой — «да там вроде всё на компанию, я не помню точно».

Безопасность: даты обновлений и история инцидентов

Вопрос 3. Когда в последний раз реально обновлялась система безопасности — не общими словами, а по логам или истории пакетов?

«Мы регулярно обновляем сервер» звучит убедительно ровно до тех пор, пока не попросишь показать apt list --upgradable или дату последнего патча ядра. Разница между «обновляем регулярно» и фактической датой в логах пакетного менеджера может составлять год и больше — это не редкость, а частая история для проектов, которые «просто работают» и поэтому их не трогают. Если ответ приходит с конкретной датой и историей — это плюс. Если продавец не может назвать даже примерный месяц последнего апдейта, вы получаете сервер с неизвестным окном уязвимости, и это стоит учитывать в цене, а не просто принимать к сведению.

Вопрос 4. Была ли когда-либо утечка данных или серьёзный инцидент безопасности — и как его обработали?

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

Бэкапы и технический долг: не обещание, а демонстрация

Вопрос 5. Реально ли работают бэкапы — готовы ли вы прямо сейчас продемонстрировать восстановление из них?

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

Вопрос 6. Есть ли известные баги или технический долг, о которых стоит знать заранее?

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

Кто на самом деле понимает систему целиком

Вопрос 7. Какая часть кода и инфраструктуры покрыта документацией — реально, не в теории?

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

Вопрос 8. Сколько людей реально понимают, как устроена система целиком?

Это прямой вопрос про bus factor — метрику, которая для инфраструктуры значит не меньше, чем для кода. Если ответ «только я» или «я и ещё один фрилансер, с которым мы не общались полгода», вы покупаете не просто сервера, а зависимость от готовности одного конкретного человека объяснить вам систему после закрытия сделки. У нас есть отдельный разбор того, как выглядит bus factor, равный единице, и что с ним делать — тот же принцип применим и к продавцу: если знание живёт в одной голове, у вас должен быть план, как забрать это знание в структурированном виде до того, как продавец станет недоступен.

Обязательства перед третьими сторонами и переходный период

Вопрос 9. Есть ли договорные обязательства перед третьими сторонами, которые переходят вместе с проектом?

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

Вопрос 10. Готовы ли вы оставаться на связи короткий период после сделки для передачи знаний — и на каких условиях?

Это вопрос не столько про технику, сколько про то, насколько продавец уверен в передаваемости своей системы. Готовность зафиксировать конкретный срок — неделю, две, месяц — с конкретным форматом (созвоны, переписка, доступность по конкретным дням) сильно отличается от расплывчатого «ну если что, пишите, отвечу как получится». Второе на практике означает, что через две недели после сделки продавец будет отвечать на вопросы через день, а через месяц перестанет отвечать вовсе, и вы останетесь с системой один на один без её создателя. Прописывайте условия переходного периода в договоре, а не полагайтесь на устное «конечно, помогу», каким бы искренним оно ни казалось в моменте.

Как читать не отдельный ответ, а всю картину целиком

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

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

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