Марія БровінськаІсторії
27 листопада 2023, 10:57
2023-11-27
Революція в розробці: як Platform engineering і NoOps зменшують витрати бізнесу та пришвидшують розробку нових продуктів у рази. Досвід Райфу
Айтівці українського офісу Райффайзен банку створили унікальну внутрішню платформу розробки, що дає змогу спростити та прискорити створення нових сервісів компанії, або ж оптимізувати старі. Тепер кожен новий сервіс, продукт чи рішення в Райфі створюється завдяки добре опрацьованим та захищеним алгоритмам дій, шаблонам, що не потребують вартісного та часозатратного написання коду окремо під кожен запит.
Айтівці українського офісу Райффайзен банку створили унікальну внутрішню платформу розробки, що дає змогу спростити та прискорити створення нових сервісів компанії, або ж оптимізувати старі. Тепер кожен новий сервіс, продукт чи рішення в Райфі створюється завдяки добре опрацьованим та захищеним алгоритмам дій, шаблонам, що не потребують вартісного та часозатратного написання коду окремо під кожен запит.
Позиція Райффайзен Банку щодо війни рф в Україні
Райффайзен Банк є одним із найбільших українських банків, який працює в країні вже понад 30 років. Банк є окремою юридичною особою, що діє відповідно до українського законодавства та дотримується всіх встановлених вимог воєнного стану в Україні.
Одразу після повномасштабного вторгнення банк заявив про свою підтримку України та припинив відносини з клієнтами та грошима, що мають російське та білоруське походження. Банк підтримує санкції проти країни-агресора.
Акціонери банку — Райффайзен Банк Інтернаціональ (РБІ) та Європейський банк реконструкції та розвитку — рішуче засудили немотивовану та криваву агресію рф проти суверенітету Української держави. Також на зборах акціонерів РБІ було проголошено позицію щодо поступового виходу з ринку рф. Як зазначається у тексті: «РБІ суворо дотримується всіх вимог чинного законодавства Австрії та ЄС, які визнають територіальну, політичну та економічну цілісність України. РБІ ані самостійно, ані через свої дочірні компанії не веде жодної господарської діяльності на територіях Донецької та Луганської областей, а також півострова Крим».
З перших днів війни Група РБІ надає значну гуманітарну допомогу Україні, яка не обмежується тільки прямим фінансуванням на більш ніж 20 мільйонів євро (майже третина від усіх перерахованих банками України коштів), а включає також всебічну підтримку людям в Україні та українським біженцям за кордоном.
Український Райффайзен Банк самовіддано працює в умовах воєнного часу, забезпечуючи стабільність банківських систем та повне виконання своїх зобов’язань перед законодавством, клієнтами та співробітниками. Багато разів визнаний найнадійнішим банком країни, Райффайзен Банк водночас є й одним із найбільших кредиторів, що надає значне фінансування економіці.
31 березня 2023 року НБУ розмістив на своєму сайті позицію про те, що Райффайзен Банк Україна має підтримку Нацбанку. Згідно з позицією НБУ, Райффайзен Банк в Україні є системно важливим банком, який сприяє підтриманню фінансової стабільності в країні в розпал війни. Участь банку в розвитку банківського сектору, економічних програмах та гуманітарних проєктах відчутна і важлива.
Райф разом з Україною!
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 entries/s, три кластери EKS та 100 нод тільки для Production», ― каже на звичній для айтівців мові Родіон.
Усього нові рішення впроваджують десятки розробників та девопсів. загальний же штат IT-підрозділу райфу ― близько 800 фахівців.
Команда платформи складається з 6 виділених інженерів за 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 actions. Кожен сервіс використовує один з 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. «Якщо це не так, то у вас платформа «відірвана від реальності», — пояснює айтівець.
Гора нових викликів
Плани у команд, якими керує Родіон дуже амбітні. «Ми маємо план до середини наступного року. У нас є проблеми, які потрібно вирішувати», ― зізнається керівник Іnfrastructure platform в Райфайзен Банку. Він зізнається. що висока завантаженість та цікаві задачі допомагають тримати голову в порядку, попри те, що довкола війна.
«Коли спілкуюся з цією командою, мені кажуть: „Родіон, якбиу нас не було такої купи роботи, було б складніше“. Тому що, коли ти не зайнятий, ти читаєш новини, ти дивишся на зраду, в тебе прильоти завжди якісь. А так — ти завжди в проблемах платформи. Так, робота допомагає тримати менталку в порядку», ― каже він.
Команда, попри періодичні складнощі, обстріли, перебої зі світлом продовжує працювати над автоматизацією процесу розробки в банку, щоб клієнт завжди міг отримувати якісний, безпечний та зручний сервіс.
«Я не хочу працювати над чимось, що мені не потрібно. І саме тому я шукав і знайшов собі челендж. Райф мені його дав півтора року тому і продовжує драйвити мене як фахівця зараз», ― розповів dev.ua Родіон.
Він зазначає, що у платформи, у NoOps, у InnerSource немає кінця. «Ти не можеш сказати: я побудував і це працює. Так, це працює. Але потенціал для покращення тут колосальний. У тебе завжди є потенціал для інновації, у тебе завжди є потенціал для спрощення», ― каже айтівець.
Аби краще розуміти запити та болі колег, айтівці з команди, що розробляють платформу, періодично змінюють професію ― вимикають свої доступи і йдуть в підрозділи, де люди мають користуватися створеними ними рішеннями. «Люди там працюють і помічають щось не дуже комфортне, якісь баги, складнощі, які згодом ми виправляємо», ― каже Родіон.
Довідка
АТ «РАЙФФАЙЗЕН БАНК». ВНЕСЕНИЙ ДО ДЕРЖАВНОГО РЕЄСТРУ БАНКІВ 27.03.1992Р. ЗА № 94, ІЗ ЗАПИСОМ ПРО ПРАВО НА ЗДІЙСНЕННЯ БАНКІВСЬКОЇ ДІЯЛЬНОСТІ ЗА № 10. УМОВИ НАДАННЯ ПОСЛУГИ ЗГІДНО З ПРАВИЛАМИ БАНКУ.
