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

Нужен ли FinOps малому бизнесу

Проблема, с которой малый бизнес сталкивается в облаке заключается не только и не столько в переплате, сколько в непредсказуемости расходов. Ситуация, когда за один месяц платишь 15 тысяч, за другой — 45, а за третий – 20, становятся нормой. И главное непонятно, почему так происходит, ведь модель pay-as-you-go кажется такой выгодной. Но это пока не начнешь разбираться.

Вот ключевые факторы, которые приводят к увеличению облачных затрат:

• Тестовые среды, которые вместо рабочих часов крутятся 24/7;

• Бесконтрольный автоскейлинг;

• Висящие без привязки к серверам диски;

• Забытые инстансы, запущенные для экспериментов;

• Автоматические бэкапы, сохраняющиеся с избыточной частотой;

• Использование для хранения данных премиум-хранилищ вместо холодных архивов.

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

Ну, так, может, и ну его, это облако? Не спешите рубить сплеча.

Даже если у вас нет возможности содержать армию аналитиков, вы не проиграли. FinOps можно освоить и без внешней поддержки и дорогущих enterprise-решений. Просто почитайте наш блог, а затем потратьте неделю на отладку самых базовых процессов, и облачные расходы пойдут на спад.

Как экономить в облаке

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

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

Шаг первый: выясняем, куда утекают деньги в облаке

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

• Вычисления

• Хранилища

• Сеть

• Управляемые сервисы

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

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

Шаг второй: настраиваем тегирование

Теперь нам нужно понять, какая команда или проект тратит больше, чем все остальные. Сделать это без тегов практически невозможно. Поэтому договоритесь с разработчиками, что есть обязательный набор меток для каждого ресурса, которыми нельзя пренебрегать. Пусть это будет что-то базовое типа project для названия проекта, environment для обозначения среды и owner для ответственного. Большего на начальном этапе и не нужно. Ну, максимум, если у вас несколько отделов, можно добавить cost_center. 

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

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

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

Шаг третий: автоматизируем самое очевидное

Сюрприз состоит в том, что уже на этом этапе можно получить реальную экономию всего за пару часов работы.

Dev и test-среды чаще всего не должны работать круглосуточно. Ну, подумайте сами, зачем тестовой базе данных мотать счетчик в субботу, если у всех разработчиков выходной? Значит, можно смело настроить автоматическое выключение серверов разработки по расписанию. Одно это действие может сэкономить вам до 70% расходов на dev-окружения.

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

Затем можно перенести старые данные в дешевые хранилища. Логи полугодовой давности совершенно необязательно держать на быстром SSD и уж тем более тратиться на премиальные NVMe. У всех провайдеров есть архивные классы хранения по копейкам за гигабайт. Их и используйте.

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

Шаг четвертый: настраиваем базовый мониторинг в облаке

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

• Во-первых, поставьте простой мониторинг расходов и ключевых метрик. Grafana с Prometheus, встроенные дашборды облачного провайдера — что это будет, не так важно. Лишь бы оно работало. Нам надо видеть три вещи: текущие траты по проектам, загрузку основных серверов и прогноз расходов на конец месяца.

• Во-вторых, настройте алерты на превышение бюджета. Все крупные провайдеры предлагают бесплатные уведомления. В российских облаках такие штуки тоже есть. Поэтому задайте лимит на 15-25% выше обычных трат и спите спокойно. Система сама пришлет письмо, когда что-то пойдет не так. 

А теперь про конкретные метрики. Сосредоточьтесь на трех ключевых показателях:

Шаг пятый: финансовая дисциплина без фанатизма

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

1. Начните с регулярных, но не очень частых кост-ревью. Раз в месяц собирайтесь минут на 15-20 и разбирайте облачные расходы. 

Примерный план такой пятнадцатиминутки:

Сравниваете траты с прошлым месяцем, находите проекты с резким ростом расходов, обсуждаете причины. Может быть, команда мобильного приложения запустила нагрузочное тестирование. Или кто-то из backend-разработчиков поэкспериментировал с новой базой данных и забыл ее выключить. Что-нибудь да найдется.

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

Только – заклинаю – не превращайте кост-ревью в поиск стрелочников. FinOps в первую очередь преследует цель добиться от сотрудников, чтобы они принимали осознанные решения, а не резали все подряд. Вы же не моэль, в конце-то концов (извините). Тем более, что ситуации бывают разные, и это нужно учитывать. Если рост расходов приводит к росту бизнеса, он оправдан. Так что не ведите себя как робот сами и не делайте таковых из своих сотрудников.

Инструменты FinOps

Хорошая новость: для старта вам совсем не нужны дорогие enterprise-решения. Встроенные инструменты облачных провайдеров закроют 80% ваших потребностей на начальном этапе вне зависимости от того, каким облаком вы пользуетесь: Cost Explorer в AWS, биллинг-панель Яндекс.Облака, Cost Management в Azure.

Для тех, кто активно использует контейнеры, есть OpenCost. Это бесплатный open-source проект для анализа расходов Kubernetes. Он показывает, сколько стоит каждый под в кластере, интегрируется с Grafana и дает детальную аналитику по неймспейсам и приложениям.

FinOps Radar – то, что надо малому бизнесу

Из российских решений обратите внимание на FinOps Radar. Это первая и пока что единственная платформа для оптимизации расходов в Яндекс.Облаке, которая работает бесплатно. Сервис автоматически ищет аномалии в тратах, находит зомби-ресурсы и присылает рекомендации по оптимизации. Для малого бизнеса это просто идеальный вариант. Достаточно дать ему доступ к аккаунту, и он найдет все, что не так, сам.

Нe и не списывайте со счетов и простые самописные скрипты. Зачастую решение из пары десятков строк Python закроют конкретную задачу лучше любого корпоративного комбайна. И притом бесплатно или почти бесплатно. 

Когда можно обойтись без FinOps

Каким бы классным и полезным ни был FinOps, будем честны подходит он не всем.

1. Если ваши ежемесячные траты не превышают 15-20 тысяч рублей и состоят из пары стабильно работающих серверов, заморачиваться с глубокой аналитикой смысла мало. В таких масштабах проще раз в полгода заглянуть в консоль и удалить пару забытых дисков, чем заниматься внедрением спецпроцессов.

2. То же касается компаний, которые используют в основном готовые SaaS-решения. Если вы работает по подписке на CRM, почту, офисные приложения и облачное хранилище, особой оптимизации вам и не требуется. Разве что можно периодически пересматривать количество лицензий и отключать сервисы, которыми никто не пользуется.

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

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

Реальный план по внедрению FinOps на месяц

Дочитали до этого места? Значит, дело осталось за малым – начать практическое внедрение. Вот вам реальный чек-лист на первые четыре недели:

Первая неделя

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

Вторая неделя

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

Третья неделя

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

Четвертая неделя

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

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

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