Как сокращать ИТ-бюджет без остановки бизнеса

Финансы просят урезать бюджет на 20%. Стандартный ответ — линейный секвестр: режем всё подряд пропорционально. В отчетности цифры сходятся, но через месяц в топовых магазинах встают кассы, пропадает интернет и останавливается приёмка товара. Итог — экономия на бумаге оборачивается потерями выручки, которые в разы превышают сэкономленное.

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

Что изменилось в подходе:

✔️ Категоризация расходов. Мы делим всё на три группы: то, без чего бизнес встанет сегодня, то, что можно временно потерпеть, и развитие.
✔️ ABC-классификация объектов. Совместно с коммерсантами определяем, какие точки продаж критичны для выручки, а какие могут работать с минимальным резервом.
✔️ Переход к диалогу о рисках. Перестаем доказывать, что бюджет «нельзя резать». Вместо этого показываем финдиректору конкретную цену простоя: сколько компания потеряет денег, если отключить сервис в конкретном магазине.

Такой метод позволил снизить OPEX на 40% при сохранении доступности критичных сервисов на уровне 99,9%.

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

#finops_эксперты

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

⚡️Вчера поговорили с экспертом нашего комьюнити Вячеславом Бессоновым (Hilbert Team)

Обсудили, как меняются подходы к управлению инфраструктурными расходами и какие задачи сегодня выходят на первый план и супер боль: «какие палки в колеса вставляют облачные провайдеры при внедрении ФинОпс»

Выпуск уже совсем скоро.

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

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

Кейсы и материалы этого выпуска относятся к стадии Ползем (Crawl) и фазе Информирование (Inform). Разбираем, как компании начинают оценку затрат, приводят данные в порядок и готовят инфраструктуру к дальнейшей оптимизации.

1. Почему нативные отчеты провайдеров создают иллюзию контроля? (из заметок по анализу дашбордов AWS/Azure)

➡️ Нативный биллинг выдает сырые технические метрики: прирост стоимости Object Storage или пула виртуальных машин на 20%. Без привязки к бизнес-логике эти отчеты превращаются в генераторы шума. Они не показывают, вызван ли рост багом в коде или притоком пользователей. Согласно опыту инженеров AWS, без кастомной разметки данных оптимизация на старте часто проводится «вслепую».

2. Почему без единой модели ресурсов сложно понять, что можно отключать? (из открытого кейса Pinterest про переход к Kubernetes-платформе)

➡️ В Pinterest описывали проблему разрозненных VM-флотов: когда инженеры управляют машинами отдельно, инфраструктурной команде сложнее строить governance-инструменты, понимать, кто владеет ресурсом, и можно ли его безопасно утилизировать. Для стадии Ползем (Crawl) это важный вывод: перед оптимизацией нужно собрать базовую картину по активам, владельцам и статусу ресурсов. Иначе любая «зачистка» превращается не в управление затратами, а в риск для прод-сервисов.

3. Какой критический минимум тегов нужен для прозрачности? (из открытых практик FinOps Foundation и AWS по cost allocation)

➡️ На старте важнее не сложная матрица тегов, а минимальная разметка, которая помогает связать расходы с владельцем, средой и сервисом. Базовый набор можно строить вокруг Owner, Environment и Service Name: кто отвечает за ресурс, где он используется и к какому сервису относится. Такой минимум не закрывает всю задачу cost allocation, но уже делает расходы читаемыми для команд и снижает шум в первичной оценке.

4. Зачем настраивать персональные дашборды для тимлидов? (из материалов Datadog по видимости затрат)

➡️ Общий счёт за инфраструктуру плохо работает как инструмент управления: он показывает сумму, но не помогает команде понять, какая часть расходов относится к её зоне ответственности. В Datadog Cloud Cost Management затраты можно разбирать по team, service, environment и другим тегам, а также выводить их на дашборды для showback и chargeback. Когда тимлид видит расходы своего сервиса или команды, обсуждение оптимизации становится предметным: где растёт стоимость, какие ресурсы дают вклад и что можно проверить без отдельной команды сверху.

5. Почему модель pay-as-you-go обманывает ожидания? (из отчетов FinOps Foundation)

➡️ В облаке вы платите за то, что заказали, а не за то, что реально утилизировали. Из-за отсутствия первичного учета компании регулярно выходят за бюджет, оплачивая простаивающие машины с избыточным запасом мощности. Согласно аналитике FinOps Foundation, до 30% бюджета улетает на оплату ресурсов, которые де-факто не выполняют полезной нагрузки (CPU и RAM), просто из-за отсутствия базовой гигиены учета.

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

⚡️ Теряет ли облачный провайдер деньги, если помогает клиентам сокращать счета?

На первый взгляд кажется, что должен. Но на практике всё работает иначе.

В новом выпуске «Практики FinOps» поговорили с Александром Либкинд, руководителем направления FinOps в Cloudru.

Разобрали, почему оптимизация затрат выгодна и клиенту, и провайдеру, где обычно находятся первые 15–30% экономии и как меняется роль FinOps в российских компаниях.

Темы выпуска:
🟣почему FinOps не прижился в России так быстро, как на Западе;
🟣где обычно находятся первые 15–30% экономии;
🟣почему отчёты раз в месяц бесполезны для управления затратами;
🟣чем FinOps для AI отличается от классического FinOps;
🟣почему автоматизация рекомендаций до сих пор остаётся сложной задачей.

Смотреть выпуск:

🎞 YouTube
📺 Rutube
📺 VK Видео

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

⏳Конец эпохи забытых GPU-инстансов

По данным Cast AI, средняя утилизация GPU в Kubernetes-кластерах составила 5%. Для сравнения: CPU, 8%, память, 20%.

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

Что важно проверять:
🟢утилизацию GPU, CPU, памяти и сети
🟢алерты на резкие cost-спайки
🟢лимиты для тестовых и экспериментальных окружений
🟢 теги владельца, продукта, окружения и срока жизни ресурса
🟢правила остановки временной инфраструктуры

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

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

Источник: Cast AI, 2026 State of Kubernetes Optimization Report

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

🪙 Как выглядят финансовые гардрейлы на практике

После новости про низкую утилизацию GPU логичный вопрос: что с этим делать без ручного контроля и разборов счетов задним числом?

Начинать лучше не со всей инфраструктуры сразу, а с самых рискованных сценариев:

🟣GPU-инстансы для экспериментов
🟣тестовые и временные окружения
🟣нагрузочные тесты
🟣пайплайны обучения и инференса
🟣ресурсы без понятного владельца и срока жизни

Для каждого такого сценария нужны базовые правила.

Первое, владелец ресурса. Должно быть понятно, какая команда запустила инстанс и к какому продукту он относится.

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

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

Четвертое, метрики утилизации. Дорогой ресурс нельзя остановить только потому, что он дорогой. Нужны данные по GPU, CPU, памяти, сети и дискам за выбранный период.

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

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

Источник: FinOps Foundation, FinOps for AI Overview

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

🔺 Выпуски Практики FinOps теперь можно слушать в аудио формате

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

В последнем выпуске обсудили, почему FinOps в России развивается иначе, где обычно находятся первые от 15 до 30% экономии, почему отчёты раз в месяц не помогают управлять затратами и чем FinOps для AI отличается от классического FinOps.

Слушать выпуск:

💬 Telegram Player (Mave)
🎵 Яндекс. Музыка
🎵 VK Музыка

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

💬 Практики FinOps

#finops #финопс #cloud

🟩 После KEDA логично перейти от инженерных гардрейлов к правилам учета затрат

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

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

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

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

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

В канале он показывает полный путь затрат: от процессов и ресурсов до конечного финансового результата, а также объясняет, что влияет на рентабельность.

💬 Практики FinOps

☁️ Стать голосом комьюнити

🟢 Как перейти к автоматизации и проверить инфраструктуру на зрелость (часть 3)

Мы начали с GPU-инстансов и постепенно вышли на общий вопрос: как сделать дорогую инфраструктуру управляемой.

Возвращаемся к инфраструктуре.

Чтобы такая модель работала не только в отчетах, каждому ресурсу нужны понятные атрибуты: владелец, команда, среда и приложение.

➡️ В первой части Александр разобрал, почему ручная очистка инфраструктуры быстро ломается.

➡️

Во второй части

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

Теперь главный вопрос: откуда возьмутся корректные метки?

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

Значит, процесс нужно закреплять на уровне инфраструктуры.

❕ Первый шаг, обязательные теги для новых ресурсов.

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

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

Но здесь важны исключения.

Жесткий запрет не должен ломать системные аккаунты, CI/CD-пайплайны, автоскейлинг и сервисные ресурсы. Поэтому во многих случаях гибкая автоматизация атрибуции безопаснее, чем правило «запретить все без тегов».

❕ Второй шаг, регламент для старых ресурсов.

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

Примерная логика может быть такой:

🟣1–2 неделя, автоматическая разметка

Скрипт помечает ресурсы как unassigned и отправляет уведомления потенциальным владельцам: «Мы нашли этот ресурс в вашей подсети, подтвердите владение».

🟣 3-я неделя, общее оповещение

Неразмеченные ресурсы попадают в общий алерт: «Через неделю ресурсы без заполненных тегов будут остановлены».

🟣 4-я неделя, безопасный карантин

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

Удаление возможно только после периода ожидания и отсутствия реакции.

Это важный принцип. Сразу удалять неразмеченные ресурсы рискованно. Остановка на несколько дней безопаснее: она помогает найти реального владельца без необратимых последствий.

❕ Третий шаг, прозрачность для команд.

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

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

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

Финальный тест на зрелость простой:

Можете ли вы за две минуты назвать владельцев пяти неразмеченных ресурсов в вашей инфраструктуре?

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

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

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

🫨, если было полезно
🙂, если уже делаете что-то похожее или планируете внедрять

#finops #финопс #cloud #finops_эксперты

💬 Практики FinOps

💬 Практики FinOps