Skip to content
imarch.dev
Назад в блог
· 7 мин чтения

FinOps на практике. Как перестать сжигать деньги в облаке

DevOps облако FinOps архитектура инструменты

Вы не поверите, сколько денег прямо сейчас утекает в ваш облачный счёт за ресурсы, которыми никто не пользуется.

Я поднимаю инфраструктуру стартапа. До этого более 18 лет по энтерпрайз площадкам по всему Казахстану, где каждый тенге на счету. И вот парадокс: в корпорации с её бюрократией финансовый контроль жёсткий, а в облаке полная вольница. Разработчик пишет terraform, деплоит, забывает. Billing приходит в конце месяца. Все удивляются.

Это не проблема денег. Это проблема видимости и культуры.

Облачные расходы утекают незаметно

Почему деньги утекают незаметно

Вот реальный кейс. Adobe. Один Pull Request с временным масштабированием для нагрузочного тестирования обошёлся в $12,000 за три недели. Не взлом, не баг в коде. Просто PR завис, никто не смотрел на расходы, счётчик крутился.

По данным SquareOps за 2026 год, организации тратят впустую 20–35% облачного бюджета. Средняя утилизация CPU составляет 15–30%. То есть вы платите за сервер, который три четверти времени просто стоит и дышит.

Откуда берётся этот мусор:

  • Сироты, то есть снапшоты, диски, балансировщики, которые давно не нужны, но никто не удалил
  • Dev-окружения 24/7, когда кластер крутится ночью и в выходные, пока разработчики спят
  • Завышенные resource requests в Kubernetes, где просят 4 CPU, а используют 0.3
  • Плохой bin packing, когда поды не упаковываются и ноды полупустые

Дашборды в этом не помогают. Дашборд показывает что уже случилось. $12K уже потрачены, PR уже смержен (или нет), но вы об этом узнаёте через три недели когда приходит счёт.

Нужен другой подход.

6 паттернов, которые реально работают

1. Tagging как основа всего, без исключений

Если ресурс не размечен, он невидим. Невидимые ресурсы никто не оптимизирует.

Минимальный набор тегов на каждый ресурс:

team: backend
service: payments-api
environment: production
owner: ilyas@company.com

По моему опыту, самая частая проблема в том, что размечать начали сегодня, а половина ресурсов создана год назад без тегов. Не пытайтесь сделать всё сразу. Работает итеративный подход:

  1. Поднял дашборд по стоимости
  2. Нашёл неразмеченные ресурсы
  3. Разметил
  4. Повторил на следующей неделе

Нудно, но это фундамент. Без тегов вы не знаете, чья команда сжигает деньги.

2. Cost-as-Code, то есть стоимость в code review

Вернёмся к Adobe. Проблема не в том, что кто-то был жадным или тупым. Проблема в том, что стоимость изменений не была видна в момент принятия решения. Написал terraform, открыл PR, reviewer смотрит на логику кода, и никто не смотрит на то, что это обойдётся в $4,000 в месяц.

Решение Infracost. Интегрируется в CI/CD, показывает дельту стоимости прямо в комментарии к PR.

Выглядит примерно так:

💰 Estimated monthly cost change: +$3,847/mo

+ aws_instance.load_test  r5.4xlarge  +$876/mo
+ aws_rds.replica         db.r5.2xl   +$2,971/mo

Теперь reviewer видит это до того, как смёржил. Это не блокировка, а сигнал. Легитимные дорогие решения всё равно пройдут, просто осознанно.

На мой взгляд, это самое высокое соотношение усилий к результату из всего что я внедрял. Настраивается за день, работает постоянно.

3. Автоматическое удаление мусора

Вручную это не работает. Люди забывают, стесняются удалять “чужое”, откладывают.

cloud-nuke (от Gruntwork) это инструмент для автоматической очистки AWS-ресурсов по возрасту и тегам. Запускаете по расписанию в dev/staging окружениях, он удаляет всё старше N дней если нет тега do-not-delete: true.

Простейший сценарий для начала:

# Удалить все ресурсы в dev старше 7 дней
cloud-nuke aws --region eu-west-1 \
  --environment dev \
  --older-than 168h

По моему опыту в стартапе, dev-окружения это главный источник мусора. Кто-то тестировал, создал RDS, Redis, три EC2, забыл. Всё это крутится.

Отдельно про снапшоты и диски. Зайдите прямо сейчас в AWS Console → EC2 → Snapshots. Отсортируйте по дате создания. Готов поспорить, найдёте снапшоты двухлетней давности от инстансов которых уже нет.

4. Rightsizing, или платить за то, что реально используете

CPU утилизация 15–30% в среднем по рынку. Это значит, что большинство инстансов можно уменьшить вдвое без заметного эффекта на производительность.

Как найти кандидатов:

  • AWS Compute Optimizer бесплатный, показывает рекомендации по типам инстансов прямо в консоли
  • AWS Cost Explorer → Rightsizing Recommendations тоже бесплатно, с конкретными числами

Алгоритм простой:

  1. Берёте список рекомендаций
  2. Смотрите на метрики за последние 2 недели
  3. Если CPU < 20% и памяти хватает, уменьшаете тип инстанса
  4. Наблюдаете неделю

По моему опыту, инженеры боятся даунсайзить production. Это нормально. Начните со staging, там риск нулевой, а данные реальные.

5. Kubernetes: resource limits и bin packing

K8s это отдельная боль. Разработчики ставят requests: cpu: 2 потому что “на всякий случай”. Планировщик резервирует ноду под эти запросы, реально используется 10% от запрошенного. Нода полупустая, но считается занятой.

Что делать:

Kubecost или OpenCost (open-source версия) показывают стоимость в разрезе namespace, deployment, даже отдельного пода. Сразу видно, кто переплачивает.

Минимальные практики:

resources:
  requests:
    cpu: "100m"      # реальное потребление, не "на всякий случай"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Плюс отключайте dev-кластеры на ночь и выходные. Если кластер нужен только с 9 до 18 в будни, это уже минус 128 часов из 168 в неделю. Экономия 75% на dev.

6. On-demand vs provisioned: думайте при проектировании

Это про культуру, но с конкретным примером. Взять тот же DynamoDB. Если выбрать on-demand режим, вы платите за реальные запросы. Provisioned capacity означает, что вы платите за зарезервированную ёмкость, используете или нет.

Для MVP и непредсказуемой нагрузки лучше on-demand. Для стабильной высокой нагрузки provisioned дешевле.

Или другой пример: запускаете ML-модель. Используете GPU-инстанс потому что “ML = GPU”. А модель это простая классификация, которая отлично работает на CPU. GPU-инстанс в 5–10 раз дороже.

Инженер должен задавать себе вопрос о стоимости в момент проектирования, а не когда счёт уже пришёл.

Инструменты: что использовать

ИнструментДля чегоЦена
InfracostСтоимость изменений в PR/CIБесплатно (open-source)
AWS Cost ExplorerАнализ расходов, rightsizingБесплатно
AWS Compute OptimizerРекомендации по инстансамБесплатно
OpenCostСтоимость в K8s по namespace/podБесплатно (open-source)
KubecostТо же + удобный UI + alertingFreemium
cloud-nukeАвтоудаление ресурсов в dev/stagingБесплатно (open-source)

На мой взгляд, для начала достаточно Cost Explorer + Infracost + cloud-nuke. Это ноль денег и один день настройки.

Как начать за один день: чеклист

Не надо внедрять всё сразу. Вот минимум который можно сделать сегодня:

Утро (2–3 часа):

  • Открыть AWS Cost Explorer, посмотреть топ-5 сервисов по стоимости за последний месяц
  • Включить Rightsizing Recommendations, выписать кандидатов
  • Зайти в EC2 → Snapshots, найти снапшоты старше 6 месяцев

День (3–4 часа):

  • Установить Infracost, интегрировать в один репозиторий с terraform
  • Договориться с командой: в PR с инфраструктурой смотрим на стоимость
  • Установить минимальный набор тегов для новых ресурсов (team, environment, owner)

Вечер (1–2 часа):

  • Найти dev/staging ресурсы без тега environment
  • Составить список того что можно выключить на ночь/выходные
  • Поставить cloud-nuke на dev-окружение с периодом 7 дней

Структурированная оптимизация даёт 15–25% экономии за первые 60 дней, по данным SquareOps. Это не магия, а просто последовательная работа.

Почему это не задача финансов

Финансовый отдел видит счёт. Инженер видит причину.

Финансы не знают, что конкретный EKS-кластер можно уменьшить с 10 нод до 6 без последствий. Они не знают, что вот этот снапшот остался от инстанса, который снесли год назад. Они не могут оценить, стоит ли платить за reserved instances или лучше on-demand.

FinOps работает только если инженеры владеют стоимостью своих решений. Это четыре компонента которые описывает Ноам Леви из ActiveFence: видимость, короткий цикл обратной связи, оптимизация использования и, самое важное, мышление с учётом стоимости.

Последнее не приходит само. Его надо встроить в процессы: cost-as-code в PR, дашборды по командам, регулярный ревью расходов на планёрке.

По моему опыту, когда разработчик видит что его PR добавляет $2,000 в месяц к счёту, он начинает думать иначе. Не из страха. Просто потому что информация стала видимой.

Облако это не магия и не бесплатно. Это счётчик, который крутится 24/7. Ваша задача знать, что он считает.

Начните с малого. Поставьте Infracost сегодня. Посмотрите Cost Explorer. Найдите один мусорный снапшот и удалите его.

Это уже лучше чем ничего.


Читайте также

Поделиться:

Похожие статьи