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

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

Открывает серию постов Игорь Гальцев («Инферит 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