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

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

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

Анализ в разрезе репозитория

Раньше мы фиксировали сам факт использования технологии. Теперь система строит полноценный технологический профиль репозитория.

Во время сканирования определяются:

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

Контроль невоспроизводимых сборок

Многие до сих пор любят использовать диапазоны версий в build файлах.

Например в build.gradle может быть написана строчка: dependency "ru.my:lib:1.2.+"

Это опасно, если у вас явно не пишутся lock файлы! При повторной сборке может подтянуться сломанная patch версия, и ваш релиз не соберется.

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

Наши опросы показали, что многие ИТ-компании до сих пор хостят реестры пакетов с релизами на своем железе. И аварии…они случаются (держал свечку как минимум 3 раза). Теряются данные, восстановить получается не все, часть пакетов нужно пересобирать заново. Иногда на ликвидацию последствий уходят месяцы. А у нас тут оказывается еще и сборки не воспроизводятся, «Финита ля комедия».

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

Достаточно выставить флажок в админке и новые сканирования определят, где у вас присутствуют риски.

Контроль цепочки поставок

Отдельно стоит выделить анализ источников зависимостей.

В нашей сфере нередко происходит ситуация, когда в build файлах находятся ссылки на публичные реестры пакетов, несмотря на наличие внутренних решений (Artifactory, Nexus,…) в рамках корпоративных стандартов. Это несет в себе риски безопасности как для эксплуатации результата сборки, так и для самой возможности этой сборки (примерами могут быть блокировки или внезапные аварии). Представьте, что вам нужно срочно доставить в прод исправление серьезного бага, а движение поставки зависло по причине недоступности внешнего ресурса. Каждый такой эпизод может оказаться очень чувствительным для здоровья и репутации бизнеса, поэтому мы добавили возможности мониторинга отклонения от корпоративной политики и в части используемых пакетных реестров.

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

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

Ранее такие вещи находились случайно, теперь это системный контроль.

От мониторинга к управлению

Самый мажорный момент - мы перестали ограничиваться обнаружением проблем.

Появился новый доменный объект: Миграция.

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

Система автоматически:

Определяет список репозиториев, где нужно внести изменения
Формирует чек-лист
Отслеживает выполнение

Теперь миграция - измеримый процесс. Прощай ручная аналитика на этапе планирования.

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

Без автоматизации - это ручной анализ, хаотичные задачи, отсутствие прозрачного статуса, потеря управляемости.

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

Итог

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

Мы больше не просто знаем, что используется. Мы знаем где, в каком объеме, с какими рисками и как это централизованно изменить.

Следующий шаг уже тестируется на наших внутренних проектах. Но это уже тема для следующей статьи.

Техрадар на максималках: от визуализации техдолга к автоматическому управлению миграциями