Несмотря на то что в России последние годы идет явный тренд на импортозамещение, многие компании продолжают пользоваться не только отечественными, но и зарубежными облаками. У кого‑то остались подразделения за границей, кто‑то завязан на legacy‑решения, которые дешевле оставить как есть, чем переезжать, а кому‑то просто лень. Причины у всех разные, но объединяет их одно: необходимость свести этот облачный зоопарк в понятную модель затрат, с которой будет удобно работать всем.
Почему одно облако ничего не решает
Казалось бы, ну какие тут могут быть вопросы? Собираем волю в кулак и переводим всех в единое облако. Будет непросто, где‑то даже не бесплатно, но зато удастся избавиться от зоопарка, а именно это нам и нужно. Вот только на бумаге все звучит куда красивее, тогда как в реальности упирается в несколько вполне земных ограничений.
Во‑первых, регуляторика. Во многих странах мира – и в России в том числе – существует запрет на хранение некоторых категорий данных (например, персональных) за границей. Работаете в Китае – значит, и данные китайских пользователей храните в Китае. А в Европе – соблюдайте GDPR. В общем, везде свои правила.
Иногда даже фактическое присутствие глобального провайдера в нужной стране может не помочь: по закону филиалу за границей все равно может потребоваться именно местный оператор с локальной лицензией.
Во‑вторых, архитектура и задержки. Возьмем простой пример: у вас сервис онлайн‑бронирования, которым пользуются клиенты по всей России от Калининграда до Владивостока. Если держать всю инфраструктуру в московском дата‑центре, задержка для дальневосточных пользователей только на сетевом раундтрипе может оказаться весьма заметной, а с учетом обработки запроса и вовсе может вырасти до неприличных значений.
Но дата‑центров с хорошим пирингом на Дальнем Востоке объективно немного. Поэтому гораздо проще перенести часть нагрузки ближе к клиентам – например, куда-нибудь в Суйфэньхэ. Технически проблема решена, но в биллинге у нас теперь еще один регион, а возможно — и вовсе другое облако.
В‑третьих, экономика. Если вы задолго до 2022 года жили в AWS, успели подписаться на enterprise-поддержку, поучаствовать в commit-программах, настроить reserved/spot instances и завести под все это автоматизацию, ломать все наверняка не захочется. Менеджеры уже знают, где какая кнопка, финансисты понимают структуру счетов, DevOps написал terraform-модули под конкретные сервисы провайдера.
Взять и переехать в другое облако с таким бэкграундом не так-то просто. Рациональнее просто подстроиться. Тут-то нам и поможет FinOps.
Как устроить нормальное тегирование
Первое, что отличает реальный FinOps от слайдов презентации, — то, насколько вы вообще понимаете, кто и что сжигает облачные бюджеты. А для этого, как мы помним, необходимо организовать систему тегирования.
Вот в этой статье очень хорошо разобран базовый набор тегов, который должен быть в каждой компании, которая претендует на прозрачность облачных расходов. Но в мультиоблачной международной конфигурации к этой базе приходится добавлять еще географический и юридический слои:
country / region — страна или регион, к которому относится нагрузка (не обязательно физический регион облака)
legal_entity — юрлицо, на которое должны лечь эти расходы
business_unit или cost_center — команда или подразделение, которое отвечает за продукт или сервис
product / service — конкретный продукт или крупный кусок платформы
env — окружение: prod, stage, dev, sandbox, эксперимент и так далее
owner / squad (или team_id при строгих требованиях безопасности) — ответственный или команда, которая владеет ресурсом и отвечает за расходы (кому писать, если вдруг счет удвоился)
опционально: revenue_stream / client — если у вас B2B и вы реально хотите видеть расходы по крупным клиентам
Только не пытайтесь придумать идеальную таксономию на 40 тегов. Просто выберите 5–7 обязательных и внедряйте их.
А вот как это сделать так, чтобы не умереть:
Новые ресурсы: запретить создание без тегов. Нет тега — нет ресурса (он просто не поднимется).
Старые ресурсы: разом разгрести все, что навертели до внедрения системы тегирования, чаще всего нереально. Поэтому делают так: берут топ‑N ресурсов по стоимости (например, те, что дают 80% расходов) и руками или скриптами проводят через кампанию ретегирования. А все остальное (обычно это стоит копейки), можно просто закрыть одним техническим тегом вроде legacy=untagged и постепенно чистить.
Проверка качества: раз в сутки или чаще запускается чек, который собирает все ресурсы без обязательных тегов или с мусором в значениях и отправляет отчет владельцам команд. Если занести это в KPI, все научатся не создавать всякий мусор еще до первой зарплаты.
Единообразие между облаками: если в AWS у вас country=pl, а в другом облаке кто‑то пишет Poland или вообще polska — считайте, что консолидированной отчетности у вас нет. А чтобы была, надо заранее договориться, как пишутся значения, и ни в коем случае не отступать от этих правил.
Маппинг на финансовую структуру: теги должны напрямую совпадать с тем, с чем работают финансы — юрлица, бюджеты, кост-центры. Если в биллинге написано legal_entity=pl_marketing, а бухгалтерия знает это как маркетинговый отдел ООО Ромашка_Польша — придется все время держать в голове, что это одно и то же. А зачем? Лучше сразу завести единый справочник и писать везде одинаково.
Очень важно, чтобы система тегов существовала не только на бумаге, но и использовалась в повседневной работе. Если разработчик в дашборде не может по этим тегам найти свой сервис и понять, сколько он стоит, схема мертва. Поэтому все, что вы придумали в методологии, нужно довести до людей, а не только до конфига в Confluence.
Как реально делить один счет между странами и юрлицами
Когда теги есть и они нормально работают, можно переходить к тому, ради чего все это затевалось: делить счета между странами, командами и юрлицами так, чтобы финансы и налоговая были довольны. Однако будьте готовы к тому, что все легко и просто только в теории. Потому что на практике у вас будет минимум три слоя данных, которые придется обрабатывать:
Сырые usage‑данные от провайдера
Логика скидок, резервирований, кредитов, коммитов
Правила, как это разнести по странам и юрлицам
Как с ними работать:
Сначала раскладываются чистые usage‑метрики по тегам: сколько CPU‑часов, гигабайт‑часов хранения, гигабайтов исходящего трафика пришлось на каждую связку country + product + env. Тут вроде все понятно: кто потребил – тот и платит.
Затем к этим группам применяется доля от общих скидок. Пример: у вас есть общий Savings Plan или Committed Use Discount. Вы можете распределить выгоду пропорционально расходам. Кто сколько потребил, тот столько скидки и получил.
Третий слой – распределение финансовых затрат. Тут логика ровно такая же, как и со скидками. Допустим, казахский и польский офисы сидят на одном аккаунте AWS. Значит, есть расходы, которые относятся к обоим офисам сразу: техподдержка, shared-сервисы и т.д. Разделить их не представляется возможным. Поэтому обычно такие расходы делятся пропорционально выручке. Если Польша заработала 60% – значит, на нее и ложится 60% общих расходов. Только не забудьте договориться об этом заранее, и все будет тип-топ.
Считается все это дело по вполне реальным формулам:
доля_страны_по_compute = usage_CPU_страны / usage_CPU_всего
доля_страны_по_выручке = выручка_страны / выручка_всего
Теперь для каждого типа затрат вы явно фиксируете, что используете: usage‑долю или выручку, а не пересчитываете каждый раз заново.
А чтобы это не просто работало, но и выглядело достаточно профессионально, нужно две вещи:
Матрица распределения: таблица, где для каждого вида расходов (Compute, Storage, Network, Support, Shared Services) написано, как их делить между странами и юрлицами. По потреблению, по выручке, по пользователям — неважно, как именно. Главное – чтобы все было зафиксировано.
Однозначная связь тегов с юрлицами: если country или cost_center в тегах не отсылают нас к конкретному юридическому лицу — вся прозрачность летит в трубу.
Если вам есть что сказать по теме, обязательно присоединяйтесь к нашему сообществу Практики FinOps в Telegram. Это отличная возможность обменяться опытом и просто пообщаться с единомышленниками.
Что делать с мультивалютностью
На этом этапе тонет много финопсовых инициатив. Причина проста: польский офис платит в злотых, казахский — в тенге, провайдер выставляет счет в долларах, а головной офис хочет видеть в рублях. В условиях скачущих курсов очень легко запутаться, это просто потребление выросло или валюта упала?
Базовый набор решений, который не стыдно показать финансисту:
Сначала выбираем единую базовую валюту – обычно это доллар или евро – и все приводим к ней. В отчетах по конкретным странам можно использовать и локальную валюту для удобства местных финансистов, но расчетная база должна быть одна. Иначе сравнивать затраты между офисами просто не получится.
Важное условие – договориться, по какому курсу пересчитывать. Наиболее удобны следующие варианты:
курс на дату счета или проводки (для помесячной отчетности и учета)
средневзвешенный курс за отчетный период (удобнее для аналитики)
Тут, опять же, главное — не прыгать между подходами.
Дальше — разделяем эффект курса и эффект потребления. В отчете показываете отдельными строками:
сколько бы стоило текущее потребление, если бы курс остался на уровне прошлого периода
сколько добавила или отняла курсовая разница
Только так можно будет понять, что из 25% роста счета, например, 10% — это реальный рост нагрузки, а 15% — скачок курса, а не наоборот.
Ну, а если хотите максимально точно, можно начать вести учет технологических метрик (CPU‑часы, запросы, терабайты хранения) вообще отдельно от денег. Тогда можно показать, что потребление выросло на 10%, а чек — на 25%: значит, 10% — нагрузка, остальное — курсы и изменения тарифов провайдера.
Как свести данные от разных провайдеров
Теперь необходимо собрать данные от разных провайдеров и как-то привести их к общему знаменателю. Потому что вас непременно ждет зоопарк не только с провайдерами, но и со счетами: один выгружает биллинг только через API в S3, второй присылает PDF в ответ на запрос в саппорт, а третий позволяет запросить CSV из личного кабинета лишь раз в месяц.
И все бы ничего, но у некоторых провайдеров CSV может даже не содержать usage-метрик. Там лежат именно строки счета. Фактически вы получаете уже агрегированную биллинговую информацию, а не данные о реальном потреблении. Так что если вы распределяете затраты по usage, такие файлы могут давать искажения: придется дополнительно нормализовать эти выгрузки и приводить их к единой модели, иначе все смешается в кашу.
Если попытаться работать с каждым форматом отдельно, через полгода у вас будет пять разных дашбордов, три Excel‑таблицы и никакой возможности свести все в одну картинку.
Выход один — завести свой внутренний формат строк биллинга и приводить к нему данные от всех провайдеров. Просто пишете скрипт для каждого источника, чтобы он сам собирал данные провайдеров и приводил к вашей схеме.
Вот как выглядит минимальный набор полей, с которым будет удобно работать:
billing_date — дата начисления
provider — AWS, Azure, Yandex Cloud и так далее
account_id — идентификатор аккаунта у провайдера
service — тип сервиса (Compute, Storage, Network)
usage_quantity — сколько единиц (часов, гигабайт)
usage_unit — в чем измеряется
cost_original — стоимость в валюте счета
currency_original — валюта счета
cost_base — стоимость в базовой валюте группы
objectID — уникальный идентификатор объекта инфраструктуры
ParentObjectID — идентификатор родительского объекта, если есть иерархия (например, диск привязан к ВМ)
tags — JSON или набор полей с тегами
Если провайдер поддерживает автоматический экспорт данных в хранилище — будет достаточно просто один раз его настроить, а дальше все будет собираться в S3 или Blob. Если нет – назначьте ответственного, который будет раз в месяц вручную загружать CSV в определенное место, откуда его подхватит скрипт. С PDF, конечно, чуть хуже. Тут остается либо написать в поддержку и попросить включить нормальную выгрузку, либо просто показать эту часть одной строкой без детализации. Будет не так красиво, но хотя бы честно.
Бюджеты и прогнозы
Следующая задача — научиться планировать расходы, а не просто фиксировать факт. Потому что приходить к руководству каждый месяц с отчетом о том, сколько потратили — это одно, а прогнозировать и закладывать в бюджет — совсем другое.
Чтобы это работало как инструмент, а не как лозунги из презентации для совета директоров, нужно разделить три уровня работы с цифрами:
Технологический: ресурсы, инстансы, хранилища, трафик
Бизнесовый: пользователи, заказы, выручка
Финансовый: деньги в базовой валюте, курсы, налоги
На технологическом уровне прогнозируете в первую очередь объем: например, рост числа запросов или данных на 20% квартал к кварталу. Это зона ответственности команд.
На бизнес‑уровне смотрите, чтобы удельные показатели не уезжали: cost per user, cost per order, доля облака в выручке продукта.
На финансовом уровне отдельно считаете 2 сценария: “если курсы и тарифы не изменятся” и “с учетом ожидаемых изменений”.
На практике это работает так. Берете факт прошлого квартала, раскладываете его на:
базовое потребление (сколько CPU, Storage, Network)
удельные бизнес‑метрики (cost per user, cost per transaction)
курсы валют и изменения тарифов
Дальше строите прогноз на следующий квартал или год:
бизнес говорит, что ожидает +15% роста пользователей
инфраструктурная команда прогнозирует, что это даст +12% к Compute и +18% к Storage (потому что новые пользователи активнее грузят контент)
финансы закладывают сценарии по курсам: базовый, оптимистичный, пессимистичный
В итоге у вас должна получиться не одна цифра, а диапазоном с явным указанием допущений. И если через квартал факт не сойдется с планом, можно будет быстро понять, где именно было расхождение: в росте нагрузки, в курсах или в удельных показателях.
Локальные бюджеты и автономия команд
Когда матрица распределения работает и все понимают, кто сколько тратит по странам и юрлицам, возникает вопрос: как сделать так, чтобы локальные команды сами управляли своими затратами, а не бегали за согласованием каждого ресурса в головной офис.
Для этого надо делить бюджет не просто по стране целиком, а по связке команда + продукт + окружение. Например:
Польша, продукт A, prod — 50 тысяч долларов в квартал
Польша, продукт A, non‑prod — 15 тысяч долларов в квартал
Польша, продукт B, prod — 30 тысяч долларов в квартал
Проще говоря, у каждой команды должен быть дашборд с ее частью затрат. Не PDF-файлик, который приходит раз в месяц, а график, который обновляется каждый день: сколько потрачено, сколько осталось, что съело больше всего.
Пороги и алерты настраиваются примерно так:
70% бюджета — информационное уведомление
85% — уведомление + требование объяснить, плановый рост или аномалия
100% — либо расширение бюджета по согласованию, либо временная заморозка dev-окружений
Таким образом команды будут видеть не только общую сумму, но и детализацию. Тогда, если вдруг прилетит всплеск по Storage, команда сможет самостоятельно залезть детализацию и увидеть, что это, например, забытые снапшоты или логи, которые никто полгода не чистил.
Трансфер-цены и внутригрупповые расчеты
Научиться делить затраты между странами и юрлицами – это, конечно, важно. Но как это все правильно оформить с точки зрения налоговой? Потому что если польское юрлицо фактически пользуется ресурсами, за которые платит российское, а документально это никак не оформлено — рано или поздно возникнут вопросики.
Спасет трансфер-прайсинг. Это набор правил, по которым компании внутри одной группы должны продавать друг другу услуги. Налоговые разных стран очень внимательно смотрят на эти сделки, потому что через них легко можно перекидывать прибыль из одной юрисдикции в другую.
Допустим, у вас головной офис в России каким-то образом держит общий аккаунт AWS и оплачивает все счета, а польское подразделение фактически потребляет часть этих ресурсов. Значит, российское юрлицо должно выставить польскому счет за предоставление облачных услуг – и обязательно по рыночной цене.
Нельзя просто взять и переложить затраты один в один. Нужно добавить наценку, как если бы вы продавали эти услуги стороннему клиенту. Наценка обычно выбирается на основании функций и рисков сторон. Для ИТ-групп встречается рабочий диапазон 5–15%, но конкретный уровень фиксируется в документации. Без этого налоговая может признать сделку нерыночной и доначислить налоги.
Что нужно для нормального оформления:
Документация по трансфер-прайсингу. В ней описываете: какие услуги предоставляются, как формируется цена, почему выбрана именно такая наценка. В крупных группах это толстые документы с экономическим обоснованием.
Договоры между юрлицами. Формальное соглашение о предоставлении облачных услуг или IT-инфраструктуры. С указанием цены, порядка расчетов, ответственности сторон.
Регулярные счета и оплаты. Раз в месяц или квартал российское юрлицо выставляет счет польскому на основании фактического потребления (которое вы уже умеете считать по тегам), польское оплачивает. Все документально.
Актуализация цен. Если затраты на облака меняются, трансфер-цены тоже нужно пересматривать. Иначе может получиться, что наценка вылезла за разумные пределы или вообще ушла в минус.
Очень многие делают трансфер-прайсинг формально, для галочки. Выставили символический счет раз в год и забыли. Но в налоговой-то не дураки сидят и все видят. Поэтому, если вы придерживаетесь такого же правила, готовьтесь, что в какой-то момент схему могут признать фиктивной.
Что делать прямо сейчас
Кажется, что все это слишком сложно, но начать можно с простых шагов. Вот что реально работает:
Провести инвентаризацию. Какие облачные провайдеры используются, в каких странах, кто платит по счетам, где уже есть скидочные программы и commit-контракты.
Договориться о минимальном наборе обязательных тегов (5-7 штук) и внедрить их через policy для новых ресурсов. Для старых — ретегировать хотя бы топ по стоимости.
Настроить единое хранилище для биллинг-данных от всех провайдеров. Для тех, кто дает API — автоматическая выгрузка. Для остальных хотя бы регулярный ручной процесс с понятным форматом.
Выбрать базовую валюту группы и зафиксировать правило пересчета курсов. Документировать его и не менять каждый квартал.
Построить матрицу распределения затрат: для каждого типа расходов (Compute, Storage, Network, Support, Shared Services) явно указать, по какому ключу они делятся между странами и юрлицами.
Запустить базовую витрину по затратам, где финдиректор, ИТ-директор и руководители локальных команд смотрят на одни и те же цифры.
Настроить бюджеты на уровне команд и окружений, а не просто ИТ по стране. Дать командам дашборды с их затратами и алертами.
Начать разделять в отчетах рост потребления, курсовые эффекты и изменения тарифов, чтобы разговор с бизнесом был честнее.
После этого международные облачные затраты перестают быть чем-то пугающим, а становятся управляемым параметром. Да, не идеальным, не до копейки точным, но достаточно понятным для принятия взвешенных решений и на уровне штаб-квартиры, и на уровне локальных команд.