Модернизацию enterprise-системы редко срывает нехватка денег. Срывает неизвестность: команда не знает, что именно унаследовала, сколько это стоит в эксплуатации и где рванёт при первой же доработке. Технический долг копится годами – в обходных решениях, незадокументированных интеграциях, устаревших библиотеках, ручных операциях вместо автоматики. Прежде чем планировать бюджет на модернизацию, проведите аудит. Без него любая оценка сроков и стоимости – гадание.

Что считать техническим долгом

Долг – это не только «плохой код». В enterprise-контуре он распадается на четыре слоя, и каждый надо мерить отдельно.

Кодовая база. Покрытие тестами, цикломатическая сложность, дублирование, доля устаревших зависимостей. Соберите цифры статическими анализаторами (SonarQube и аналоги), а не на глаз.

Архитектура. Жёсткие связи между модулями, точки отказа без резервирования, синхронные вызовы там, где нужна развязка. Если две системы общаются через прямые SQL-запросы в чужую базу – это долг, который заблокирует любое масштабирование. Развязка через очереди и события снимает часть таких связей; мы разбирали подход в материале про событийную архитектуру на Kafka.

Данные. Дубли справочников, рассинхронизация между системами, отсутствие единого источника истины. Это самый дорогой долг: он мешает не разработке, а бизнес-процессам.

Эксплуатация. Ручные регламенты, отсутствие мониторинга, развёртывание без CI/CD. Здесь долг измеряется человеко-часами поддержки в месяц и это деньги, которые видно сразу.

Как проводить аудит

Аудит – это инвентаризация плюс оценка рисков, а не разовый прогон линтера. Порядок действий:

  1. Картируйте систему. Составьте реестр компонентов, интеграций и потоков данных. В унаследованных контурах половина связей не задокументирована – их находят только трассировкой реального трафика и анализом логов.

  2. Соберите метрики. Для каждого компонента зафиксируйте состояние кода, частоту инцидентов, время простоя, стоимость поддержки. Привяжите технические показатели к деньгам – иначе разговор с владельцем бюджета не состоится.

  3. Опросите команду. Разработчики и эксплуатация знают, где «нельзя трогать». Эти зоны страха – точная карта самого опасного долга.

  4. Оцените регуляторные риски. Для госсектора и работы с ПДн проверьте соответствие 152-ФЗ, требованиям импортозамещения и наличие сертифицированных компонентов. Несоответствие – это долг с прямым штрафным эквивалентом, и в 2022 году давление по импортозамещению только растёт.

Приоритизация и связь с бюджетом

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

Результаты аудита ложатся прямо в финансовое планирование. О том, как связать архитектурные решения с распределением ИТ-бюджета, мы писали в разборе бюджета и архитектуры, а общий технологический контекст года – в обзоре трендов 2022.

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

Вывод

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