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

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

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

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

  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. Договориться с ответственными за технологии о том, чтобы они периодически проверяли и обновляли набор продуктов по своим направлениям.

Источник: https://habr.com/ru/post/553798/


Интересные статьи

Интересные статьи

Привет Хабр! Меня зовут Александр Баулин, я – технологический журналист. В настоящий момент нахожусь в переходном состоянии — в статусе фрилансера выбираю вернуться ли в журналистику и...
Какое-то время назад я опубликовал статью про то, как я занимался созданием ДНК-секвенатора (прибора для чтения ДНК) путём реверс-инжиниринга микросхемы. Но со временем, пока я это делал ...
Вячеслав Ермолин, 5 июля 2020 г. Миссия: Shiyan Weixing-6 (02)/Chuangxin-3A (02) — технологический экспериментальный спутник для отработки технологий и исследования космическо...
Как-то у нас исторически сложилось, что Менеджеры сидят в Битрикс КП, а Разработчики в Jira. Менеджеры привыкли ставить и решать задачи через КП, Разработчики — через Джиру.
С версии 12.0 в Bitrix Framework доступно создание резервных копий в автоматическом режиме. Задание параметров автоматического резервного копирования производится в Административной части на странице ...