Infrastructure Cost Reviews in English: FinOps Language for Engineering Teams (англійською)
Англійський словник для перегляду вартості інфраструктури: правильний розмір, зворотне стягнення, прогнозування, відхилення від бюджету, резервована потужність, неактивні ресурси і мова аномалії вартості.
Оскільки вартість хмарної інфраструктури стала першокласною інженерною проблемою, на перетині фінансів і технологій з’явився новий словник — FinOps. Інженерні команди, які раніше були оптимізовані тільки для продуктивності, тепер повинні брати участь у перегляді витрат, пояснювати відхилення бюджету фінансовим зацікавленим сторонам і обґрунтовувати рішення щодо інфраструктури з точки зору ефективності витрат. Для не рідних англомовних носіїв мови, мова управління хмарними витратами поєднує фінансову термінологію з технічними концепціями таким чином, що може бути незнайомим.
Ключовий словник
** Правильный размер ** Процес порівняння розподілу обчислювальних ресурсів (тип екземпляра, пам’ ять, ЦП) з фактичними вимогами до навантаження — вилучення надмірно розподілених обчислювальних ресурсів і уникнення помилок через недостатнє розподіл.
“Наш аналіз правильного розміщення показав, що 40% наших екземплярів EC2 працювали з менш ніж 15% використанням ЦП — ми запланували вправи правильного розміщення на наступне вікно обслуговування.”
Возврат платы Модель, в якій хмарні витрати розподіляються назад командам або бізнес-підрозділам, які їх здійснили, що робить команди фінансово відповідальними за використання їх інфраструктури.
- “З тих пір, як ми ввели зворотний збір, команди почали ставити складніші питання про те, чи вони дійсно потребують цієї додаткової копії.” *
Бюджетна відмінність Різниця між запланованим бюджетом і фактичними витратами — позитивна відхилення означає недоотримання коштів, негативна відхилення означає перевищення витрат.
- “Ми маємо 23% негативну дисперсію за Q2 - фактичні витрати на інфраструктуру перевищили прогноз на £ 41,000, в основному завдяки розширенню даних конвеєра.” *
Зарезервовані обсяги / Зарезервовані екземпляри Зобов’ язання використовувати вказану кількість хмарних ресурсів протягом фіксованого періоду (зазвичай один або три роки) в обмін на значну знижку порівняно з ціною на запит.
“Перетворюючи наші базові обчислення на зарезервовані екземпляри, ми досягли 38% зниження вартості цих навантажень у порівнянні з тарифами на запит.”
** Неактивний ресурс ** Обладнаний ресурс, який споживає кошти, але не надає жодної цінності, наприклад, зупинена віртуальна машина, яка все ще вимагає сплати за зберігання, або не використовується балансувальник навантаження.
“Автоматичне сканування ресурсів бездіяльності знайшло 17 неприєднаних томів EBS і 3 еластичні IP-адреси, які коштують приблизно £800/місяця без пов’язаного навантаження.”
Аномалия стоимости Неочікуваний пік або відхилення у витратах на хмару, що виходять за межі звичайного шаблону — часто це вказує на неправильне налаштування, непередбачуваний процес або незаплановане використання.
- “Попередження про виявлення аномалії вартості було викликано о 14:00 — вартість виходу S3 за ніч зросла втричі. Ми розслідуємо, чи не було неправильно налаштовано завдання пакетного експорту, щоб працювати безперервно.»*
- Нет, нет, нет Подібно до зворотного зобов’язання, але без фінансового переказу - команди можуть бачити вартість, приписану до їх послуг для обізнаності і підзвітності, але бюджет не рухається.
- “Ми починаємо з показу назад перед переходом до повного зворотного звіту - ми хочемо, щоб команди розуміли свій профіль витрат, перш ніж вони будуть фінансово відповідальні за це.” *
Корисні фрази
Представляем обзор затрат:
«Цього місяця витрати на інфраструктуру склали £142,000 — на 8% більше прогнозу. Основним чинником було незаплановане збільшення витрат на перенесення даних з нового аналітичного конвеєра. Я пройду через розрив і три дії, які ми робимо, щоб повернути це в порядок»
** Пояснення відхилення: **
«Негативна відмінність в обчисленні в основному з нового навчання ML середовища, яке ми забезпечили у відповідь на невідкладний запит команди продукту в тиждень два. Це не було в першому бюджеті. Ми рекомендуємо це додати до базисного прогнозу на Q3»
** Рекомендуємо правильне розміщення: **
“Заснований на двох тижнях використання даних, кластер API-шлюзів постійно працює на 12% процесора. Ми рекомендуємо зменшити розмір з m5.2xlarge до m5.large екземплярів — прогнозована економія становить £ 3200 на місяць без впливу на продуктивність.”
** Обґрунтування резервованої потужності: **
“Наша базова обчислювальна нагрузка была стабильной в течение шести месяцев. Перетворення цього базисного рівня на річні зарезервовані екземпляри дозволить заощадити приблизно £ 18 000 за період зобов’язань. Точка рівноваги — чотири місяці — після цього ми на заощадженнях»
Повідомлення про аномалію:
“Я хочу попередити про аномалію вартості, яку ми виявили вчора: вартість NAT-шлюзу в 3 рази перевищує середньомісячну. Попереднє розслідування вказує на те, що неправильно налаштована функція Lambda робить виклики API в петлі. Ми зупинили функцію і проводимо розслідування»
Поширені помилки
Плутаєте “кошт” і “тратити” У мові FinOps, * cost * часто відноситься до окремої ціни або ставки, тоді як * spending * відноситься до фактично витрачених грошей. * « Наша вартість за запит збільшилася » * означає, що ціна за операцію зросла. * « Наші витрати збільшилися » * означає, що загальний рахунок збільшився. Вони можуть мати різні причини і різні рішення — будьте точними.
** Використання « зберегти » без базисного рівня ** Ствердження на кшталт * “це збереже гроші” * надто нечіткі, щоб бути корисними в перегляді витрат. Фінансові та інженерні зацікавлені сторони повинні знати базову лінію, прогнозовану суму і рівень довіри: * “Заснований на поточних тарифах на запит і наших спостережуваних моделях використання, ця зміна передбачає зменшення щомісячних витрат приблизно на 4200 фунтів стерлінгів - приблизно 11% від вартості впливу на навантаження ”. *
Представлення витрат без контексту Звітування * “ми витратили £ 142,000 цього місяця” * без порівняння з прогнозом, тенденцією або еталоном залишає зацікавлених осіб без рамки для оцінки того, чи є ця цифра хорошою чи поганою. Завжди надайте принаймні одну точку відліку: відхилення від прогнозу, порівняння з попереднім місяцем або відсоток від загального бюджету інфраструктури.
Словник FinOps з’єднує інженерію і фінанси - і команди, які вільно говорять, краще розташовані, щоб зробити справу як для інвестицій, так і для ефективності.
Bridging the Gap: FinOps Language for Diverse Teams (англійською)
Основні концепції FinOps - оптимізація хмарних витрат через видимість, підзвітність і стратегічне управління ресурсами - все більш актуальні для всіх інженерних команд. Однак, ефективне спілкування на ці теми вимагає певного словникового запасу, в якому часто домінує англомовна термінологія. Для розробників, які будують свої професійні навички англійської мови, нюанси мови FinOps можуть бути особливо викликом. Це не просто про розуміння * що * сказано; це про розуміння * як * це сказано - тонкі наслідки і очікування, вбудовані в кожну фразу. Цей розділ присвячено підтримці носіїв англійської мови, які не є її рідними носієм, на шляху до розуміння мови, пропонуючи практичні приклади і підкреслюючи ключові області, де ретельне врахування фразування може значно змінити ситуацію.
Однією з поширених перешкод є розуміння різниці між «правильним розміром» і просто «розширенням». У той час як розширення * підвищує * додавання більшої обчислювальної потужності для збільшення попиту, «правильний розмір» має глибші наслідки - що існуючі ресурси оцінюються проти фактичних моделей використання і відповідно оптимізуються. Сказати «Ми повинні масштабувати наші екземпляри EC2» негайно говорить про реактивну відповідь на пік трафіку. Однак, пропонуючи «Давайте правильно розмістимо екземпляри EC2 на основі даних про використання за останні 30 днів», обговорюється проактивна оптимізація і ефективне розподіл ресурсів. Остання більш узгоджена з принципами FinOps. Аналогічно, «зворотне стягнення» не просто про призначення витрат; це представляє зміну відповідальності за рішення про споживання хмар - надання команді змоги розуміти і управляти своїми індивідуальними бюджетами. Важливо уникати надмірно технічного жаргону при поясненні цих концепцій тим, хто менш знайомий з термінологією, вибираючи замість цього ясну, дієву мову, яка зосереджена на результатах, а не тільки на процесах.
Важливим аспектом є також обговорення щодо прогнозування і відхилення бюджету. Команди часто борються за точне передбачення витрат на хмару, що призводить до несподіваних перевиконань бюджету. Замість того, щоб просто сказати «Бюджет був перевищений», більш ефективним підходом було б: «Фактичні витрати значно відхилилися від прогнозованих $ 500 / місяць через збільшення трафіку в години пік. Нам потрібно вдосконалити нашу модель прогнозування і впровадити автоматизовані правила масштабування. “Це демонструє відповідальність, підкреслює кореневу причину і пропонує рішення - все це повідомляється ясною, професійною мовою. Нарешті, пам’ятайте, що активне виявлення “аномалій витрат” (незвичайних піків у використанні) є ключовим; опис цих аномалій вимагає точної термінології - не просто сказати “витрати високі”, але детально описати * що * є незвично високим і * чому *.
# aws ec2 describe-instances --instance-ids i-0abcdef1234567890Ця команда, наприклад, показує деталі конкретного екземпляра EC2, що дозволяє інженерам негайно побачити використання процесора, використання пам’яті і мережевого трафіку - дані, необхідні для обговорення правильного розміру. Зрозуміти такі команди, як ця, забезпечує основу для розуміння складніших розмов FinOps про оптимізацію ресурсів.