AI FinOps 2026: Главное из отчета FinOps Foundation

К апрелю 2026 года управление затратами на ИИ официально признано приоритетом №1 в ИТ-инфраструктуре.

По данным свежего State of FinOps, 98% компаний уже внедряют контроль ИИ-трат, так как старые методы мониторинга здесь не работают.

Что важно знать:

✈️ Чек за ИИ — это «слоеный пирог»: он суммирует токены, API-вызовы, аренду GPU, векторные базы и трафик. Без внедрения стандарта FOCUS найти источник перерасхода практически невозможно.
✈️ Забытый на час мощный видеопроцессор (GPU) обходится бюджету как неделя работы обычного сервера.
✈️ Главный навык года: умение считать юнит-экономику нейросетей (соотношение стоимости одного ответа к его бизнес-ценности) — теперь компетенция №1 для технических команд.

Что делать:

✈️ Переходить на мониторинг аномалий в реальном времени: всплески нужно ловить в течение часа, а не по итогам месяца
✈️ Внедрять финансовые гардрейлы: согласовывать жесткие лимиты и правила автоматического отключения ресурсов еще до запуска модели в эксплуатацию.

Источник: State of FinOps 2026 by FinOps Foundation

💬 Практики FinOps

А мы продолжаем серию «Как говорить в ИТ сегодня, чтобы вас поняли» 🙂

💬 Практики FinOps | 💬 Практики FinOps

Как digital-агентство сократило расходы на 1.1 млн в год на Kubernetes и СУБД

«Наши расходы на облака растут, хотя нагрузка не увеличивается» — с такой жалобой обратилось digital-агентство, разрабатывающее мобильные приложения

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

Ситуация клиента весьма типичная, 85% компаний не контролируют расходы на Kubernetes. Провайдеры вам этого не скажут, но переплаты за базы данных и хранилища часто превращаются в незаметный налог.

Для контекста ➡️ Компания вдет 15+ мобильных приложений. Вся инфраструктура находится в Kubernetes от Yandex Cloud в связке с Managed MongoDB. При этом ежемесячный счёт достигал 150 тыс. руб., хотя фактическая нагрузка вдвое ниже.

В ходе аудита мы обнаружили три основных источника перерасхода. Во-первых, кластеры завершённых проектов — 3 окружения, простаивавшие без нагрузки (~32 тыс. руб./мес). Во-вторых, MongoDB на «золотом» тарифе, которая работала с 30% загрузкой CPU/RAM. Третьим источником было хранилище для билдов с 8 ТБ старых сборок, которые никто давно не использует.

Чтобы снизить расходы на облачную инфраструктуру, мы предприняли следующие действия:

Шаг 1. Чистка Kubernetes
Здесь мы удалили три неиспользуемых кластера и внедрили автоскейлинг подов, это сократило нагрузку в нерабочие часы на 40%. Плюс настроили расписание выключения dev-окружений на ночь и выходные.

Шаг 2. Оптимизация MongoDB
🔹 Перевели базы данных на меньшие инстансы (снижение затрат с 45 до 28 тыс. руб./мес);
🔹 Включили автомасштабирование для пиковых нагрузок при среднемесячной утилизации 85%;
🔹 Настроили кеширование частых запросов, что снизило нагрузку на CPU.

Шаг 3. Умное хранилище
Последним этапом было упорядочивание хранилища. Перенесли старые билды в Cold Storage, освободив бюджет на 18 тыс. руб./мес. Внедрили автоочистку сборок старше 2 месяцев и настроили логирование проектов — логи старше 30 дней теперь удаляются автоматически.

Эти шаги быстро дали ощутимый результат. Ежемесячная экономия составила 91 тыс. руб. — 60% от изначальных затрат. ROI нашей работы было 11 дней, а значит клиент окупил нас за 2 недели. Ну и приятный бонус, за счет очистки кластеров скорость развертывания новых приложений выросла на 20%.

Случай довольно показательный, когда в проекте используется Kubernetes, несколько окружений, СУБД или хранилища для билдов и логов, есть переплата.

Такие кейсы встречаются всё чаще, потому что кризис требует подсчета каждой копейки и внедрения зрелых практик FinOps.

#кейсы_finops

💬 Практики FinOps | 💬 Практики FinOps

💸Полнота данных (data completeness) в облачном биллинге

Пустые вешалки и порядок в шкафу

Представьте, что вы решили разобрать гардероб. У вас 100 вешалок, но на 30 из них висят только пустые чехлы или бирки. Вы пытаетесь понять, сколько у вас зимних курток, но видите только пустые плечики.

В FinOps это ваш биллинг без тегов. Провайдер выставил счет, но в 30% строк не указано, чьи это ресурсы. Вы открываете дашборд, а там висят неопознанные затраты (unallocated costs).

Почему это важно для аналитики

Метрика полноты данных показывает, насколько ваш биллинг обогащен метаданными. В методологии FinOps Foundation это основа качества данных. Без нее невозможно сделать корректную аллокацию (распределение) затрат по бизнес-юнитам. Если данные неполные, вы видите общую сумму, но не видите структуры и не можете определить ответственного за рост расходов.

Как оценить точность отчетов
Для оценки используется базовый показатель качества данных:

Количество строк с тегами / Общее количество строк в биллинге = DQ Score

🫥Результат 1 (100%): Идеальный порядок. Каждый цент в облаке привязан к конкретному владельцу или проекту.

🫥 Результат менее 0.7 (70%): Данные недостаточно детальны. Отчетам нельзя доверять на 100%, необходимо внедрение обязательной политики тегирования (tagging policy).

Практический подход
Порядок в тегах — это не бюрократия, а единственный способ сделать облако прозрачным. Если вы видите неопознанные ресурсы, вы не можете управлять их эффективностью.

Начинать исправление ситуации стоит с самых дорогих сервисов. Если у вас достигнуто полное тегирование на 80% самых затратных ресурсов, это уже победа.

Даже если мелкие вспомогательные ресурсы остались «пустыми вешалками», общая финансовая картина будет достоверной для принятия бизнес-решений.

💬 Практики FinOps | 💬 Практики FinOps

Новая прикладная FinOps-статья на Хабр от Flowwow

Екатерина Чичкова и Марина Андреева расписали, как помочь инженерам контролировать косты без боли и бюрократии.

Главный инсайт: ежедневный алертинг и жесткая аллокация ресурсов. Без понятного владельца у сервиса любой сигнал превращается в фоновый шум, поэтому сначала внедрили адресность трат, а затем — систему «светофоров» в мессенджер.

Этот и другие FinOps-подходы позволили командам видеть аномалии в моменте и сэкономить более 20 млн рублей за 2025 год. Внутри статьи — архитектура ботов и грабли, на которые лучше не наступать при настройке API.

Для тех, кто хочет так же 👉 читайте статью и задавайте вопросы.

💬 Практики FinOps | 💬 Практики FinOps

💬 Эксперт нашего комьюнити Александр Либкинд (cloud.ru) делится простыми шагами на завтрашнее утро

Это выполнимые действия, которые помогут улучшить прозрачность и контроль за расходами без внедрения сложных фреймворков (процессов).

Забирайте готовый чек-лист:

0️⃣Проверьте, что у ваших команд есть ролевой доступ к финансовой информации и метрикам ресурсов в их проектах. Прозрачность (Visibility) — фундамент для принятия решений инженерами.

0️⃣Найдите и удалите бесхозные ресурсы, например, «висячие» диски и свободные IP-адреса, ресурсы без владельца старше 14 дней. Прямой способ моментально сократить Cloud Bill.

0️⃣Настройте лимиты для каждой команды с порогами информирования 50/80/90%, ориентируясь на средние расходы команд или прогноз. Для Development сред правила могут быть жестче и допускать остановку при 100% исчерпании лимита. Это предотвратит неконтролируемое сгорание бюджета (Forecasting & Budgets).

0️⃣Внедрите политики создания новых ресурсов, обязательных к применению: тегирование (тип среды, центр-затрат, бизнес-юнит, владелец). Без этого невозможна системная работа по снижению затрат и ее автоматизация.

5️⃣Настройте алерты на изменение метрик стоимости выше 30% или Х ₽/день для общих расходов и ключевых SKU (услуг). Базовый Anomaly Detection для выявления ошибок конфигурации, багов автоскейлинга или DDOS в моменте.

6️⃣Настройте правила автоматического выключения (расписание) Development сред в нерабочее время. Это не окажет влияния на бизнес и позволит сэкономить.

Есть чем поделиться? Пишите @finops_admin

#FinOps_чеклист

💬 Практики FinOps | 💬 Практики FinOps

Что скрывается за ИТ-аббревиатурами, или как не запутаться в софте для управления инфраструктурой

На масштабах enterprise-сегмента ручные проверки биллинга давно не работают. Однако на рынке ИТ-менеджмента так много похожих систем, что в их назначении путаются даже опытные инженеры.

Картинка выше наглядно показывает базовый принцип: как продвинутая система «умный дом» не дает топить улицу и жечь свет в пустых комнатах, так и профильный софт убирает инфраструктурный мусор.

Разберем классы систем из нашего опроса, чтобы определить, кто за что отвечает. Правильный ответ: Инструменты оптимизации затрат (Cost Optimization Tools)

Это софт для детального анализа и автоматического устранения лишних расходов в облаке. Платформы подключаются к инфраструктуре по API, непрерывно оценивают реальную утилизацию ресурсов (CPU/RAM) и выдают конкретные рекомендации:

🟣Оптимизация размеров (right-sizing): где можно уменьшить мощность серверов без потери производительности.
🟣Простаивающие ресурсы (idle resources): какие диски, базы данных или сетевые шлюзы забыли отключить.
🟣Управление обязательствами: где выгоднее применить пакетные скидки провайдеров или резервирование мощностей.

В чем разница со смежными системами:

🟢Управление ИТ-активами (ITAM): контролирует жизненный цикл физического железа и лицензий на ПО (от закупки до утилизации). Они следят за контрактами, но не видят минутную утилизацию процессоров в облаке.
🟢Мониторинг производительности приложений (APM): отслеживает здоровье сервисов (логи, трейсы, задержки). Они знают, где падает скорость кода, но сфокусированы на стабильности приложения, а не на его стоимости.
🟢Управление ИТ-услугами (ITSM): отвечает за организацию ИТ-процессов (например, обработка инцидентов службой поддержки) и к инфраструктурным костам отношения не имеет.

По данным ежегодных исследований FinOps Foundation, компании в среднем тратят впустую от 32% до 40% своего облачного бюджета. Согласно отчетам платмов мониторинга (Datadog), средняя утилизация процессоров в Kubernetes-кластерах из-за избыточных резервов часто не превышает 10%, а до половины тестовых сред продолжают работать по выходным, генерируя пустые затраты.

👀 Не полагайтесь только на ручные проверки. При больших оборотах специализированный софт окупает себя в первый же месяц за счет находок, которые физически невозможно заметить в выгрузках Excel.

💬 Практики FinOps | 💬 Практики FinOps

Дайджест: разборы открытых кейсов по оптимизации инфраструктуры

Изучили публичные доклады и собрали архитектурные подходы к оптимизации затрат на инфраструктуру из мировых практик.

1. Как перестроить топологию кластеров, чтобы не переплачивать за межзонный сетевой трафик? (из архитектурных разборов Pinterest)

➡️ Передача данных между разными дата-центрами (зонами доступности) внутри одного региона у большинства провайдеров платная. В Pinterest перестроили топологию кластеров так, чтобы микросервисы общались преимущественно внутри одной зоны, и внедрили Zone-Aware маршрутизацию. Это снизило сетевые расходы (Data Transfer) на десятки процентов.

2. Зачем переводить бэкенд на альтернативную ARM-архитектуру процессоров? (по техническим кейсам Honeycomb и профильных ИТ-конференций)

➡️ В SmugMug и Honeycomb перевели значительную часть бэкенда и баз данных со стандартных процессоров x86 на ARM-чипы. С точки зрения производительности на единицу затрат это дало мгновенный эффект: цена инстансов ниже примерно на 20%, а производительность в многопоточных задачах выше. Код компилируется точно так же, а эффективность использования бюджета растет.

3. Как автоматизировать скейлинг по кастомным метрикам вместо стандартных? (из опыта масштабирования систем Airbnb)

➡️ Стандартное масштабирование по утилизации процессора часто запаздывает: инстансы поднимаются поздно, а выключаются неохотно. В Airbnb настраивают триггеры масштабирования Kubernetes (HPA) на основе кастомных продуктовых метрик — например, количества входящих запросов в очереди (Queue Depth). Инфраструктура сжимается мгновенно, как только падает поток.

4. Как настроить автоматическое управление слоями хранения данных? (из докладов инженеров Netflix по управлению Big Data)

➡️ В Netflix терабайты данных генерируются ежеминутно. Держать всё на горячих дисках нерентабельно. Там настроили жесткие политики жизненного цикла: данные аналитики через 7 дней автоматически падают в категорию редкого доступа, через 30 дней — в мгновенный архив, а через 90 — окончательно архивируются. Тип хранения выбирается строго на основе частоты запросов API.

5. Как использовать спотовый флот со смешанными типами инстансов без риска даунтайма? (из практики инжиниринга Skyscanner)

➡️ Провайдер может забрать дешевые спот-мощности в любой момент с коротким уведомлением. В Skyscanner используют логику Mixed Instances Policy. Кластер собирается из 5–7 разных типов инстансов разных поколений и размеров. Если провайдер забирает один тип, кластер тут же пересобирается на другом, сохраняя стабильность продукта.

💬 Практики FinOps | 💬 Практики FinOps

Ждем слово ответное, нравится ли вам рубрика наша

💬 Практики FinOps | 💬 Практики FinOps

📈 Индекс эффективности облака: почему FinOps — это не про экономию, а про рост маржи

Если ваш бизнес вырос в два раза, а счет за облако увеличился ровно на те же 100% — радоваться рано. С точки зрения зрелого ИТ-менеджмента, это означает, что архитектура продукта не масштабируется, а просто копирует неэффективность.

Связать технические параметры инфраструктуры с финансовыми отчетами помогает Индекс эффективности облака (Cloud Efficiency Rate). Его задача — показать, насколько рационально система использует каждый вложенный рубль для генерации прибыли.

🟢Как это работает на уровне DevOps:
Инженерам нет смысла следить за абстрактной стоимостью облака. Их фокус — юнит-стоимость (Unit Cost). Например, сколько процессорного времени и памяти уходит на обработку одного API-запроса или авторизацию пользователя.

Чтобы этот показатель снижался при росте нагрузки, команды уходят от статических серверов и настраивают динамическую утилизацию. Приложение масштабируется (например, через HPA по кастомным метрикам очередей вроде Kafka или RabbitMQ) строго в моменты пикового наплыва транзакций и мгновенно сжимается до минимума в периоды затишья. Компания перестает платить за «воздух» и избыточные лимиты, выставленные инженерами на всякий случай.

🟢 Как это работает на уровне бизнеса:
Для финансового директора и владельца продукта главным маркером становится динамика Индекса эффективности.

❕ Идеальный сценарий: кривая бизнес-заказов идет круто вверх, а график расходов на ИТ растет по пологой траектории или остается стабильным. Это доказывает, что код оптимизирован, архитектура спроектирована правильно, а инфраструктурный «мусор» своевременно зачищается.

❕ Аварийный сценарий: трафик бизнеса стабилен, а расходы на облако растут. Это прямой сигнал о накоплении технического долга, наличии бесхозных дисков или аномалий в коде, которые сжигают бюджет впустую.

Для точного расчета индекса важно правильно подготовить базовые данные. С помощью автоматических инструментов автоматизации разовые крупные платежи за скидочные пакеты амортизируются (распределяются равномерно по часам), а общие платформенные сервисы прозрачно распределяются между продуктовыми командами пропорционально их реальному потреблению.

Совет: Переведите цену ИТ-эффективности с языка «выключенных серверов» на язык юнит-экономики продукта. Если бизнес растет быстрее, чем затраты на его инфраструктуру — ваша стратегия управления затратами работает правильно.

💬 Практики FinOps | 💬 Практики FinOps

🪙 Продолжаем серию «FinOps-чеклист». На очереди — взгляд на инфраструктуру как на бизнес-юнит

После «быстрого старта» важно перейти к системной модели. Эксперт сообщества Практики FinOps Дмитрий Деев, руководитель отдела ИТ-инфраструктуры и сервисов в Ви.Tech (ВсеИнструменты.ру), делится подходом, как превратить ИТ-ресурсы в управляемые финансовые единицы.

5 шагов Дмитрия для построения «фундаментального» учета:

🤩 Категоризация по правилам бизнеса
Разделяем расходы на CapEx (железо, лицензии) и OpEx (облака, техподдержка). On-premise, облака и гибриды считаем по-разному, так как их стоимость формируется из разных компонентов. Без этой «базы» невозможно считать стоимость сервисов.

🤩 P&L-центры как владельцы ответственности
ИТ-инфраструктура — это набор P&L-центров. Каждый ресурс должен быть «привязан» к подразделению, которое отвечает за свои расходы и доходы. Так мы уходим от оценки «в среднем по больнице» и переходим к финансовой прозрачности на уровне продуктов.

🤩 Прозрачное ценообразование ресурсов
В частной виртуализации цена не лежит на поверхности. Мы рассчитываем стоимость 1 vCPU и 1 GB RAM, закладывая в них:

— Стоимость железа и платформы.
— Коэффициенты под отказоустойчивость (HA).
— Целевые коэффициенты переподписки (overcommitment).

Это позволяет точно аллоцировать затраты на конкретные бизнес-задачи.

🤩 Тегирование и аллокация
Присваиваем виртуальным машинам и namespaces (в K8s) теги, соответствующие P&L-центрам. Сопоставляем данные с гипервизоров и от облачных провайдеров с этими метками. Результат — полная картина: кто именно потребляет ресурсы и сколько это стоит.

🤩 Установка лимитов и планирование
Вместо того чтобы просто «раздавать» ресурсы, мы устанавливаем лимиты в соответствии с бюджетами P&L-центров. Это вынуждает команды (тимлидов и CTO) более точно оценивать свои потребности, работая в заданных рамках.

Итог: такой подход позволяет не просто экономить «на спичках», а принимать обоснованные инвестиционные решения по развитию инфраструктуры, основываясь на цифрах, а не на ощущениях.

Коллеги, а вы уже пробовали «приземлять» стоимость vCPU на конкретные бизнес-продукты в своей компании? Какие главные сложности возникли при внедрении P&L? 👇

#FinOps_чеклист

💬 Чат | 💬 Практики FinOps

🟢 Как хаотичные проверки ломают продакшен и почему разовая очистка не работает? Часть 1

Опытом делится Александр Либкинд, руководитель направления развития сервисов управления затратами и эксперт Практики FinOps.

Казнить «server-01» нельзя помиловать — стандартная проблема при инвентаризации ИТ-инфраструктуры. Инициатива по очистке облака от неиспользуемых мощностей редко проходит безболезненно. Обычно процесс выглядит так: руководство назначает ответственного, тот неделями собирает данные по разным отделам и системам, а затем пытается разобраться, нужен ли конкретный актив бизнесу или перед ним пустая трата бюджета.

Следующий шаг — запросы по компании в попытке найти владельцев ресурсов. В ответ обычно тишина, так как никто внутри команды не знает, чьи это мощности. Тогда включается режим крайних мер: «Раз не ответили, значит, мусор. Останавливаем (удаляем, если действовать радикально)».

В этот момент инициатива приводит к сбою. Под остановку (удаление) случайно попадает критически важный компонент, падает боевой сервис, сотрудники и клиенты недовольны, а дежурные инженеры судорожно чинят проблему на ходу. Настоящего владельца так никто и не нашел. Бизнес получает деструктивный вывод: трогать неразмеченные ресурсы в облаке слишком опасно.

Когда инцидент исчерпан, а руководство требует снизить суммы в счетах от провайдеров, начинается новая волна проверок. Удаляются давно не запускаемые виртуальные машины, свободные IP-адреса и неиспользуемые диски. В следующем месяце счет действительно становится меньше. Все выдыхают и хлопают друг друга по плечу.

На первый взгляд, это результат. Но давайте смотреть на вещи честно: к FinOps это не имеет отношения. Это временный эффект чистой комнаты перед приходом гостей, когда весь хлам просто прячут в шкаф, главное не открывать его. Без системных изменений через пару месяцев инфраструктура снова превратится в свалку. Разовая зачистка временно латает дыры, но не меняет культуру потребления ресурсов.

🌸 Почему так происходит?
Потому что поиск владельцев опирается на человеческую память, а удаление — на ручной анализ сырых данных. Инженер по-прежнему может в два клика арендовать мощный сервер, забыть про него и уволиться. А сервер будет тихо сжигать бюджет до следующей генеральной уборки. Чтобы проблема ушла навсегда, отказываться нужно не от очистки, а от ручного контроля за ресурсами.

Во 2 части мы разберем, почему стандартные инструменты визуализации затрат часто оказываются бесполезными и как спроектировать базовые правила разметки без перегрузки инженеров.

😏 — жду продолжения
👾 — ставлю реакцию, чтобы мой прод не удалили

#finops_эксперты

💬 Чат | 💬 Практики FinOps

От Gross Spend к Net Spend: реальная стоимость облака

В аналитике облачных затрат легко получить искаженную картину, если смотреть только на базовые отчеты в консоли провайдера. Чтобы понимать реальную экономику ИТ-продукта, мы обязаны разделять базовую розничную стоимость потребления и фактические чистые расходы компании.

Представьте покупку авиабилета. На сайте указана цена 10 000 рублей. Это базовая стоимость (gross spend). Но у вас есть промокод на 1 000 рублей, а банк после покупки вернет еще 500 рублей в виде кэшбэка. В итоге из вашего кармана уйдет ровно 8 500 рублей. Это ваша чистая трата (net spend).

В облачных расчетах логика аналогичная. Существует розничная цена ресурсов и реальная сумма, которую списывает провайдер.

🫥 Как это считать правильно

Для вычисления чистой стоимости ресурсов в FinOps используют формулу:

Net Spend = Gross Spend - (Discounts + Credits + Rebates)

Каждое корректирующее значение имеет свою специфику в структуре данных.

Discounts (скидки). Сюда относятся корпоративные скидки за объем потребления или за обязательства по выкупу мощностей (commitments).

Credits (кредиты). Это бесплатные гранты от провайдера на тестирование новых сервисов, компенсации за нарушение SLA или маркетинговые ваучеры.

Rebates (рибейты). Прямые возвраты денег или бонусов на счет при выполнении определенных условий годового контракта.

С точки зрения аналитики данных, если мы оцениваем общую эффективность ИТ-бюджета на уровне руководства, мы всегда используем амортизированные чистые затраты (Amortized Net Costs). Но при расчете юнит-экономики отдельных сервисов мы обязаны сохранять видимость базовых цен (Gross Unblended Costs). Это позволяет инженерам видеть реальную рыночную стоимость их архитектурных решений, а финансистам фиксировать фактические оттоки денег.

🫥 Почему это важно

Большинство нативных дашбордов по умолчанию показывают розничные цены, что создает слепую зону для бизнеса по нескольким причинам.

Во-первых, происходит искажение маржинальности. Продукт может казаться планово убыточным по базовым тарифам провайдера, хотя с учетом корпоративной скидки его облачная себестоимость полностью укладывается в экономику.

Во-вторых, ломается логика справедливой аллокации. Если один департамент потратил время, закоммитился на использование конкретных типов серверов и получил скидку 30%, эти сэкономленные деньги должны уменьшать счет именно этой команды, а не размываться по всей компании.

В-третьих, возникают ошибки планирования. Без понимания разницы между типами затрат невозможно составить точный бюджет на следующий квартал, так как вы не будете видеть реальный темп списания денег со счетов.

Нельзя оценивать облако по сырым выгрузкам. Финансовая отчетность требует внедрения механики нормализации биллинга. Только разложив каждую строчку от провайдера на составляющие, мы получаем достоверную картину и понимаем, сколько на самом деле стоит наша инфраструктура.

#finops_inform #finops_walk

💬 Чат | 💬 Практики FinOps

🟩 Часть 2. Почему красивые графики слепы и как работает базовая политика атрибуции

В первой части Александр Либкинд разобрал, почему попытки очистить облако вручную заканчиваются либо хаосом и сбоями, либо временным «затишьем» перед превращением инфраструктуры в свалку.

С ручными проверками всё понятно — это тупиковый путь.

⚙️ Раз нужна автоматизация, логично начать со сбора данных, чтобы не бегать по отделам с вопросами. Первая мысль менеджмента обычно звучит так: «Нам нужны красивые дашборды».

Компании умеют строить отличные круговые диаграммы и выводить топ-5 самых дорогих проектов в BI-системах.

На дашборде по самому затратному проекту видны конкретные траты:

🟣Вычислительные ресурсы:1.5 млн ₽
🟣Контейнеры: 1.2 млн ₽
🟣Базы данных: 900 тыс. ₽

Графики выглядят аккуратно. Но стоит задать три простых вопроса, как наступает тишина:

➡️ Кто конкретно отвечает за эти 1.5 млн?
➡️ Как сумма распределена между продом и тестом?
➡️ Какую бизнес-задачу решает система за 3.6 млн в месяц?

Без понимания владельцев любая аналитика слепа. Мы видим, что именно купили у провайдера, но не знаем, нужно ли это бизнесу.

Это как получить выписку по карте, где указаны только магазины: маркетплейс — 100 тыс., супермаркет — 50 тыс. Куда ушли деньги — понятно, но кто их потратил и принесло ли это пользу — загадка. График без привязки к людям указывает на симптомы, но не ставит диагноз.

Лекарство — строгая политика атрибуции затрат. У каждого ресурса должны быть теги с четкими ответами на вопросы: кто и зачем его создал. Не нужно придумывать сложную систему из десятка меток.

⚙️ Достаточно определить четыре ключевых параметра:

🟣Команда / Отдел (например: Отдел продаж)
🟣Ответственный (например: ivan.ivanov@company.ru)
🟣Среда (например: dev)
🟣Приложение (например: BI по МСБ)

Разница огромна. Виртуальная машина с техническим названием «server-01» без меток вызывает паралич у дежурного инженера: удалять страшно, а вдруг это важная база данных?

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

Иван, ты указан как ответственный за dev-конфигурацию «server-01»
для BI по МСБ. Он не используется более 14 дней и сжигает 25 тыс. ₽ в месяц. Пожалуйста, удали его или настрой отключение в нерабочее время. Инструкция ниже.

Никакого страха — только прозрачность и действие. В финальной части мы перейдем от теории к технической реализации и настроим правила, которые сделают ручной контроль ненужным.

#finops_эксперты

💬 Чат | 💬 Практики FinOps