Можна мати найкращу інфраструктуру у світі. Але якщо ніхто не стежить за витратами — ти просто ефективно спалюєш гроші.
62 підписки Azure. Різні команди. Різні проєкти. Різні бюджети. І жодного автоматичного алерту на аномалії витрат у жодній з них.
Вдумайтесь. Шістдесят дві підписки з хмарними ресурсами, що працюють 24/7, білються щохвилини — і єдиний спосіб помітити стрибок витрат — це коли приходить місячний рахунок. На той момент збитки вже завдано.
Я бачив це раніше. Забута ВМ, що працює три місяці. Невидалене тестове середовище, що пожирає premium storage. Неправильно налаштований автоскейлер, що вирішив: 3 ночі — ідеальний час запустити 50 інстансів. Все виявлюване. Все запобіжне. Все дороге.
Чому нативні алерти на бюджет не працюють
В Azure є вбудовані бюджетні алерти. Задаєш поріг, отримуєш листа при перевищенні. Просто.
Занадто просто.
Бюджетні алерти реактивні. Кажуть "ти вже витратив $10,000" — не "щось змінилося, і ти збираєшся витратити $10,000." На момент спрацювання бюджетного алерту гроші вже пішли.
Виявлення аномалій витрат — інше. Використовує машинне навчання для встановлення базової лінії витрат, потім алертить при відхиленні від патерну. Не "досяг числа", а "це незвично для твого середовища."
Проблема? Azure cost anomaly alerting не працює на рівні Management Group. Тільки на рівні підписки. Що означає: для 62 підписок потрібно 62 індивідуальних конфігурації алертів.
Ніхто не буде клікати через Azure Portal 62 рази.
Підхід з Automation Runbook
Я автоматизував це. Azure Automation Runbook створює алерти на аномалії витрат по всіх 62 підписках через Cost Management REST API.
Runbook:
- Аутентифікується через System-Assigned Managed Identity — без збережених креденшалів, без service principal, без секретів у змінних (знайомо?)
- Ітерує по кожній підписці
- Перевіряє, чи є вже алерт (ідемпотентно — безпечно перезапускати)
- Створює алерт якщо немає, оновлює якщо конфігурація дрифтнула
- Ставить expiration на 2030 — бо "тимчасові" алерти, що закінчуються і ніхто не продовжує, гірше ніж відсутність алертів
Один запуск runbook. 62 підписки сконфігуровані. Консистентно. Повторювано. Аудитовано.
Чому не Azure Policy?
Я пробував Azure Policy першим. Здавалося логічним — policy-based примус алертів на аномалії витрат по всіх підписках.
Не працює.
Cost anomaly алерти — не ARM-ресурси в традиційному сенсі. Не можна деплоїти через deployIfNotExists ефект Policy. Можна написати audit policy для перевірки наявності (я написав — корисно для дашбордів комплаєнсу), але авто-ремедіація неможлива.
Тому: Policy для аудиту, Runbook для створення. Два інструменти, комплементарні цілі.
Патерн щоденного планування
Runbook запускається щодня. Не тому що алерти треба створювати кожен день — вони персистентні. А тому що:
- Нові підписки отримують алерти автоматично
- Дрифт конфігурації виправляється (хтось видалив алерт? Завтра повернеться)
- Дати expiration продовжуються за потреби
- Аудит-трейл показує безперервний governance, а не одноразове налаштування
Щоденне розклад з Managed Identity означає нуль обслуговування. Жодних ротацій токенів. Жодних прострочених креденшалів о 3 ночі. Жодних "автоматизація зламалась, і місяць ніхто не помітив."
Розмова про FinOps
Ось що більшість інженерів упускає про управління витратами: це не про скорочення витрат. Це про розуміння, на що витрачаєш і чому.
Якщо команда піднімає 10 додаткових ВМ для навантажувального тесту — це очікувані витрати. Видатки зростають, але це свідомо. Тривога не потрібна.
Якщо rogue-процес починає писати 500 ГБ логів у premium storage — це аномальні витрати. Неочікувані. Незаплановані. Саме те, що коштує $3,000 до того, як хтось відкриє Azure Portal.
Виявлення аномалій ловить другий сценарій без хибних спрацювань на перший. Ось різниця між корисним алертингом і шумом.
Що змінилося
До: Щомісячний огляд рахунків. "Чому ця цифра вища?" Пошук винних. Постмортем. Обіцянка "стежити." Ніхто не стежить.
Після: Аномалія виявляється в реальному часі. Правильна команда отримує сповіщення. Розслідування відбувається, поки аномалія ще маленька. Фінансові збитки мінімізовані.
Перша аномалія, яку ми впіймали — тестове середовище, яке забули розібрати після демо спринту. Воно працювало 11 днів. Алерт на аномалію спрацював на 2-й день. Ми впіймали рано. Попередній підхід? Знайшли б на рахунку через 30 днів.
Цифри
- 62 підписки покриті
- 1 runbook керує всіма
- 0 збережених креденшалів (Managed Identity)
- Щоденні автоматичні перевірки комплаєнсу
- 2030 дата expiration (бо "тимчасове" — ніколи не тимчасове)
FinOps — не команда. Це практика. І як будь-яка практика, починається з автоматизації.
Бо ніхто не буде вручну перевіряти 62 рахунки підписок кожен день. А runbook буде. Кожен день. Без скарг.
62 підписки. Один runbook. Нуль сліпих зон.
Ось так виглядає FinOps у масштабі.