Инфраструктурный долг в оценке проекта: как посчитать честную скидку

MAATRIX

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

Что такое инфраструктурный долг и почему его нельзя игнорировать

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

Конкретные формы, в которых он проявляется:

• Устаревший софт. ОС и рантайм без поддержки вендора, база на ветке, которую больше не патчат, зависимости с открытыми CVE без апдейта без миграции на мажорную версию.
• Недокументированная инфраструктура. Никто не может ответить, зачем этот cron на сервере и что сломается, если убрать строчку в nginx.conf. Знание живёт в голове одного человека — не метафора, а буквально то, что описывает статья о bus factor, равном единице.
• Архитектурные риски. Единая точка отказа без резерва, база и приложение на одном сервере без деления по нагрузке, ручной деплой без отката, отсутствие мониторинга.
• Заброшенная эксплуатация. Непроверенные на восстановление бэкапы, не отозванные доступы бывших подрядчиков, TLS-сертификаты на автопродлении, за которым никто не следит.

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

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

Аудит перед оценкой: что и как искать

Оценить долг без аудита невозможно — можно только гадать, а гадание в переговорах о цене всегда работает против той стороны, у которой меньше данных. Аудит перед сделкой должен закрыть четыре области.

Софт и версии. Список всего, что установлено на серверах: ОС, веб-сервер, СУБД, рантайм (PHP/Node/Python/Java), ключевые библиотеки. Для каждого пункта — версия и статус поддержки: активная, security-only, end of life. Отдельно — открытые уязвимости в зависимостях (сканер зависимостей или хотя бы npm audit / pip-audit / composer audit дадут первое приближение).

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

Документация и процессы. Есть ли runbook на восстановление после падения, описан ли процесс деплоя, зафиксировано ли, кто имеет доступ и к чему. Проверялись ли бэкапы восстановлением (не «бэкап есть», а «разворачивался и проверялся хотя бы раз»).

Доступы и безопасность. Список всех, у кого есть SSH-доступ, доступ к панели хостинга, к DNS, к платёжным реквизитам домена. Отдельно — бывшие сотрудники и подрядчики, доступы которых не отозваны: ключ подрядчика, забытый в authorized_keys, обычно всплывает через полгода после сделки, а не на аудите.

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

От списка проблем к трудоёмкости: первый слой оценки

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

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

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

Итог первого слоя — таблица: проблема → трудоёмкость в часах → стоимость в деньгах. Это ещё не скидка, это её сырьё.

Срочность: не все проблемы весят одинаково

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

• Критично. Открытая уязвимость с публичным эксплойтом, доступы бывших сотрудников с правами на прод, отсутствие любых бэкапов на боевой базе, истекающий на днях TLS-сертификат — то, что должно быть закрыто в первые дни после сделки.
• Важно, но не горит. Устаревшая мажорная версия рантайма без известных активных эксплойтов, отсутствие резервирования при исторически стабильной нагрузке, недокументированные, но работающие процессы. Разумный горизонт — от одного до нескольких кварталов.
• Желательно. Оптимизация, улучшающая производительность или удобство эксплуатации, но не несущая риска отказа или утечки. Может годами жить в бэклоге без последствий.

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

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

Поправка на неопределённость: разумная предосторожность, а не точная наука

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

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

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

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

Практика для продавца: раскрывать раньше, чем найдут

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

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

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

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

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

Практика для покупателя: долг — не повод отказаться, а фактор цены

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

Практический подход для покупателя — три шага:

1. Отделить закрывающие сделку проблемы от ценообразующих. Есть узкий класс находок, которые действительно должны остановить сделку или глубоко её пересмотреть: юридические риски (нелицензионный софт в проде, нарушение условий хранения персональных данных), полная невозможность восстановить контроль над критичным активом (например, домен зарегистрирован на третье лицо без права передачи). Всё остальное — не повод отказаться, а повод торговаться.
2. Использовать методику из предыдущих разделов, чтобы прийти на переговоры с числом, а не с ощущением. «Мне не нравится, что у вас не обновлялось» — слабая переговорная позиция. «Мы оценили устранение критичных и важных пунктов в X часов работы, из них Y критично и должно быть закрыто в первый месяц» — сильная.
3. Заложить не только скидку, но и план. Купленный со скидкой долг всё равно нужно закрывать — скидка компенсирует будущие расходы, но не отменяет саму работу. Разумно сразу после сделки иметь список пунктов из аудита с приоритетами по срочности как рабочий план. Если предстоит смена ответственного за инфраструктуру, пригодится подход из статьи о передаче сервера подрядчику — чек-лист по доступам и рискам работает и как инструмент аудита, и как инструмент передачи дел.

Отдельно про переговорную динамику: скидка за инфраструктурный долг — не наказание продавца, а справедливое разделение стоимости работ, которые всё равно придётся выполнить. Формулировка «мы вместе смотрим на объём работ и делим его стоимость честно» вместо «вы продаёте неисправную вещь» делает переговоры заметно спокойнее.

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