По данным рыночных исследований, только треть организаций точно знает, на что тратится их облачный бюджет. Остальные 80%+ косплеят лося, несущегося по горящему лесу – их ведет судьба. В конце месяца они получают счет за облако, но разобраться, кто и на что потратился, у них не получается. Да и как тут разобраться, если одни команды экономят и оптимизируют, другие боятся пожертвовать ресурсоемкими экспериментами, а третьи просто забывают выключить тестовые среды? 

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

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

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

Последствия непрозрачности облачных расходов

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

Нет, что использовать и как – дело, конечно, хозяйское. Но справедливо ли тогда всех оценивать одинаково? Вопрос риторический. Чтобы такого не было, нужна атрибуция затрат, когда каждой части счета присваивается конкретный "владелец”. Если этого не сделать, определить реальную стоимость каждого продукта или сервиса будет невозможно. Что, собственно, мы и видим у большинства компаний, которые никак не могут поместиться в свой же бюджет.

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

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

Хорошо, что есть unit economics. Это действительно классная штука, которая позволяет рассчитать стоимость облачной инфраструктуры в пересчете на единицу бизнес-ценности. С ней вы поймете, сколько стоит обслужить одного пользователя, обработать один заказ или показать тысячу рекламных баннеров. Зависит от того, что вам нужно.

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

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

Пять уровней детализации

Переход от хаоса к порядку не происходит за одну ночь. Тут нужна эволюция, причем поэтапная.

Уровень 1: Общий котел

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

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

В российских реалиях такой подход чаще всего еще и очень рискованный. Тарифы у отечественных провайдеров меняются чаще западных, а курсовые колебания – например, если вы продолжаете пользоваться иностранными облаками – могут в одночасье увеличить счета на 20-30%. То есть без детализации вы просто не поймете, откуда взялся перерасход.

Уровень 2: Кто сколько съел

Второй уровень начинается с распределения расходов по провайдерам. VK Cloud выставляет счета в одном формате, Яндекс.Облако — в другом, Cloud.ru — в третьем. Чтобы сравнить яблоки с яблоками, приходится все приводить к общему знаменателю. Муторно? Да, но по-другому никак.

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

Уровень 3: Что на что тратим

На третьем этапе можно начать раскладывать деньги по типам услуг:

• Compute (вычислительные ресурсы) обычно съедает 60-70% бюджета. Сюда входят виртуальные машины, контейнеры и т.п.

• Storage (хранение данных) требует еще 20-30%. К этой категории относятся диски, объектные хранилища, базы данных.

• Data Transfer (сетевой трафик) — тянет на 10-15%. Тут и внешний трафик, и межзональный.

• Managed Services (управляемые сервисы) — сколько повезет, но обычно процентов 5-10. Здесь будут всякие балансировщики, мониторинг, бэкапы.

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

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

Уровень 4: Персональная ответственность

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

На первый взгляд, ничего сложного. Знай себе – проставляй теги: cost_center, project, environment, owner. Но попробуйте заставить разработчиков не забывать это делать и, главное, делать это правильно, и будьте уверены: просто не будет.

К сожалению, российские провайдеры не предлагают полноценного автотегирования. Нет, кое-что, конечно, есть:

• В VK Cloud можно прописывать теги в конфигурационных файлах через Terraform, и они применятся при создании ресурсов. Лучше чем ничего, но до нормальной автоматизации далеко.

• Яндекс.Облако предлагает систему лейблов, которыми можно управлять через CLI и веб-интерфейс. Есть каталоги для логического разделения ресурсов. Но опять же — все ручками.

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

И все-таки, на этом этапе уже можно увидеть реальную картину: какие команды тратят больше, какие проекты самые дорогие, а какие окружения жрут ресурсы не по назначению. Но справедливого перераспределения затрат пока нет. Это все еще просто красивые дашборды. 

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

Уровень 5: Каждый сам за себя

Финальный босс – создание cost-центров с собственными бюджетами и реальной ответственностью за его соблюдение. На этом этапе заканчивается детский сад, и начинают работать серьезные модели Showback и Chargeback.

Showback — это мягкий подход. Он заключается в том, чтобы показать командам их траты без фактического списания денег с их бюджетов. Дескать, вот, ребята, смотрите, сколько вы угрохали на тестовые среды. Так у людей будут выстраиваться нейронные связи между цифрами, которые они видят, и действиями, которые предпринимают.

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

Только осторожнее с Chargeback. Чтобы применять этот инструмент контроля, необходимо сделать так, чтобы к точности атрибуции нельзя было подкопаться. Лучше год поработать в режиме Showback и довести все процессы до ума, чем потом решать конфликты. Вы же не доктор Курпатов.

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

Как это сделать технически

Теория хороша, но без техники далеко не уедешь.

Битва за теги

Первым делом важно понять, что тегирование – это история про единообразие. Тут не может быть никакой самодеятельности. Вообще. Совсем. Даже регистр в названиях тегов имеет огромное значение. Нельзя, чтобы одну команду называли и "backend", и "Backend", и "back-end". Это непреложная истина, которую должны принять все.

Звучит, опять-таки, элементарно, но в реальности каждая команда точно будет делать по-своему. Поэтому нужны четкие правила и их жесткое соблюдение. Все должно быть прописано в wiki, зафиксировано в шаблонах и проверяться автоматически. 

Необходимый минимум тегов для любого ресурса, которые обязательно должны быть:

• cost_center — за чей счет банкет

• project — к какому продукту относится

• environment — продакшен, тест или разработка

• owner — конкретный ответственный

Берем конкретный пример. Сервер базы данных для мобильного приложения интернет-магазина в продакшене должен иметь теги:

• cost_center=mobile_team

• project=mobile_app

• environment=production

• owner=ivanov@company.ru

А тестовая среда для того же проекта получит теги:

• cost_center=mobile_team

• project=mobile_app

• environment=staging

• owner=petrov@company.ru

Так в конце месяца можно будет точно сказать: мобильная команда потратила 150 тысяч на продакшен и 50 тысяч на тестирование. А если кто-то забыл выключить staging-среду на выходные, виновник сразу найдется.

Атрибуция затрат в Kubernetes

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

Наиболее популярные решения – OpenCost и Kubecost. Они анализируют потребление ресурсов на уровне подов и пытаются распределить стоимость узлов между неймспейсами.

Но вся загвоздка в том, что эти штуки заточены под западные облака. OpenCost нормально работает только с AWS, Azure и GCP. А для отечественных провайдеров приходится пилить костыли.

Возьмем пример: у вас есть Kubernetes-кластер из 5 нод, каждая стоит 20 тысяч в месяц. Итого 100 тысяч. На кластере работают 3 неймспейса:

• frontend — потребляет 40% CPU и памяти

• backend — потребляет 35%

• analytics — потребляет 25%

Соответственно, распределение затрат должно выглядеть так: frontend — 40 тысяч, backend — 35 тысяч, analytics — 25 тысяч.

Только вот загвоздка. Но всем нужны общие сервисы — мониторинг, ingress-контроллеры, DNS, логирование. А кто должен за них платить? Frontend генерирует много трафика, но процессор почти не нагружает. Analytics наоборот — жрет ресурс CPU как не в себя, но при этом не имеет сетевой активности. А если кто-то запустил нагрузочное тестирование и на час поднял сотню подов — честно ли драть с них деньги за весь месяц?

Поэтому большинство компаний просто берет и делит: 30% стоимости кластера поровну между всеми (это за общую инфраструктуру), оставшиеся 70% — по факту потребления CPU и памяти. Не устраивает? Предложите свой способ в комментариях. Может быть, мы даже напишем о нем статью.

Мультитенантные архитектуры

Проще всего решить проблему атрибуции — дать каждому подразделению отдельный аккаунт. Благо российские провайдеры такую возможность поддерживают:

• Яндекс.Облако: каталоги и организации

• VK Cloud: проекты

• Cloud.ru: организации и проекты

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

Работа с shared-ресурсами

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

Варианта три, и все не идеальные:

• Пропорционально использованию: мониторим реальную нагрузку и делим расходы соответственно. База данных стоит 50 тысяч в месяц. Команда A делает 60% запросов, команда B — 30%, команда C — 10%. Соответственно, A платит 30 тысяч, B — 15 тысяч, C — 5 тысяч.

• Фиксированные квоты: договариваемся заранее, что каждая команда платит поровну или по заранее определенным долям. Этот метод проще в реализации, но может быть (или выглядеть) несправедливо.

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

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

Финансовые процессы

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

Значит, надо разделять:

• CEO хватит графика, где видно, что потратили больше или меньше относительно прошлого месяца; плюс топ-3 самых дорогих проектов. Не дайте гендиру утонуть в цифрах.

• Продакту важно знать unit economics: сколько стоит обслужить одного пользователя его приложения, обработать один заказ, показать тысячу баннеров.

• А DevOps-инженеру нужно побольше деталей вплоть до последнего сервера, чтобы понимать, где можно оптимизировать. Без подробностей он работать не сможет.

Тут главное – чувство текущего момента. С одной стороны, важно не переборщить с вводными, а с другой – ничего не утаить.

Но какими бы ни были отчеты, есть несколько универсальных метрик, которые должны быть у всех:

• Cost per team — сколько каждое подразделение тратит в месяц

• Cost per product — во что обходится каждый продукт или сервис

• Процент распределенных затрат — какую долю расходов удалось привязать к владельцам

Последний показатель особенно болезненный. В теории нужно стремиться к 90%+ распределенных затрат, но на практике больше 70-80% получить реально сложно. Всегда почему-то находятся ресурсы непонятного происхождения, которые боятся прибить.

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

Чек-лист внедрения

А теперь переходим к внедрению. 

1. С чего нужно начать, так это с аудита. Изучите, куда уходили деньги в последние полгода. Нередко уже на этом этапе обнаруживается, что половина ресурсов вообще непонятно зачем нужна.

2. Проведите инвентаризацию ресурсов. Это скучно, но создать реестр всего, что у вас крутится в облаке, просто необходимо.

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

4. Следом – автоматизация. Ведь чем меньше люди делают руками, тем меньше ошибок. Конечно, полностью исключить человеческий фактор не получится. Кто-нибудь обязательно напишет “test” вместо “testing”. Но точность достигается только практикой. И использованием автоматики. По крайней мере, там, где можно.

5. После – назначаем стрелочников. Вернее, ответственных. FinOps-инженеры, которые будут всем рулить, должны иметь реальные полномочия. Если они не могут заблокировать создание ресурсов без тегов, какой от них толк?

6. Самое сложное – это обучение команд. Готовьтесь к тому, что половина будет сопротивляться изменениям принципиально. И тут нужно терпение и аргументация.

7. Затем утверждаем политику распределения shared-ресурсов. Важно единообразно понимать, как делить общие базы данных, балансировщики нагрузки, системы мониторинга. Договоритесь заранее, чтобы потом не было споров.

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

Что получится в итоге

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

Зато вы гарантированно сможете рассчитывать на:

• Повышение точности прогнозирования.

• Ответственность команд за свои расходы.

• Повышение эффективности затрат.

• Детализированное управление затратами.

Да, на все потребуется время, силы и нервы, а переход между уровнями может затянуться не на один год. Не факт даже, что все будет получаться с первого раза. Но альтернатива — продолжать сжигать деньги в топке облачного хаоса – куда хуже. Так что задумайтесь. Потом скажете спасибо. И нам, и себе.