Как экономить на облаке: считаем деньги правильно

Говорят, что порядок нужен придуркам, а гении властвуют над хаосом. Но, кажется, этот тезис придумали сами придурки

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

Почему все пошло не так

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

Попробуйте просчитать unit economics в таких условиях – и получится чушь. Да, вы знаете общие расходы на облако, но, как определить, какая их часть приходится именно на мобильное приложение, а не, скажем, на сайт, аналитику или тестовые среды?

Без четкого распределения затрат мы получаем просто гадание на кофейной гуще. Хуже того, продукт может только казаться прибыльным в отчетах, а на самом деле проедать половину IT-бюджета через скрытые инфраструктурные траты, которые вы даже не фиксируете. Что же делать? Муравья мучить не надо. Лучше займитесь детализацией.

Как выбраться из финансовой каши

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

Этап первый: тратим как получается

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

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

Этап второй: разбираемся с провайдерами

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

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

Этап третий: раскладываем по полочкам

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

Например, что виртуальные машины и контейнеры съедают львиную долю бюджета. Нередко это может быть даже 60-70%. Хранение данных, как правило, тянет еще 20-30%. Ну, а остатки доедают сетевой трафик и управляемые сервисы.

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

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

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

Этап четвертый: каждому ресурсу своего хозяина

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

Оно покажет, кто сколько тратит с разбивкой по командам, что хорошо. Но есть одна сложность – люди.

Заставить всех верно проставлять теги – задача не из легких. Программистам и так есть чем заняться, скажут вам.

Ситуация усугубляется тем, что российские провайдеры пока этому тоже особо не помогают. У VK Cloud можно прописать теги в конфигурационных файлах Terraform. Яндекс.Облако предлагает лейблы и каталоги для организации ресурсов, а Cloud.ru хвастается развитой системой тегирования, но ни там, ни тут без ручного контроля не обойтись.

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

Этап пятый: каждый отвечает за свой бюджет

Финальная стадия — создание отдельных cost-центров с реальной финансовой ответственностью. На этом этапе каждая команда получает свой лимит расходов и сама за него отвечает.

Тут есть два основных подхода:

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

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

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

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

Правила хорошего тегирования

В теории все звучит гладко, но стоит дойти до дела – и начинаются проблемы. В частности, тегирование – это история про жесткую дисциплину. В этом деле критически важно не допускать разночтений. Если команда называется Backend, то и называть ее надо именно так, а не back-end или даже backend. В противном случае, система просто не вывезет.

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

• cost_center — кто за это платит
• project — к какому продукту или сервису относится
• environment — production, staging или development
• owner — конкретный ответственный человек

Kubernetes — отдельная история

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

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

Впрочем, даже если инструменты есть, с распределением все равно не все просто. Допустим, у нас есть кластер стоимостью 100 тысяч рублей в месяц. На нем работают три проекта: фронтенд с потреблением 40% ресурсов, бэкенд – с 35%, аналитика – с 25%. Казалось бы, просто берем и делим затраты в тех же пропорциях. Но тут есть подводные камни.

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

Каждой команде свой аккаунт

Другой способ решить проблему с атрибуцией — выделить каждой команде отдельный облачный аккаунт. Российские провайдеры это поддерживают:

• В Яндекс.Облаке есть каталоги и организации;
• VK Cloud предлагает проекты;
• Cloud.ru тоже умеет разделять ресурсы по организациям.

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

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

Есть несколько основных вариантов:

1. Первый — делить пропорционально использованию. Просто ставите мониторинг и считаете, от кого сколько запросов уходит к общей базе. А затем распределяете эти расходы в тех же пропорциях. 
2. Второй — взять и поделить. Такой подход проще в реализации, но может показаться несправедливым.
3. Третий — воздавать каждому по заслугам его. Ну, или, проще говоря, брать больше с тех, кто приносит компании больше денег или обслуживает больше пользователей. Это вполне логично с точки зрения бизнеса, но значительно сложнее в подсчетах.

Отчеты для разных ролей

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

• Руководству компании обычно достаточно общей картины: растут расходы или падают, какие три проекта обходятся дороже всего, есть где-то резкие скачки в тратах или нет. Лишние детали будут не поняты и только помешают.
• Продакты ориентируются в основном на unit-экономику. Им важно, сколько стоит инфраструктура для обслуживания одного пользователя, обработки одного заказа или показа тысячи рекламных объявлений. Эти цифры помогают понять реальную рентабельность продуктов и принимать обоснованные решения об их развитии.
• Ну, а DevOps’ы требуют максимальной детализации вплоть до отдельных серверов. Им нужно знать, какие ресурсы недоиспользуются, где можно сэкономить, что оптимизировать в первую очередь.

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

• Cost per team — месячные расходы каждого подразделения. Помогает понять, кто тратит больше и есть ли для этого объективные причины.
• Cost per product — стоимость инфраструктуры для каждого продукта или сервиса. Без этого корректно посчитать рентабельность просто невозможно.
• Процент распределенных затрат — какую долю общих расходов удалось привязать к конкретным владельцам. Это показатель качества вашей системы учета.

Пошаговый план внедрения

Главное правило внедрения – не пытаться охватить все сразу. Гарантированно свихнетесь. Поэтому идите по порядку:

• Начните с аудита. Посмотрите, куда ушли деньги за последние полгода. 
• Составьте список всего, что у вас работает в облаке. 
• Распишите правила тегирования.
• Настройте автоматическое создание ресурсов с правильными тегами. 
• Назначьте ответственных. 
• Объясните командам, зачем это все нужно (но приготовьтесь к сопротивлению).
• Договоритесь заранее, как делить общие ресурсы. 
• Настройте автоматические отчеты. 

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

И еще один важный момент: первые результаты увидите не сразу. Первые месяца три-четыре будет казаться, что занимаетесь ерундой. Это нормально. Все-таки система учета затрат — не та штука, которая работает с первого дня. Зато когда заработает, сразу станет понятно, стоило ли оно того. Так что мужайтесь.

Что получится в результате

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

Помимо прямой экономии денег, вы получите несколько приятных эффектов:

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

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