Или все наоборот? 💬

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

📊 Облака 2026: Прогноз и реальность

Рынок уверенно идёт к 500+ млрд рублей, но важнее не цифры, а то, как меняется сама логика потребления облака.

Что уже видно на практике:

⏺️ Спрос на решения в области искусственного интеллекта и графические ускорители пересобирает бюджеты на ходу
⏺️ Гибридные и мультиоблачные подходы стали стандартом, одного провайдера уже недостаточно
⏺️ Модель безопасности с нулевым доверием закладывается сразу в архитектуру, а не добавляется позже

Приятно видеть, что эксперты рекомендуют внедрять FinOps-практики. Мы в сообществе это только приветствуем. Управлять облаком в 2026 году без системы — как ехать в тумане без приборов.

Базовый минимум, который сейчас должен быть:

⏺️ Отклонения в расходах отслеживаются сразу, а не в конце месяца
⏺️ Все ресурсы размечены и привязаны к проектам
⏺️ Регулярно отключается всё, что не используется
⏺️ Используются прерываемые вычислительные мощности там, где это оправдано

Если коротко, облако в 2026 — это баланс между скоростью разработки и контролем затрат.

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

🔗 Для тех, кто хочет освежить в памяти детали: источник

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

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

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

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