Аддитивность и полуаддитивность в FinOps аналитике

В аналитике облачных затрат есть две ловушки, в которые легко попасть при объединении данных. Чтобы не нарушать логику отчетов, важно различать типы метрик.

Представьте две чашки чая по 50°C. Если перелить их в один чайник, вода не станет кипятком в 100°C. Она останется 50°C, просто её станет в два раза больше.

В данных всё точно так же:

🔵Объем (деньги) — это аддитивная величина. Их можно и нужно складывать.
🔵Температура (загрузка CPU/RAM) — это полуаддитивная величина. Складывать её нельзя.

Как считаем:

Когда мы говорим о деньгах, работает простая сумма. Мы складываем затраты Проекта А и Проекта Б, чтобы получить общий бюджет. Это база для аллокации, здесь математика линейная и понятная:

Общие затраты = Сумма всех трат

С нагрузкой (утилизацией) всё иначе. Суммировать проценты загрузки процессора или памяти физически бессмысленно. Если сложить показатели трех серверов по 40%, в отчете получится 120%. Это цифра из параллельной реальности, которая никак не поможет в оптимизации.

Для таких метрик используют другие подходы:

🔵Среднее значение: сумма всех значений нагрузки, деленная на количество серверов.
🔵95-й процентиль (P95): уровень, который нагрузка не превышала в 95% случаев. Это золотой стандарт для FinOps, так как он показывает реальный потолок потребления, отсекая случайные разовые пики.

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

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

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

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

Вчера состоялась продуктивная встреча с экспертом сообщества. Александр Либкинд поделился уникальным опытом и взглядом на развитие FinOps в России.

Выпуск выйдет совсем скоро. Следите за обновлениями!

💬 Практики FinOps

Миграция в облако: 5 главных ошибок 2026 года

Бизнес больше не спрашивает, как заменить VMware. На повестке — прозрачный FinOps, управляемость гибридных сред и безопасность. Облака перестали быть просто альтернативой «своему железу» и стали базовым инструментом для масштабирования сервисов.

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

Самые яркие мысли дискуссии о том, почему миграция до сих пор остается для многих болезненным процессом:

Михаил Кадер (архитектор ИБ, UserGate)

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

Константин Анисимов (заместитель гендиректора, Astra Cloud)

Есть статистика, зафиксированная в США: 97 % клиентов недовольны прозрачностью биллинга — они не понимают, как формируется счёт. С другой стороны, когда компании выезжают обратно из облака в свою инфраструктуру, они сталкиваются с отсутствием функциональности PaaS.

Андрей Радыгин (руководитель «Облачного партнёрства» DeckHouse, «Флант»)

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

Станислав Погоржельский (технологический евангелист VK Cloud, VK Tech)

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

Сергей Самоукин (директор по продуктам, «Спикател»)

Чтобы не разочаровываться, стоит взять облако на тест и посмотреть, как оно работает технически, как собрано. У каждого облака есть свои нюансы — их нужно изучить, убедиться, что вы разбираетесь в счёте, когда он придёт.

Сергей Мерещенко (лидер продукта Cloudlink, «Орион софт»)

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

Андрей Коновалов (руководитель отдела продуктов, MIND Software)

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

📺 Запись эфира в VK Видео

💬 Практики FinOps

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