FinOps: 12 вещей, которые вам не расскажут на конференции

Знаете, что обычно происходит, когда компания решает, что ей пора внедрять FinOps? Правильно. Выделяют человека, дают ему должность и ждут. Человек этот начинает делать отчёты. Отчёты рассылаются по подразделениям. Подразделения их читают. И на этом всё.

А потом приходит финдир и спрашивает: почему счёт за инфраструктуру опять вырос? И все дружно смотрят на того самого человека, у которого нет ни бюджета, ни метрик, ни, собственно, возможности на что-то повлиять.

Мы вместе с Виталием Глушаковым решили собрать 12 тезисов о том, как FinOps работает в реальности. Не как в презентациях на конференциях, а как оно бывает, когда дашборд есть, а финансовой модели нет. Когда shared-сервисами пользуются все, а платит непонятно кто. И когда экономия на серверах обходится дороже, чем если бы вообще ничего не трогали.

Интересно? Тогда бегом читать нашу новую статью на Хабр!

#эксперты_finops

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

Правильный ответ: Ресурс — это «внутренности» Объекта

Разбираемся, почему это разделение считается фундаментом в FinOps.

Представьте автомобиль. Сам автомобиль — это Объект (конфигурационная единица). У него есть ID, владелец и номер. Но чтобы он ехал, ему нужны бензин и масло. Это Ресурсы. Мы платим за литры бензина (ресурсы), чтобы функционировала машина (объект).

В чем суть для FinOps
Биллинг всегда показывает расходы на ресурсы: ядра (vCPU), гигабайты (RAM), терабайты (Disk). Но бизнесу не нужны просто «ядра», ему нужна работа конкретного сервиса.

Задача аналитики: привязать траты на ресурсы к конкретному Объекту (базе данных, микросервису или веб-сайту). Только так понятно, кто именно «съел» бюджет.

Практический совет
Связывайте данные биллинга (деньги за ресурсы) с данными мониторинга (нагрузка) через ID Объекта.

Это лучший способ увидеть реальность: не купили ли вы слишком много «бензина» для машины, которая стоит в гараже и никуда не едет (те самые Idle resources).

Если у вас есть ресурсы без привязки к объектам, это «бесхозные» затраты. При оптимизации их режут первыми.

#финотека

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

🤕 Забытый GPU-инстанс и счет на 85 000 руб

Облачный лорд пишет:

Прилетел отчёт по биллингу за две недели: минус 85 000 руб. Начали разбираться, оказалось, перед отпуском один из инженеров поднял GPU-инстанс для теста и не выключил. Всё это время он просто крутился.

Финдир уже пришёл с вопросами, обсуждается депремирование отдела. У кого-нибудь был похожий кейс? Получалось договориться с провайдером о частичном возврате или это просто оплачивается как есть?

💬 Мнение эксперта. Игорь Гальцев, технический директор:

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

Диалог с провайдером. В российских облаках, таких как VK Cloud и Yandex Cloud, решения принимают не только автоматически. Если это первый инцидент, стоит направить официальный запрос с описанием ситуации, указанием на человеческую ошибку и уже принятые меры. Иногда провайдер может вернуть часть суммы бонусами на счёт, так называемое грантовое возмещение. Это не обязанность, а их решение.

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

Техническое решение «на вчера»:

Автостоп по расписанию. Все ресурсы с тегами «env: dev» или «env: test» автоматически останавливаются в 20:00 по будням и на весь период выходных и праздничных дней. При необходимости ресурс можно включить вручную, но при наступлении следующего периода он будет остановлен автоматически.

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

Квоты на GPU. На уровне облака задаются ограничения на запуск ресурсоёмких инстансов. Превышение лимитов требует дополнительного согласования.

Ждем ваши истории! Хотите поделиться своим кейсом или факапом? Поделиться историей или кейсом можно через анонимную форму.

Будем разбирать вместе с экспертами нашего комьюнити и искать решения.

✍️ Ссылка на форму

#finops_разбор #эксперты_finops

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

🔍 Как ИТ-инфраструктура помогает бизнесу выжить в 2026?

Вы переплачиваете до 1 млн. руб. в год, если всё ещё не внедрили практики FinOps. Станислав Тибекин, сооснователь ИТ-интегратора НИКСИС | NIXYS, с опытом в DevOps более 15-ти лет, на своём канале рассказывает, как сократить расходы на серверную инфраструктуру на примере клиентского кейса.

Клиент НИКСИС | NIXYS — веб-студия с более чем 50 проектами: корпоративные сайты, интернет-магазины. Данные — в облаке у провайдера Selectel.

Статьи расходов:
🔹15 неиспользуемых виртуальных машин (с утилизацией потребления < 10%);
🔹 избыточные мощности — ресурсы с низкой фактической нагрузкой;
🔹 неоптимальный объем арендованных дисков и тип хранилища для хранения файлов (Storage - S3).

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

Переплата: ~82,5 тыс. руб. / месяц (~990 тыс. руб. / год).

Как оптимизировали бюджет?
🔹 Заменили статичные виртуальные машины на виртуальные машины с автомасштибированием;
🔹 Перевели проекты на Managed PostgreSQL с автоматическим масштабированием;
🔹 Перенесли архивные данные в холодное хранилище (Cold Storage);
🔹 Настроили мониторинг нагрузки ресурсов и рекомендаций по оптимизации (чтобы не повторять ситуацию неэкономных затрат в будущем).

В кризис бизнес платит за решения, которые ведут к прямому сокращению издержек в кратчайшие сроки, а не через 1–3 года — до такой временной точки он может не дожить. Выстраиваете контроль над инфраструктурой и переживайте вызовы рынка уже сегодня.

#партнерскийпост

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

👀 Почему отчеты по затратам не сходятся и как это исправить

Теги и методы распределения не спасают от ручного сбора данных из облаков и CMDB. В итоге на вопрос «кто за что платит» нет четкого ответа, а данные разбросаны между биллингом, Excel и финансовыми таблицами.

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

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

Почему в Enterprise FinOps схема «Звезда» — это база? ⭐️

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

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

Почему в FinOps выбирают именно «Звезду»?

✈️ Скорость: Это самая быстрая архитектура для SQL-запросов. BI-инструменты мгновенно объединяют справочники с фактами, так как между ними всего один «шаг» (JOIN).
✈️ Гибкость: Если у продукта сменился владелец, обновляется всего одна строка в справочнике. Вся история за годы мгновенно пересчитывается без перезаписи миллионов строк биллинга.
✈️ Простота: Аналитику не нужно строить сложные цепочки связей — всё соединяется с центром напрямую.

А что не так с другими вариантами?

Схема «Снежинка»: Здесь справочники разбиты на мелкие под-таблицы (например, «Регион» вынесен из «Локации»). Это экономит каплю места, но плодит лишние JOIN-ы. На терабайтах данных это превращает работу с отчетами в бесконечное ожидание загрузки.

Схема «Data Vault»: Это архитектура для инженеров данных, чтобы надежно хранить сырые данные (Raw Layer). Но она слишком сложна для быстрой аналитики из-за обилия «хабов» и «линков». Для отчетов на основе Vault всё равно приходится строить витрины в виде «Звезд».

Схема «Созвездие фактов»: Набор из нескольких звезд. Полезна, когда нужно объединить разные источники (например, биллинг и данные мониторинга), но для базовой задачи распределения затрат это избыточное усложнение.

Практический совет:
При проектировании FinOps-хранилища (DWH) всегда стоит стремиться к схеме «Звезда». Чем лаконичнее ваша таблица фактов и чем «площе» справочники-измерения, тем быстрее будут грузиться дашборды у вашего финансового директора.

#Финопс #АрхитектураДанных #ХранилищеДанных #СхемаЗвезда #DWH

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

👀 Как говорить в ИТ сегодня, чтобы вас поняли

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

Аддитивность и полуаддитивность в 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