Безперечно, ви задавалися питанням, скільки коштує інфраструктура вашого проекту. При цьому дивно: зростання витрат не лінійне щодо навантажень. Багато власників бізнесу, СТО та розробники прихильно розуміють, що переплачують. Але за що саме?
Зазвичай скорочення витрат зводиться просто до пошуку найдешевшого рішення, тарифу AWS або, якщо ми говоримо про фізичні стійки, оптимізацію конфігурації обладнання. Мало того: фактично, цим займається будь-хто, як бог на душу покладе: якщо ми говоримо про стартап, то це, ймовірно, провідний девелопер, у якого вистачає голівняків. У конторах більш цим займається CMO/CTO, часом у питання влазить сам генеральний директор на пару з головбухом. Загалом ті люди, у яких і «профільних» турбот вистачає. І виходить, що рахунки за інфраструктуру зростають, але розбираються з цим... ті, хто не має часу з цим розбиратися.
Якщо в офіс треба купити туалетний папір, то цим займеться завгосп або відповідальна людина з клінінгової компанії. Якщо мова про розробку – ліди та CTO. Продажі теж все зрозуміло. Але ще з бородатих часів, коли «серверною» називали шафу, в якій стояла звичайна tower-системка з трохи великою кількістю оперативної пам'яті та парою хардів у рейді, всі (або, як мінімум, багато) ігнорують той факт, що закупівлями потужностей має займатися теж спеціально навчена людина.
На жаль, історична пам'ять і досвід говорять про те, що це завдання десятиліттями перекладалося на людей «випадкових»: хто був ближчим, той і підхопив питання. І лише недавно на ринку стала оформлятися і приймати деякі конкретні контури професія FinOps. Це та сама спеціально навчена людина, чиє завдання полягає у контролі за купівлею та використанням потужностей. І, зрештою, у зниженні витрат компанії з цього напряму.
Ми не агітуємо відмовитися від дорогих та ефективних рішень: кожен бізнес має сам вирішувати, що йому потрібно для комфортного існування у плані заліза та хмарних тарифів. Але не можна не звернути увагу на той факт, що бездумна закупівля «за списком» без подальшого контролю та аналізу використання для багатьох компаній у результаті виливається в дуже солідні збитки через неефективне управління «активами» свого бекенда.
Хто такий FinOps
Допустимо, у вас солідне підприємство, про яке продажники з придихом говорять «ентерпрайз». Ймовірно, "за списком" ви прикупили десяток-другий серверів, AWS і ще дещо "по дрібниці". Що логічно: у великій компанії постійно відбувається якийсь рух — одні команди ростуть, інші розпадаються, треті переводять на сусідні проекти. І ось поєднання цих рухів у сукупності з механізмом закупівель "за списком" у результаті призводять до нового сивого волосся при перегляді чергового щомісячного рахунку за інфраструктуру.
То що робити — терпляче сивіти далі, зафарбовувати чи розібратися у причинах появи цих численних жахливих нулів у платіжці?
Що гріха таїти: узгодження, схвалення та безпосередньо оплата заявки всередині компанії на той же тариф AWS — справа не завжди (насправді майже ніколи) швидка. І саме через постійний корпоративний рух частина цих самих придбань може десь «загубитися». І банально простоювати. Якщо безхазяйну стійку у своїй серверній уважний адмін помітить, то у випадку з хмарними тарифами все набагато сумніше. Вони можуть стояти на приколі місяцями — оплачені, але водночас уже нікому не потрібні у відділі, під який купувалися. При цьому колеги з сусіднього кабінету своє волосся, що поки не посивіло, не тільки на голові, але і в інших місцях починають рвати — їм уже енний тиждень не можуть сплатити приблизно такий же тариф AWS, потрібний позаріз.
Яке найочевидніше рішення? Правильно, передати кермо нужденним, і всі задоволені. Та тільки горизонтальні комунікації не завжди добре налагоджені. І другий відділ може просто не знати про багатство першого, якому це багатство якось і не особливо потрібним виявилося.
Хто у цьому винен? — Загалом сказати, ніхто. Так поки що все влаштовано.
Хто від цього страждає? - Все, вся компанія.
Хто може виправити ситуацію? - Так-так, FinOps.
FinOps — не просто прошарок між розробниками та необхідним їм обладнанням, а людина чи команда, які знатимуть, де, що й наскільки добре «лежать» у плані тих самих хмарних тарифів, куплених компанією. Фактично ці люди повинні працювати в одній упряжці з DevOps, з одного боку, і фінансовим департаментом з іншого, виконуючи роль ефективного посередника і, що найважливіше — аналітика.
Трохи про оптимізацію
Хмари. Порівняно дешево та дуже зручно. Але це рішення перестає бути дешевим, коли кількість серверів стає двоцифровим або трицифровим. До того ж, хмари дають можливість використовувати все більше сервісів, які раніше були недоступні: це і бази даних як сервіс (Amazon AWS, Azure Database), serverless-додатки (AWS Lambda, Azure Functions) та багато інших. Вони всі дуже круті тим, що прості у використанні — купив та поїхав, жодних проблем. Ось тільки чим глибше компанія та її проекти поринають у хмари, тим гірше спить фінансовий директор. І тим швидше сивіє генеральний.
Справа в тому, що рахунки за різні хмарні сервіси завжди вкрай заплутані: вам по одній позиції може прийти тристорінкове розшифрування, за що, куди і як пішли ваші гроші. Це, звичайно, приємно, але розібратися в ній практично нереально. Причому наша думка в цьому питанні далеко не єдина: для того, щоб переводити хмарні рахунки на людську, існують цілі сервіси, наприклад або . Якщо хтось заморочився створенням окремого сервісу для розшифрування рахунків, масштаб проблеми переріс вартість фарби для волосся.
Отже, що в цій ситуації робить FinOps:
- чітко розуміє, коли та в яких обсягах було закуплено хмарні рішення.
- знає, як ці потужності використовуються.
- перерозподіляє їх, залежно від потреб того чи іншого підрозділу.
- не купує «щоб було».
- і в результаті економить ваші гроші.
Відмінний приклад – хмарне зберігання холодної копії БД. Ви, наприклад, архівуєте для того, щоб скоротити обсяги споживаного простору і трафіку при оновленні сховища? Так, здавалося б, ситуація копійчана - в окремому конкретно взятому випадку, але сукупність таких копійчаних ситуацій потім і виливається в непомірні витрати на хмарні послуги.
Або інша ситуація: у вас куплені про запас потужності на AWS або Azure, щоб не впасти під піковим навантаженням. Чи можна бути певним, що це оптимальне рішення? Адже якщо ці інстанси простоюють 80%, то просто даруйте гроші Amazon. Тим більше, для таких випадків у тих же AWS і Azure є burstable інстанси — навіщо вам вхолосту сервери, що коптять, якщо можна використовувати інструмент для вирішення проблем якраз пікових навантажень? Або замість інстансів On Premise варто подивитися у бік Reserved - вони обходяться набагато дешевше і на них ще й знижки дають.
До речі, про знижки
Як ми говорили на початку, закупівлями часто займається будь-хто — крайнього знайшли, а далі він якось сам. Найчастіше «крайніми» стають люди і так зайняті, і в результаті ми отримуємо ситуацію, коли людина швидко та кваліфіковано, але повністю самостійно вирішує, що й у яких кількостях купувати.
Адже при взаємодії з продажником з боку хмарного сервісу можна отримати вигідніші умови, якщо йдеться про оптову закупівлю потужностей. Зрозуміло, що отримати такі знижки у машини при мовчазному та односторонньому оформленні не вийде — але поспілкувавшись із реальним менеджером з продажу, може й вигоріти. Або ці хлопці можуть підказати, на що в них зараз знижки. Теж буває корисно.
При цьому потрібно пам'ятати, що на AWS або Azure світло клином не зійшлося. Звісно, не йдеться про організацію власної серверної — але й альтернативи цим двом класичним рішенням від гігантів є.
Наприклад, Google підвіз для компаній платформу Firebase, на якій можна «під ключ» розмістити той самий мобільний проект, який може вимагати швидкого масштабування. Сховища, реалтайм БД, хостинг та хмарна синхронізація даних на прикладі цього рішення доступні в одному місці.
З іншого боку, якщо ми говоримо не про монолітний проект, а про їхню сукупність, то централізоване рішення не завжди вигідне. Якщо проект довгоживучий, має свою історію розробки та відповідну кількість необхідних для зберігання даних, варто подумати про більш фрагментарне розміщення.
При оптимізації витрат на хмарні сервіси ви раптово можете усвідомити, що для критично важливих для бізнесу додатків можна придбати і потужніші тарифи, які забезпечать компанії безперебійний заробіток. При цьому «спадщину» розробки, старі архіви, БД та інше зберігати в дорогих хмарах — таке собі рішення. Адже для подібних даних цілком підійде і стандартний дата-центр із звичайними HDD та середньопотужним залізом без будь-яких «примочок».
Тут знову можна подумати, що «ця метушня того не варта», але вся проблематика даної публікації ґрунтується на тому, що на різних етапах відповідальні люди забивають на дрібниці і роблять так, як зручніше та швидше. Що, зрештою, через кілька років виливається в ті самі хорор-рахунки.
Що в підсумку?
Взагалі хмари – це круто, вони вирішують купу проблем для бізнесу будь-якого розміру. Проте новизна цього явища призводить до того, що ми все ще немає культури споживання та управління. FinOps – це організаційний важіль, який допомагає ефективніше користуватися хмарними потужностями. Головне — не перетворювати цю посаду на аналог розстрільної бригади, чиїм завданням зловитиме неуважних розробників за руку і «отруяти» за простої потужностей.
Розробники мають розробляти, а не рахувати гроші компанії. І ось FinOps повинні зробити як процес купівлі, так і процес списання або передачі хмарних потужностей іншим командам простим і приємним заходом для всіх сторін.
Джерело: habr.com