Мы десятилетиями строим IT-системы, но до сих пор не можем ответить на элементарный вопрос: кто за что платит? Теги есть, аллокация настроена, но в отчетах — хаос. Затраты разбросаны по разным системам (биллинг облака, CMDB, Excel-таблицы у финансистов), и все это приходится собирать вручную перед каждым советом директоров.
В этой статье мы разберем почему классические подходы к распределению затрат дают сбой, и предложим практическую дорожную карту перехода от «гаданий на кофейной гуще» к прозрачной системе учета.
Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.
Почему теги не работают: от хорошей идеи к «теговому хаосу»
Теги — это благо, пока их мало. Но в реальности крупной компании теги могут превратиться в источник головной боли, приведем список типичных проблем:
Проблема | Как это выглядит |
Опечатки |
|
Несогласованные форматы |
|
Пропущенные теги | От 15 до 40 процентов объектов в инфраструктуре не имеют тегов вообще |
Изменение структуры | Команды реорганизовали, а теги остались старые |
Избыточная детализация | 200 уникальных значений тега "team" и 80 из них уже не актуальны |
Реальная история из практики: Глобальная SaaS-компания пытается рассчитать стоимость на одного клиента. 15% ресурсов вообще не имеют тегов. Еще 10% — с опечатками. Итог: $2.3 млн годового списания нельзя «разложить» по продуктам. Платформенная команда вынуждена абсорбировать чужие расходы.
Еще одну из возможных проблем можно условно назвать «парадокс тегирования» - чем больше мы стараемся детализировать, тем больше создаем «тегового долга» (tag debt) — накопленных проблем, которые потом приходится разгребать вручную .
Три столпа распределения расходов, которые рушатся поодиночке
Успешное распределения затрат держится на трех китах
Гранулярность (Granularity) — способность «разрезать» затраты на нужные куски: по командам, сервисам, средам, продуктам.
Где ломается: теги не выдерживают сложных иерархий. Одна виртуалка может принадлежать приложению, которое входит в сервис, который относится к продуктовой линейке, которая закреплена за бизнес-подразделением. Пропустите один уровень — и вся модель аллокации рушится.
Достоверность (Accuracy) — данные должны отражать реальную картину с учетом скидок, резервирований, амортизации и shared-инфраструктуры.
Где ломается: инженеры видят показатели, которые не сходятся со счетами, и перестают доверять отчетам. Финансисты, наоборот, требуют «полной стоимости» с учетом всех корректировок. В итоге — два параллельных мира.
Доверие (Trust) — отчеты, которым верят и на основе которых принимают решения.
Где ломается: в погоне за достоверностью мы упрощаем. Например, откатываемся к отчетам на уровне аккаунтов, потому что теги ненадежны. Доверие со стороны CFO есть, но инженеры теряют гранулярность для оптимизации. Если данные не вызывают доверия, они бесполезны, даже если технически они идеальны.
Модели распределения расходов
Выбор модели распределения расходов определяет не только отчетность, но и поведение команд.
Showback — показываем, но не наказываем, информируем команды об их расходах, но из их бюджета деньги не списываются. Среди плюсов: такой подход не вызывает сопротивления, формирует культуру осознанности. Из минусов: можно игнорировать, если нет последствий. Оптимальное применение этой модели это начальный этап FinOps, когда важно «просто увидеть ситуацию целиком».
Chargeback — показываем и списываем, расходы закрепляются за командами и вычитаются из их бюджетов. Из плюсов: реальная мотивация оптимизировать, четкая бюджетная дисциплина. Минусы: может вызвать конфликты, требует безупречной аллокации. Оптимально применять эту модель в зрелой FinOps-культуре, когда доверие к данным уже сформировано.
Для построения FinOps-культуры с нуля лучше начинать с модели showback, где главное это прозрачность и грамотная настройка тегов. И только после принятия и согласования правил аллокации можно вводить финансовую ответственность .
Где теряются деньги: общая инфраструктура и контрактные скидки
Даже когда теги на месте, а данные сведены в единое хранилище, остаются два «черных ящика», которые превращают аллокацию затрат в политические дебаты. И если с ними не разобраться, любые отчеты будут вызывать споры, а не решения.
Первый такой ящик — общая (совместно используемая) инфраструктура. Платформенные сервисы, общие кластеры Kubernetes, общие базы данных, централизованные системы логирования — все это критически важно для бизнеса, но непонятно, кому списывать затраты. Можно распределить поровну между всеми пользователями — это просто, но несправедливо: команда, которая потребляет 10% ресурсов, будет платить столько же, сколько команда с 90% нагрузки. Можно пойти по пути пропорционального распределения — справедливо, но технически сложно: нужно собирать метрики потребления для каждого сервиса и агрегировать их в единую модель. А можно просто покрывать все из центрального бюджета — удобно для команд-потребителей, но тогда реальные затраты становятся невидимыми, и ни у кого нет стимула их оптимизировать. Идеального сценария не существует, но без явно задокументированных правил распределения расходов по общей (совместной) инфраструктуре споры будут возникать снова и снова.
Второй «черный ящик» — контрактные скидки (commitment discounts). Вы купили резервирование ресурсов (Reserved Instances) или используете "экономичные" тарифные планы (Savings Plans) со скидкой 40%. Отлично, экономия есть. Но вот вопрос: какой команде записать эту экономию? Если распределять скидку неравномерно, одни команды начнут выглядеть неестественно эффективными, а другие — «переплачивающими», хотя на деле они просто оказались в разное время в одном пуле. Это искажает стимулы: команда, которая «получила» скидку, может расслабиться и перестать оптимизировать, а та, которой «не повезло», будет тратить энергию на споры с финансистами, а не на свою инфраструктуру.
Правильный подход — это сделать распределение скидок прозрачным и предсказуемым. Нужно задокументировать правила распределения и, например, делить экономию пропорционально фактическому потреблению каждого из участников, и сделать эти правила доступными для всех. Только тогда отчеты перестанут быть поводом для конфликтов и станут инструментом для принятия решений.
Сбор данных из разных систем
Если бы все данные, необходимые для управления облачными расходами, лежали в одной системе — проблем бы не было. Достаточно открыть один отчет, и вот он: кто, за что и сколько заплатил. Но реальность, как всегда, сложнее.
Биллинг провайдера дает сырые затраты по ресурсам, но не говорит, кому эти ресурсы принадлежат. CMDB хранит данные о конфигурациях и владельцах, но не знает, сколько за них заплачено. Мониторинг фиксирует метрики нагрузки, но не связывает их с финансовыми показателями. Финансовые системы оперируют бюджетами, кост центрами и планами, но не понимают, что такое «виртуальная машина». И, наконец, есть Excel — универсальное хранилище всего, что никуда не влезло, от ведомостей до ручных корректировок.
В итоге FinOps-команда вынуждена выполнять роль переводчика между техническими и финансовыми отчетами. Данные копируются из системы в систему, актуализируются перед каждым отчетным периодом, вручную сверяются и перепроверяются. Любое изменение в одной из систем — например, переименование кост центра или смена владельца ресурса — требует ручного исправления во всех остальных. А самое опасное: при ручном сведении невозможно отследить изменения во времени. Вы видите итоговую сумму в отчете, но не можете сказать, когда и почему она изменилась.
Результат предсказуем: FinOps-команда тратит до 80% времени на сведение данных, а не на оптимизацию. Вместо того чтобы искать, где можно сократить расходы или повысить эффективность, люди занимаются копированием строк из одной таблицы в другую. А в это время деньги продолжают утекать.
Что делать: дорожная карта от хаоса к порядку
Итак мы разобрали, где и почему теряются деньги. Теперь используем 5 шагов чтобы выстроить прозрачную систему распределения затрат:
Шаг 1. Признайте проблему и назовите ее
Зафиксируйте % нераспределенных затрат (unallocated spend)
Определите, где у вас «теговый долг»
Согласуйте с руководством, что текущая ситуация — это проблема, а не норма
Шаг 2. Создайте единую таксономию
Определите обязательные теги для всех ресурсов :
Тег | Назначение |
| Ответственный (куда идти с вопросами) |
| Финансовая привязка |
| prod / dev / test — приоритеты |
`application | К какому продукту относится |
| Стратегическая единица |
Шаг 3. Автоматизируйте контроль
Настройте правила, запрещающие создание ресурсов без обязательных тегов (Azure Policy и аналоги)
Используйте наследование тегов для всех объектов инфраструктуры в рамках заданных подписок или групп
Установите для сотрудников процент соответствия используемых тегов установленным правилам обязательным показателем/индикатором качества их работы (KPI)
Шаг 4. Внедрите единый процесс сбора данных
Используйте ELT-подход (сначала собираем все в сыром виде)
Применяйте открытые стандарты (например, FOCUS) для унификации данных
Создайте центральное хранилище, куда стекаются данные из всех источников
Шаг 5. Сначала showback, потом chargeback
Начните с прозрачности — покажите командам их расходы без финансовых последствий
Соберите обратную связь: справедливо ли распределение?
Только после того, как данные признаны достоверными, переходите к chargeback
Заключение: распределение расходов — это не техническая задача
Проблема распределения затрат не в том, что мы не умеем программировать, а в том, что мы пытаемся решить организационную задачу техническими средствами.
Теги — это инструмент, но не стратегия. Распределение — это договоренность между бизнесом, финансами и IT о том, как мы считаем деньги.
Если ваши отчеты вызывают споры, а не решения — начните с того, чтобы просто назвать проблему. «У нас 30% нераспределенных затрат». И двигайтесь к порядку шаг за шагом.