Марія БровінськаИстории
27 ноября 2023, 10:57
2023-11-27
Революция в разработке: как Platform engineering и NoOps уменьшают издержки бизнеса и ускоряют разработку новых продуктов в разы. Опыт Райфа
Айтишники украинского офиса Райффайзен банка создали уникальную внутреннюю платформу разработки, позволяющую упростить и ускорить создание новых сервисов компании, или оптимизировать старые. Теперь каждый новый сервис, продукт или решение в Райфе создается благодаря хорошо проработанным и защищенным алгоритмам действий, шаблонам, не требующим стоимостного и временного написания кода отдельно под каждый запрос.
Айтишники украинского офиса Райффайзен банка создали уникальную внутреннюю платформу разработки, позволяющую упростить и ускорить создание новых сервисов компании, или оптимизировать старые. Теперь каждый новый сервис, продукт или решение в Райфе создается благодаря хорошо проработанным и защищенным алгоритмам действий, шаблонам, не требующим стоимостного и временного написания кода отдельно под каждый запрос.
Fintechgineer
dev.ua пообщался с Родионом Сабодашем, который, собственно, руководит восемью командами, среди которых команда построения внутренней автоматизированной платформы. Несмотря на свой возраст (30 лет), успел поработать в 5 fintech-компаниях и банках: ПриватБанке, monobank, Таскомбанке, разрабатывал продукты для американского банка в Техасе и для казахстанского финучреждения. Родион присоединился к Райфу в 2021 году, когда почувствовал, что ему не хватает челленджей. Банк как раз начал менять организационную структуру, взял курс на разработку новых сервисов, инфраструктуры и продуктов.
«Это было время, когда от классической модели, где есть отдельный департамент разработки и эксплуатации сервисов, мы двинулись к доменной организационной структуре с принципами Transparency, E2E, Data driven, Opensource only, In house development для быстрого развития сервисов для наших клиентов», ― объясняет Родион.
Рассказываем, какова роль Internal Developer Platform в бизнесе Райффайзен Банка и работе дивизиона Technology Райффайзен Банка, где есть как platform engineering, так и finOps-специалисты.
Цели и задачи изменений
Перед командой Родиона встала задача изменить алгоритм действий при разработке новых продуктов. То есть от системы, где отдельная команда разрабатывает, затем отдельная команда разворачивает сервер, отдельная команда доставляет сервис и отдельная команда ставит его на мониторинг, банк должен был перейти на Continuous Deployment (непрерывное развертывание) с учетом нового стека технологий разработки, безопасности, инфраструктуры и новой организационной структуры.
Перед разработчиками встало несколько вопросов:
Как изменить операционную модель большинства команд? Как предоставить им инструменты и процессы для разработки сервисов и при этом не внедрять сложность создания одного и того же функционала в различных бизнес-доменах?
«Это как создать колесо. Каждый из нас может его создать, но в этом нет смысла», ― в шутку говорит Родион.
Как сделать коммуникацию прозрачной и понятной?
Как дать свободу в разработке и экспериментах и одновременно не получить «зоопарк» технологий и решений?
Как убедиться, что сервисы трудоспособны и безопасны?
«Большое количество изменений, переход от разработки на основе решений от вендора к in-house и контекст банка, где надежность и безопасность сервисов всегда будут на первом месте, нуждалось в трансформации инфраструктуры во что-то, что стандартизирует разработку, предоставляет „центральные“ инструменты, будет гарантировать распространение изменений по всем командам в случае необходимости», — говорит Родион. Таким решением стала Platform engineering, которая могла бы закрыть все вопросы и стать унифицированным решением всего IT в банке.
Platform engineering ― дисциплина построения внутренних платформ для разработчиков, централизованная коллекция инструментов, сервисов и автоматизированных процессов для того, чтобы поддерживать быструю разработку и доставку сервисов клиентам
Нет аутсорсу
К внедрению новых решений айтишники Райфа уходили два года. И сложнее всего было, по словам Родиона, убедить опытных разработчиков в том, что такие изменения будут в пользу бизнеса. Отдельный момент — разный опыт каждого из айтишников. Есть работающие в банке десятки лет, а есть те, кто только начал свой путь в IT, но прекрасно ориентируется в современных инструментах и решениях.
«Например, одному из наших разработчиков за 50 и 15 лет он работает в банке. В то же время, он изменил свой консервативный майндсет и поддержал необходимость новых подходов», ― рассказывает Родион.
Кстати, самый молодой член команды, работающий над платформой, вдвое младше — ему 24 года.
Как создавалась платформа? Platform team, по словам Родиона, приступила к разработке in-house infrastructure product по концепту noOps, где разработчик использует self-service вместо запроса к Ops коллеге.
Для эффективной коммуникации внутри организации, рассказывает Родион, была внедрена дополнительная церемония для анонсов, обучения и получения живого фидбека — Office Hours. Офисные часы — это когда сотрудники могут обсудить то или иное нововведение, задать вопрос команде разработки, да и вообще обменяться мнениями относительно платформы. Такие встречи в Райфе проводятся раз в две недели, решаются вопросы прозрачности коммуникации и обратной связи.
Кроме того, есть Platform Enhancement Proposal. Главная роль этого канала — убедиться, что backlog платформы — это потребности заказчиков + возможность сделать contribution самостоятельно в кодовую базу платформы.
«Когда что-то разрабатываешь, это автоматически тестируется и затем доставляется прямо клиенту. Мы исключаем любой человеческий фактор где-то посреди этой цепочки», ― объясняет Родион.
Он отмечает: новая модель исключает создание неработающих сервисов, что вызывает недовольство клиента. Это внутренний продукт, используемый разработчиками банка для выполнения заказов от внутренних команд разработки сервисов.
Основная цель такого решения и команды платформы — сокращение времени доставки кода в production и упрощение сложности инфраструктуры.
«Для нас эта миссия дополнилась еще принципом „noOps“ — минимизировать количество человеческих операций в цепочке взаимодействия разработчиков с инфраструктурой и снизить время цикла разработки программного обеспечения. Поэтому разработка любого platform service всегда включает в себя self-service», ― объясняет Родион. Он добавляет, что ставку именно на платформенную инженерию делают ведущие компании в мире. Однако часто в индивидуальных решениях используют тот же стек, которым пользуются DevOps инженеры. Однако Platform engineering — это о другом. «Она должна быть понятной и четкой для команды, которая будет реализовывать эту платформу. И она должна быть полностью совместима с миссией и ценностями компании», ― отмечает Сабодаш.
Как устроена Platform engineering в Райфе
Самый главный компонент платформы, которую нельзя купить — Collaboration, говорит Родион. То есть определяющее значение в построении платформы имеют:
Прозрачная коммуникация
Механизмы предоставления/получения обратной связи
Возможность делать contribution в IDP
Вторая составляющая — постоянное и регулярное обсуждение нового решения. Platform team в Райфе, как и любая продуктовая команда, имеет Demo day, где представляют реализованные фичи и решения. «Это об управлении ожиданиями, обратной связи, прозрачности коммуникаций и получении фидбека», ― объясняет Родион. На митингах можно задать вопросы команде платформы, почелэндить roadmap, предложить свою фичу, пожаловаться или получить воркшоп от команды платформы. «Эта встреча опциональна раз в две недели, и в среднем к нам приходят подискутировать 80–100 человек», ― рассказывает Родион.
Третья составляющая — предложения по совершенствованию платформы.
«Здесь мы взяли подход по опенсорсу. И если у нас есть заказчик, которому нужна какая-нибудь фича от платформы, нужно понимать, что фича платформы распространяется на всех. Это не что-то эксклюзивное», — говорит Родион.
Разработчики имеют git-репозиторий для запросов на создание новой фичи на платформе. Такой механизм позволяет голосовать за те или иные фичи, определяя приоритетность их внедрения, и позволяет айтишникам самостоятельно делать platform contribution. Вся компания может ставить ругательства, может писать свои комментарии, решать, что на платформе нужно, а что нет.
Четвертый элемент новой платформы Райфа — Open backlog and all git repositories. Roadmap и текущие активности всегда открыты всей компании. «Любой человек может пойти и посмотреть, над чем мы работали, на чем мы планируем работать, как мы это делаем конкретно», — объясняет Родион.
Ну и последний элемент — обязательные Operational Level Agreement (OLA) для запросов в поддержку и инцидентов. «Время — главное KPI для поддержки и проблем на production, и благодаря этому стейкхолдеры платформы всегда знают „что ожидать“ от платформы», ― говорит Родион.
Все разработки разработчики тестируют собственноручно. например, недавно был пилот по Platform engineer injection в команду разработки бизнес-сервисов. Во время такого эксперимента у инженера платформы отнимают доступы (godmode) от платформы и выдают доступы доменного devops. Так человек работает над задачами домена целый спринт — две недели. Это позволяет «не замыленному» глазу посмотреть на реальный service quality платформы и найти зоны для улучшения.
Кто работает над платформой
В настоящее время на новой платформе разрабатывается более 700 сервисов.
«Более 2000 github раннеров, которые скейлятся с появлением новых джобов, это ~500 внутренних rps на микросервисы и ~4k rps на наши публичные домены, ~100К msg/s на Kafka, более 100 Postgre RDS, наши fluentbit процессируют 11k, три кластера EKS и 100 нод только для Production», ― говорит на привычном для айтишников языке Родион.
Всего новые решения вводят десятки разработчиков и девопсов. общий же штат IT-подразделения райфа — около 800 специалистов.
Команда платформы состоит из шести выделенных инженеров по IDP и Cloud Architect, который также работает с другими бизнес-командами и командами платформы. Трое инженеров отвечают за Developer support и experience.
«Это люди, которые организуют некий developer experience, чтобы наши разработчики, пользующиеся платформой и встречающиеся с какой-то проблемой, не чувствовали себя как никому не нужные люди. Они обрабатывают запросы, проводят консультации, воркшопы», — объясняет Родион.
Еще трое отвечают за core feature development. «Разработчику не нужен человек для создания инфраструктуры разработки сервисов. Все, что нужно для старта и после, можно получить через self-service, это точно безопасно, потому что коллеги по безопасности принимали участие в разработке нашей автоматизации. И мы уверены, что все это не упадет завтра, потому что фактически у нас есть набор таких шаблонов, которые переиспользуются уже самостоятельно нашими девелоперами», ― говорит Родион, объясняя, что именно это и называется NoOps и акцентируя на том, что NoOps ― это не инструмент, а принцип.
Engineering Manager ответственен за коммуникацию, управление, планирование и выполнение задач. Cloud Architect работает не только с командой платформы микросервисов, но и с другими проектами, поэтому здесь он частично задействован в принятии технических решений.
Отказ от технологий динозавров
Родион отмечает то, что команда платформы не хотела работать с «какими-то технологиями динозавров». «Банка уже более 30 лет, и у нас очень много старых технологий. Современные проблемы нуждаются в современных инструментах», ― говорит он.
Для того чтобы развивать платформу достаточно ограниченными ресурсами, команда унифицирует и упрощает автоматизацию. Разработчики обслуживают не более 10 запросов поддержки и держат support volume не более 10 Tickets/day, а экстренные запросы пытаются вообще сводить до 0.
Большинство сервисов Райфа находится в облаке на базе Amazon Web Services и там, где произвольно использовать managed services: EKS, MSK, RDS, S3, R53.
«После миграции в облако я сделал шаг в сторону для того, чтобы команда развивалась более самостоятельно. К моменту миграции в тучи они уже достигли того уровня зрелости, когда могут сами принимать решения, они сами видят эти или другие проблемы. И сейчас эта команда более автономна», — рассказывает Сабодаш.
Для Infrastructure-as-Code здесь используются terraform и terragrunt, который автоматизирован с github actions и atlantis. «И это об унификации IaC-операций в компании. На этом подходе построена вся инфраструктура как микросервисов, так и других продуктов», — говорит Родион.
Создание «сервиса» на платформе также проходит через автоматизацию (Service Provisioner): девелопер создает тикет с названием сервиса и его деталями в jira template, и после его согласования github workflow и terragrunt создают все необходимое от LDAP аккаунтов с git-репозиториями и ranners Vault инфраструктуры. После этого у разработчика есть все для старта разработки.
Все возможные опции по управлению сервисом, над которым работает команда, в инфраструктуре доступны в base helm chart. Этот инструмент предоставляет интеграцию с платформенными сервисами через yaml Engineering.
Как инфраструктурные релизы, так и бизнес используют gitOps на основе ArgoCD. Каждый домен имеет свой argoCD и возможность создавать внутреннюю инфраструктуру, управлять релизами.
«Например, feature environments создаются с помощью ApplicationSets и PR Generator. Canary/Blue-green настроен с помощью Argo rollouts. CI построен на github действия. Каждый сервис использует один из reusable workflow, в котором обязательны code scanning, dependency scanning, docker scanning, build и тестирование», — говорит Родион.
Поэтому, если команде безопасности или платформы нужно что-то обновить, это можно сделать с помощью автоматизации сервисов.
Если сервису для работы требуются облачные сервисы типа RDS, то разработчик может создавать их с помощью Crossplane compositions, созданных платформой. «Фундаментальная разница crossplane с такими классическими инструментами, как terraform в том, что, по моему мнению, нельзя построить настоящий self-service на terraform. Когда из crossplane вы исключаете infrastructure drift, change automation, release changes идут из одного helm release», ― говорит он. И добавляет: в начале разработка условного RDS-модуля (Crossplane composition) кажется более длинной и менее удобной, но со временем становится очевидно, что использование этого фреймворка дает положительный эффект на количестве времени, необходимого для поддержки платформы.
Вся sensitive конфигурация хранится в hashicorp vault и автоматически монтируется к воркладам в кластере. Vault также используется для получения временных кредитов RDS, Redis и создает TLS сертификаты с PKI.
«Автоскейлинг может быть как классический от Kubernetes, так и KEDA с возможностью скейлить сервисы по событиям из Kafka или DynamoDB. Также мы пилотируем Karpenter cluster autoscaler для более гибкого управления compute в нашем кластере. Думаю, что в будущем пул нод каждого домена будет выглядеть как karpenter provisiner с arm и x64 on-demand/spot нодами», — рассказал Родион Сабодаш.
Он рассказывает, что в планах Райфа ― отказ от terraform для 0day cluster/addons operations и service provisioner для сокращения времени как развертывания новой среды, так и уменьшения времени управления.
Почему NoOps невозможно купить
По мнению Родиона, NoPops алгоритмы и автоматизированные решения для создания сервисов компании нельзя купить, поскольку каждая система строится под конкретную организацию и перечень ее внутренних продуктов. «У каждой организации есть культура, цели, миссия. И когда мы говорим о „что-то купить“, это не всегда равно тому, что нуждается в твоей организации. Здесь либо нужно переформатировать организацию под то, что ты купил, либо делать свое, потому что купленным вряд ли кто-то сможет пользоваться», ― объясняет айтишник.
Среди преимуществ NoOps подхода Родион выделяет следующие:
― скорость реализации проектов;
― легкость управления разработкой;
― оптимизация расходов на разработку благодаря ограниченному штату;
― простота масштабирования бизнеса.
«То есть, если мы приходим и говорим: «Колега, у нас сейчас нет capacity для того, чтобы удовлетворить ваш запрос через загрузку другими проектами», то в NoOps-домене могут сказать: «Окей, мы сделаем это, если это им нужно», ― иллюстрирует разницу подходов Родион.
Разработчик отмечает, что использование golden workflows в платформе продолжается просто до момента, когда становится нужной кастомная конфигурация. «На этом этапе нужно углубляться в то, какие компоненты, как и как развернуты и сконфигурированы. На нашем объеме это может быть затруднено даже с документацией и воркшопами от платформы. Потому уровень экспертизы разработчиков со временем растет, а с ним растет и автономность разработчиков», — добавляет Сабодаш.
Он отмечает, что профиль platform engineer должен включать soft skills как обязательные, потому что без них получится некая «fancy platform without customers».
Родион приводит пример: «Хотя мы и разделяем failure domain у нас были большие инциденты где платформа удаляла все github runners, или с утра dev среда оказалась без RDS баз. И, строя, подобные платформы, подобного можно минимизировать, но не избежать».
Также он отмечает, что Backlog платформы должен отображать customer needs. «Если это не так, то у вас платформа оторвана от реальности», — объясняет айтишник.
Гора новых вызовов
Планы у команд, которыми руководит Родион, очень амбициозные. «У нас есть план до середины следующего года. У нас есть проблемы, которые нужно решать», ― признается руководитель Infrastructure platform в Райфайзен Банке. Он признается. что высокая загруженность и интересные задачи помогают держать голову в порядке, несмотря на то, что вокруг война.
«Когда общаюсь с этой командой, мне говорят: „Родион, если бы у нас не было такой кучи работы, было бы сложнее“. Потому что когда ты не занят, ты читаешь новости, ты смотришь на измену, у тебя прилеты всегда какие-то. А так ты всегда в проблемах платформы. Да, работа помогает держать менталку в порядке», ― говорит он.
Команда, несмотря на периодические сложности, обстрелы, перебои со светом, продолжает работать над автоматизацией процесса разработки в банке, чтобы клиент всегда мог получать качественный, безопасный и удобный сервис.
«Я не хочу работать над чем-то, что мне не нужно. Именно поэтому я искал и нашел себе челлендж. Райф мне его дал полтора года назад и продолжает драйвить меня специалистом сейчас», ― рассказал dev.ua Родион.
Он отмечает, что у платформы, у NoOps, у InnerSource нет конца. Ты не можешь сказать: я построил и это работает. Да, это работает. Но потенциал для улучшения здесь колоссальный. У тебя всегда есть потенциал для инновации, у тебя всегда есть потенциал для упрощения», — говорит айтишник.
Чтобы лучше понимать запросы и боли коллег, айтишники из команды, разрабатывающие платформу, периодически меняют профессию — отключают свои доступы и идут в подразделения, где люди должны пользоваться созданными ими решениями. «Люди там работают и замечают не очень комфортное, какие-то баги, сложности, которые впоследствии мы исправляем», ― говорит Родион.
