Azure та DevOps краще разом! Частина 2. Практична сторона FinOps

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

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

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

Хмарна міграція

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

Найпростіший, але часто найдорожчий варіант:

Повторне розміщення (Lift-and-Shift) означає переміщення програм у хмару «як є». У той час, як багато нових проєктів використовують хмарні технології із самого початку, для великомасштабної міграції традиційних систем організації часто вирішують переводити програми такими, як вони є. Очевидно, у більшості випадків такий підхід може лише збільшити ваш рахунок без оптимізації витрат.

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

Повторна купівля передбачає перехід на інший продукт або послугу. Часто ми бачимо викуп у формі переходу на платформу SaaS. Хоча такий проєкт, як перехід на Office 365, може вимагати багато часу, зрештою завдяки ньому формується система, що потребує мінімального додаткового обслуговування.

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

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

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

Практична сторона

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

Ви можете знайти всі сценарії в цьому репозиторії.

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

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

system

Унікальний короткий ідентифікатор Системи, визначений у реєстрі всіх Систем. Приклад:

system: system1

env

Середовище розгортання системного компонента, щоб дозволяє чітко вказати, до якого середовища належить актив. Приклад:

env: dev

env: staging

env: production

region

Цей тег використовується для визначення логічного географічного коду активу. Приклад:

region: europe

region: usa

createdby

Цей тег переважно використовується для тегування ресурсів інфраструктури, що дозволяє визначити джерело розгортання ресурсів інфраструктури. Скажімо, нам потрібно визначити, які ресурси надаються через Terraform Cloud або Flux. Приклад:

CreatedBy: terraform

CreatedBy:Vasil Kovalenko

costowner

Асоційована компанія, яка оплачує послуги, які використовують цю систему / ресурси. Потрібна для аналізу фінансів. Приклад:

costowner: TeamC

costowner: TeamA

costowner: TeamB

Налаштування вилучення даних

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

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

Після експорту ви отримаєте файл CSV з тегами та власниками. Файл можна легко відкрити в Excel або використати для створення звіту Power BI. У звіті візуально відобразяться ресурси та власники, які становлять найбільші витрати.

У третій частині цієї серії статей ми плануємо пояснити, як створити звіт Power BI з автоматичним оновленням, надавши вам практичну статистику.

Інструменти для роботи з ресурсами

Безумовно, мати звіти — цінно. Вони допомагають зрозуміти, хто за які ресурси відповідає та скільки з ними пов’язаних витрат. Але який наступний крок? Як ми вже згадували раніше, майже кожен постачальник хмарних послуг пропонує власний набір інструментів для аналізу та оптимізації витрат. Наприклад, Azure надає Azure Advisor, який допомагає визначити потенційні області для економії коштів.

The Azure Advisor аналізує конфігурацію ресурсів і моделі використання, а потім пропонує персоналізовані рекомендації для оптимізації ваших ресурсів і витрат Azure. Ці рекомендації стосуються низки сфер, зокрема:

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

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

Вебінтерфейс

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

Використання вебінтерфейсу порталу Azure:

1. Увійдіть на портал Azure.
2. Перейдіть до «Керування витратами + виставлення рахунків».
3. Виберіть «Рекомендації щодо вартості» або «Порадник Azure».
4. Ознайомтеся з різними категоріями рекомендацій і дотримуйтеся наданих вказівок.

Використання сценарію для рекомендацій через PowerShell. Не забудьте увійти, використовуючи логін az:

az advisor recommendation list --category cost

Такий сценарій використовує Azure CLI (інтерфейс командного рядка), щоб отримати від Azure Advisor рекомендації щодо витрат. Це зручний спосіб автоматизувати процес і отримати рекомендації програмним шляхом.

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

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

Резервування

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

1. Перейдіть до розділу «Рекомендації» або «Порадник Azure» на порталі Azure.
2. Виберіть категорію «Бронювання».
3. Перегляньте рекомендовані бронювання для ваших ресурсів.
4. Придбайте необхідну кількість бронювань.

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

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

Перегляд ресурсів

Які ще поради можна застосувати швидко та ефективно? Насамперед це стосується перегляду ресурсів, як варіант — аналіз використання ресурсів конкретною віртуальною машиною, як у прикладі:

Якщо ви не використовуєте ресурси, то навіщо платити більше?

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

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

Ці дії дуже прості та не вимагатимуть багато часу.

Висновки

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

Ми будемо раді, якщо ви надасте власні приклади хмарної оптимізації Azure.

Дякуємо за те, що ви є частиною спільноти!