В прошлой статье я рассказывал, как мы оживили техрадар: научили систему автоматически обходить git репозитории, определять стек технологий, находить устаревшие зависимости и визуализировать технологический ландшафт компании.
Это важный шаг в развитии внутренних процессов, но он покрывал только часть потребностей команды. Со временем стабилизация сбора и анализа состава ИТ-ландшафта позволила нам выйти на следующий логический этап - управление изменениями.
Сегодня техрадар — это уже не просто система наблюдения, но полноценный пункт управления вашим ИТ-ландшафтом, умеющий управлять миграциями технологий системно и автоматически.
Анализ в разрезе репозитория
Раньше мы фиксировали сам факт использования технологии. Теперь система строит полноценный технологический профиль репозитория.
Во время сканирования определяются:
используемые фреймворки
инфраструктурные технологии
менеджеры пакетов
сами пакеты по каждому менеджеру
используемые реестры пакетов
Контроль невоспроизводимых сборок
Многие до сих пор любят использовать диапазоны версий в build файлах.
Например в build.gradle может быть написана строчка: dependency "ru.my:lib:1.2.+"
Это опасно, если у вас явно не пишутся lock фай��ы! При повторной сборке может подтянуться сломанная patch версия, и ваш релиз не соберется.
Я видел проекты, где такое прописывают для минорных версий зависимостей и даже для плагинов. А потом, на этапе сборки релиза, подтягивается новая версия линтера с обновленными правилами. И вы снова вынуждены проходить весь производственный цикл, от создания задачи, доработки проекта до code review и прочих корпоративных телодвижений, прежде чем поставка будет готова к установке в прод.
Наши опросы показали, что многие ИТ-компании до сих пор хостят реестры пакетов с релизами на своем железе. И аварии…они случаются (держал свечку как минимум 3 раза). Теряются данные, восстановить получается не все, часть пакетов нужно пересобирать заново. Иногда на ликвидацию последствий уходят месяцы. А у нас тут оказывается еще и сборки не воспроизводятся, «Финита ля комедия».
Мы сейчас не задаемся вопросом о том, что кто-то облажался с бэкапами. Даже при их наличии порой необходимо восстановить хотя бы сборки за последнюю неделю. Мы подходим к этой проблеме с другой стороны - а именно к определению самого факта воспроизводимости.
Достаточно выставить флажок в админке и новые сканирования определят, где у вас присутствуют риски.
Контроль цепочки поставок
Отдельно стоит выделить анализ источников зависимостей.
В нашей сфере нередко происходит ситуация, когда в build файлах находятся ссылки на публичные реестры пакетов, несмотря на наличие внутренних решений (Artifactory, Nexus,…) в рамках корпоративных стандартов. Это несет в себе риски безопасности как для эксплуатации результата сборки, так и для самой возможности этой сборки (примерами могут быть блокировки или внезапные аварии). Представьте, что вам нужно срочно доставить в прод исправление серьезного бага, а движение поставки зависло по причине недоступности внешнего ресурса. Каждый такой эпизод может оказаться очень чувствительным для здоровья и репутации бизнеса, поэтому мы добавили возможности мониторинга отклонения от корпоративной политики и в части используемых пакетных реестров.
Второй случай, когда это может быть полезно - переезд с одного реестра на другой. Мы добавили возможность явного выбора целевого решения для таких случаев. Новое сканирование покажет, в каких исходниках миграция выполнена, а в каких нет.
Это особенно важно для крупных организаций, где один «левый» реестр пакетов может стать точкой входа для инцидента.
Ранее такие вещи находились случайно, теперь это системный контроль.
От мониторинга к управлению
Самый мажорный момент - мы перестали ограничиваться обнаружением проблем.
Появился новый доменный объект: Миграция.
Каждая миграция представляет из себя формализованный процесс. От вас требуется сказать системе чего вы хотите, а она уже знает, где технологию нужно внедрить, обновить, заменить или вывести из эксплуатации.
Система автоматически:
Определяет список репозиториев, где нужно внести изменения
Формирует чек-лист
Отслеживает выполнение
Теперь миграция - измеримый процесс. Прощай ручная аналитика на этапе планирования.
В крупной организации проблема не в том, чтобы обновить одну библиотеку, а в том, чтобы обновить её в сотнях репозиториев системно и контролируемо.
Без автоматизации - это ручной анализ, хаотичные задачи, отсутствие прозрачного статуса, потеря управляемости.
С автоматизацией - полный технологический профиль, формализованные миграции, измеримый прогресс, управляемый техдолг.
Итог
Техрадар эволюционировал от системы наблюдения к платформе управления жизненным циклом технологий.
Мы больше не просто знаем, что используется. Мы знаем где, в каком объеме, с какими рисками и как это централизованно изменить.
Следующий шаг уже тестируется на наших внутренних проектах. Но это уже тема для следующей статьи.
