Готово ли ваше облако к 2026 году? Быстрый FinOps-чек-лист
Облачные расходы растут, а контроль и прозрачность часто не поспевают. Чтобы понять, насколько процессы готовы к следующему году, эксперты из Практики FinOps подготовили короткий чек-лист.
Это бесплатный инструмент в формате гугл-таблицы. Прохождение занимает 5–7 минут.
Что дает чек-лист:
видно, где процессы уже работают, а где есть пробелы
понятно, на каких этапах теряется прозрачность расходов
есть конкретные шаги, что имеет смысл внедрять дальше
Чек-лист можно пройти одному, например CTO или Head of Engineering, либо вместе с командой, инженером, архитектором и финансовым специалистом.
Результат, понятный срез текущего состояния и ориентиры, как корректировать облачные расходы в 2026 году.
Разная тарификация. Один провайдер включает трафик в стоимость ВМ, второй берёт за каждый гигабайт отдельно. Третий считает по часам, четвёртый – по фиксу. Свести все это воедино – задачка со звездочкой.
Стоимость межоблачного трафика. Если база живёт в одном облаке, а приложение – в другом, каждый запрос гоняет данные туда-обратно.
Отсутствие прозрачности. Когда никто не знает, во что обходится работа, – это большая проблема. Ведь если не знаешь цифры, то и оптимизировать нечего.
Что с этим делать?
Закладывать мультиклауд в архитектуру сразу. Kubernetes, Terraform, инфраструктура как код — это не модные словечки, а реальная защита от vendor lock-in.
Считать cost per unit для каждого сервиса.
Давать командам бюджеты и показывать реальные цифры. Когда разработчики видят, что их фича жрёт 300 тысяч в месяц, они вдруг начинают задумываться об оптимизации.
Нарисовать схему, где что лежит. Часто оказывается достаточно просто переставить сервисы и таким образом сократить расходы на трафик почти вдвое.
Есть что сказать по теме мультиклауд? Присоединяйтесь к нашему комьюнити Практики FinOps. Там очень ждут вашего мнения.
Уровень загрузки ресурсов (Percentage Resource Utilization)
Уровень загрузки ресурсов помогает быстро понять, насколько действительно используются выделенные мощности. Это один из самых простых и при этом самых рабочих способов найти неоптимальности в инфраструктуре. Компании начинают применять его ещё до формального внедрения FinOps, просто потому что здравый смысл подсказывает: если сервис использует 5% ресурсов, есть повод что-то менять.
Мы смотрим на три базовых показателя. Это CPU, память и диск. Этого достаточно, чтобы увидеть общую картину. Да, в инфраструктуре есть и другие ресурсы, например трафик, но для первичной диагностики хватает именно этих трёх.
Как считается
➖ CPU: использованные ядро-часы / количество выделенных ядер
➖ Память: фактическое потребление в гигабайтах / выделенный объём
➖ Хранилище: используемые GB / выделенное пространство
Что даёт этот анализ
Когда компания оценивает уровень загрузки, она перестаёт работать на предположениях и начинает принимать решения на фактах. На практике это чаще всего приводит к трём сценариям.
Команда отказывается от ресурсных объектов, если загрузка держится на уровне нескольких %.
Команда объединяет инфраструктуру. Например, три виртуальные машины загружены по 20% каждая, их сводят в одну, а две отключают.
Команда корректирует конфигурацию. Это классический rightsizing, когда сервису просто уменьшают объём ресурсов, потому что реальная нагрузка намного ниже.
Это базовый навык, с которого начинается оптимизация в любой компании. Он одинаково полезен и в публичных облаках и в частных инфраструктурах. И независимо от уровня зрелости, компании, которые работают с фактической загрузкой, быстрее находят резервы, снижают расходы и точнее планируют будущие потребности. (Источник: FinOps Foundation).
Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.
Если во вторник утром сервисы Яндекса работали у вас через раз, знайте, что вы такой не один. Мы в Практиках FinOps тоже смотрели на ошибку 504 и думали, что это у нас что-то сломалось. А оказалось, это ru-central-1b упал. Поэтому полетело все, что там крутилось: Аптека.ру, КИОН, ФНС и много кто еще.
К обеду все починили. Только вот Яндекс такой не один. Последние недели облачные провайдеры падают один за другим как доминошки. То AWS накроется, то Azure, то Cloudlfare. То есть, по сути, даже неважно, где вы хоститесь: cloud-native компании накрывает независимо от географии.
На бумаге аптайм в 99,95%, обещанный провайдерами, выглядит очень привлекательно, но на практике оказывается так, что даже одна упавшая зона может положить десятки сервисов. Причем происходит это, как правило, именно в самый неудобный момент как у Яндекса: утро понедельника, пиковая нагрузка, куча клиентов. И тут бац — лежим. Тут волей-неволей задумаешься о том, чтобы уйти в гибрид.
Да и почему бы, собственно, нет? Гибридная инфраструктура сейчас – это отнюдь не перестраховка параноиков, а более чем здравый подход, который позволяет разместить все самые критичные сервисы на собственных серверах. Упала зона — половина продолжает работать. А если FinOps применим к гибриду не хуже, чем к облаку, оснований отказываться от него фактически и не остается.
Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе. Там много интересного.
Как научить команды экономить IT-бюджет: 3 рабочих совета
Упс…
Хотите довести финдира до нервного срыва? Просто не отключайте на выходные тестовые инстансы, а еще лучше – разверните staging на том же железе, что продакшен. А когда счет за облако придет на 800 тысяч вместо 300, спросите: "А при чем тут я?".
Нет, это не вредные советы Г. Остера, это жизнеописание большинства компаний, которые не в курсе культуры разумного потребления ресурсов.
Метрики затрат в Grafana. Если стоимость работы кластера отображается рядом с загрузкой CPU и потреблением памяти, разработчик реально видит, что во что обходится. Случился скачок расходов на графике — значит, надо разбираться. Только на этом можно сэкономить 20-30%.
Калькулятор стоимости в PR. Штуки типа Infracost смотрят на изменения в инфраструктурном коде и прямо в Pull Request пишут, во что это выльется. Так можно отсекать слишком дорогие вещи еще на этапе ревью.
Собственный бюджет команды. Если бюджет превратился из общего в индивидуальный, пространства для маневра станет меньше, но и от халатного отношения к деньгам придется отказаться. Ведь если финансы закончатся — разработка встанет. Когда понимаешь, что лично отвечаешь за перерасход, начинаешь мыслить иначе. Для начала хватит простых showback-отчетов: сколько потратили, сколько планировали, где можно ужаться.
Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе. Там много интересного.
Фишки FinOps Radar: бесплатная платформа, которая помогает экономить в Yandex Cloud
Как говорили в старину, с FinOps Radar и облако милее
Облако – вещь удобная, но непредсказуемая. Особенно, если вести учет расходов по-старинке, в Excel. Таблички, конечно, работают неплохо, но только в железной инфраструктуре. А в облаке без специальных инструментов никак.
FinOps Radar — это первый бесплатный сервис для оптимизации расходов в Yandex Cloud.
Что он умеет:
Обнаружение аномалий. Сервис сравнивает текущие расходы с расходами за последнюю неделю. Если траты выросли больше чем на 5% от среднего, система помечает это цветом. Желтый — рост 5-10%, все что выше – красный. Можно сразу открыть детализацию и понять, какой сервис съел бюджет.
Поиск зомби-ресурсов. Это все то, за что вы платите впустую: забытые инстансы, неприсоединенные диски и т.д. Платформа показывает сумму потенциальной экономии по каждой позиции.
Автоалерты. Письма об аномалиях приходят в 05:00, о новых рекомендациях — в 09:00. Можно даже выгрузить отчет в Excel и в конце месяца показать начальству, сколько денег сэкономили.
Главное — сервис ничего не трогает в вашей инфраструктуре. Только смотрит и советует. У него даже прав таких нет. Вы даете доступ только для чтения, он собирает данные и показывает проблемы. А как на них реагировать — решаете сами.
Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.
А вы знали, что почти треть компаний не знает, куда уходят их облачные бюджеты? Нет, они, конечно, получают счета и даже по ним платят. Но почему в прошлом месяце было так, а в этом эдак, и кто в этом виноват – не имеют никакого представления.
Естественно, при таком подходе говорить о какой-либо эффективности не приходится. Потому что если одни экономят, а другие забивают на отключение тестовых сред и гоняют MongoDB там, где хватило бы PostgreSQL, толку не будет. Ведь платить-то все равно из общего котла.
Уровень 1 - тот самый общий котел, когда выделяется какая-то сумма, и вся она тратится без отслеживания эффективности. На этом уровне прозрачность находится на нуле.
Уровень 2 - расходы распределяются по провайдерам. На этом уровне уже видно, что VK Cloud выставил столько-то, Яндекс Облако столько-то. Но почему – пока непонятно.
Уровень 3 – раскладка по услугам. Compute съедает 60-70%, Storage – 20-30%, трафик – 10-15%. Уже появляется понимание, где самые дорогие компоненты.
Уровень 4 – тегирование ресурсов. Так будет видно, какая команда тратит больше.
Уровень 5 – cost-центры с реальными бюджетами. Showback показывает командам траты без списания денег. Chargeback списывает реальные суммы с реальных бюджетов.
Компании, дошедшие до пятого уровня, экономят 20-30% без потери производительности.
Есть примеры обратного или хотите чем-то поделиться? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.
FinOps против Excel: кто управляет деньгами в облаке
Классический финконтроль — это история, которая в облаке почти не работает.
На первый взгляд кажется, что финконтроль в облаке работает так же, как и раньше. Таблицы, бюджеты, отчеты, всё под контролем. Но стоит заглянуть глубже, и привычные инструменты начинают давать сбой.
Когда инфраструктура была железной, всё было стабильно. Купили сервер, занесли в бухгалтерию, рассчитали амортизацию, и живи спокойно. Расходы предсказуемы, план сбывается, отчеты сходятся.
А потом пришло облако. Сегодня нагрузка почти нулевая, а завтра конкурента блокируют, и трафик у тебя растет в разы. Автоскейлинг добавляет новые инстансы, счёт за неделю превращается в месячный.
CFO смотрит на это и разводит руками. Финансисты видят цифры, но не понимают, почему всё так скачет.
Проблема не в суммах, а в подходе. Старый финконтроль держится на стабильности, а облако живёт по принципу «всё меняется каждую минуту». Любая мелочь в архитектуре мгновенно отражается в P&L, а привычные отчеты не успевают за скоростью изменений.
Вместо агрегированных сумм — расходы по командам и проектам
Вместо запоздалых реакций — наблюдение в реальном времени.
Это уже даже не про “оптимизацию”, а про банальную прозрачность. Или транспарентность. Называйте как хотите.
Главное – что благодаря этому CFO может видеть деньги не в Excel, а прямо в инфраструктуре, и перестает реагировать на факты, а начинает ими реально управлять.
Тут-то баланс и восстанавливается: разработчики понимают цену своего кода, финансисты — динамику расходов, а бухгалтерия наконец перестает удивляться собственным счетам.
Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.
Облачное хранилище работает отлично, пока работает. Но провайдер может закрыться, подписка закончиться, а аккаунт заблокироваться. Что тогда будет с вашими фотками?
Закрытие сервиса
Обычно провайдеры предупреждают о закрытии за месяц-два или три. Это время дается, чтобы вы могли выгрузить всё, что хранилось в облаке. Но общего правила нет.
Parse объявил о закрытии за год, а Everpix – за месяц. Но и в том, и в другом случае пользователям дали возможность выгрузить свои данные. Только после этого архивы удалили физически.
Истечение подписки
У каждого провайдера свои правила хранения после окончания оплаченного периода. iCloud держит данные всего месяц, Dropbox – 2, а Google Drive позволяет загрузить их в течение двух лет.
Часть сервисов блокирует только загрузку новых файлов, оставляя возможность скачать старые. Но после истечения грейс-периода поддержка не восстанавливает ничего.
Есть что рассказать? Станьте голосом комьюнити и делитесь с участниками своими кейсами в сообществе.
Случаи потери данных
Бывает, что данные пропадают случайно. Вероятность такого исхода мала, но не равна нулю. Так, в 2015 году в дата-центр Google в Бельгии молния ударила 4 раза подряд. Пострадало около 0.000001% данных, то есть где-то 10 байт на гигабайт. Тем, кто попал в эту погрешность, конечно, легче не стало. Но цифры показывают, насколько это редкая ситуация.
В целом же, облака остаются более надёжным решением, в отличие от локальных дисков. Главное – оплачивать подписку вовремя.
Выгоден ли FinOps? Как рассчитать ROI и определить экономию
Выгоден ли FinOps? Безусловно. Но мало осознать это самому. В этом нужно убедить еще и руководство. А прениями сторон тут точно не обойтись. Топы – люди цифр, поэтому им нужны реальные расчеты и гарантии возврата вложенных средств. Значит, необходимы конкретные метрики.
Базовая формула расчет ROI для FinOps стандартна:
Но выгода в облаке — не просто сэкономленные рубли. Сюда входят предотвращенные перерасходы, время инженеров, точность бюджетов. И всё это надо переводить в цифры.
А как? Для этого есть специальные способы расчетов.
Снижение затрат:
Расходы падают на 15-30% без потери производительности. Всего-то и нужно, что отключить забытые dev-серверы, не брать инстансы с запасом и пользоваться скидками.
Cost per Unit (стоимость обслуживания пользователя):
Тут без сюрпризов: растет с нагрузкой — плохо масштабируется. Падает — все ок.
Точность бюджета:
Без FinOps погрешность может достигать 25-30%, а с ним – 5-8%.
Продуктивность:
Автоматизация высвобождает 10-12 часов в неделю. При ставке 3000₽/час — экономия 30-40 тысяч рублей на человека.
Опыт показывает, что FinOps окупается за полгода-год, а экономия продолжает держаться и дальше. Главное — понимать, что это не разовая чистка ресурсов, а постоянный процесс.
Есть что рассказать? Станьте голосом комьюнити и делитесь с остальными своими кейсами в сообществе.
Учиться на чужих ошибках дешевле, чем на своих. Практики FinOps рассказали, как разбирались с облачными расходами.
FinOps без иллюзий
Игорь Гальцев: FinOps – это не должность и не софт, а процесс. Инженеры, финансисты и менеджмент должны работать вместе, а из инструментов – только теги, распределенное бюджетирование и алерты.
Когда счёт прилетает внезапно
Антон Черноусов из Yandex Cloud запустил проект без лимитов. Как итог – счёт на $2700 за день. Решить проблему помогла настройка бюджетов, алертов и автоматизации.
Практика и культура
Антон Егорушков из Купер (СберМаркет) рассказал, что динамические стенды и скоринг команд напрямую влияют на то, как расходуются бюджеты. Поэтому культуру FinOps строить сразу, иначе потом выйдет дороже.
Простые шаги
Станислав Погоржельский из VK Cloud считает, что экономия приходит как побочный эффект порядка. Добиться этого можно тестированием нагрузки, настройкой лимиты автоскейла и хранением файлов там, где надо.
FinOps в Kubernetes
Алексей Минаев: 70% переплат сидят в Kubernetes, потому что ресурсов выделяют больше, чем используют. В итоге CPU загружен на 13%, память на 20%. Правильные реквесты и автоскейл поднимают утилизацию до нормальных 70%, и переплата исчезает.
SaaS и лицензии
Дитер Мейсон из Roku: FinOps не ограничивается только облаком. FinOps – это в том числе про управление подписками, аномалии в продлениях лицензий и, конечно, расчёт ROI.
Поначалу Купер вообще не применял FinOps в своей работе, но потом привязал теги, CMDB и автоматизацию через Terraform. Результат: 75% расходов распределяются по владельцам, прозрачность и прогнозируемость бюджета.
ST Microelectronics работают с маленькой FinOps-командой, но экономят миллионы. Инженеры сами прогнозируют свои расходы и получают бонусы за точность прогнозов. В итоге их экономия – 30% без ущерба для SLA.
Transport for NSW безуспешно боролись с зомби-ресурсами и ручными выгрузками. А потом запустили FinOps-дашборды и детектор аномалий. Как результат – расходы на Data Lake упали на 22%.
inQdo Cloud считали все расходы в Excel. Но когда внедрили FinOps-платформу, автоматизировали биллинг и нашли утечки бюджета, ситуация изменилась. Аналитику они сделали платной услугой для клиентов — и FinOps начал зарабатывать сам на себя.
Еще мы разобрали кейсы Qventus, Sportradar, Лемана Тех и NinjaCat. Проблемы у всех похожие, а решения разные: кто-то внедрил chargeback, кто-то показал разрабам цену запроса, а кто-то просто настроил автовыключение неиспользуемых ресурсов. Но все остались в плюсе.
Есть что рассказать? Залетайте в наше сообщество в Telegram и поделитесь своей историей с единомышленниками.
Как бы странно это ни звучало, но главное, на чем держится FinOps, — это общий язык, на котором говорят и финансисты, и технари. При этом у каждого из них есть своя роль:
➖ инженеры и DevOps, которые запускают ресурсы и должны видеть их стоимость
➖ продакты и бизнес-менеджеры, которые отвечают за ценность и окупаемость
➖ финансисты и закупки, которые смотрят на бюджеты и договоры
➖ руководители и C-level, которые принимают стратегические решения
В каждой компании распределение может отличаться. Но идея одна: никто не работает в вакууме. Инженеры понимают, во сколько обходятся их сервисы, финансисты знают, за что платят, а топы видят, какую отдачу приносит облако.
Такой подход убирает вечный спор, кто сколько тратит, и превращает расходы в совместную ответственность.
Близка тема, где финансы и инженеры наконец говорят на одном языке? Заглядываем в «Практики FinOps», там выходят кейсы, доклады, лайфхаки и немного самоиронии про жизнь в облаке.
Управлять облачными расходами часто сложнее, чем кажется
FinOps Community Bot
Счета растут, бюджеты сложно прогнозировать, а прозрачности мало. Особенно это ощущают компании, где несколько команд используют разные облачные сервисы и никто не видит полной картины.
Чтобы помочь компаниям системнее подойти к FinOps, мы собрали FinOps Community Bot. Это Telegram-бот, который объединяет несколько инструментов:
Тест по FinOps. 9 вопросов за 5–7 минут. Бот рассчитает уровень зрелости вашей компании в управлении облачными затратами и подскажет следующие шаги.
База знаний. Подборка статей, инструкций и практических материалов по FinOps.
Календарь событий. Митапы, вебинары и конференции для специалистов и руководителей.
Закрытый чат. Возможность обсудить опыт с коллегами и задать вопросы сообществу.
Бот полезен для любых ролей: CEO увидит картину в целом, CFO получит идеи по оптимизации расходов, DevOps-инженеры и CTO — практические шаги для улучшения процессов.
Начать просто: пройдите тест, получите рекомендации и используйте остальные функции бота для глубокого погружения и обмена опытом.
