Когда технический долг и legacy-системы тянут CIO вниз

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

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

По данным Gartner, к 2027 году компании, которые не смогут правильно оценить и выбрать инструменты миграции и модернизации legacy-систем, будут тратить на 50% больше, чем конкуренты, сделавшие правильный выбор. А в средних и крупных компаниях до 20% годового IT-бюджета может уходить на управление техническим долгом и его снижение.

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

Не «долг», а «сложный процент»

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

Один технический руководитель описал это прямо: «Каждое новое изменение становится сложнее внедрить, количество дефектов растёт в разы, продуктивность команды падает». Эта эрозия постепенна и незаметна, но ровно до того момента, когда что-то внезапно не сломается. Например, возникнет критичный сбой, который приведет к срыву сроков крупного проекта.

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

Здесь ключевым моментом является то, что технический долг автоматически не равен «старой системе». Стабильно работающая legacy-система, которая продолжает получать поддержку, может быть экономически абсолютно оправдана (работает – не трогай). А микросервис, запущенный два года назад, но с размытыми границами и отсутствием тестов, накапливает серьёзный технический долг. То есть, критерием здесь выступает не столько возраст, а то, насколько дороже, медленнее и рискованнее становятся будущие изменения.

Как заставить совет директоров услышать «технический долг»

Главное препятствие для CIO в борьбе с техническим долгом это необходимость объяснить бизнес-руководству почему нужно тратить драгоценный бюджет на «невидимые вещи». Для этого нужно уметь доходчиво объяснить топам в чем суть проблемы и что с ней нужно сделать.

Исследование Forrester показывает: технический долг долго игнорируется потому, что бизнес-руководители не понимают его влияния, а технические руководители не умеют эффективно его донести. Первый шагом к разрыву этого круга являются два правильных вопроса. Как технический долг и технологическое устаревание влияют на общий рост и выручку бизнеса? Как приоритизировать эту проблему в наших решениях об IT-инвестициях?

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

Ключевые метрики квантификации

Таким образом, мы приходим к тому, что квантификация технического долга должна одновременно отражать «техническое состояние» и «бизнес-цену».

Здесь, при рассмотрении технической стороны вопроса будут важны несколько показателей. Цикломатическая сложность измеряет сложность логики кода, и тревожным сигналом тут является рост сложности в ключевых модулях. Покрытие кода тестами показывает долю автоматизированных тестов, и опасно, когда оно ниже 80% или едва достигает нормы. Доля дублированного кода отражает объём кода, скопированного вместо абстрагирования, и её рост — плохой знак. Время сборки и деплоя характеризует скорость доставки изменений, и оно должно падать, а не расти. Частота инцидентов говорит о надёжности систем, и регулярные сбои в legacy это явный симптом.

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

Формула «процента по долгу»

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

Например, если команда тратит 40% времени на «тушение пожаров» и обходные пути вместо создания ценности, то это и будет вашим «процентом по долгу». И задача CIO как раз показать, что снижение этого процента на 10 пунктов высвобождает эквивалент N инженеров без найма.

Стратегии модернизации: три пути и их выбор

Не существует единственно правильной стратегии модернизации legacy систем. Выбор зависит от бизнес-контекста, критичности системы, бюджета и терпимости к риску.

Постепенная модернизация (Strangler Fig)

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

У этого пути есть явные плюсы, например, риск распределён во времени, бизнес не останавливается, а быстрые победы возможны уже на ранних этапах. Но как водится, здесь есть и минусы. Так, этот подход требует дисциплины и архитектурного видения, период сосуществования может затянуться, а также нужна инфраструктура для маршрутизации и интеграции.

Выбирать этот путь стоит тогда, когда система критична, но не настолько, чтобы её нельзя было трогать, а также, есть время и ресурсы на постепенную работу.

Параллельная модернизация (Parallel Run)

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

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

Этот подход оправдан для критичных систем — банковских и финансовых, связанных с безопасностью, где цена ошибки высока.

Радикальная замена (Big Bang / Rip and Replace)

При радикальной замене старая система выключается, новая включается. Это классический большой взрыв (big bang) с сопутствующими последствиями.

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

Выбирать этот путь стоит тогда, когда система настолько устарела, что поддерживать её дороже, чем заменить, бизнес готов к риску, а решение проверено.

Сравнение подходов

Если сравнивать три стратегии по ключевым критериям, картина выглядит следующим образом. По уровню риска постепенная модернизация даёт низкий риск, параллельная — средний, а радикальная, соответственно высокий. По срокам первая является самой долгой, параллельная — средняя, а радикальная наиболее короткая. Стоимость постепенной распределена во времени, параллельная имеет высокий пик, радикальная требует большой единовременной суммы. Нагрузка на команду у постепенной умеренная, параллельной высокая, а у радикальной очень высокая.

И по обратимости постепенная и параллельная дают высокую обратимость, радикальная — низкую. Влияние на бизнес у постепенной минимально, в то время, к у параллельной оно среднее и высокое у радикальной.

Как убедить бизнес инвестировать в «невидимую» работу

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

Например, вместо «Нужно переписать модуль расчётов», скажите «Сейчас любое изменение в расчётах занимает 6 недель и требует ручного тестирования. После модернизации оно займет 3 дня и все проверки будут выполняться автоматически. Это позволит выпускать новые тарифы в 4 раза быстрее».

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

Сам разговор не должен походить на просьбу «дать бюджет на техдолг». Предложите пакет: «Мы выделяем X% ёмкости на модернизацию в обмен на Y% ускорения доставки через Z месяцев». Это превращает технический долг из «центра затрат» в инвестицию с измеримой отдачей.

Также, многие успешные CIO вводят правило: 20% ёмкости команды постоянно направлено на снижение технического долга. Это не проект с концом, а постоянная практика, как гигиена. Бизнес легче принимает это, когда видит, что речь идет не об «остановке ради ремонта», а о «поддержании формы».

Баланс между инновациями и поддержанием работоспособности

Концепция «двух скоростей» (быстрые инновации плюс медленная надёжность) популярна, но опасна, так как создаёт «второй сорт» в команде и часто приводит к тому, что legacy-команда выгорает, а инновационная теряет связь с реальностью.

Лучший подход в такой ситуации это единая команда с явным разделением ёмкости: 60–70% на развитие бизнеса, 20–30% на снижение техдолга и модернизацию, 10% на инновации и эксперименты.

Относитесь к legacy-системе как к продукту с собственным владельцем, roadmap и метриками. Это меняет отношение: не «поддержка старья», а «управление критичным активом».

И не стоит забывать о правильных метриках. Важно помнить, что измерять нужно не только скорость работы, но и общее состояние, то есть здоровье систем.

Когда мы замеряем только скорость доставки, команда будет накапливать долг. Если измерять только стабильность, команда перестанет внедрять инновации. Поэтому нужен сбалансированный набор, состоящий из скорости (lead time, частота деплоя), стабильности (MTTR, доля неудачных изменений), здоровья кода (покрытие, сложность, дублирование) и здоровья команды (выгорание, текучка).

Выводы

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

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

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