Российский бизнес активно инвестирует в облака, но по сравнению с развитыми странами этот сегмент у нас в стране пока занимает довольно скромное место. В США, к примеру, облачные сервисы уже составляют до половины корпоративных ИТ-расходов, тогда как в России их доля в разы ниже. Однако это лишь значит, что у нас в стране есть огромный потенциал для роста в данной сфере. Только за прошлый год облачный рынок в РФ вырос более чем на 36%, и это определило не только позитивный, но и негативный тренд, который заключается в неэффективном расходовании средств. Стало ясно, что техническим специалистам уже недостаточно просто разрабатывать и поддерживать системы. Теперь нужно понимать экономику каждого виртуального сервера, каждой базы данных, каждого терабайта трафика. Но как? Помогут, как всегда, метрики.

Подписывайтесь на наше FinOps-комьюнити в Telegram. Обещаем на спамить. Там только настоящая польза, рабочие кейсы и общение с единомышленниками.

1. Коэффициент использования ресурсов

Начнем с основ. Вы платите за облачные ресурсы, и это норма. А вот используются ли они по максимуму? Это первый вопрос, на который нужно ответить честно.

Коэффициент использования показывает, какая часть оплаченных мощностей реально работает под нагрузкой. Если сервер загружен на 20%, значит 80% его мощностей простаивают и содержатся впустую. При этом вы платите за все 100%. Скажете, что это крайности и настолько больших разбросов в показателях быть просто не может. А вот и может.

Исследования показывают, что среднестатистическая компания использует только 13% выделенных процессорных мощностей и 20% памяти в кластерах Kubernetes. Это как снимать дом, а жить в чулане под лестницей. Кому-то может и нравится. Но есть подозрение, что в корпоративной среде лучше делать ставку не на косплей, а на высокую рентабельность бизнеса при минимуме нерациональных расходов.

Как считать? Казалось бы, берешь фактическое потребление, делишь на выделенные ресурсы, получаешь процент. Звучит просто, но реальность несколько сложнее. Нужно правильно собирать метрики. Для обычных виртуальных машин большинство отечественных провайдеров показывают загрузку прямо в консоли управления. VK Cloud, Яндекс.Облако, Cloud.ru — у всех есть базовые графики загрузки.

С контейнерами, конечно, сложнее. Kubernetes создает поды, выделяет им ресурсы через реквесты и лимиты, но фактическое потребление может кардинально отличаться. Эти данные можно собирать через Prometheus, группировать по проектам или окружениям и сравнивать с лимитами. Тогда и станет понятно, где у вас реальная нагрузка, а где просто резерв, который никто не трогает.

Как интерпретировать: для продакшн-систем нормальная загрузка CPU в среднем должно быть на уровне 60-70%. Можно немного больше, но не слишком, чтобы был запас для пиковых нагрузок. А вот память можно нагружать плотнее, до 80-85%. Так что, если видите постоянную загрузку меньше 20%, пора пересматривать размеры инстансов. Или приложение тянет меньше, чем ожидали. Но и в том, и в другом случае это знак – деньги уходят в пустоту.

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

Подводные камни. Конечно, стремиться к загрузке в 100% опасно. Все-таки всплески на проде – это обычное дело, и если их не заложить, может прилететь, когда этого совсем не ждешь. То же самое касается и работы с Java-приложениями, где любое переполнение памяти запускает агрессивную сборку мусора.

2. Процент облачных потерь

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

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

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

Как находить: без автоматизации искать “пустые” ресурсы в большой инфраструктуре нереально. Отечественные провайдеры потихоньку внедряют системы рекомендаций, но пока это скорее исключение, чем правило. Тот же VK Cloud показывает некоторые предложения по оптимизации, а Яндекс.Облако добавляет уведомления о простаивающих ресурсах. Но все остальное приходится делать самим.

Чаще всего для этого приходится писать свои скрипты аудита. Но в целом логика простая: если сервер неделю потребляет меньше 5% CPU и к нему никто не подключается, это кандидат на удаление. Диск не монтировался месяц — тоже под вопросом. База данных без активных соединений — изучаем внимательнее.

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

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

Или вот другая история: приложение удалили, а диск остался. К нему уже никто не подключается, но он все еще болтается в системе и продолжает списывать деньги. Если процессы очистки не настроены, такие забытые тома могут накапливаться буквально десятками, особенно если CI/CD за собой не убирает.

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

3. Доля распределенных затрат

Идем дальше. Допустим, неэффективные ресурсы и мусор мы нашли. Но кто за них отвечает? Без понимания того, кто и за что платит, оптимизация превращается в игру вслепую.

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

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

Как реализовать: логичнее всего использовать теги на всех ресурсах. Если каждый сервер, база, диск будут содержать информацию о команде, проекте, окружении, выявить слабое место будет проще. Да, где-то придется повозиться. Где-то (например, в Kubernetes) будут нужны лейблы на уровне неймспейсов и деплойментов, где-то ручное распределение затрат по пропорциям нагрузки, а где-то придется считать по потребленному CPU, памяти или количеству подов на узле. Но в целом все довольно ясно.

Ведь если у вас на одном ноде работает 3 неймспейса, и один из них держит 60% CPU, другой — 30%, а третий — 10%, именно в такой пропорции и надо раскладывать стоимость этого узла между командами. Кубекост даже может сделать это автоматически, но при желании можно собрать свою метрику вручную.

Российские провайдеры тоже активно развивают возможности тегирования. Cloud.ru предоставляет полноценную систему управления тегами через Tag Management Service и Evolution Tags, позволяющую маркировать виртуальные машины, диски, подсети и группы безопасности с поддержкой API и Terraform. Яндекс.Облако использует систему каталогов для группировки ресурсов по проектам и бизнес-критериям, а также поддерживает лейблы для логической группировки всех ресурсов. Однако техники автоматического проставления тегов при создании ресурсов среди российских провайдеров пока распространены не так как на Западе.

И все бы ничего, но проблемы с доступом из России сильно осложняет их использование. Особенно в условиях усиливающегося тренда на импортозамещение. Поэтому, как говорилось в том анекдоте, надо иметь свои.

Практические советы: начинайте с крупных ресурсов — они дают основной эффект. Внедряйте проверку тегов в пайплайны CI/CD. Регулярно присылайте отчеты о неразмеченных ресурсах команде. А лучше сразу возьмите за правило сами и расскажите остальным, что тег без владельца – минус в карму.

4. Unit Cost — стоимость единицы ценности

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

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

В российских условиях метрика стала актуальнее из-за экономической нестабильности. Компании внимательнее следят за эффективностью каждого рубля. Unit Cost помогает понять, не растет ли стоимость обслуживания клиентов быстрее доходов. А если растет, то почему и что с этим делать.

Как выбрать единицу:

• Для SaaS-продуктов подойдет количество активных пользователей или API-вызовов. Для интернет-магазинов — обработанные заказы.

• Для финтех-решений — транзакции.

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

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

Как считаем: общие облачные затраты делим на количество единиц за период. Сложность в том, что данные лежат в разных системах: расходы — в биллинге провайдера, бизнес-метрики — в аналитике продукта.

У отечественных провайдеров API для биллинга развиты слабее, чем у западных гигантов. Но в целом прогресс налицо. Например, VK Cloud предоставляет программный доступ к детализации, Яндекс.Облако развивает биллинговые API, а Cloud.ru предлагает комплексное решение для контроля затрат с развитой системой программного доступа к биллинговым данным.

Что показывает: снижение Unit Cost говорит о росте эффективности. Или, проще говоря, вы обслуживаете больше пользователей за те же деньги. А рост может быть оправдан новыми функциями или сигнализировать о проблемах производительности.

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

5. Доля зарезервированных ресурсов

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

• Долгосрочный договор

• Предоплата

• Фиксированные мощности

Главное, что все это позволяет получить скидки.

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

Российская специфика

Российские провайдеры предлагают разные модели экономии:

• VK Cloud дает скидки при годовой предоплате

• Яндекс.Облако — при увеличении объемов потребления

• Cloud.ru предлагает индивидуальные тарифы для крупных клиентов.

Сложные модели резервирования, как у AWS или Azure, пока развиты слабо. Но базовый принцип — обязательство тратить определенную сумму в обмен на лучшие условия – работает везде.

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

Допустим, в месяц вы тратите 200 тыс, из них 130 тыс — по предоплате. То есть доля зарезервированных ресурсов составляет 65%. Ваша цель — не просто повысить этот процент, а убедиться, что резерв реально используется. Если резерв куплен, но не работает — это деньги на ветер.

Инструменты для автоматического мониторинга пока редкость. Поэтому такие вещи обычно приходится считать вручную по счетам или строить собственные дашборды через API.

Стратегия: начинайте с анализа стабильных нагрузок. Резервировать имеет смысл продакшн-базы данных, которые крутятся 24/7. Но для переменных нагрузок типа dev-окружения и микросервисов больше применим гибридный подход. В конце концов, глупо резервировать то, что живет меньше месяца.

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

6. Отклонение от бюджета

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

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

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

Отклонение = (Факт – План) / План × 100%

А дальше просто смотрим на цифры. Если расхождение в 20% – это повод разобраться, если 50% и выше – почти трагедия.

Мониторинг: У большинства российских провайдеров уже есть базовые инструменты для отслеживания расходов, но назвать их полноценной системой бюджетного контроля пока сложно. Например, VK Cloud позволяет установить лимиты и присылает уведомления при их превышении. Яндекс Облако предлагает детализацию по проектам, отслеживает динамику трат и развивает аналитику в личном кабинете. 

Однако продвинутые FinOps-функции вроде прогнозирования или автоматических рекомендаций у наших поставщиков пока редкость. Так что часто именно техническим специалистам приходится вручную следить за расходами, чтобы не пролететь с бюджетом. Например, настраивать ежедневные сводки расходов в корпоративный чат или интеграцию с системами мониторинга. Можно завести простую проверку: если дневной расход на 30% выше среднего за неделю — бьем тревогу.

Анализ причин: превышения бюджета могут быть оправданными (рост бизнеса) или сигнализировать о проблемах, и вот они уже могут быть самыми разными. Для поиска причин лучше использовать детализацию по сервисам, регионам и командам. Без такой разбивки вся аналитика превращается в гадание на кофейной гуще: цифры-то есть, а что с ними делать – непонятно.

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

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

7. Аномалии в расходах

И последнее — для тех случаев, когда что-то идет совсем не так. Резкие всплески расходов могут говорить о серьезных проблемах, которые нужно решать немедленно.

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

В российских условиях источники аномалий могут быть весьма специфичными: 

• DDoS-атаки на критическую инфраструктуру

• Резкие изменения в поведении пользователей после блокировок зарубежных сервисов

• Попытки обхода ограничений.

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

Как реализовать: отечественные провайдеры только начинают внедрять ML-системы для выявления аномалий. Пока большинство решений проще западных аналогов.

Базовый подход — статистический анализ. Если дневные расходы выросли больше чем на 50% от среднего за месяц, стоит разобраться в причинах.

Типы проблем зависят от характера всплеска. Резкие скачки чаще всего связаны с багами в коде. Это могут быть зацикленные запросы, неэффективные алгоритмы или просадки в кэшировании. А вот если рост расходов происходит постепенно, это уже может говорить о деградации производительности или о стабильном увеличении нагрузки, которое вы проспали.

Диагностика: начинайте с анализа биллинга — какие сервисы дали рост, в каких дата-центрах. Сопоставляйте с логами приложений, метриками мониторинга, недавними релизами.

Для российских условий важно учитывать внешние события:

• Новости, которые влияют на поведение пользователей

• Изменения в законодательстве

• Проблемы у конкурентов, которые могут привести к росту вашей нагрузки.

Практические шаги

Эти семь метрик работают не поодиночке, они дополняют друг друга и вместе дают объемную картину. Но просто знать про них — мало. Нужно уметь применять их на практике, особенно в реалиях российского рынка. Вот несколько рекомендаций, с чего начать и как выстроить подход к FinOps пошагово:

• Начинайте постепенно. Выберите 2-3 самые критичные метрики. Использование доступных ресурсов и облачные потери хорошо подходят для старта.

• Учитывайте местную специфику. Ограниченный выбор провайдеров, валютные риски, регуляторные требования – все это влияет на интерпретацию метрик и принятие решений.

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

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

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

Управление облачными расходами больше не экзотика. Сегодня — особенно в условиях ограниченного выбора провайдеров и быстро меняющегося регулирования — эта практика стала критически важной. Описанные метрики помогут превратить облачные траты из черного ящика в управляемый инструмент оптимизации. Главное — начать измерять. И помнить: не нужно оптимизировать все сразу. Лучше выбрать 2-3 самые болезненные точки и сосредоточиться на них.

Больше про FinOps в нашем сообществе в Telegram.