Техдолг. От хаоса в Excel до живой карты технологий: рассказывает Иван Головко, CEO GINC Radar
Иван Головко, CEO и основатель GINC Radar, — о том, как превратить управление техдолгом из ручного ада в прозрачный и автоматизированный процесс.
Боль разработчика
Про техдолг написаны горы постов и сломаны тонны копий. За свою карьеру в IT, пройдя путь от инженера до руководителя, я снова и снова наблюдал один из двух сценариев.
Первый — «да ну его, потом разберёмся». Всё внимание уходит в фичи, техдолг игнорируется. «Потом» наступает внезапно: что-то падает, миграция из-за критичной уязвимости превращается в месяцы ручного ада, люди выгорают и бегут. Конец известен.
Второй сценарий — «будем всё контролировать по науке». Создаётся технаправление, вводятся ADR, требования к лицензиям, собираются комитеты. Работает, но какой ценой: титанические усилия, сотни человеко-часов на рутину, тонны вики-страниц. Разработчики меньше пишут код и больше координируют процессы.
Оба сценария плохи. В первом — хаос и судный день, во втором — бесконечный админотдел внутри R&D. По моим оценкам, до 30% времени R&D-команды буквально сгорает на ручные сверки, бесконечные миграции и попытки просто понять, на каком стеке мы работаем. Это прямые убытки для бизнеса, которые никто не считает.
Добро пожаловать в ручной Ад
Нужно проверить, на каких версиях живёт любимый фреймворк. Что делает разработчик?Клонирует проект, ждёт, лезет в lock-файл или руками смотрит зависимости через команду. А таких проектов десятки или сотни.
Дальше — координация. Вики, таблички, Jira. На миграцию, например, favorite-framework 1.1.x → 2.x.x заводятся десятки задач, кто-то вручную проставляет версии в табличку. Кто-то случайно затирает чужую строку, кто-то забывает обновить статус. В лучшем случае всё работает на честном слове.
ADR? Красиво, модно, молодежно, но кто из ревьюеров реально их читает и поддерживает?Лицензии? Пропустил GPL в коммерческий продукт — получишь юристов на голову. Для нормальной автоматизации нужны отдельные инструменты и штат.
Итого — везде бардак и ручной труд. Общей картины нет. У каждого своя правда: у одной команды в вики, у другой в чатике, у третьей в голове лида. Если CTO спросит «на чем мы реально стоим», ответа нет.
Где-то в идеальном мире
Я понял, что рынку нужен совершенно другой инструмент. Не очередная система контроля, а живая карта технологического здоровья компании. Система, которая сама обходит репозитории, собирает стек и зависимости, показывает живую карту технологий и сигнализирует, где беда.Не в виде красивой слайд-картинки для презентации, а в виде настоящего живого радара, к которому можно привязать проверки и правила.
Хочется нажать кнопку и получить список: вот проекты, где фреймворк отстал на 3 мажорных версии; вот лицензии, которые конфликтуют с политикой; вот прогресс миграции.Хочется, чтобы новые репозитории находились сами, а Jira-таски на миграции создавались автоматом. Хочется не тонуть в табличках, а видеть живую динамику: что растёт, что устаревает, что нужно тушить.
Мечта выглядела утопично. Но однажды я решил: стоит попробовать ее реализовать.
Как реализовать мечту
Идея была первым шагом. В какой-то момент стало ясно, что для решения такой задачи нужен системный подход, а не просто набор скриптов. Так что, я основал компанию GINC и собрал крутую команду. Так началась работа над GINC Radar — платформой, которая должна была навсегда изменить подход к управлению техдолгом. Путь оказался длинным и местами болезненным, но интересным.
Что доступно на рынке
Конечно, мы не стали сразу писать код, а изучили, что уже существует:
- Zalando Tech Radar — классика, вдохновлённая ThoughtWorks. Это прекрасная визуализация и инструмент знаний, но явно — ручная: архитекторы собираются, голосуют, рисуют.
- Backstage.io — мощная платформа-ландшафт для инженерной панели, включающая плагин Tech Radar. Но он всё ещё фокусируется на ручном пополнении и хранении метаданных.
- Fossa — как и другие SCA-инструменты, отлично сканирует зависимости. Но у него свой чёткий фокус: управление лицензиями и уязвимостями в Open Source компонентах. К тому же это западное и довольно дорогое решение. Оно отвечает на вопрос: «Не нарушаем ли мы лицензии и не используем ли уязвимые компоненты?». А нам нужен ответ: «на чём мы вообще стоим?».
Итак, инструмента, который сам лезет в репозитории и строит живую стратегическую карту, не нашлось.
Сначала — визуализация
Мы взяли за основу простое open-source решение для техрадара — AOE Tecnology Radar, но быстро поняли, что оно не тянет. Пришлось переписать ядро Angular с выделенным API-слоем и модульной архитектурой и углубиться в тригонометрию визуализации: как делить сектора, как показывать квадранты и нестандартные структуры. Хотелось гибкости, а не жёсткой картинки.
Мы допилили поддержку сложных структур, сделали визуальный конструктор: можно загрузить структурированный JSON или сконфигурировать радар мышкой, двигая ползунки.
В реальном мире, в компании может быть несколько продуктов и команд, а значит — нужны несколько радаров. Окей, сделали поддержку множества, без ограничений с рендерингом на базе D3.js.
Дальше — данные
Картинка без данных — витрина. Настоящая магия — под капотом.Мы научили GINC Radar сканировать репозитории: либо указываешь URL, либо он через API Bitbucket/GitLab сам находит все проекты (используем эндпоинты для списков репозиториев, веток и файлов, обрабатываем rate limits; для ускорения применяем многопоточность). Настраиваешь фоновые задачи и ждёшь. Некоторые сканирования могут быть сильно ресурсоемкими. Если не хочется ждать, всегда можно запустить сканирование вручную.
Парсить зависимости — отдельная история. В одном проекте есть lock-файл, в другом нет. Пришлось сделать два режима:
- если есть lock-файлы (package-lock.json, gradle.lockfile, Gemfile.lock и т. д.) — быстро и точно читаем их;
- если нет — эмулируем окружение (поднимаем микро-CI в Docker и запускаем команды вроде go list -m all, ./gradlew dependencies, кэшируем результаты для ускорения повторных проверок).
Сейчас GINC Radar поддерживает больше десяти пакетных менеджеров: Bundler, Composer, Conan, Gradle, npm, NuGet, pip, SwiftPM и др. И этот список постоянно растет.
Самое нетривиальное — маппинг
Сырые данные: «spring-core v2.5.4». А на радаре это что? Spring? Spring Boot? Просто «Java-фреймворки»?
Сначала мы делали гибкие регулярки, настраивали их руками в админке. Больно, но иначе никак.Сейчас мы интегрируем в GINC Radar AI-ассистента на базе последних моделей GPT. Он помогает автоматически классифицировать сотни библиотек, экономя десятки часов работы архитекторов.
И ещё — мониторинг
Мы поняли, что техрадар — не место для табличных данных (для этого сделали отдельные страницы и аналитику).
Но он идеален как сигнализатор.
А значит, нужны правила. Ключевые правила уже встроены в GINC Radar, и они дают мгновенный эффект: контроль устаревания версий и распространения нежелательных технологий. И мы постоянно расширяем библиотеку правил, от валидации лицензий до контроля прогресса миграций.
Ключевые выводы из нашего пути
Масштабных пилотов ещё не было, совсем недавно стартанули. Но уже есть архитектура, продуманная платформа и подход находит отклик у тимлидов и архитекторов, которые сталкиваются с теми же проблемами.
Первые внедрения GINC Radar показали: одна из команд смогла за две недели спланировать и запустить миграцию критичного фреймворка, на которую раньше у них ушли бы месяцы. Прозрачность стека позволяет принимать решения, основанные на данных, а не на интуиции.
Главные инсайты:
- GINC Radar — это единство данных и визуализации. Вы видите не просто красивую картинку, а живое отражение вашего кода, которое обновляется автоматически.
- GINC Radar — это не набор скриптов, а полноценная инженерная платформа. Мы взяли на себя всю сложность интеграций, парсинга и анализа, чтобы вы могли сфокусироваться на развитии продукта.
Вместо вывода
Хватит мириться с хаосом в технологическом стеке и терять время и деньги на ручной труд. Управление техдолгом может и должно быть автоматизированным и прозрачным.
Узнайте, как GINC Radar может помочь именно вашей компании. Запишитесь на персональное демо, и мы покажем, как вернуть контроль над вашим технологическим ландшафтом.
Хочется автоматизировать рутину, чтобы оставалось время писать код. Вернуть разработчиков и архитекторов обратно в продукт. На этом и стоим.
Иван Головко, CEO GINC Radar