Можно иметь лучшую инфраструктуру в мире. Но если никто не следит за расходами — ты просто эффективно сжигаешь деньги.
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 в масштабе.