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

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

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

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

2. Чтобы принимать правильные архитектурные решения. У команд появляется источник информации о том, какие решения рекомендуется использовать для тех или иных целей.

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

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

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

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

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

• Adopt технологии, которые активно используются в проектах.

• Trial технологии, которые прошли боевое тестирование и готовятся перейти в актив компании.

• Assess технологии, к которым компания ещё присматривается.

• Hold морально устаревшие технологии или решения, которые себя не оправдали на практике.

• 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 (менеджер репозиториев кода для хранения и распространения релизов) как раз потому что последний обеспечивает более низкий уровень безопасности.

Заключение

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

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

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

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

3. Выстроить структуру в формате, который вам удобен таблица, база знаний, визуализация вроде той, которую использовали мы.

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