Как мы работаем
Мы — команда разработчиков DevX. Мы работаем в направлении dev-to-dev: экспериментируем с технологиями и оптимизируем цифровую среду и инфраструктуру, чтобы нашим коллегам было максимально удобно создавать и развивать сервисы и продукты QIWI.
О нашем стеке
Наша команда состоит из бэкенд и фронтенд разработчиков. Основные ЯП у бэкенда: Java и Kotlin, Node.js; у фронтенда: Typescript+React. Также некоторые сервисы пишем на Python.
Почти все инструменты нашей среды разработки (IDE) входят в кит JetBrains. Фронтенд использует Visual Studio Code, WebStorm; бэкенд — PYCharm, Intellij IDEA.
Микрофронтенды — наше всё
У нас в QIWI много внутренних сервисов, которыми пользуются разные команды разработчиков. В этом году мы выступили с инициативой по организации централизованного доступа к ним. Микрофронтенд подход позволит интегрировать новые сервисы в портал, над которым наша команда работает в данный момент. Сейчас этот проект находится в экспериментальной фазе и пока в пилоте находятся только три сервиса — два от DevX и один от команды DevOps, но в дальнейшем мы надеемся тиражировать этот подход на всю IT команду QIWI.
Как мы настроили и поставили на поток работу с данными
Мы часто выступают первопроходцами — обкатываем новые решения и подходы на себе, а затем стараемся тиражировать их на остальные отделы. Одним из подобных проектов в 2022 году было внедрение решения Apache Airflow для сбора информации по цифровым активам.
Предпосылки проекта
В QIWI сервисы постоянно изменяются, появляются новые способы разработки, деплоя и поддержки. По мере роста компании появлялось больше решений и больше самостоятельных команд программистов. Всё это усложняло процессы мониторинга, сбора и обработки данных. Нужен был инструмент, который позволил бы увидеть картину целиком — состояния и метрики сервисов, тренды разработки, скорость и проблемы релизов.
О продукте
Apache Airflow — написанное на Python открытое программное обеспечение для создания, выполнения, мониторинга и оркестровки потоков операций по обработке данных. Центральным элементом Airflow является ориентированный ациклический граф (DAG) — представление, которое объединяет операции в единую цепочку (data pipeline), в нём видны зависимости между узлами. Для описания задачи разработчик использует различные операторы (Operator).
Вызовы проекта
Внедрение происходило с участием двух независимых команд, впервые объединённых в один проект. У нас в DevX большой процент новичков: часть ребят были незнакомы ни друг с другом, ни с процессами и требованиями компании. В целом это нормальная история, но часть внимания ушла на налаживание коммуникации и процессов. Вторая сложность — согласование разнородных данных. Несмотря на похожие подходы, каждая команда сама решает как им вести разработку, а это усложняет сбор данных.
Мы не представляли в полном объёме, как наиболее корректно внедрить решение. Тем не менее перед нами поставили задачу развернуть Apache AirFlow таким способом, чтобы впоследствии этот стандарт использовался по всей компании.
Внедрение началось в тот момент, когда менялся процесс релизов сервисов QIWI — и в этом была основная сложность. Релиз Airflow осуществлялся с помощью ArgoCD, а не на привычном нам Workflow. Более того, развёртывание проходило в разных окружениях (Dev, CI, Prod), что увеличивало сроки релиза. Вообще, с начала внедрения до вывода в продакшн ушло около 2 месяцев. Это не только развертывание Airflow, но и написание ациклических данных для сбора данных.
Учитывая специфику сервисов QIWI, нам нужно было всё время уделять особое внимание политике сетевой безопасности и постоянно коммуницировать с dev-ops инженерами и ISEC специалистами. Это именно тот случай, когда для разработчика важны софтскиллс, которые помогают услышать друг друга, учесть интересы и потребности нескольких сторон IT-структуры компании и сократить время на развёртывание.
Выгода от нового решения
Для внутренней аналитики и оптимизации необходимо собирать много данных о состоянии своих сервисов, репозиториев и т.д. До внедрения Apache AirFlow мы пытались реализовать эту задачу с помощью собственных скриптов, написанных на Python. Этот подход работал на начальных этапах развития портфеля продуктов компании. При увеличении источников данных стали возникать сложности с управлением доступом к ним, мониторингом изменений и ошибок. Фактически у нас не было адекватных инструментов для контроля.
AirFlow устранил все эти проблемы за счёт своих мощных возможностей по оркестрации потоков данных. Решение позволило аккумулировать большие объёмы информации в одном месте и трансформировать её в любой удобный вид. В отличие от предыдущего инструмента, непригодного для масштабирования, AirFlow стабильно ведёт себя при любых расширениях объёма и источников данных — любому разработчику достаточно написать небольшой скрипт для коннекта источника и AirFlow и сделать свой сборщик данных под свой проект. Считаем, что в крупных компаниях с большим количество сервисов и продуктов такие инструменты — это must-have.