Cloud cost anomaly detection

Cloud cost anomaly detection — это pipeline, который закрывает gap между облачным биллингом и оперативной реакцией команды. Cost Explorer и провайдерские дашборды показывают картину только тогда, когда инженер зайдёт и посмотрит. За две-три недели забытый ресурс превращается в счёт на тысячи долларов, а в конце месяца finance-отдел задаёт вопросы, на которые уже поздно отвечать.

Что делает автоматизация

1. Подтягивает данные о расходах из облачного провайдера (AWS Cost and Usage Report, GCP Billing Export, Azure Cost Management) с daily granularity.
2. Разбивает расходы по срезам: сервис, регион, тег, команда, environment — в зависимости от принятой tagging-политики.
3. Строит baseline потребления на исторических данных за 7–30 дней, учитывая сезонность и weekday/weekend паттерны.
4. Детектирует аномалии по каждому срезу через статистическую модель (z-score, IQR или Prophet — выбор зависит от характера данных).
5. Формирует человекочитаемое сообщение вида «EC2 в us-east-1 стоит существенно выше baseline — проверьте autoscaling-группу prod-api».
6. Отправляет алерт в Slack, Microsoft Teams или email ответственному инженеру с прямой ссылкой на соответствующий раздел Cost Explorer.
7. Поддерживает тред для комментариев: кто взял задачу, что оказалось причиной, был ли это реальный рост нагрузки или утечка конфигурации.
8. Сохраняет историю инцидентов для последующего разбора и для тренировки модели на реальных false positive и true positive.

Для SaaS-команд с 5–50 инженерами автоматизация заменяет еженедельный ручной отчёт и роль дежурного FinOps-инженера, который «случайно заметил» аномалию.

Чего автоматизация НЕ делает

• Не блокирует и не отключает ресурсы автоматически. Решение о снижении расходов принимает человек — автоматизация даёт сигнал, а не действие.
• Не заменяет FinOps-стратегию: не ведёт бюджеты, не распределяет расходы между проектами, не прогнозирует годовые траты и не готовит материалы для CFO.
• Не ищет возможности оптимизации (reserved instances, spot, rightsizing) и не выдаёт рекомендации по архитектуре. Это смежная задача для отдельной автоматизации или консалтинга.

Автоматизация построена как ETL-пайплайн с алертингом. У облачных провайдеров нет унифицированного API для real-time расходов, поэтому решение работает по схеме daily batch: биллинг обновляется раз в сутки, и этой частоты достаточно для большинства use case.

Архитектура pipeline

1. Источник данных. AWS Cost and Usage Report выгружается в S3, GCP Billing — в BigQuery, Azure — в Storage Account. Grow2.ai подключается к соответствующему хранилищу через read-only роль.
2. Ingestion. Скрипт (Python или TypeScript) читает свежие строки биллинга, нормализует схему и грузит в промежуточное хранилище — DuckDB, ClickHouse, BigQuery или Postgres, в зависимости от инфраструктуры клиента.
3. Обогащение контекстом. К записям присоединяются данные из observability-стека: метрики нагрузки из Prometheus / Datadog, теги ресурсов из облака, информация о релизах из CI/CD. Это нужно, чтобы алерт содержал не только «выросло», но и «почему выросло».
4. Модель аномалий. Для каждого среза (сервис × регион × тег) строится baseline. Для стабильных сервисов — z-score на rolling window 14–30 дней. Для сервисов с трендом и сезонностью — Prophet или аналог. Порог чувствительности настраивается под команду: процент отклонения к ожидаемому значению плюс минимальный абсолютный прирост, чтобы не спамить мелочью.
5. Генерация нарратива.AI-модель или локальная LLM получает raw-аномалию и контекст и формирует текстовое сообщение. Промпт включает: цифры отклонения, топ-3 причины-кандидата на основе контекста (релиз, autoscaling-событие, новый регион), рекомендуемые next steps.
6. Доставка. Сообщение уходит в Slack-канал команды или по email. Для критичных аномалий — дополнительный PagerDuty или Opsgenie вызов.
7. Feedback loop. В Slack-треде инженер помечает алерт как true positive, false positive или known issue. Метки сохраняются и используются для тюнинга порогов.

Шаги внедрения

1. Discovery (3–5 дней). Grow2.ai проводит audit текущего биллинга, tagging-политики и каналов коммуникации. Результат — список срезов для мониторинга и определение owner'ов.
2. Ingestion setup (2–3 дня). Настраивается экспорт биллинга, создаются read-only креды, разворачивается pipeline загрузки.
3. Baseline и модель (3–4 дня). Обучается модель на исторических данных, подбираются пороги. Первая неделя — shadow mode: алерты идут только инженеру-интегратору.
4. LLM-нарратив и интеграция со Slack (1–2 дня). Настраивается промпт, подключается Slack-бот, тестируются сценарии.
5. Staging и настройка под команду (2–3 дня). Пороги корректируются, канал доставки согласовывается, назначаются ответственные.
6. Handoff (1 день). Документация, runbook, обучение дежурного по автоматизации.

Основные компоненты

Решение — custom-code: готового off-the-shelf продукта, который одинаково работает с разными tagging-политиками и внутренними конвенциями, нет. Код разворачивается в инфраструктуре клиента (Kubernetes, Lambda, Cloud Run — по выбору), данные биллинга не покидают периметр.

Для запуска cloud cost anomaly detection команде нужен базовый уровень зрелости в FinOps и observability. Без этого автоматизация всё равно запустится, но качество алертов будет низким — много ложных срабатываний и мало контекста.

Данные и доступы

• Экспорт биллинга настроен и работает: AWS Cost and Usage Report в S3, GCP Billing Export в BigQuery или Azure Cost Management export. Без исторических данных за 14+ дней модель не построит baseline.
• Read-only доступ к биллинг-хранилищу через IAM-роль или service account.
• Минимальная tagging-политика на ресурсах: хотя бы один тег, разделяющий окружения (prod / staging / dev) и команды или продукты. Без тегов автоматизация работает только на уровне сервисов.
• Доступ к Slack, Microsoft Teams или корпоративной почте для доставки алертов.
• По желанию: выгрузка метрик из Prometheus, Datadog или CloudWatch для обогащения контекстом.

Команда и процессы

• Один DevOps- или SRE-инженер как technical owner автоматизации — отвечает за поддержку и тюнинг порогов.
• Понятно, кто реагирует на алерты: дежурный, конкретный инженер или канал команды.
• Готовность раз в 1–2 недели ревьюить false positive и корректировать модель в первые месяц-два после запуска.

Ориентировочные сроки

Внедрение занимает 2–4 недели в зависимости от качества исходных данных. Если биллинг-экспорт и теги уже настроены — ближе к двум неделям. Если tagging-политику приходится проектировать с нуля — ближе к четырём.