Azure та DevOps краще разом! Частина 1. Контроль ресурсів і фінансів з FinOps

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Вітаю! З вами Віктор, Cloud Operation Manager, та мій колега Іван, Process Analyst. У цій серії статей ми хотіли б заглибитися в фундаментальну теорію та її практичну реалізацію щодо теми, відомої як FinOps. Ми з Іваном працювали над подібними завданнями в Sitecore Managed Cloud. Тому я вважаю, що наш досвід буде корисний як для новачків, так і для тих, хто вже знайомий із темою.

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

Яка мета FinOps

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

Чому управління витратами має значення

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

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

Відповідно до даних за 2023 рік, наданих державою FinOps, розподіл витрат вважається основною можливістю практики FinOps.

Налаштуйте та ввімкніть FinOps

Отже, коли краще починати впровадження FinOps? Тоді, коли підвищення цінності та прямої маржі шляхом скорочення витрат було надто пізним?

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

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

Краще починати відстежувати та контролювати використання ресурсів, щойно завершиться етап розгортання проєкту, або коли буде виконано масштабування середовища, оскільки це дає змогу раніше встановити зв’язок між групами проєкту та налаштувати конфігурацію ресурсів.

Хто займається FinOps

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

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

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

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

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

Найпоширеніші звіти FinOps для керівників зі звіту про стан FinOps за 2022 рік.

На що впливає FinOps

Основою практики FinOps є розуміння того, як виставляються рахунки за хмарні послуги Project, яка структура ресурсу Project за контрактом і яка початкова мета, яку мав досягти Project (зазвичай основна інформація зберігається в контракті та картах ресурсів середовища).

FinOps постійно відстежує та працює за допомогою власних хмарних інструментів витрат, таких як AWS cost explorer або центр обробки даних Microsoft Azure.

Але іноді проєкти мають кілька джерел споживання хмари, як-от Microsoft Azure і Solr, і в цьому випадку організаціям потрібно використовувати детальні дані про виставлення рахунків і споживання для кожного ресурсу, отримані через API або спеціальні інструменти звітування. Але повну картину споживання можна буде побачити лише після встановлення одночасного розрахунку ресурсу та подачі даних про споживання, яку веде FinOps.

Основний формат і атрибути платіжних даних

Атрибути хмарного платежу також мають тенденцію включати знімок використання протягом певного періоду часу. До рядка використання буде додано таке:

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

Як налаштувати FinOps у вашій організації

Етап 1: планування FinOps в організації

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

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

Плануйте цільові дії та вимагайте штат з відповідними навичками для FinOps.

Ухваліть рішення щодо збору та зберігання даних споживання хмари.

Продумайте інструменти звітності та передачу даних FinOps зацікавленим сторонам.

Етап 2: прийняття FinOps

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

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

Етап 3: експлуатаційний етап

Життєвий цикл FinOps побудований навколо 3-етапної моделі та має однакові принципи в кожному з них.

Основні принципи FinOps:

• перехресні команди повинні співпрацювати;
• рішення ухвалюються на основі цінності хмари для бізнесу;
• кожен бере на себе відповідальність за використання своєї хмари;
• звіти FinOps мають бути доступними та своєчасними;
• централізована команда керує FinOps;
• перевагами хмарної моделі зі змінними витратами потрібно користуватися.

Для підготовки успішної практики FinOps необхідно виконати певні критерії:

1. Підготовувати карту ресурсів або список ресурсів активних проєктів, як це було вказано в контрактах і активних розгорнутих середовищах. (Цього можна досягти в співпраці з відділом продажів і зборі фактичного списку розгорнутих ресурсів за допомогою власних інструментів Microsoft Azure).
2. Відстежувати повні й актуальні дані про споживання від усіх хмарних постачальників.
3. Увімкнути аналіз витрат і прогнозування витрат для активних проєктів.
4. Можливість оцінити розбіжності між договірним (бюджетним) і фактичним рівнем споживання.

Звітування — це єдиний спосіб надати інформацію про розбіжності споживання хмари та надати рекомендації щодо структури ресурсу чи зміни розміру. Критичною передумовою процесу звітності є якість даних, які збираються через API або власні хмарні рішення, про які згадувалося раніше.

Рекомендується розділити процес звітності на кілька рівнів.

1. Макрозвіти із загальними фактичними та бюджетними (контрактними) значеннями споживання.
2. Конкретні звіти про проєкт.
3. Спеціальна звітність.
4. Джерело даних, зібраних в один універсальний файл або джерело з максимальним рівнем деталізації.

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

Наступні важливі критерії успішного FinOps:

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

Звичайно, недостатньо знайти дані. Ви повинні це інтерпретувати. Ваша мета — самоосвіта. Вам потрібно почати розмову зі своїми колегами з фінансів, інженерії та бізнес-сфери (LoB) про те, чого ви хочете досягти.

Ключові моменти звітності FinOps:

• відображення даних про витрати проєкту / бізнесу;
• контрактне використання ресурсів і прогноз споживання;
• ідентифікація ресурсів, які спричиняють фактичні розбіжності в споживанні за договором VS;
• створення системи показників проєкту для порівняння, наскільки різні проєкти працюють з точки зору оптимізації витрат і ресурсів.

Оптимізація проєкту або бізнесу

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

Практик FinOps: Гей, схоже, ви не використовуєте ці ресурси тут. Вони вам потрібні?
Член команди: О, вони ще там? Я забув про них! Я їх зараз видалю.

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

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

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

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

Масштабне скорочення використання потребує культурних змін. Це не одноразове виправлення, а безперервний цикл вибору ресурсів належного розміру та усунення надмірного надання.

Зменшення використання вимагає від інженерів думати про вартість так само, як про пам’ять або пропускну здатність: як про ще один KPI розгортання. І дуже скоро вони побачать, наскільки важливо розглядати вартість як показник ефективності.

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

Додаткова економія можлива на ресурсах правильного розміру, які ви використовуєте послідовно з опціями зниження швидкості.

Зменшення використання шляхом видалення / переміщення

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

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

Навіть якщо вам потрібно зберегти невикористаний обсяг для цієї мети, є способи зменшити суму, яку ви платите. Наприклад, постачальники хмарних послуг пропонують кілька рівнів зберігання, і платити за дані в дорожчих сховищах немає сенсу, якщо ви можете перемістити їх у дешевший ресурс «холодного сховища», як-от Azure Archive або сховище AWS Glacier.

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

Зменшення використання за рахунок зміни розміру (виправлення розміру)

Щоб змінити розмір ресурсу, вам потрібна видимість того, скільки ресурсу використовується. Ця видимість повинна містити використання ЦП, використану пам’ять, пропускну здатність мережі та використання диска.

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

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

FinOps — це співпраця між командами, і фахівець FinOps не повинен виконувати його самостійно. Саме тут розмова має вирішальне значення, оскільки зазвичай неможливо зробити висновок про метод, який використовували команди для визначення розміру своїх ресурсів, просто дивлячись на показники.

Кожна рекомендація щодо правлення — це можливість обговорення з кимось.

Ви повинні повністю розуміти загальні зусилля щодо правового розміру ресурсів, що існують, і переконатися, що нові програми мають правильний розмір із самого початку.

Платити менше за хмарні ресурси

Оптимізація тарифів і оптимізація використання зазвичай починаються з аналізу використання обчислювальної техніки — скільки ми платимо за екземпляри AWS EC2, Google Compute Engine, віртуальні машини Azure, керовані контейнери або безсерверне використання в хмарі. Для цього є дві ключові причини. По-перше, для більшості клієнтів витрати на обчислення є найбільшою окремою категорією витрат, часто безумовно. По-друге, ціноутворення на комп’ютери є однією з найстаріших і найдосконаліших пропозицій від постачальників хмарних послуг, і воно має найбільше можливостей для отримання знижок на основі зобов’язання.

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

Порівняння варіантів резервування в трьох великих постачальників хмарних послуг

На вимогу / Оплата за потреби

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

Де використовуються ресурси

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

Така ціна забезпечує значну економію (до 91% !) порівняно зі ставками за запитом і зазвичай може бути найдешевшим способом використання ресурсів. Однак ризик втрати ресурсу в будь-яку хвилину означає, що служби, що працюють на спотових ресурсах, повинні мати можливість впоратися зі зменшенням доступності ресурсів. Спотові ресурси зазвичай використовуються для пакетної обробки, яку можна відновити чи перезапустити, якщо ви втратите ресурс.

Знижки на основі зобов’язань

Знижки на основі зобов’язань — це хороший загальний термін для таких варіантів знижок, як бронювання, зарезервовані екземпляри, плани заощаджень, гнучкі CUD або знижки на обов’язкове використання. Загалом, ці типи знижок дають змогу взяти на себе довгострокове зобов’язання перед постачальником хмарних послуг за використання певного типу хмарних ресурсів (або витрату певної суми на них), як-от обчислення, бази даних, AI/ML (штучний інтелект / машинне навчання) — протягом певного періоду часу (іноді в певному місці чи з певними параметрами). Натомість постачальник хмарних послуг знижуватиме звичайні тарифи на вимогу для цього встановленого обсягу використання або вартості. Чим конкретніше ваше зобов’язання, чим довше ви зобов’язуєтесь або чим більше ви платите наперед, тим більшою буде ваша знижка в переважній кількості випадків.

Ціни на зберігання

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

Автоматизація управління витратами

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

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

Параметри розгортання інструментів

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

Рідна хмара

Завдяки автоматизації, яка виконується в хмарному обліковому записі, сценарії можуть надаватися постачальником хмарних послуг або ширшою спільнотою. Вони виконуються у хмарному обліковому записі на платформах Function-as-a-Service (наприклад, Azure Function).

Саморобний

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

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

Розміщений на сторонньому вебсайті

Що стосується готових рішень автоматизації, то доступні безкоштовні інструменти з відкритим вихідним кодом, а також варіанти платного ліцензування програмного забезпечення. Завдяки цій моделі розгортання команди використовують програмне забезпечення сторонніх розробників, але запускають його у власному середовищі, самостійно обслуговуючи та керуючи службою. У просторі з відкритим кодом рекомендованим інструментом є програма Cloud Custodian, створена командою Capital One.

SaaS третьої сторони

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

Ви часто сплачуєте щомісячну плату, яку легко порівняти з перевагами самого інструменту. Ця модель справді впливає на безпеку, про що ми поговоримо трохи пізніше.

Що автоматизувати

Управління тегами

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

Запуск / зупинка ресурсу за розкладом

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

Скорочення використання

Автоматизація скорочення усуває такі відходи або принаймні надсилає сповіщення відповідальним співробітникам для кращої оптимізації витрат. Автоматизоване отримання даних про ресурси з таких служб, як Trusted Advisor (для AWS), сторонньої платформи оптимізації витрат або напряму з метрик ресурсів дає вам простий спосіб надсилати сповіщення членам команди, відповідальним за ресурси для дослідження або, у деяких середовищах, дозволяє автоматично зупинити або змінити розмір ресурсів.

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

Залишайтеся з нами, оскільки ми застосовуємо практичний підхід до розуміння того, як FinOps функціонує в екосистемі Azure.

Будь ласка, не соромтеся приєднуватися до нашого каналу телеграм-каналу для обговорення цієї теми або будь-яких інших запитів, пов’язаних із Azure Cloud. А також пишіть у коментарі ваші запитання та думки.