Марія БровінськаІсторії
30 червня 2023, 12:47
2023-06-30
«FinOps-фахівці в Україні або дуже зайняті, або їх немає». Як заощадити 1,5 млн євро завдяки оптимізації витрат
Під час надшвидкої міграції у хмару минулого року Райффайзен Банк був шокований щомісячним зростанням вартості хмарних ресурсів і це дало поштовх до зародження FinOps-практик і поширення FinOps-культури. Серед різних варіантів впровадження була обрана модель розвитку FinOps культури та підвищення обізнаності ІТ-персоналу та керівників.
Поширення культури відповідального поводження з грошима серед сотень айтішників у банку, що працюють, дало свій ефект і нещодавно український Райф отримав корпоративну нагороду від Raiffeisen Bank International як банк, що зекономив найбільше коштів за останні 12 місяців серед усіх банків групи Raiffeisen. Сума економії склала 1,5 млн євро і це стало можливим завдяки кропіткій щоденній праці всього FinOps Community українського банку.
Як працює спільнота фінопсів, навіщо воно потрібне і який ефект дає, розповів dev.ua очільник нового напряму та ідеолог раціонального використання коштів Богдан Кобзаренко. Він працює в Райфі вже майже 20 років, останні з яких наполегливо дбав про дата-центри фінустанови та дані у них. «Я постійно щось оптимізую ― ресурси, кошти. Це майже стиль життя», ― зізнається Богдан.
Що таке FinOps
Богдан описує роботу FinOps як класифікацію, візуалізацію і оптимізацію IT-частини витрат, а також глибоке розуміння того, скільки коштує кожен з IT-ресурсів. І як результат, розуміння впливу кожного з компонентів на вартість кінцевого продукту чи продуктів компанії.
За словами Богдана, для нього особисто FinOps не став чимось новим, оскільки, відповідаючи за дата-центри й те, що у них всередині, він завжди займався оптимізацією використання ресурсів і витрат на інфраструктуру дата-центрів. «Взагалі FinOps хоч і виникає в момент міграції в хмари, але не обмежується ними. Це культура споживання ІТ-ресурсів в широкому розумінні цього слова. FinOps-практики потрібно запроваджувати не тільки для хмарних рішень», ― пояснює він.
Так, оптимізація витрат на ліцензії, апаратні ресурси, класифікація наземних ресурсів в дата-центрі, на переконання Богдана, теж частина FinOps.
«Але у хмарі набагато складніше це робити», ― каже фахівець. Райфу дуже допомогло те, що певні елементи FinOps впроваджували і вивчали поступово. Також активно консультувалися у фахівців Amazon Web Services (AWS), у хмару якого переносили дані банку.
«Вони нас консультували не тільки з базових рекомендацій, а й з деталей оптимізацій, яких немає у відкритих джерелах або які описані частково. Було дуже приємно відчувати постійну підтримку від представників AWS стосовно оптимізації використання ресурсів», ― наголошує Богдан.
Народження FinOps Community
Розуміння необхідності впровадження FinOps практик прийшло приблизно на 4-й місяць після початку міграції в AWS. СТО банку Григорій Таций запропонував створити внутрішнє Raif FinOps Community, яке об'єднало людей, які хочуть розуміти як аналізувати та як впливати на кости в AWS хмарі.
Наразі в ком’юніті вже приблизно півсотні фахівців, і їхня кількість постійно зростає.
Такий нетривіальний для України крок дав свій результат ― SRE та DevOps Райфу вже враховують кращі світові практики. «Якщо вони створюють ресурс, то не вибирають хаотично тип ресурсу, або спосіб його використання. Вони обирають оптимальний профіль застосування, користуючись певними аргументами», ― каже Кобзаренко.
FinOps у дії
За словами Богдана Кобзаренка, завдяки практикам FinOps, банк уже зекономив приблизно 1,5 млн євро і це тільки в AWS.
«Перш за все, це тегування ресурсів. Була розроблена політика тегування, яка стала обов’язковою для всіх. Налаштували контролі, статистику і візуалізували динаміку тегування. І як результат маємо чітке розуміння для чого використовується кожен ресурс і хто його власник. Як додатковий бонус маємо можливість розуміти вартість хмарної інфраструктури в розрізі банківських продуктів, що суттєво спрощує розрахунок сукупної вартості володіння (TCO) і розуміння собівартості банківських сервісів», ― розповідає фахівець.
Другим кроком, який стартував паралельно з першим, було підвищення обізнаності в FinOps інструментах та підходах. Була описана модель FinOps зрілості, з трьома рівнями та з описом критеріїв оцінки. Були зроблені базові асесменти хмарної інфраструктури і на цій базі проведені коучинг-зустрічі з командами, які дали перший поштовх до оптимізації ресурсів в хмарі.
«На початковому етапі впровадження FinOps ми використовували один з онлайн-сервісів, що надавав рекомендації по оптимізації. Учасники ком’юніті туди заходили досить часто і дивилися на те, що і як вони можуть оптимізувати. І перші результати з’явились завдяки їх рекомендаціям. Та все-таки глибока оптимізація, яка дала відчутні фінансові результати, була досягнута завдяки самописним рішенням, які створювали самостійно, поступово розвиваючи і нарощуючи сфери аналізу», ― розповідає Богдан.
Він каже, що в компанії через масштаби бізнесу та використання різних хмарних продуктів була потреба дивитися глибше, і в результаті фінопс-фахівці створили власні інструменти, якими користуються і нині.
Кобзаренко наголошує: кейсу, де одним кроком Райфу вдалося зекономити мільйони завдяки FinOps, наразі немає. Проте низка маленьких системних оптимізацій призвели до вагомого результату. Зокрема, за словами Богдана, в банку провели ревізію EBS (Elastic Block Store) та оптимізували їхні типи, характеристики та розміри. Також Райф провів ревізію подвійного використання ліцензій, ревізію снапшотів та ревізію AMI, оптимізували мережеві сервіси та об’єми мережевого трафіку, міняли розміри та типи EC2 і RDS, активно використовують Reserved Instances і Saving Plans та багато іншого.
Банк активно використовує MAP програму AWS, що спрощує та робить дешевшим процес міграції з наземних дата-центрів у хмару. Повна назва цієї програми — AWS Migration Acceleration Program і вона дає змогу отримати суттєвий кешбек із вартості ресурсів, що мігровані з наземних дата-центрів.
«Була цікава історія, коли учасник ком’юніті знайшов не обов’язкові витрати на міжзонний трафік у розмірі декількох сотень доларів і поділився своєю знахідкою на FinOps Community. У результаті аналізу по всім нашим акаунтам було знайдено можливостей для економії на міжзонному трафіку на тисячі доларів. Хоча раніше на цей Usage Type не звертали уваги», ― згадує експерт Райфу.
Для тих, хто має велику хмарну інфраструктуру, буде корисним розгорнути CUDOS Dashboard. Він дає можливість дуже детально і в різних розрізах аналізувати AWS витрати.
Приклади ситуацій, коли експертиза FinOps може допомогти прийняти оптимальне для бізнесу рішення:
Один диск типу io2 з 30 000 Iops коштує дорожче, ніж два диски GP3 по 15 000 Iops, а отже FinOps має запропонувати таку архітектуру, яка підтримує шардування.
Ведучи розробку на Java, FinOps з самого початку вибирає архітектуру ARM, яка дешевша, ніж її аналоги Intel або AMD і водночас має більшу ефективність.
Надсилання повідомлень у SNS. FinOps знає, що повідомлення можна відправляти пакетами по 10 штук, що підвищує ефективність інструменту в 10 разів.
FinOps інтегрується в IAC pipeline і показує, скільки коштуватимуть зміни в інфраструктурі ще до їх застосування в тому чи іншому середовищі.
FinOps допомагає стежити за тим, щоб невикористані ресурси миттєво видалялися, такі як невикористовувані томи EBS.
Прогнозування витрат
Дуже зручна річ — це прогнозування вартості на етапі створення ресурсу. При спробі створити ресурс у хмарі AWS у Райфі налаштований автоматичний розрахунок її прогнозованої вартості і вже на етапі створення інженер може прийняти рішення про прийнятність чи неприйнятність вартості ресурсу. Також цей функціонал допомагає уникнути помилки вже на етапі розгортання.
Прогнозування витрат, базуючись на планах зростання чи оптимізації і враховуючи історичні данні, це один з базових обов’язків FinOps спеціалістів.
Чи є FinOps-фахівці на ринку України
Кобзаренко розповідає, що готових фахівців-фінопсів на українському ринку праці майже немає.
Тож якими якостями та навичками має володіти FinOps-спеціаліст та чи може хороший розробник стати FinOps-фахівцем?
FinOps повинен мати хороші аналітичні здібності, гарно розуміти фінансову складову ІТ ресурсів і в першу чергу хмарних, вміти обробляти, структурувати і візуалізувати дані, що отримані з різних джерел. Мати базові навички програмування та формування SQL запитів, що спростить процес обробки даних, також є важливим. І звичайно такий спеціаліст повинен мати гарні комунікативні навички, щоб вміти доносити свою думку до інших і вміти пояснити отримані результати, і за потреби підказати шляхи імплементації.
Так, насправді кожен може стати FinOps, як в принципі і освоїти будь-яку іншу спеціальність. В більшості випадків девопсу, хмарному архітектору чи розробнику варто розуміти базову логіку при прийнятті хмарних інфраструктурних рішень для того, щоб економити вже на етапі проєктування чи впровадження. Розуміння, як зробити дешевше без втрати функціональності продукту, дає змогу економити досить суттєві кошти.
П’ять порад від Богдана Кобзаренка для бізнесу, який планує запровадити в себе FinOps
Не відкладати оптимізацію на потім. Тому що бізнес втрачає кошти кожен день, і тут зволікання можуть стати фатальними.
Почати не з оптимізації ресурсів, а з навчання та розвитку культури FinOps в компанії. Це дасть набагато кращі плоди, ніж найняти одну людину, яка все оптимізує. Ця людина відпрацює, оптимізує, потім піде, і все поступово повернеться в той самий стан, в якому було до цього. Тому розвиток культури, щоб підсвідомо інженер уже ухвалював рішення, правильні з точки зору фінансів, є першочерговим.
Провести чітку класифікацію всіх ресурсів і визначити власника для кожного об'єкта. Важливо, щоб у кожного об'єкта, який коштує більше, ніж $1 на місяць, був власник, людина, яка відповідає за цей ресурс. Тому що, коли відповідальність розмита по кількох функціях або спеціалістах, це не відповідальність. І класифікація і визначення власника — це дуже важливо для хмарних ресурсів. Також вкрай важливо візуалізувати витрати усіх власників ресурсів, щоб усі учасники, хто використовує клауд, чітко бачили, скільки витрачає сусід, і скільки витрачає він.
FinOps-безпека. На кожному акаунті мають бути чіткі ліміти по використанню коштів, і повинні бути налаштовані тригери на спрацювання по кост-аномаліям. Якщо, наприклад, хтось помилився в скрипті при створенні ресурсів, то це може настворювати ресурсів на величезну суму грошей. Від цієї помилки не захищений ніхто. А якщо стоять ліміти, то просто можна це зупинити. Другий кейс — це, наприклад, злом акаунта ― коли це стається, то встановлені ліміти допомагають принаймні зрозуміти, що тебе зламали і почали створювати ресурси.
Орієнтуватися на «низько звисаючі плоди». Не варто закопуватись у щось цікаве по оптимізації ресурсів. Краще брати той напрям, що дасть найбільший результат за найменший час.
Чи є в Україні курси з FinOps? (Особливо цікавить MultiCloud FinOps)