«Хмара практично не має обмежень у масштабуванні ресурсів. Але дуже швидко ми зрозуміли, що справжнім дефіцитом є не інфраструктура, а інженерні знання та досвід. Саме їх потрібно було навчитися масштабувати», — говорить Павло Клець, керівник з питань впровадження хмарних рішень Райффайзен Банку.
Читайте также: Спиш, а крипта торгується. Гайд для айтівця по спотових ботах, або Як налаштувати ШІ-помічника і забути про графіки
Landing Zone вирішує не всі проблеми
Як і більшість великих організацій, свою хмарну трансформацію Райффайзен Банк починав із Landing Zone.
Landing Zone забезпечив для кожної команди створення стандартизованих AWS-акаунтів, мережеву архітектуру, централізоване управління доступами, логування та базові механізми безпеки. Цей фундамент став важливою відправною точкою для подальшого розвитку хмарної платформи.
Фактично Landing Zone відповідає на питання «де працювати», але не відповідає на питання «як працювати».
Різні команди по різному організовували свій Terraform-код, використовували різні підходи до IAM, власні naming conventions та стандарти тегування. Частина змін виконувалася через AWS Console або локальні terraform apply. Процес Code Review також відрізнявся між командами.
Коли CloudOps-інженери аналізували інфраструктурний код різних команд, вони часто бачили кілька способів вирішення однієї й тієї самої задачі. Кожне рішення було технічно правильним, але в масштабі організації така різноманітність поступово ускладнювала підтримку, аудит і передачу знань між командами. На рівні окремої команди це виглядало як гнучкість, але на рівні організації така різноманітність поступово створювала операційний ризик.
Від експертів до платформи знань
Важливо, що нинішня модель не є результатом роботи однієї команди.
Вона формувалася роками завдяки внеску архітекторів, фахівців з IT-безпеки, платформенних та продуктових команд, CloudOps-інженерів та великої кількості ентузіастів із різних напрямків банку. Ключовим фактором є те, що сама по собі CloudOps команда може самостійно побудувати, але не може самостійно спроектувати механізм, який враховує потреби всього IT Банку. Цей механізм може стати лише результатом плідної співпраці його користувачів та його розробників.
В результаті утворилась інженерна спільнота, яка поступово накопичувала практики, стандарти та підходи, які згодом стали частиною платформи. У певний момент стало зрозуміло, що масштабувати потрібно не інфраструктуру, а накопичені знання організації. Після цього будь-яка проблема стала проходити шлях: опис → стандартизація → автоматизація.
Саме так набір інструментів, що використовувався поверх Landing Zone поступово перетворився на додатковий операційний шар, який вже уніфікував не лише інфраструктурне середовище, а й спосіб керування ним.
Його метою було створити систему, яка дозволяє сотням інженерів працювати за однаковими правилами, але без постійних звернень до профільних спеціалістів. Все що раніше треба було узгоджувати в переписці тепер стало можливим перевірити в автоматичному режимі.
«Ми намагалися зробити так, щоб правильне рішення було найпростішим рішенням. Якщо інженер змушений пам’ятати десятки локальних правил, значить система ще недостатньо зріла», — пояснює Павло Клець.
Єдина структура: Terragrunt, як Don’t Repeat Yourself фреймворк для Terraform
На масштабі понад 6,5 тисяч Terraform-планів головним викликом стала не розробка нових конфігурацій, а їхня підтримка, повторне використання та керованість. Саме тому Банк перейшов до моделі, де інженери працюють переважно з готовими Terraform-модулями, а Terragrunt використовується як механізм побудови єдиної структури та управління залежностями.
Сьогодні хмарна інфраструктура банку містить понад 1 000 000 рядків конфігурацій хмарних сервісів в AWS та OCI (Oracle Cloud Infrastructure). Для кожного хмарного провайдера був побудований окремий Git-репозиторій з Terragrunt кодом. Це дозволило повністю перейти на Terraform-модулі. Фактично Terraform-модулі перетворилися на внутрішній каталог перевірених інженерних рішень.
Зараз структура цих Terragrunt-репозиторіїв відображає як межі відповідальності команд, так і реальну модель володіння ресурсами. Завдяки цьому інженери можуть швидко знаходити необхідні конфігурації, розуміти контекст змін та визначати відповідальних за будь-який компонент інфраструктури. Фактично такий набір Git-репозиторіїв став операційною точкою правди для всієї хмарної платформи.
Єдиний процес: Atlantis, інструмент, що перетворив складний банківський процес внесення змін на ChatOps
Окрім структури коду, Райффайзен Банк уніфікував і сам процес внесення змін.
Усі інфраструктурні зміни проходять через єдиний процес, побудований навколо Pull Request-ів. Інженер бачить майбутні зміни ще до застосування, автоматично проходить перевірки політик та залучає до рев’ю відповідальних власників ресурсів. Це дозволило зробити контроль частиною звичного процесу розробки, а не окремою бюрократичною процедурою.
Ключовим елементом процесу став Atlantis, який дозволив зробити вищеописаний процес обов’язковою частиною кожного Pull Request.
Для швидкого пошуку власників ресурсів, які будуть залучені до перевірки Pull Request, використовується механізм GitHub Code Owners. Аналогічний підхід також підтримується і GitLab, та інших системах і дозволяє визначати відповідальних за певні директорії з кодом.
Open Policy Agent (OPA) інтегровані в Atlantis Workflows і виконують автоматичний контроль відповідності внутрішнім політикам та вимогам IT-безпеки. Це дозволяє відповідальним за контроль та перевірки командам керувати автоматичними перевірками, швидко додаючі всі нові вимоги в Git-репозиторій з політиками. Тепер усі регуляторні вимоги відображені в коді та версіоновані, що спрощує контроль за їх виконанням.
Ручні зміни через AWS Console звісно теж можливі, але дозволяються лише як виняток під час критичних інцидентів і мають окремий механізм контролю за діями учасників інциденту. Але зміни, які є частиною щоденних робочих процесів, проходять лише через Pull Request-и з Atlantis, який мінімізує можливість людської помилки, навіть при неповному розумінні виконавцем усіх вимог.
За останній рік через платформу пройшло понад 5 400 Pull Request-ів на зміни інфраструктури. Повний цикл зміни — від створення Pull Request до застосування в інфраструктурі — займає 26 хвилин (взято медіану за останній рік). Все це дозволяє зберігати баланс між швидкістю доставки змін та керованістю їх якістю на масштабі сотень інженерів.
Єдине сховище знань: Open Policy Agent та Terraform-модулі
Однією з цілей було зробити так, щоб профільні експерти перестали бути обов’язковими учасниками кожної зміни. Архітектори, фахівці з IT-безпеки та платформні інженери більше не повинні вручну перевіряти кожне рішення. Їхнім завданням стало переносити свої вимоги та підходи в Terraform-модулі та Git-репозиторії з політиками.
Будь-яка вимога, яка регулярно виникала під час рев’ю, консультацій або аудитів, проходила однаковий шлях: опис — стандартизація — автоматизація.
У результаті значна частина вимог до структури інфраструктурного коду, налаштування доступів, криптування та тегування ресурсів сьогодні реалізована безпосередньо в Terraform-модулях та OPA-політиках. Для інженера це означає, що значну частину перевірок він отримує ще до залучення інших команд. Платформа сама сигналізує про відхилення від стандартів і дозволяє виправити більшість проблем ще на етапі Pull Request.
Саме таким чином реалізовані перевірки наповнення VPC Security Groups та IAM Policies. Якщо Terraform-план не суперечить визначеним політикам, перевірка вважається автоматично пройденою і не потребує додаткового залучення профільних спеціалістів.
Якщо ж виявляється конфлікт із політиками або стандартами, відповідні експерти автоматично залучаються до Pull Request через коментарі та можуть оцінити доцільність виключення або надати необхідне погодження. У результаті значна частина процесу відбувається автоматично, але при цьому зберігається той самий рівень контролю та експертного нагляду.
Читайте также: Samsung додасть у смартфони Galaxy ШІ для діагностики домашніх тварин
У результаті знання перестають існувати лише в головах окремих експертів. Вони стають частиною платформи та автоматично масштабуються на сотні інженерів одночасно.
Раніше типова інфраструктурна зміна могла вимагати 3–5 окремих погоджень через Jira та електронну пошту. Сьогодні весь процес зведений до одного Pull Request у GitHub, який автоматично залучає необхідних експертів і виконує більшість перевірок без участі людини.
Це дозволило одночасно підвищити якість інфраструктури, скоротити кількість ручних погоджень та в декілька разів зменшити time-to-market для бізнес-фіч. Виграли від цього і команди Банку, і його клієнти.
Cloud Governance як Developer Experience
У Райффайзен Банку переконані, що на певному масштабі Cloud Governance перестає бути виключно питанням контролю за якістю. Воно стає частиною Developer Experience. Задача не обмежити роботу інженера, а дати комфортні інструменти для самоперевірки. Саме можливість самоперевірки суттєво зменшує кількість запитань, задати які так і не наважились, або не знайшли час. А це і є ключем до якості технічних рішень.
«На масштабі сотень інженерів Cloud Governance тепер стає елементом Developer Experience. Його завдання — не обмежувати інженерів, а зменшувати когнітивне навантаження та допомагати приймати правильні рішення швидко та самостійно. Все це змусило нас створити фреймворк в якому не треба призначати зустріч, щоб бути впевненим, що твоє технічне рішення задовольнить усіх», — говорить Павло Клець.
Водночас Developer Experience не зводиться до впровадження найновіших інструментів або популярних технологій. Справжня цінність з’являється тоді, коли інструменти відображають спосіб роботи організації: її процеси, структуру команд, моделі відповідальності, вимоги інформаційної безпеки та практики управління змінами.
Іншими словами, Платформа повинна адаптуватися до Організації, а не Організація до Платформи.
Саме коли інструменти з яких складається платформа починають відображати реальні процеси компанії, вони прискорюють роботу та допомагають масштабувати накопичений досвід організації. І лише тоді платформа зменшує початкові вимоги до інженера, прискорює його залучення в новий проект та дозволяє сконцентруватися на бізнес-задачах. А передбачуваність якості перестає бути задачею виконавця — вона стає задачею платформи. І це важливо як для команд розробки, так і для команд, що керують інфраструктурою, бо в світі хмарних технологій їх робота вже зовсім не відрізняється від класичної розробки.
У Райффайзен Банку розглядають цей підхід не лише як технічну ініціативу, а як частину загальної IT-стратегії.
За його словами, сучасна платформа повинна не лише надавати доступ до технологій, але й масштабувати найкращі практики організації через інструменти та процеси.
Одним із найкращих індикаторів зрілості платформи в банку вважають швидкість онбордингу, як нових людей, так і нових систем. Новий інженер вже витрачає місяці на вивчення внутрішніх правил та процесів — в 2026 році метрика Time To 1st Pull Request в Райффайзен Банку досягла середнього значення 11 днів і 40 днів для Time to 10th Pull Request. Бо між його змінами в коді і фактичним застосуванням його в хмарі є ціла платформа Cloud Governance, що втілює досвід сотень його колег.
Якщо починати сьогодні
Важливо розуміти, що для більшості організацій не потрібно одразу будувати складну платформу з десятків інструментів. Майже все, що описано в цій статті, починається з доволі простих речей.
Спочатку потрібно домовитися про єдиний спосіб внесення змін. Якщо одна команда працює через Pull Request, друга через AWS Console, а третя через локальний terraform apply, то жодна Cloud Governance модель не працюватиме.
Після цього варто навести лад у структурі Terraform-коду та визначити відповідальних за кожну його частину. Саме це зазвичай дає найбільший ефект на ранніх етапах.
Наступний крок — почати уважно дивитися на зауваження архітекторів, IT-безпеки та платформних команд. Якщо одна й та сама вимога повторюється десятий раз поспіль, це хороший кандидат на автоматизацію. Якщо її можна перевірити автоматично — її не повинна перевіряти людина.
Саме так поступово формується платформа. Не через впровадження модних інструментів, а через перенесення накопиченого досвіду організації в код, Terraform-модулі та автоматичні перевірки. Майже п’ять років розвитку Cloud Governance в Райффайзен Банку привели до простого висновку: масштабувати потрібно не інфраструктуру. Масштабувати потрібно накопичений досвід організації.
Cloud Governance як фундамент для AI
Додатково варто зазначити, що сучасні AI-асистенти найкраще працюють у середовищах, де структура, процеси та правила організації описані кодом. Terraform-модулі, політики Open Policy Agent, стандартизована структура репозиторіїв та процеси внесення змін через Pull Request-и фактично стали формалізованим описом інженерних практик Банку.
Завдяки цьому AI отримує доступ не лише до інфраструктурного коду, а й до накопичених знань організації про безпеку, архітектуру, управління змінами та стандарти розробки. У певному сенсі AI став ще одним інженером, який працює всередині Банку і так само потребує зрозумілого контексту для прийняття правильних рішень.
Саме тому інвестиції в Cloud Governance сьогодні одночасно стають інвестиціями у здатність організації ефективно використовувати AI, адже сучасні мовні моделі можуть масштабувати лише ті знання, які вже були формалізовані та перенесені з голов інженерів у код, політики та автоматизовані процеси.
Резюме
Досвід Райффайзен Банку показує, що на великому масштабі Cloud Governance платформа перестає бути набором технічних обмежень. Вона покращує щоденний досвід інженерів, робить їхню непросту роботу більш комфортною та створює умови для ініціативності.
Мета такої платформи — створити середовище, у якому правильні інженерні рішення приймаються природно, швидко та передбачувано. Саме тоді вона стає механізмом масштабування знань, практик і досвіду всієї організації.
У результаті правильне рішення більше не залежить від того, чи знайшов інженер потрібного експерта, чи пам’ятає він усі локальні правила, або чи має достатньо досвіду саме в цій предметній області. Платформа сама допомагає рухатися правильним шляхом.
І саме тому сьогодні Cloud Governance є не лише елементом управління хмарою, а й одним із фундаментів Developer Experience та використання AI.
Читайте также: ІТ-компанії потрапили до антирейтингу роботодавців, які найбільше приховують зарплати у вакансіях