🤩В крупном бизнесе нет единственного владельца облака

Сегодня Бессонов Вячеслав (Hilbert team) на Partner Conf’25 говорил о том, как переводить технические метрики в бизнес-результаты.

Супер понятный месседж: CTO и инженеры продолжают показывать CPU, RPS и аптайм, а бизнесу важно другое — стоимость фичи, влияние инцидентов на выручку и эффективность инфраструктуры.

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

✅ Практики FinOps | База знаний

А Кирилл сегодня выйдет погулять поработать? 😁

✅ Практики FinOps | База знаний

🤩Публичное облако или частное?

Казалось бы, облако — есть облако. Залил данные и пользуешься. Так ведь нет же, придумали еще какие-то частные и публичные, а простому народу — разбирайся.

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

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

✅ Подписаться

💫 Задержка видимости затрат (Cost Visibility Delay)

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

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

Формула:
Задержка видимости = время появления расхода / время его отображения

Что нужно:
🟣биллинг провайдера
🟣ваш ETL, который собирает и обновляет данные

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

Источник: FinOps Foundation
#считаем_finops

✅ Практики FinOps | База знаний

😁Кажется урок усвоен, но….есть еще треки на всякий случай?

✅ Подписаться

💫 Как Salesforce навели порядок в облаке для 15 000 инженеров

Salesforce давно живут в SaaS и знают, что такое большие нагрузки. Но когда в 2020 году компания переехала в публичное облако, стало ясно: старые подходы больше не работают.

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

Что придумали
Команда создала метрику COIN — простой показатель, который помогает честно посмотреть на эффективность каждой команды.

Суть такая:
COIN = 1 − (потенциальная экономия / общие затраты)

Что сделали на практике
🔴сегментировали затраты по командам, сервисам и владельцам
🔴вытащили биллинг, утилизацию, мониторинг в единую модель
🔴создали систему рекомендаций (висящие диски, CPU, трафик)
🔴добавили честные исключения — если рекомендация технически не подходит
🔴раскрыли инженерам ВСЕ формулы, данные и расчёты
🔴сделали COIN внутренним продуктом: версионирование, обновления, трекинг

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

Что получили в итоге
🟣инженеры наконец видят реальную картину расходов
🟣команды начали соревноваться сами с собой, улучшая COIN
🟣исчезли споры «мы и так оптимизируем» — всё видно по метрике
🟣руководство получает честные данные для решений
🟣оптимизация перестала быть разовым проектом и стала культурой

Источник: доклад Salesforce на FinOps X, COIN Score Framework
#кейсы_FinOps

✅ Подписаться

📣Сервисы Яндекса легли — и не только у вас

Если вы вдруг заметили, что поиск Яндекса не открывается, платежный сервис Пэй не позволяет провести оплату, а такси не вызывается, знайте, вы такой не один. Мы в Практиках FinOps этого добра тоже хлебнули — сидели, ловили 504 и пытались понять, в чем же дело.

Оказалось, что в зоне ru-central-1b упал кусок сетевых дисков, и повалились почти все, кто на них завязан, в т.ч. Аптека.ру, КИОН и ФНС. Кому-то повезло больше, и их отпустило почти сразу, а кто-то — как, например, мы — был вынужден терпеть до самого обеда.

Яндекс официально подтвердил сбой и прислал комментарий:

«Наблюдалась частичная недоступность сервисов в зоне ru-central1-b. Это был локальный сбой некоторых сервисов, остальные зоны работали без перебоев. На данный момент работа сервисов восстановлена».

Хорошая новость в том, что сейчас всё уже подняли. Плохая — что такие истории случаются не только в Яндексе и не только в России. Так трясёт всех клауд-нейтив игроков, кто живёт полностью в облаке и искренне верит, что «ну мы же в облаке, там всё надёжно».

И вот тут начинается самое интересное. Годами компании повторяли мантру, что свой ЦОД это прошлый век и всё должно жить в облаке. А потом облако ложится посреди рабочего дня, и весь этот нарратив тихо сворачивается и делает вид, что его никогда не существовало.

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

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

✅ Подписаться

Или танец с бубном надежнее? 😁

✅ Подписаться

Вакансия недели | Аналитик FinOps

💫Клаудмастер ищет FinOps-аналитика

З/п: обсуждается на собеседовании
Формат работы: удалённо
Опыт: от 2-х лет

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

Что важно для роли
🟢опыт в FinOps, cloud economics, IT-финансах или аналитике данных от 2-х лет
🟢понимание, как устроено ценообразование и биллинг у провайдеров разных категорий
🟢умение разбирать данные и приводить их к структуре: DataLens, Excel, SQL
🟢навык финансового моделирования и работа с бюджетами
🟢способность говорить на одном языке и с технарями, и с финансистами

Что предстоит делать
🟣анализировать расходы в мультиоблачных и гибридных средах
🟣строить модели потребления, выявлять аномалии и искать точки экономии
🟣помогать командам внедрять FinOps-подход и выстраивать прозрачность в расходах

#finops_карьера

✅ Подписаться

🤩Ох уж эти непредсказуемые счета до FinOps

✅ Подписаться

💫С первым днём зимы!

До праздников осталось чуть-чуть, а до конца отчётов как обычно, вечность. Чтобы пережить декабрь спокойно, сохраняйтесь в Excel почаще или просто включите автосохранение 😁

✅ Подписаться

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

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

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

Как считается
➖ CPU: использованные ядро-часы / количество выделенных ядер
➖ Память: фактическое потребление в гигабайтах / выделенный объём
➖ Хранилище: используемые GB / выделенное пространство

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

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

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

Источник: FinOps Foundation.
#считаем_finops

✅ Практики FinOps | База знаний