Еженедельный разбор от экспертов-практиков

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

Открывает серию постов Игорь Гальцев («Инферит FinOps», ГК Softline)

Мы десятилетиями строим сложнейшие IT-системы, а на совете директоров до сих пор сыплемся на элементарном вопросе: «Кто конкретно и за что платит?».

Обычно всё идет по классике: руководство требует прозрачности, и мы радостно бежим обвешивать инфраструктуру тегами. Проходит месяц, инженер (у которого и так дел по горло) убивает кучу времени на разметку, а биллинг в итоге всё равно не сходится. В отчётах — зияющие дыры на десятки тысяч. Знакомая история?

Почему я считаю, что теги сами по себе не спасают?
Теги — это благо, пока их мало. Но в реальности крупной компании они быстро превращаются в «теговый хаос» (Tag Debt).

Один пишет costCenter, другой — costcenter, третий — Cost-Center. Для системы это три разные сущности.

Около 30% ресурсов вообще остаются «голыми» («создам быстро, потом размечу» — ага, конечно).

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

Три кита распределения расходов, которые рушатся первыми:

Гранулярность. Теги плохо держат иерархии. Виртуалка может принадлежать приложению, которое входит в сервис, который часть продукта... Пропустите один уровень — и вся ваша модель летит в мусорку.

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

Доверие. Если данные не вызывают доверия у CFO, они бесполезны. Даже если технически они выглядят идеально.

Я часто повторяю на лекциях одну мысль:

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

В чём главная ловушка?
FinOps-команда тратит 80% времени на роль «переводчика» между технарями и финансами. Мы просто перекладываем строчки из одной таблицы в другую вместо того, чтобы реально оптимизировать расходы (и экономить компании деньги).

Есть, что рассказать? Станьте голосом коммьюнити — пишите @finops_admin

#эксперты_finops

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

🫥 Инструменты для системного учета затрат

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

Игорь Гальцев выделяет три решения для прозрачности затрат:

✈️ Kubecost / OpenCost — прозрачность внутри кластера. Позволяет разложить общую стоимость оборудования до конкретной единицы потребления (пода) и приложения. Без этого невозможно определить реальный вклад каждого сервиса в общий счет.

✈️ Cloud Custodian — автоматическое наведение порядка. Вы один раз фиксируете правила в виде кода, и система сама удаляет неиспользуемые накопители или останавливает временные стенды по графику. Это исключает человеческий фактор и необходимость постоянных уговоров.

✈️ Стандарт FOCUS — единый стандарт описания затрат. Позволяет привести счета от разных поставщиков к общему виду, чтобы команда тратила время на поиск путей экономии, а не на ручное сведение таблиц и сопоставление разных форматов отчетности.

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

#эксперты_finops #Инфраструктура #Автоматизация

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

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