Cloud Cost Vocabulary: FinOps, Unit Economics, and Cost Optimisation Language (англійською)
Майстер хмарних витрат Англійський словник: FinOps chargeback, showback, зарезервовані екземпляри, плани економії, стратегія міток, економіка одиниць і комунікація оптимізації витрат.
Оскільки хмарні витрати стали головним центром бізнес-затрат, словник хмарного фінансового управління — часто називається FinOps — перейшов від фінансових команд до інженерних розмов. Інженери, які розуміють цей словник, можуть брати активну участь у перегляді витрат, приймати кращі архітектурні рішення і повідомляти про компроміси зацікавленим сторонам, які турбуються про рахунок хмари.
Філософський словник
**FinOps (Cloud Financial Operations) ** — практика і культурний рух, який об’єднує фінансові, інженерні та бізнес-команди для спільного управління хмарними витратами. “Ми сформували робочу групу FinOps для перегляду наших щомісячних витрат на AWS і визначення можливостей оптимізації.”
Chargeback — модель, де хмарні витрати розподіляються назад до бізнес-підрозділів або команд, які їх здійснюють, безпосередньо впливаючи на їх бюджети. “З використанням chargeback, команда інженерів даних тепер бачить повну вартість своїх ETL-конвейерів на власному P&L, що значно змінило їхні рішення щодо інфраструктури.”
** Showback ** — схоже на зворотне стягнення, але вартість повідомляється командам для видимості без фактичного стягнення їх бюджету. Перший крок до повної моделі зворотного стягнення. « Ми впроваджуємо показ зворотного стягнення у цьому кварталі, щоб команди могли побачити, скільки вони витрачають, перш ніж ми перейдемо до повного зворотного стягнення наступного року. »
** Стратегія теґування ** — послідовне застосування теґів метаданих до хмарних ресурсів (наприклад, team, environment, project, cost-centre ) для вмикання атрибуції витрат і звітності. “Без послідовної стратегії теґування, 40% наших витрат AWS не можна приписати — ми не можемо сказати, яка команда або проект відповідальний.”
** Зарезервовані екземпляри (RI) ** — зобов’ язання використовувати певний тип хмарного ресурсу протягом 1 або 3 років у обмін на значну знижку (до 72%) у порівнянні з ціною за запитом. « Ми купили зарезервовані екземпляри для базової обчислювальної потужності; ціна за запитом тепер використовується лише для надмірного трафіку. »
** План економії ** — гнучка модель зобов’ язання (AWS, Azure і GCP всі пропонують варіанти), де ви зобов’ язуєтеся витрачати мінімальні кошти за годину в обмін на знижені тарифи, з більшою гнучкістю, ніж у резервованих екземплярах, щодо типу екземпляра і регіону. « Ми перейшли з резервованих екземплярів на план економії обчислень, оскільки він дає нам знижку з гнучкістю змінювати сім’ ї екземплярів за зміною нашої архітектури. »
** Ціна за запитом ** — стандартна модель ціноутворення з оплатою за використання без зобов’ язань, максимальною гнучкістю і найвищою вартістю за одиницю. « Ціна за запитом підходить для непередбачуваних або короткочасних завантажень; використання її для стабільних базових завантажень є непотрібно дорогим »
** Приклади Spot / Preemptible ** — хмарні екземпляри, які пропонуються з різкою знижкою (до 90%) у обмін на згоду на те, що провайдер хмарних послуг може припинити їх надання за короткий термін. « Ми виконуємо наші завдання пакетної обробки даних на примірниках Spot; завантаження є стійкими до помилок, а економія коштів є значною. »
Відходи — хмарні ресурси, які працюють, але не надають цінності, такі як неактивні середовища розробки, надмірно обладнані екземпляри або забуті тестові ресурси. « Наш щомісячний звіт про відходи виявив £12,000 невикористовуваних ресурсів на непродуктивних облікових записах — екземпляри EC2, які залишилися після скасування проекту. »
Словник економічних термінів
Економіка одиниць пов’язує витрати на хмару з результатами бізнесу, роблячи розмови про вартість більш значущими для продукту і фінансових команд.
** Вартість за одиницю ** — вартість хмари, приписана одній бізнес-одиниці цінності, наприклад, вартість на активного користувача, вартість на виклик API або вартість на оброблену транзакцію. « Наша вартість на активного користувача становить £0. 18 на місяць; наша мета на наступний квартал — знизити її нижче £0. 12 за допомогою оптимізації інфраструктури. »
** Ефективність хмари ** — широкий термін для співвідношення бізнес-цінності, що надається до витрат на хмару. Команди стежать за цим, щоб переконатися, що, як бізнес росте, хмарні витрати зростають пропорційно або сублінійно. “Наш коефіцієнт ефективності хмар покращився: прибуток зріс на 40% в останньому кварталі, в той час як хмарні витрати зросли лише на 15% - це історія економіки одиниць, яку ми хочемо розповісти раді”
** Зміна розміру ** — відповідність обсягу ресурсів хмари фактичному використанню, а не надмірне забезпечення для пікового попиту. « Після зміни розміру наших екземплярів RDS на основі фактичного використання процесора і пам’ яті, ми зменшили вартість нашої бази даних на 35%. »
** Неактивні ресурси ** — ресурси хмари, які працюють, але споживають мало або не споживають жодної значущої робочої нагрузки. « Ми знайшли 23 екземпляри EC2 у середовищах розробки і тестування з використанням ЦП нижче 2% — це неактивні ресурси, які ми можемо безпечно припинити або зменшити розмір. »
** Аномалія вартості ** — несподіваний стрибок витрат на хмару, який значно відрізняється від базового рівня. Сучасні інструменти FinOps автоматично виявляють аномалії. « Попередження про аномалію вартості було викликано минулого вівторка, оскільки розробник випадково запустив екземпляр з великою кількістю пам’ яті у виробничому режимі, а не у стадіонарному. »
Приклади слів у контексті
-
«Перед тим, як ми зобов’язуємося до резервованих екземплярів, нам потрібно проаналізувати наші фактичні дані використання за останні шість місяців — купівля резервів для потужності, яку ми не надійно використовуємо, не є економією, це відходи в іншій формі»
-
«Звіт про показ за минулий місяць показує, що команда даних відповідає за 38% наших загальних витрат на хмару; як тільки вони зможуть це чітко побачити, я очікую, що їхні рішення щодо архітектури стануть значно більш обізнаними про витрати»
-
«Наш рівень відповідності теґування в даний час становить 62% — це означає, що ми не можемо приписати більше третини наших витрат команді або проекту. Досягнення 95% відповідності теґування є передумовою для будь-якої значущої програми FinOps. ”
-
«Відсотки за транзакцію зросли непропорційно за останні два місяці — прибуток збільшився на 15 %, але хмарні витрати зросли на 40 %. Ця розбіжність є сигналом того, що щось в нашій економіці є неправильним і потребує дослідження»
-
«Ми виявили £ 8000 на місяць в відходах по бездіяльних інстанціях розробки; тільки правильно розраховані ці ресурси зменшать наш щомісячний рахунок AWS приблизно на 12% без впливу на продуктивність або продуктивність розробників»
На практиці: Навігація нюансів обговорення вартості хмар
Для розробників, які недавно обговорюють хмарні витрати з інженерами з інших команд - особливо з тими, хто розмовляє англійською як другою мовою - важливо розуміти, що термінологія не завжди інтуїтивна. Це не просто про те, щоб знати що щось є; це про те, як ви формулюєте свої питання і зауваження, і як інші можуть оформити свої запити. Просте нерозуміння може призвести до розчарування і, в кінцевому підсумку, неефективних витрат. Розглянемо декілька звичайних сценаріїв.
Уявіть, що ви переглядаєте запит на витягування, який значно збільшує використання екземпляра обчислення. Ви бачите коментар від іншого розробника: « Збільшення розміру екземпляра EC2 для покращення продуктивності — це добре ». Як людина, для якої мова не є рідною, ви можете інстинктивно запитати: « Чому це « добре »? Чи можемо ми кількісно оцінити вплив на вартість?» Термін «штраф» може здатися нечітким. Це не обов’язково образа, але їй бракує точності. Ефективнішим підходом було б обережно дослідити деталі: «Чи можете ви розглянути прибутки від продуктивності і надати деякі дані, що демонструють співвідношення витрат і прибутку? Зокрема, які показники ми моніторимо - використання процесора, використання пам’яті, мережевий вхід/вихід? “Ключеве значення має формулювання вашого питання з точки зору вимірюваного впливу. Аналогічно, коли команда запитує новий зарезервований екземпляр, запитання «Це збереже нам гроші?» без контексту може ввести в оману. Краще сказати: «Давайте проаналізуємо прогнозовану економію коштів за термін порівняно з ціною на запит і розглянемо потенційні зміни в нашій робочій нагрузкі»
Інша часта ситуація виникає під час обговорення зворотного стягнення FinOps. Команда може запитати про розбивку витрат, пов’язаних з певною послугою - “Скільки розробники витратили на AWS минулого місяця?” Це вимагає пояснення. Це не просто про загальний рахунок; це про розуміння * хто * використовував ресурси і * з якою метою *. Вам слід вивчити стратегії мітки, які часто є складними, але важливими для точного розподілу зворотних зобов’ язань. Ясна стратегія теґування є основою будь-якого успішного впровадження FinOps. Без цього, ви просто дивитеся на число - потенційно вводяче в оману.
Нарешті, пам’ятайте, що комунікація навколо оптимізації витрат не просто про презентацію даних; це про створення консенсусу і вирівнювання пріоритетів. Використання фраз на кшталт «Досліджуємо варіанти зменшення наших витрат при збереженні продуктивності» є набагато більш співпрацею, ніж просто заявою «Ми повинні скоротити витрати»
Ось приклад того, як ви можете використовувати консоль AWS CloudWatch для дослідження використання процесора — поширений показник, який використовується в обговореннях щодо оптимізації витрат:
aws cloudwatch get-metric-statistics \
--namespace "AWS/CloudWatch" \
--metric-name "CPUUtilization" \
--dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
--start-time 2024-10-26T00:00:00Z \
--end-time 2024-10-27T00:00:00Z \
--period 3600 # One hour
--statistics Average
За допомогою цієї команди можна отримати середнє використання процесора для певного екземпляра EC2 ( i-0abcdef1234567890 ) за одну годину. Результати можна використовувати для обґрунтування запитів на менші розміри екземплярів або для визначення неефективного коду, який споживає надмірні ресурси. Представлення цих даних - разом з поясненням їх наслідків - набагато переконливіше, ніж просто сказати: “Використання процесора є високим”