Ваша програма d; Навчання FinOps - Блог Cellenza

програма

У своєму останньому дописі в блозі "Важливість гігієни тегів у підході FinOps" ми почали впроваджувати деякі основоположні принципи FinOps (це, нагадаємо, прийняття рішень на основі бізнес-показників, таких як встановлення цілей, засоби контролю за досягнення цих цілей тощо). Тому ми заклали основи, щоб дозволити нашим споживачам усвідомити своє споживання хмари. Тепер вони можуть вимірювати вплив своїх майбутніх рішень. Зараз саме час перейти до наступного етапу, запропонувавши їм навчальну програму для зменшення рахунків у хмарі.

Гравці у вашій тренувальній програмі

Програма тренувань обов'язково адаптована до нео-спортсмена, який перебуває після обмеження (інвазивний вид спортивних залів у наші дні). Якщо програма занадто напружена з самого початку, вона обов’язково відмовиться в короткостроковій перспективі. Потім спортивний тренер повинен адаптувати програму до кожного, щоб тримати їх мотивованими, з цілями, яких він може досягти. У групі учасників не всі мають однаковий рівень на старті, не однакові цілі і перш за все однакові мотивації (схуднення, підготовка до першого півмарафону тощо). Для FinOps це майже те саме. У компанії є кілька гравців з дуже чіткими цілями:

  • команда DevOps,
  • дует «Бізнес/Власник продукту»,
  • Менеджер,
  • команда фінансів/закупівель.

Давайте разом розкриємо цих чотирьох акторів.

Ролі команди DevOps

Для початку ми можемо представити команду DevOps наступним чином (без карикатури):

  • Надання надійної заявки є її головною метою,
  • Ненавидить технологічну неефективність і хоче бути в курсі технологій,
  • Час безвідмовної роботи - це одиниця виміру,
  • Більше дбає про зменшення технічного боргу, ніж хмарний рахунок.

Ролі команди бізнесу/власника продукту

Для дуету Business/Product Owner ми можемо описати їх ролі таким чином:

  • Відповідальний за доставку товару, що відповідає точним специфікаціям, у постійному пошуку золотого трикутника (якість, вартість, час),
  • Потрібно продемонструвати, що виділені ресурси (бюджет, персонал, хмарний бюджет тощо) використовуються з розумом для обґрунтування цього бюджету,
  • Потрібно продемонструвати, що він узгоджується зі своїми кошторисами бюджету, щоб уникнути необхідності порушувати баланс золотого трикутника.

Ролі керівника проекту

Менеджер має трохи інші міркування, ось вони:

  • Він несе стратегію (Digital Factory, Cloud Center of Excellence тощо),
  • Він повинен довести вартість, отриману в результаті вкладених інвестицій (знаменита рентабельність інвестицій),
  • Він постійно шукає, щоб скоротити час виходу на ринок і продемонструвати цінність своєї стратегії та виміряти отриманий прибуток.

Ролі команди закупівель/фінансів

Нарешті, закупівлі/фінанси трохи більш приземлені і хочуть почути лише про цифри:

  • Мріяти про точний і, перш за все, передбачуваний читабельний рахунок-фактура в Хмарі (ми маємо право мріяти),
  • Хотіли б мати можливість перерахувати все до найближчого євроцента,
  • Хоче якнайшвидше бути поінформованим про ризики бюджетних зсувів.

Ви зрозумієте, кожен актор цієї програми дуже різний зі своїми міркуваннями. Проблема полягає в тому, що їх міркування не завжди узгоджуються з баченням FinOps.

Наприклад, для DevOps його пошук технологічної ефективності не завжди сумісний з пошуком бюджетного дефіциту (sic). Якось це трохи нормально, адже той факт, що ресурси доступні на основі самообслуговування, багато що сприяє. У дохмарну еру нам довелося задовольнятися ресурсами, що надаються "в приміщеннях" (які були обмежені технологіями та нашими інвестиціями). У хмарі DevOps більше не має цих обмежень (отже, оргія споживання, яку ми бачимо на перших рахунках-фактурах). На початку нашої тренувальної програми єдине, що об’єднує наших гравців, - це вимога робити краще з однаковим бюджетом (економічний період після Covid-19 вимагає).

Впровадження стратегії FinOps

Раціоналізація споживання хмарних послуг - це не просто проста схема. Якщо ми обмежимося цим, ми будемо планувати кілька разів на рік (після отримання кожного нового рахунку від нашої CSP). В принципі, це працює, але ми задоволені тим, що реагуємо, коли могли виявити проблему раніше, зокрема, щоб виправити або пом'якшити наслідки для нашого наступного законопроекту.

Всьому цьому можна навчитися, і, на жаль, не за одну ніч. Наш спортивний тренер має ті самі занепокоєння, будуючи свою програму тренувань, тому наш спортсмен після обмеження не може претендувати на короткотерміновий марафон. Ми всі знаємо, що перед тим, як зможете бігти, вам потрібно навчитися ходити, і тим самим налаштуванням стратегії FinOps знадобиться час. Він організований у три основні етапи: Повзати, гуляти, бігати.

Перший крок FinOps: сканування

Введення гігієни тегів було необхідною умовою для початку. Справді, пам’ятайте, що FinOps повинен приймати рішення, базуючись на показниках стосовно створеної вартості бізнесу. У спортивному контексті тренер почне з оцінки витривалості нео-спортсмена після обмеження. Зазвичай його ситуація не є яскравою. У хмарі це те саме. Якщо ми дійшли до цієї ситуації (занадто високий рахунок за хмари), це тому, що ми не змогли споживати з ощадливістю.

FinOps має певну видимість наших витрат завдяки введенню "Тегу гігієни". Як видно на малюнку нижче, при такому низькому рівні тегованих ресурсів буде важко визначити великі бюджетні суми (середовища, центр витрат тощо) і, отже, забезпечити видимість.

Для нашого тренера FinOps це перший крок у навчальній програмі: налаштуйте звітність для різних гравців за допомогою такого інструменту, як Power BI, із «Управлінням витратами Azure Power BI App». Після цього наш тренер FinOps зможе дати свої перші рекомендації: вам потрібно посилити свої теги !

Розрахунок швидкості горіння для контролю відмінностей у споживанні хмар

На цьому етапі ми також повинні навчитися виявляти наші відмінності у споживанні хмар. Тут ми знову можемо провести паралель із нашим спортивним тренером, який попросить своїх нео-спортсменів після обмеження відстежувати їх щоденне споживання калорій, корельоване з їх фізичною активністю (завдяки новому підключеному годиннику). FinOps матиме той самий підхід, але з нашим споживанням хмари та дисперсійним аналізом.

Під час навчання ми повинні розуміти наші споживчі тенденції. У спортивному контексті ми реєструватимемо спалені калорії за точними показниками (кількість підтягувань, віджимань тощо). У контексті FinOps це трохи те саме розрахунок "BurnRate" (буквально як швидко ви спалюєте гроші). Що нас зацікавить - це аналіз варіацій.

На ілюстрації нижче проведено аналіз "BurnRate" порівняно з тим же днем ​​попереднього місяця. Аналіз стовпця "Дрейф витрат" говорить нам, що в цьому обсязі дійсно є дрейф витрат (дана підписка). Цей дрейф може бути виправданим (введенням у виробництво тощо) чи ні. Мета полягає в тому, щоб якомога швидше виявити різницю витрат, щоб зреагувати.

Пошук відходів за допомогою бюджету Azure

Наш пошук ощадливості також передбачає усунення зайвого. У контексті FinOps це пошук "Відходи": витратити частину нашого бюджету на хмарні ресурси, які будуть недостатньо використані або взагалі не використовуватися. Тренер спорту запропонує той самий підхід до своїх нео-спортсменів після утримання, заборонивши зайве з їх раціону (чіпси, печиво тощо). На цьому етапі нашої навчальної програми ми обмежимося виявленням цих ресурсів, оскільки зміна наших звичок вимагає часу, і ми не змінюємо свої програми у виробництві за одну ніч.

Це полювання на зайве пройде технічний аналіз ресурсів із запитанням: чи справді це корисно для моєї програми? Цей аналіз займе час, але буде необхідним, щоб не відтворити ті самі помилки.

Завдяки гарній гігієні етикеток ми отримали видимість витрат, ми починаємо визначати свої піки споживання, щоб якнайшвидше зменшити надлишок, як показано нижче:

В Azure ми маємо бюджети Azure, які дозволять нам виявляти піки споживання. Цікавим у цьому інструменті є його здатність фільтрувати за заданим обсягом (Група управління/Підписка), як показано нижче. Завдяки цьому Azure екстраполює наше споживання за попередні періоди, щоб допомогти нам уточнити поріг споживання, який не повинен бути перевищений.

Є ще більш цікаве: насправді можливо встановити бюджети щодо тегів, які ми ввели. Вони дають змогу відстежувати споживання на рівні відділу, середовища чи навіть програми, коротше будь-який тег, який є навіть трохи репрезентативним з точки зору використання.

Нарешті, ми також можемо відфільтрувати за типом нарахувань у рахунку-фактурі Azure. Існує також два типи навантажень: Використання та ринок. Моніторинг другого дуже важливий для моніторингу покупок ліцензій та передбачення суми рахунку-фактури для цих платежів.

Для нашого спортивного тренера настав час вивести своїх нео-спортсменів після утримання на наступний етап. Вони сподобалися цим зусиллям і починають бачити перші корисні ефекти. Те саме стосується FinOps.

Другий етап програми: Прогулянка

Навчившись повзати на першому кроці навчальної програми, ми навчимося ходити. На попередньому кроці ми вивчили чесноти ощадливості та виявили низку хмарних ресурсів, які мають незначний розмір або навіть непотріб. Наскільки легко обійтися без зайвого (обертання), також складно змінити розмір ресурсів програми, яка вже працює. Для цього нам знадобляться додаткові технічні аналізи, щоб переконатися, що ця зміна розміру не зробить програму непридатною для використання.

Зараз у нашого спортивного тренера є згуртована група, яка бере участь у його тренувальній програмі. Те саме з FinOps. Кожен із залучених гравців знайшов вигоду завдяки досягненню своїх спільних цілей (раціоналізація нашого споживання хмарних ресурсів), виміряних за показниками, якими ділились усі. Зараз саме час докласти зусиль, щоб зменшити наш рахунок. Інструмент, такий як Azure Advisor, цікавий як вихідний пункт. Ми просто повинні ігнорувати обіцянки заощадження. Як FinOps, ми беремо на себе зобов'язання щодо зменшення витрат на певний звітний період. Однак сума, оголошена Azure Advisor, згладжується протягом наступних дванадцяти місяців, незалежно від нашої частоти. Це деталь, але це робить обіцянку економії неточною.

Після раціоналізації споживання наших хмарних ресурсів прийшов час подивитися, як з часом зменшити рахунок. В Azure це поняття взаємодії з механізмами бронювання. Ми просимо корпорацію Майкрософт надати нам вигідну ціну за даний ресурс (тип віртуальної машини, бази даних тощо), натомість ми зобов'язуємося до періоду споживання (один або три роки). Це слід розглядати як договір лізингу автомобілів "à la française", для якого достроковий вихід передбачає штрафні санкції (відомі маленькі рядки договору). Якщо ми не впевнені, що наші ресурси будуть тривати протягом усього часу залучення, очікувана економія буде зменшена. Цими застереженнями слід керувати та правильно пов’язувати їх із ресурсами. Тут знову дуже добре зроблено інформаційну панель PowerBI "Управління витратами Azure Power BI App". Це дає нам рекомендації щодо „розподілу” наших бронювань, щоб якнайкраще їх використовувати в рамках наших підписок.

Тому дуже важливо навчитися добре управляти своїми бронюваннями, перш ніж інвестувати великі кошти, інакше ми виявимо занадто пізно, що вони будуть коштувати нам набагато дорожче, ніж ми думали. Найгірший сценарій - це розуміння того, що нам виставляють рахунок за бронювання ресурсів, не використовуючи їх, і що поряд із ними ми оплачуємо ті самі ресурси в режимі "Оплачуй, як йдеш". Щоб скористатися аналогією з нашим нео-спортсменом після пологів, він платить передплату в тренажерному залі, ніколи не ходить туди, продовжуючи переїдати.

Третій етап програми: Біг

Біг на 5 кілометрів доступний багатьом людям, регулярні 10 км вимагають невеликої практики. Отже, коли ми говоримо про марафон 42 км, це інший світ. Спортсмен буде працювати над своєю витривалістю з так званими "основними" періодами. Для FinOps ми готуємось не до марафону, а до триатлону. FinOps - це не одна дисципліна, а багато.

FinOps - це не лише контроль витрат. Існує кілька дисциплін:

Стратегія

Для успіху вам потрібен план. Визначення цілей та показників, яких слід дотримуватися, залежать від фаз «Сканування» та «Прогулянка». На рівні "Біг" ми зосередимось на вдосконаленні процесу прийняття рішень відповідно до трикутника "вартість, час, якість". Наш вибір мав наслідки, і ми можемо виміряти їх, щоб зрозуміти, як покращити себе.

Управління

За поняттям управління ми зосередимось на моніторингу фінансових цілей. Нам потрібно вдосконалитись у складних вправах побудови бюджетів для наших хмарних архітектур, а також у бюджетних прогнозах.

Збірка

Створити хмарний додаток раціонально з самого початку непросто. Нам доведеться вчитися, іноді за кілька ітерацій (як це не парадоксально, нам доведеться вчитися невдало, щоб навчитися успіху). За ідеєю побудови ми намагатимемося максимально використовувати PaaS або навіть SaaS-послуги на шкоду IaaS. Це спільний підхід, при якому всі учасники зможуть скористатися еталонними архітектурами, які ми використовуємо, та освоїти найкращі. Ми повинні переконатися, що ділимось цими знаннями. Якщо FinOps народився у Хмарному центрі передового досвіду (CCoE) до того, як здобути незалежність, щоб працювати самостійно, дуже важливо, щоб ця культура FinOps була передана CCoE і ділилася в компанії.

Біг

Щодня ми навчились вимірювати ефективність технічної оптимізації на основі суто фінансових показників, що відображають цінність бізнесу для компанії. Ми також навчились аналізувати свої витрати набагато детальніше (завдяки повазі Тегу гігієни). Щоб продовжувати працювати над витривалістю, нам доведеться протистояти іншим командам і таким чином створити спільну культуру FinOps у компанії.

Оптимізація

Ми засвоїли достоїнства "розширення прав", яке зводиться до якомога точнішого вимірювання своїх екземплярів хмарних ресурсів, тому нам все одно доведеться вивчити та краще використовувати модель виставлення рахунків, яка постійно розвивається.

Висновок

У цій статті ви могли помітити, що програма тренувань, запропонована нашим тренером FinOps, схожа на підготовку до Ironman (з багатьма іншими дисциплінами для засвоєння). Беручи участь у FinOps, ви починаєте гонку на довгі дистанції, в якій вам потрібно навчитися управляти своїми зусиллями. Тому потрібно буде попрацювати над своєю витривалістю. Ми можемо отримати значну вигоду за дуже короткий термін (як нагадування, за словами Гартнера, до 35% наших рахунків-фактур у Хмарі - це лише "Відходи"), але ми не повинні зупинятися на досягнутому і розуміти, що це добре культура ощадливості, яку нам доведеться розвивати з часом.

Це буде колективне та постійне навчання. Як і DevOps, FinOps - це спільна бізнес-культура, яку потрібно розвивати. Ваш прогрес протягом навчальної програми дозволить вам змінити своє сприйняття: витрачати гроші не є неминучим, ви просто повинні продемонструвати, що вони добре витрачені і що ви можете раціоналізувати їх використання.

БЮЛЕТИН CELLENZA

Отримуйте найкраще з нашого блогу раз на місяць, не більше того !