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

Боль разработчика

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

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

Второй сценарий — «будем всё контролировать по науке». Создаётся технаправление, вводятся ADR, требования к лицензиям, собираются комитеты. Работает, но какой ценой: титанические усилия, сотни человеко-часов на рутину, тонны вики-страниц. Разработчики меньше пишут код и больше координируют процессы.

Оба сценария плохи. В первом — хаос и судный день, во втором — бесконечный админотдел внутри R&D. По моему опыту, до 30% времени уходит на контроль версий, ручные сверки, пересчёт рисков и на то, чтобы просто понять, что у нас вообще происходит по стеку.

Как выглядит этот «ад» изнутри

Нужно проверить, на каких версиях живёт любимый фреймворк. Что делает разработчик?
Клонирует проект, ждёт, лезет в lock-файл или руками смотрит зависимости через команду. А таких проектов десятки или сотни.

Дальше — координация. Вики, таблички, Jira. На миграцию, например, favorite-framework 1.1.x → 2.x.x заводятся десятки задач, кто-то вручную проставляет версии в табличку, кто-то случайно затирает чужую строку, кто-то забывает обновить статус. В лучшем случае всё работает на честном слове.

ADR? Красиво, модно, молодежно, но кто из ревьюеров реально их читает и поддерживает?
Лицензии? Пропустил GPL в коммерческий продукт — получишь юристов на голову. Для нормальной автоматизации нужны отдельные инструменты и штат.

Итого — везде бардак и ручной труд. Общей картины нет. У каждого своя правда: у одной команды в вики, у другой в чатике, у третьей в голове лида. Если CTO спросит «на чем мы реально стоим», ответа нет.

Где-то в идеальном мире

В какой-то момент я поймал себя на простой мысли: а как хотелось бы, чтобы было?

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

Хочется нажать кнопку и получить список: вот проекты, где фреймворк отстал на 3 мажорных версии; вот лицензии, которые конфликтуют с политикой; вот прогресс миграции.
Хочется, чтобы новые репозитории находились сами, а Jira-таски на миграции создавались автоматом. Хочется не тонуть в табличках, а видеть живую динамику: что растёт, что устаревает, что нужно тушить.

Мечта выглядела утопично. Но однажды я решил: стоит попробовать ее реализовать.

Как реализовать мечту

Идея была первым шагом. В какой-то момент стало ясно, что для решения такой задачи нужен системный подход, а не просто набор скриптов. Мы собрали команду и сфокусировались на этом, как на нашем основном проекте. Путь длинный и местами болезненный, но интересный.

Что доступно на рынке

Конечно, мы не стали сразу писать код, а изучили, что уже существует:

• Zalando Tech Radar — классика, вдохновлённая ThoughtWorks. Это прекрасная визуализация и инструмент знаний, но явно — ручная: архитекторы собираются, голосуют, рисуют. 

• Backstage.io — мощная платформа-ландшафт для инженерной панели, включающая плагин Tech Radar. Но он всё ещё фокусируется на ручном пополнении и хранении метаданных.

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

Итак, инструмента, который сам лезет в репозитории и строит живую стратегическую карту, не нашлось. 

Сначала — визуализация

Мы взяли за основу простое open-source решение для техрадара — AOE Tecnology Radar, но быстро поняли, что оно не тянет. Пришлось переписать ядро на Angular с выделенным API-слоем и модульной архитектурой и углубиться в тригонометрию визуализации: как делить сектора, как показывать квадранты и нестандартные структуры. Хотелось гибкости, а не жёсткой картинки.

Мы допилили поддержку сложных структур, сделали визуальный конструктор: можно загрузить структурированный JSON или сконфигурировать радар мышкой, двигая ползунки.

В реальном мире, в компании может быть несколько продуктов и команд, а значит — нужны несколько радаров. Окей, сделали поддержку множества, без ограничений с рендерингом на базе D3.js.

Дальше — данные

Картинка без данных — витрина. Настоящая магия — под капотом.
Мы научили систему сканировать репозитории: либо указываешь URL, либо она через API Bitbucket/GitLab сама находит все проекты (используем эндпоинты для списков репозиториев, веток и файлов, обрабатываем rate limits; для ускорения применяем многопоточность). Настраиваешь фоновые задачи и ждёшь. Некоторые сканирования могут быть сильно ресурсоемкими. Если не хочется ждать, всегда можно запустить сканирование вручную.

Парсить зависимости — отдельная история. В одном проекте есть lock-файл, в другом нет. Пришлось сделать два режима:

1. если есть lock-файлы (package-lock.json, gradle.lockfile, Gemfile.lock и т. д.) — быстро и точно читаем их;

2. если нет — эмулируем окружение (поднимаем микро-CI в Docker и запускаем команды вроде go list -m all, ./gradlew dependencies, кэшируем результаты для ускорения повторных проверок).

Сейчас поддерживаем больше десяти пакетных менеджеров: Bundler, Composer, Conan, Gradle, npm, NuGet, pip, SwiftPM и др. И этот список постоянно растет.

Самое нетривиальное — маппинг

Сырые данные: «spring-core v2.5.4». А на радаре это что? Spring? Spring Boot? Просто «Java-фреймворки»?

Сначала мы делали гибкие регулярки, настраивали их руками в админке. Больно, но иначе никак.
Сейчас почти готовы прикрутить ИИ, подрубаемся через OpenAI api к нужной модели и получаем от нее результаты, которые пользователь может либо принять, либо ввести свое правило.

И ещё — мониторинг

Мы поняли, что техрадар — не место для табличных данных (для этого сделали отдельные страницы и аналитику).

Но он идеален как сигнализатор. 

А значит, нужны правила, например:

• устаревание. Зависимость в проекте отстает от latest версии на настроенную величину.

• недопустимое распространение. Технология, которую планируется убрать (например, в статусе Hold), используется в слишком большом проценте проектов.

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

Ключевые выводы из нашего пути

Главные инсайты:

• визуализация без данных — бесполезна, данные без визуализации — хаос. Нужно и то, и другое;

• автоматизация техдолга — это не пара скриптов, а серьёзная инженерная задача с интеграциями, поддержкой и гибкостью;

• даже для внутренней задачи стоит проектировать как продукт, иначе всё утонет в костылях.

Вместо вывода

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

Если интересно покопаться в технических деталях, в комментах могу рассказать больше: про архитектуру, JSON-конфиги радара, правила сигналов и то, как мы прикручиваем ИИ для маппинга. Интересно было бы услышать: как вы решаете подобные задачи у себя?

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