Облако по природе своей устроено так, что деньги из него утекают как песок сквозь пальцы. Не потому что провайдеры жадные или инженеры попались безответственные. Всему виной органический рост: тут один сервис поднял новый кластер, здесь команда не выключила стейджинг после релиза, там забыли про снапшот двухлетней давности. По отдельности каждый из этих факапов – вроде не катастрофа. Но в конце месяца счета неизменно напоминают о том, что думать так — большое заблуждение. В прошлых материалах цикла мы уже разбирали типичные боли тех, кто работает с облаками, и рассматривали, почему счета растут, хотя инфраструктура не меняется. А сегодня поговорим про первый и самый важный методологии FinOps, которая должна решить эти проблемы: Inform.
Практики FinOps в Telegram| Бот
Почему начинать с оптимизации — плохая идея
Первая мысль, которая появляется, когда счет за облако в очередной раз оказывается процентов на 40 выше запланированного, — взять и что-нибудь урезать. Неважно что. Лишь бы сократить расходы. Ну, оно вроде и логично. Режем лишнее – оставляем нужное – сокращаем траты.
Вот только вся проблема в том, что без понимания структуры затрат такая оптимизация — это что угодно, только не она. Потому что так можно запросто угробить десяток-другой человекочасов на тюнинг компонента, который дает 2% от общего счета, и не заметить, что 60% уходит на базы данных, про которые никто не вспоминал с момента основания компании. Или, скажем, прибить сервис, который выглядел как заброшенный, но на самом деле держал чей-то продакшн. И ходи потом доказывай, что не верблюд.
Поэтому и начинается FinOps не с Optimize, а с Inform. Ведь пока нет реальной картины расходов, любое вмешательство в инфраструктуру — чистой воды вредительство.
Суть фазы Inform — создать единый источник правды о затратах. То есть это должен быть не просто дашборд с общей суммой, а система, в которой инженер, менеджер и финансист смотрят на одни и те же данные и, что самое главное, одинаково их читают и понимают.
Казалось бы, задачка – не бей лежачего. Просто найми кого-нибудь умнее австралопитеков – и дело в шляпе. Ан нет. Должности-то у всех разные, и образ мыслей тоже разный. Инженер думает ресурсами, менеджер — проектами, финансист — деньгами. Поэтому наша задача – все это грамотно состыковать.
Зачем? Да потому что есть и еще один эффект, который в деньгах не считается, но на практике чувствуется очень хорошо. Он состоит в том, что когда разработчики видят, во что обходится их dev-среда, они начинают относиться к ее аптайму ответственнее и сами выключают все на ночь без лишних напоминаний. Не потому что этого требует регламент, а потому что зачем жечь деньги, когда можно не жечь?
Четыре ключевые компетенции фазы Inform
Фаза Inform строится на четырех компетенциях. Сразу предупреждаю: визуально они могут выглядеть как пункты из методички, которую ваш университетский преподаватель по ИГПЗС (не спрашивайте, это личное) втюхивал вам перед зачетом. Но пусть вас это не отталкивает. Во-первых, потому что страшного там ничего нет. А, во-вторых, потому что за каждой из них стоит конкретная практическая задача, без которой чуда не случится.
Сбор и нормализация данных. Все начинается с биллинга — и это, пожалуй, самая неромантичная часть. Несмотря на то что провайдеры чаще всего без проблем позволяют получить детализацию, каждый из них делает это в каком-то своем формате. Поэтому первая задача, которая перед нами стоит, — вытащить из этого что-то читаемое: с нужной гранулярностью, в единой модели, пригодной для сравнения периодов и срезов. Большинство крупных провайдеров уже дают API и коннекторы к популярным BI — так что технически это решаемо. Но даже штатный биллинговый интерфейс закрывает многое, если знать, куда смотреть.
Аллокация затрат. Если первый пункт мы назвали самым неромантичным, то этот назовем самым болезненным. Дело в том, что провайдерский счет состоит из сущностей, понятных только технарям: инстансы, диски, трафик, managed-сервисы. Но бизнес-то работает в терминах проектов, команд и продуктов. Так что аллокация — это приведение всех этих штук к единому знаменателю, когда мы берем и соотносим каждый потраченный рубль с конкретной бизнес-единицей. А иначе будет невозможно понять, кто нагенерил все эти расходы, которые несет компания. И, как следствие, невозможно будет строить хоть сколь-нибудь осмысленное бюджетирование.
Отчетность и аналитика. Допустим, данные собрали, нормализовали и даже что-то поняли. Но смотреть на общую сумму в счете — не аналитика. Аналитика начинается там, где появляются вопросы: какой сервис вырос за последние две недели? Где пики потребления и с чем они совпадают по времени? Какой проект тратит непропорционально много относительно своей нагрузки? Именно ответы на такие вопросы и становятся основой для решений.
Что касается управления аномалиями, это уже задача фазы Operate, и мы подробно разберем ее в одном из следующих материалов цикла.
Штатные инструменты FinOps: что доступно бесплатно
Многие считают FinOps какой-то блажью: не то игрушкой для мега-корпораций, не то подобием секты с позитивным мышлением, платиновыми директорами и невозможностью реально для “низов” реально чего-то достичь. Хорошая новость: это неправда.
Никуда ввязываться и тратиться на что-то с сомнительной нужностью не придется. Большинство зрелых российских провайдеров уже включили в базовый функционал все, что может вам потребоваться в фазе Inform.
Яндекс Облако, например, предлагает бесплатные дашборды на базе DataLens прямо из коробки. Они уже включают в себя готовые отчеты, которые закрывают большую часть аналитических потребностей на старте:
потребление по месяцам для отслеживания динамики и планирования бюджета;
разбивка текущего месяца по сервисам и продуктам, где сразу видно, что формирует основную часть счета;
разбивка по облакам и каталогам — базовая аллокация по командам или проектам;
подборка из 10 самых дорогих ресурсов, которая показывает, где оптимизация даст максимальный эффект;
утилизация зарезервированных ресурсов, которая позволяет убедиться, что за committed use не платят впустую.
Кстати, для продвинутой аналитики в DataLens также доступен Нейроаналитик – AI-агент, который помогает визуализировать данные и находить инсайты. Он входит в тариф Business (990 рублей в месяц за пользователя), но для базовых дашбордов и отчетов он не обязателен.
Для тех, кому штатных отчетов мало и хочется построить что-то свое, есть простой и рабочий пайплайн: детализация биллинга выгружается в Object Storage, оттуда ее забирает Yandex Query, который умеет делать SQL-запросы прямо по файлам в бакете. И все это без отдельной базы данных и лишней инфраструктуры. На выходе же получаем данные в любом нужном срезе, которые подключаются к DataLens или любому другому BI.
Важный нюанс: в биллинговой детализации отдельные ресурсы (CPU, RAM, диск) не привязаны к конкретному объекту, например к виртуальной машине. Чтобы строить отчеты именно по объектам, а не по разрозненным компонентам, придется дополнительно подтягивать эту информацию через API провайдера и связывать ее с биллингом.
Реализуется за день. Зато покрывает полный цикл: подключение источника, сбор, нормализация и представление в виде дашборда.
Правда, здесь довольно быстро упираешься в одну вещь. Провайдеры структурируют свои отчеты вокруг технических сущностей. То есть они отвечают на вопрос что потреблялось, но не отвечают на вопрос кем и зачем. Тут-то и начинается задача аллокации.
Аллокация: без тегов не взлетит
Провайдерские отчеты – вещь сама по себе хорошая, но очень специфическая по содержанию. Они, как мы уже упоминали, не дают понимания, какая команда потребила те или иные ресурсы, какой проект и т.п.
Базовый уровень аллокации дает сама структура провайдера. В Яндекс Облаке это иерархия «Облако – Каталог», в CloudDirector – Tenant, vDC и vApp, в Azure – Tenant, Subscription и Resource Group. Разнося ресурсы по этим сущностям, уже можно получить грубую разбивку по командам или проектам.
Но этого недостаточно. Структура провайдера - это организационные рамки, а не бизнес-логика. Один каталог может обслуживать несколько команд, один subscription – несколько продуктов. Поэтому, чтобы аллокация стала точной, нужны теги.
Это как раз тот инструмент, благодаря которому мы можем взять технические сущности из счета и соотнести каждую с конкретной бизнес-единицей: командой, продуктом, проектом.
Тег — это метаданные, которые прикрепляются к ресурсу при создании: team, project, environment, owner.
Казалось бы, проставили и все. Но нет. Потому что работают они только при выполнении трех условий:
Теги есть на всех ресурсах (или хотя бы на большинстве);
Проставлены консистентно;
Обновляются при изменении контекста.
Ручное тегирование – это стратегия провала. Люди ошибаются, забывают, используют разные названия для одного и того же. Единственный надежный подход – принудительное тегирование через IaC и CI/CD: нет тега – нет деплоя.
Реализуется через линтеры для Terraform или Pulumi, которые проверяют наличие обязательных тегов до применения плана. На больших инфраструктурах добиться стопроцентного покрытия --- почти утопия, но даже частичное внедрение через IaC радикально улучшает качество данных по сравнению с ручным подходом.
Некоторые провайдеры также позволяют настроить политики на уровне облака, которые блокируют создание ресурсов без нужных меток. Подробнее про построение модели тегирования и типичные ошибки при ее внедрении мы еще поговорим в отдельном материале цикла.
Главное – что, когда тегирование выстроено, аллокация становится самой рядовой практикой, а не манной небесной. Команды просто видят свой срез расходов и о бюджетах уже рассуждают со знанием дела.
Вебинар по FinOps
Разберем:
Как запустить FinOps без бюджета на платформы и консультантов
Где компании чаще всего ошибаются (и как не повторить их путь)
Как пройти все этапы на практике, а не в теории
>>> Зарегистрироваться на вебинар <<<
Shared-ресурсы: тег не поможет нам
Несмотря на то что теги закрывают вопрос аллокации почти для всего, существует целый класс инфраструктуры, к которому тег попросту не пришьешь. Речь про shared-ресурсы:
Общий Kubernetes-кластер
Централизованный мониторинг
Сетевые балансировщики
Все это жрет деньги, но кому выставлять счет, непонятно. И теги тут не помогут — команд-то несколько.
Что же делать?
Игнорировать такие расходы нельзя. В крупных инфраструктурах shared-компоненты запросто могут составлять 20–30% от общего счета. Просто списывать их в «общие расходы» было бы странно. Но делать этого и не нужно, потому что есть несколько подходов к распределению таких затрат:
Even split — самый простой. Мы берем общую стоимость shared-ресурса и делим поровну между всеми командами, которые им пользуются. Если k8s-кластер стоит 100 тысяч рублей в месяц и на нем работают 4 команды — каждая получает по 25 тысяч. Преимущества: просто считать, легко объяснять. Недостатки: несправедливо, если команды потребляют ресурсы совершенно по-разному. Хотя для старта сойдет.
Proportional — честнее, но сложнее. Тут мы распределяем затраты пропорционально фактическому потреблению. Для k8s это считается по метрикам из Prometheus: средний CPU request, memory request, количество подов. Данные сопоставляем с биллингом и получаем долю каждой команды. Такой подход требует настройки сбора метрик, зато дает адекватную картину.
Fixed ratio — договорной подход. Команды заранее согласовывают фиксированные доли независимо от фактического потребления. Например, платформенная команда берет на себя 40% расходов на shared-инфраструктуру, продуктовые команды делят остальные 60% поровну. Работает там, где измерить реальное потребление сложно или попросту некогда.
Посмотрим на конкретный пример. Допустим, у нас есть managed Kubernetes в Яндекс Облаке на трех нодах по 8 vCPU и 32 ГБ RAM каждая. Стоимость при on-demand тарификации — около 45 000 рублей в месяц. На кластере работают три команды:
Команда | CPU request (среднее) | Memory request (среднее) | Доля |
Backend | 12 vCPU | 48 ГБ | 50% |
Frontend | 6 vCPU | 24 ГБ | 25% |
Analytics | 6 vCPU | 24 ГБ | 25% |
При пропорциональном распределении Backend получает счет на 22 500 рублей, а Frontend и Analytics — по 11 250. При even split каждая команда заплатила бы по 15 000. То есть Backend оказался бы в очевидном выигрыше за чужой счет.
На практике выбор метода зависит от зрелости процессов. Для старта even split — нормально. Главное – начать хоть как-то распределять shared-расходы, а не игнорировать их. А потом, когда инструменты сбора метрик будут настроены и появятся данные, можно будет переходить к proportional.
Нормализация данных: почему сырой биллинг не читается
Теги решают вопрос владения. С этим разобрались. Но есть еще одна вещь, про которую обычно вспоминают позже, чем надо, — качество самих данных. Провайдер отдает все, что у него есть, и формально этого достаточно. Только это еще не значит, что полученные данные пригодны для анализа. Потому что тут есть три нюанса, каждый из которых портит вам жизнь по-своему:
Гранулярность. По умолчанию детализация идет с разбивкой по дням. Для месячного анализа нормально, но если нужно отследить аномалию с точностью до часа — придется либо настраивать более частую выгрузку, либо параллельно тянуть метрики потребления из Cloud Monitoring и сопоставлять их с биллингом.
Нейминг ресурсов. resource_id в биллинге — это технический идентификатор вроде fhmxxxxxxxxxxxxxxxx. Чтобы понять, что это за ресурс, нужно обогащать данные через API провайдера: тянуть имена инстансов, дисков, сервисов и джойнить с биллинговой детализацией. Без этого шага отчет — это просто список непонятных идентификаторов, с которым работать никто не будет.
Скидки и reserved instances. Если есть committed use discount, то cost в детализации уже учитывает скидку, но не всегда очевидно, к какому ресурсу она применена. Чтобы аллокация не врала, нужно отделять мух от котлет. То есть экономию от резервирования считаем отдельно и распределяем по командам пропорционально. Потому что иначе одна команда получит всю скидку, а остальные будут платить по on-demand.
Помимо качества самих данных, есть еще вопрос, про который обычно вспоминают сильно позже, чем стоило бы, — как именно их агрегировать. SUM по месяцу — это, конечно, первое, что приходит в голову, и для общей картины сойдет. Но если нужно разобраться с аномалией или спланировать мощности — уже не вывозит. Среднее скроет пиковые нагрузки, максимум покажет самый страшный день, но не скажет, насколько он вообще типичен.
Поэтому на практике лучше использовать персентиль 95. Он отрезает разовые всплески, но показывает тот уровень, на который реально стоит закладываться. Медиана же помогает понять, как выглядит «нормальный» день без влияния выбросов.
Какой метод выбрать — зависит от задачи, но главное, чтобы все пользовались одним и тем же. Иначе инженер и финансист будут смотреть на одни и те же данные и при этом видеть совершенно разные цифры.
Мало считать все в vCPU и гигабайтах. Пока инженер видит «средний CPU request — 12 vCPU», для него это абстракция. А вот когда он видит «22 500 рублей в месяц» — это уже более предметно.
В Яндекс Облаке пайплайн нормализации выглядит так: детализация выгружается в Object Storage, Yandex Query подключается к бакету и позволяет делать SQL-запросы прямо по файлам без отдельной базы данных. Параллельно с этим через API провайдера подтягиваются имена ресурсов, а теги приводятся к единому внешнему виду, и уже нормальные, читаемые данные подключаются к DataLens или любому другому BI.
Вот простой пример запроса, который считает расходы по тегу team за текущий месяц:
SELECT
labels['team'] AS team,
SUM(cost) AS total_cost,
DATE_TRUNC('day', usage_date) AS day
FROM billing-export/detail
WHERE usage_date >= DATE_TRUNC('month', CURRENT_DATE())
AND labels['team'] IS NOT NULL
GROUP BY team, day
ORDER BY day, total_cost DESC
Ресурсы без тега team в этом запросе просто выпадут из выборки — и никто об этом не предупредит. Поэтому тегирование — та история, где лучше сделать нормально сразу и не разбираться потом, куда делись 30% расходов.
Showback: когда данные начинают работать
Ну вот, данные есть, аллокация работает, каждый (ну, или почти каждый) рубль учтен. Остается один вопрос: а команды-то об этом знают? Потому что если все это лежит в выгрузке, которую смотрит раз в месяц один инженер — считайте, что не знают. А showback — это когда данные доходят до всех, кому они нужны, а не только до тех, кто умеет открывать CSV.
Но бояться showback не надо. Он не перекладывает реальные платежи между командами, а просто создает прозрачность. Это полная противоположность chargeback, когда деньги начинают реально перераспределяться внутри организации. Но для начала хватит и этого.
Хороший showback-отчет отвечает на три вопроса:
Сколько потратили за период в абсолютных цифрах и в сравнении с предыдущим месяцем?
На что именно ушли деньги в разбивке по сервисам и ресурсам?
Укладываемся ли в бюджет — и если нет, то почему?
Только вот прозрачность, которая обновляется раз в полгода-год — это фактически ее отсутствие. Базовый минимум – это ежемесячный showback. Но даже в с такой частотой хороших показателей не добиться: когда отчет придет, менять уже будет нечего. Поэтому идеал — еженедельные отчеты с детализацией по дням. Так аномалия, которая показала себя в среду, будет видна уже в пятницу, а не через три недели, когда по счету уже заплатили
Но даже ежедневные отчеты ничего не дадут, если до людей они не доходят. Дашборд — штука, конечно, удобная, но только если человек сам туда идет, а добровольно обычно ходят единицы. Поэтому рассылка раз в неделю – наше все: пришло в почту, открыл, посмотрел. Тут уж не отвертишься.
Аномалии: лучше сегодня, чем в конце месяца
Но рассылка — это расписание. А аномалии на ваши расписания чихать хотели с высокой колокольни. Та, что случилась в понедельник, к пятнице уже успевает обрасти какой-то суммой. Поэтому аномалии — отдельная история, со своими инструментами.
Большинство провайдеров дают базовые бюджетные лимиты с уведомлениями. Работает это так: достигли 80% бюджета, получили письмо. Но деньги-то уже ушли, а вы только узнали. Это необходимая первая линия защиты, но она носит чисто реактивный характер: деньги уже потрачены, а вы только узнали.
Следующий уровень — автоматическое обнаружение аномалий. Для этого есть специальные инструменты вроде FinOps Радар, которые следят за динамикой расходов по каталогам и сигналят, если что-то пошло не так. Суть предельно проста: вы даете продукту доступ только для чтения к своему аккаунту Yandex Cloud, а он начинает собирать данные и искать проблемы.Система сама замечает, что в конкретном каталоге расходы за день выросли, скажем, на 121% относительно среднего за последнюю неделю, и присылает уведомление.
Вот вам реальный пример из практики: три дня подряд расходы на k8s-кластер растут аномально — +121%, потом +79%, потом еще +52%. Если мониторинга нет, пропустить такое – плевое дело, особенно если смотреть на общий счет, а не на детализацию по каталогам. Но с уведомлением сразу можно пойти посмотреть деплои, проверить метрики подов. В общем, причину роста точно найдешь и скорее всего быстро.
На практике эти два инструмента чаще всего работают вместе. Лимит не дает счету взлететь в стратосферу в принципе. А автодетект ловит точечный инцидент — как в примере выше, на первый день роста, а не на третий. То есть поймал сигнал — идешь разбираться. Но для этого нужен нормальный дашборд.
Три дашборда, которые нужны инженерам
Если уведомления говорят о том, что что-то пошло не так, то дашборды – что именно и где. То есть вы увидите не просто общий биллинговый отчет на 40 колонок, а понятный срез под конкретный вопрос. Только не один, а три:
Дашборд 1. Динамика затрат во времени. Он показывает, как менялись расходы день за днем или неделя за неделей. По нему сразу видно, что и вследствие чего происходило: вот здесь выкатили релиз — стало дороже или нет, вот здесь кто-то гонял нагрузочный тест — во сколько это обошлось. Увидели резкую свечу на графике без видимой причины — идем смотреть деплои и изменения конфигурации за этот период. Видим равномерный и немотивированный рост месяц за месяцем — идем смотреть архитектуру.
Дашборд 2. Разбивка по сервисам. Он отвечает на вопрос, что именно жрет деньги. Если 65% уходит на управляемые базы данных, благодаря этому дашборду становится понятно, что оптимизировать именно надо там, а не, скажем, в compute. Если неожиданно много уходит на трафик — стоит посмотреть, как сервисы расположены друг относительно друга.
Дашборд 3. Разбивка по каталогам и проектам. Это, по сути, и есть FinOps в действии: Он показывает, кто именно жрет деньги. Каждая команда видит свой срез и отвечает за него. Полезно смотреть на соотношение prod, stage и dev: если dev стоит сопоставимо с продакшном — кто-то либо гоняет там нагрузочные тесты, либо просто забыл выключить ресурсы после работы.
Никакой дополнительной инфраструктуры. Все строится поверх биллинговой детализации, которую провайдер и так нам дает.
Результат фазы Inform: от хаоса к управляемым облачным затратам
Фаза Inform – это не история про немедленную экономию. Очень важно сразу это понять, чтобы не разочаровываться в первые недели. Ее результат — не сэкономленные рубли, а то, что решения теперь принимаются на основе данных, а не ощущений.
До Inform картина обычно такая: финансовый отдел спрашивает, почему счет вырос, инженеры пожимают плечами. Видят только свою часть инфраструктуры. Но общей картины нет ни у кого. То есть разговор за экономию получается как диалог слепого с глухим. А в таком формате, естественно, каши не сваришь.
После того как Inform выстроен, тот же разговор звучит иначе: даже если расходы на проект выросли, скажем, на 15% за последние две недели, но это совпало с запуском новой фичи, никто не пугается. Потому что вот конкретные ресурсы, которые добавились, и вот их стоимость в разбивке по сервисам. Никаких «наверное». Только цифры.
В результате счета перестают быть сюрпризом. Да, это еще не оптимизация. Но если каждый ресурс имеет владельца и каждый скачок расходов можно привязать к конкретному событию, облако начинает быть предсказуемым. А с этим уже можно не только работать, но и нормально двигаться дальше к Optimize и Operate. Но об этом – в следующих статьях цикла.
