Обновить
15
24
Дмитрий Важенин@vazhendima

Пользователь

Отправить сообщение

Уровень загрузки ресурсов (Percentage Resource Utilization)

Уровень загрузки ресурсов помогает быстро понять, насколько действительно используются выделенные мощности. Это один из самых простых и при этом самых рабочих способов найти неоптимальности в инфраструктуре. Компании начинают применять его ещё до формального внедрения FinOps, просто потому что здравый смысл подсказывает: если сервис использует 5% ресурсов, есть повод что-то менять.

Мы смотрим на три базовых показателя. Это CPU, память и диск. Этого достаточно, чтобы увидеть общую картину. Да, в инфраструктуре есть и другие ресурсы, например трафик, но для первичной диагностики хватает именно этих трёх.

Как считается

➖  CPU: использованные ядро-часы / количество выделенных ядер

➖  Память: фактическое потребление в гигабайтах / выделенный объём

➖  Хранилище: используемые GB / выделенное пространство

Что даёт этот анализ

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

  1. Команда отказывается от ресурсных объектов, если загрузка держится на уровне нескольких %.

  2. Команда объединяет инфраструктуру. Например, три виртуальные машины загружены по 20% каждая, их сводят в одну, а две отключают.

  3. Команда корректирует конфигурацию. Это классический rightsizing, когда сервису просто уменьшают объём ресурсов, потому что реальная нагрузка намного ниже.

Это базовый навык, с которого начинается оптимизация в любой компании. Он одинаково полезен и в публичных облаках и в частных инфраструктурах. И независимо от уровня зрелости, компании, которые работают с фактической загрузкой, быстрее находят резервы, снижают расходы и точнее планируют будущие потребности. (Источник: FinOps Foundation).

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Теги:
0
Комментарии0

FinOps против Excel: кто управляет деньгами в облаке

Классический финконтроль — это история, которая в облаке почти не работает.
Классический финконтроль — это история, которая в облаке почти не работает.

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

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

А потом пришло облако. Сегодня нагрузка почти нулевая, а завтра конкурента блокируют, и трафик у тебя растет в разы. Автоскейлинг добавляет новые инстансы, счёт за неделю превращается в месячный.

CFO смотрит на это и разводит руками. Финансисты видят цифры, но не понимают, почему всё так скачет.

Проблема не в суммах, а в подходе. Старый финконтроль держится на стабильности, а облако живёт по принципу «всё меняется каждую минуту». Любая мелочь в архитектуре мгновенно отражается в P&L, а привычные отчеты не успевают за скоростью изменений.

FinOps меняет этот подход:

  • Вместо квартальных отчетов — короткие кост-ревью

  • Вместо агрегированных сумм — расходы по командам и проектам

  • Вместо запоздалых реакций — наблюдение в реальном времени.

Это уже даже не про “оптимизацию”, а про банальную прозрачность. Или транспарентность. Называйте как хотите.

Главное – что благодаря этому CFO может видеть деньги не в Excel, а прямо в инфраструктуре, и перестает реагировать на факты, а начинает ими реально управлять.

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

Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Роли в FinOps

Как бы странно это ни звучало, но главное, на чем держится FinOps, — это общий язык, на котором говорят и финансисты, и технари. При этом у каждого из них есть своя роль:

➖  инженеры и DevOps, которые запускают ресурсы и должны видеть их стоимость

➖  продакты и бизнес-менеджеры, которые отвечают за ценность и окупаемость

➖  финансисты и закупки, которые смотрят на бюджеты и договоры

➖  руководители и C-level, которые принимают стратегические решения

В каждой компании распределение может отличаться. Но идея одна: никто не работает в вакууме. Инженеры понимают, во сколько обходятся их сервисы, финансисты знают, за что платят, а топы видят, какую отдачу приносит облако.

Такой подход убирает вечный спор, кто сколько тратит, и превращает расходы в совместную ответственность.

Близка тема, где финансы и инженеры наконец говорят на одном языке? Заглядываем в «Практики FinOps», там выходят кейсы, доклады, лайфхаки и немного самоиронии про жизнь в облаке.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Информация

В рейтинге
358-й
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Зарегистрирован
Активность