Англійська мова для оптимізації витрат на обладнання

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

---

Мова клану — мова клану

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

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

---

Основні напрямки діяльності: фінанси та кредит

• ** Обчислення ** — потужність обробки, яку споживають ваші завдання (віртуальні машини, контейнери, функції)
• ** Виправлення ** — коригування розподілу ресурсів відповідно до фактичного використання, виключення надмірного розподілу
• ** Перевизначено** — було виділено більше ресурсів, ніж насправді потрібно для виконання завдання
• ** Неактивні ресурси ** — обчислювальні, зберігальні або мережеві ресурси, які запущено, але не використовуються
• ** Ціни за запитом ** — оплата за ресурси за стандартною ставкою, без зобов’ язання
• Зарезервовані екземпляри (RI) / Плани економії — попередні зобов’язання до хмарних провайдерів в обмін на значні знижки (зазвичай 30-70%)
• ** Точкові екземпляри ** — запасні обсяги хмарного зберігання, доступні за зниженими цінами, але з можливістю переривання
• ** Хмарні витрати ** — загальна сума витрат на хмарні служби за вказаний період
• ** Економіка одиниць ** — вартість на одиницю бізнес-випуску (наприклад, вартість на транзакцію, вартість на користувача)
• Chargeback — розподіл хмарних витрат назад до команд або продуктів, які їх генерували

---

Основні напрямки діяльності: управління та аналіз

• ** Мітки розподілу витрат ** — мітки метаданих, застосовані до хмарних ресурсів для відстеження витрат за командою, проектом або середовищем
• FinOps — хмарна практика управління фінансами, що поєднує фінанси, операції та інженерію
• ** Попередження про бюджет ** — автоматичне сповіщення, яке буде викликано, якщо витрати наближаться до або перевищать пороговий рівень
• ** Аномалія вартості ** — несподіваний стрибок витрат на хмару, який часто позначається інструментами моніторингу
• ** Showback ** — повідомлення про хмарні витрати командам для обізнаності, без вимоги оплати (в порівнянні з зворотним стягненням)
• **TCO (Total Cost of Ownership) ** — повна вартість роботи системи, включаючи непрямі витрати
• ** Покриття зобов’ язаннями ** — відсоток допустимих витрат, які покриваються зарезервованими екземплярами або планами економії
• ** Марна трата ** — гроші, витрачені на ресурси, які не дають жодної цінності

---

Розглянемо приклади оцінки витрат

Відкриття засідання з перегляду витрат

• “Давайте пройдемося по витратам на хмару цього місяця. Я позначаю основні аномалії, а потім ми можемо обговорити варіанти»
• “Ми на 18% перевищили бюджет цього кварталу. Я хочу вивести на поверхню ключові драйвери і запропонувати деякі швидкі перемоги»
• «Перед тим, як ми поглянемо на цифри, давайте погодимося, що ми оптимізуємо — найнижчу абсолютну вартість, або найкращу вартість на одиницю?»

Ідентифікація проблем

• “Ми маємо значний перевищення в середовищі стажування. Ці екземпляри сидять бездіяльними вночі і на вихідних»
• «Кошти на перенесення даних є несподіванкою — ми платимо за вихід, який ми не враховували в огляді архітектури»
• “Ця аномалія з’явилася 14-го. Ми відслідковували це назад до неправильно налаштованої політики авто-масштабування, яка розширює 40 додаткових екземплярів. ”
• “Наша обіцянка покриття лише 22%. Майже все працює на запит, що є нашим найдорожчим варіантом»

Розробка рішень

• “Найнижче висять плоди тут - правильне розміщення. Швидкий аналіз показує, що ми могли б знизити з m5.xlarge до m5.large на сімох з цих послуг, не впливаючи на продуктивність»
• “Я б рекомендував нам перенести пакетну обробку на місця. Вони допускають помилки, тому переривання не є блокуванням»
• «Якщо ми зобов’язуємося до одногорічного плану економії для цього базового обчислення, ми розглядаємо приблизно 40% економії порівняно з попитом»
• “Позначка правопорядку дасть нам набагато кращу видимість. В даний час, близько 30% наших ресурсів не мають позначок розподілу витрат»

Обговорення компромісів

• «Зобов’язання резервованого екземпляра знижує витрати на 12 місяців, але зменшує нашу гнучкість, якщо змінюються вимоги»
• «Спостерігати екземпляри для цього навантаження є витратною перевагою, але нам потрібно перевірити, що наша логіка повторних спроб грациозно обробляє переривання»
• «Відновлення виробничої бази даних звучить привабливо, але нам потрібно належне тестування навантаження, перш ніж ми торкнемося до неї — профіль ризику відрізняється від безстатевих послуг»

---

Реальні приклади розмов

Сценарій 1: FinOps Monthly Review

** Инженер: ** “Наши затраты на S3 выросли на 35% в этом месяце. Більшість з них знаходиться в аналітичному відсіку — схоже, що ми припинили закінчувати старі об’єкти, коли ми змінили політику життєвого циклу останнього спринту»

“Хороший пойманный. Що це за слово?»

** Инженер: ** “Повторне застосування правила життєвого циклу негайно зупинить зростання. Ми також можемо архівувати об’єкти, які старші за 90 днів, в Glacier, щоб відновити близько $ 600 на місяць. ”

Відділ фінансових операцій: “Давайте зробимо і те, і інше. Чи можете ви вставити квиток і оцінити вплив економії?»

Сценарій 2: Перегляд архітектури з фокусом на вартість

** Архітектор: ** “Пропонований дизайн запускає всі служби на виделених екземплярах EC2. Чи ми подивились на Fargate для менших мікросервісів?»

** Инженер: ** “Ми ще не зробили прямого порівняння. Фаргейт спростив би операції, але мені потрібно було б запустити числа, чи є вартість одиниці краще в нашому масштабі. ”

Архітектор: “Давайте зробимо це умовою перед тим, як завершити проект. Вартість за запит має бути частиною рішення.»

---

Використовується для передачі повідомлень про збитки

При представленні витрат на хмару керівництву, перетворюйте технічні деталі на вплив на бізнес:

• «Наші хмарні витрати на активного користувача зменшилися з $ 2,40 до $ 1,85 в цьому кварталі, на 23% краще»
• «Ініціатива по коректуванню розмірів забезпечила $ 4200 щомісячної економії без зміни якості обслуговування»
• «Ми прогнозуємо, що покриття зобов’язань досягне 60% до Q3, що повинно зменшити наш річний рахунок за хмару приблизно на $ 18,000»
• “Аномалия стоимости была разрешена. Корінь причиною була помилка конфігурації; ми додали попередження про бюджет, щоб вловити подібні події протягом 24 годин. “

---

Розвиток культури

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

Почніть з використання мови витрат природно в повсякденній розмові. Під час розробки можливості запитайте: « Яка вартість цього підходу?» Під час перегляду PR перевірте, чи правильно вказано мітки нових ресурсів. Під час закриття спринту, повідомляти показники вартості разом зі швидкістю.

Словник, який наведено у цьому довіднику, є основою. Практикуюсь в реальних розмовах, і це стане другою природою.

Навигація: навігаційна система з точними даними

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

Однією з ключових областей є вираз критичності. Просто сказати «це занадто дорого» не допоможе. Замість цього, націлюйтеся на структуровані спостереження, пов’язані з конкретними даними. Наприклад, замість «Ця VM коштує занадто багато!», спробуйте: «Тип екземпляра m5.large виглядає значно дорожче, ніж рекомендований m5.xlarge. Засноване на поточних показниках використання, які показують лише 30% використання процесора, зменшення до m5.xlarge може потенційно зменшити щомісячні витрати приблизно на $150 - див. долучені дані моніторингу.” Цей підхід ґрунтується на ваших занепокоєннях у вимірюваних фактах і пропонує конкретне рішення. Аналогічно, коли ви отримуєте зворотній зв’язок під час перегляду коду, наприклад, коментар «Розгляньте оптимізацію цього запиту бази даних», важливо зрозуміти * чому * переглядач запропонував це. Запитання прояснюючих питань, таких як «Чи можете ви розглянути конкретні проблеми з продуктивністю, які ви спостерігали?», Демонструє залученість і дозволяє спільно вирішувати проблеми, а не оборону.

Іншою поширеною проблемою є використання надто сильної мови, особливо при запропонуванні змін. Фрази на кшталт «Вам потрібно це виправити» можуть сприйматися як конфронтаційні. Замість цього, сформулюйте пропозиції як рекомендації: «Я виявив можливість покращити економічність, досліджуючи зарезервовані екземпляри для цього навантаження». Або, у повідомленні Slack, відповідаючи на запитання колеги щодо масштабування, ви можете сказати: «Давайте оцінюємо налаштування автоматичного масштабування, щоб переконатися, що воно відповідає очікуваним піковим вимогам. Після цього ми зможемо переглянути, чи не краще було б використовувати інший тип екземпляра. ” Пам’ ятайте, співпраця є ключовою — формування вашого вводу як спільної спроби сприяє більш позитивній і продуктивній дискусії.

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

# Example: Using AWS CLI to check instance costs
aws ce budget describe-budget --budget-name "monthly_cost_optimization"

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