Можно иметь лучшую инфраструктуру в мире. Но если никто не следит за расходами — ты просто эффективно сжигаешь деньги.

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:

  1. Аутентифицируется через System-Assigned Managed Identity — без хранимых креденшалов, без service principal, без секретов в переменных (знакомо?)
  2. Итерирует по каждой подписке
  3. Проверяет, есть ли уже алерт (идемпотентно — безопасно перезапускать)
  4. Создаёт алерт если нет, обновляет если конфигурация дрифтнула
  5. Ставит 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 в масштабе.