Как технологический радар помогает осознанному развитию корпортивной ИТ-экосистемы

Зачем собирать свой технологический радар

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

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

Как устроен технологический радар

Инструмент объединяет четыре категории: (1) техники, (2) языки и фреймворки, (3) инструменты и (4) платформы.

Каждая из этих областей подразделяется на 4 кольца:

Adopt — технологии, которые активно используются в проектах.
Trial — технологии, которые прошли боевое тестирование и готовятся перейти в актив компании.
Assess — технологии, к которым компания ещё присматривается.
Hold — морально устаревшие технологии или решения, которые себя не оправдали на практике.

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

Три больших тренда enterprise ИТ-радаров

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

1. Распределённые облачные среды. Это, разумеется, главный тренд последних нескольких лет. Монолитные продукты в прошлом – сейчас компании используют микросервисные приложения и облачные платформы, обеспечивая себе большую производительность на единицу затрат.

В этой технологической корзине у нас такие решения, как:

Kubernetes и Openshift, на которых строятся частные облака
Docker и Docker Compose – всем известные средства для разворачивания приложений в средах с поддержкой контейнеризации
Harbor – используем в качестве Docker Registry и для проверки контейнеров на уязвимости
Cтек продуктов ELK для мониторинга и логирования распределённых систем.
Jaeger - платформа для мониторинга, трассировки и управления транзакциями в распределённых архитектурах
Istio – управление трафиком и балансировки нагрузки, аутентификации и авторизации пользователей.
KNative - платформа для построения Serverless-продуктов, благодаря чему удаётся оптимизировать ресурсы и упростить операционные затраты на сопровождение (логи, мониторинг, метрики).
Публичные облака Microsoft Azure и Google Cloud – используем для тех случаев, когда данные можно отправлять в стороннюю инфраструктуру, например, для dev-окружений.

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

Что мы используем, чтобы решать эти задачи:

Azure DevOps – создание и тиражирование DevOps-пайплайнов, внедрение и распространение лучших практик разработки.
SonarQube – статический анализ кода, проверки на покрытие тестами, общую удобочитаемость и т.д.
Google Analytics, Google BigQuery, Grafana – средства аналитики и визуализации данных, чтобы отслеживать поведение пользователей и проверять рабочие гипотезы
Kotlin для бэкенда – более лаконичный и безопасный язык, чем Java
Подходы к разработке:
- Continuous Delivery
- Trunk Based Development
- Feature Flags
- Техники А/Б-тестирования

3. Безопасность продуктов. Сдвиг к распределенной облачной архитектуре меняет требования к безопасности – теперь нельзя выстроить защищенный контур вокруг продукта, каждое приложение внутри системы теоретически представляет собой источник угрозы. Требования к безопасности конкретного микросервиса значительно повышаются и подход к поиску уязвимостей меняется и смещается на ранние стадии разработки продукта.

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

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

Поскольку компания не может позволить себе использовать незащищённые технологии, тема безопасности так или иначе распределена по всему радару. Например, SonarQube помогает нам проверять код на базовые уязвимости, а использование Kotlin для бэкенда снижает риски, что в продукте появятся опасные ошибки. Упомянутый в первом разделе Harbor позволяет сканировать используемые контейнеры на безопасность и заменяет в нашей практике схожий инструмент Nexus (менеджер репозиториев кода для хранения и распространения релизов) – как раз потому что последний обеспечивает более низкий уровень безопасности.

Заключение

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

Если хотите создать свой радар, план действий такой:

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