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

Бизнес без FinOps. Очень успешно

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

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

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

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

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

• Забытые инстансы от экспериментов;

• Автоматические бэкапы с избыточной частотой;

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

Все это может добавлять до 30% к стоимости облака. И тут уже неважно, большая у вас компания или нет.

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

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

Где деньги, Билли: проблема shared-ресурсов

Этот мем – крик души каждого, кто хоть раз пытался распределить shared-ресурсы по отделам. Представим, что у нас есть Kubernetes-кластер стоимостью 400 тысяч в месяц, на котором крутятся сервисы пяти команд. При этом счет всегда приходит один. Вопрос – кто должен платить и сколько?

Можно разделить поровну, но тогда команда мобильного приложения, которая использует 10% ресурсов, заплатит столько же, сколько backend, который потребляет 60%. А это несправедливо. Можно поделить пропорционально потреблению, но для этого нужна система учета: теги, метрики, распределение. Короче, тот самый FinOps, которого нет.

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

А вот будь у вас FinOps, было бы понятно, кто сколько тратит. Каждая команда могла бы видеть свой вклад в счет, можно строить отчеты по проектам, отделам или клиентам. 

Мультиклауд без FinOps: пожар, но мы улыбаемся

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

Один провайдер включает трафик в стоимость виртуалки. Другой дерет по 10 рублей за гигабайт. У третьего вообще фиксированная плата за месяц. Попробуйте в такой мешанине разобраться, где и что разместить. Даже названия сервисов скорее всего будут разные: у одного виртуалка — это instance, у другого VM, у третьего compute unit.

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

Эффект Питера: вчера забыл, сегодня отвечаешь

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

Вот вам реальная история из практики: один разработчик решил поэкспериментировать с GPU для нейронок. Запустил инстанс, поигрался пару часов, получил результаты и ушел домой, естественно, ничего не выключив. А через месяц бухгалтерия приходит с чеком на 47 тысяч рублей. Виновник даже бровью не повел. Да и допустимо ли вообще его винить, если он уже не помнит, что натворил? 

Кстати, почитать другие кейсы из практики FinOps можно в нашем сообществе в Telegram. Присоединяйтесь. Там много полезной информации.

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

Решение: тегирование как обязательное условие. Создаешь ресурс — указываешь project, owner, environment. Нет тега — нет ресурса. Главное – настроить политики так, чтобы без правильных меток не создавалось вообще ничего. А когда есть owner, значит, есть кому предъявить. Только так все будут помнить про выключение dev-сред.

Сначала ты молод: эволюция финопсера

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

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

Ведь большинство проблем с облачными расходами решается не сложными процессами, а элементарной гигиеной. Просто берешь и раз в месяц открываешь консоль провайдера, смотришь список ресурсов и спрашиваешь себя: "А это вообще зачем?". Если ответов нет, удаляешь — и счет сразу уменьшается на 20-30%.

Облако не только для бэкапов: осознание приходит со счетом

Нет, сначала ты искренне веришь, что берешь облако только для бэкапов. А потом думаешь — а чего dev-среды не перенести? Разработчики только спасибо скажут. Затем туда же отправляется staging. А там и до продакшена недалеко. Ну, раз уже все остальное и так там.

В результате вместо 30 тысяч рублей вы платите за облако под 300. Тут-то и приходит понимание, что что-то пошло не так.

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

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

Переносим дата-центр в облако: задумываться о резервировании нужно до пожара

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

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

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

Kubernetes и Terraform — это не для красоты, а чтобы можно было перенести инфраструктуру в другое место, если что-то пойдет не так. В один клик, конечно, все сделать не получится, но хотя бы ваши труды не пойдут прахом.

Тратить деньги впустую vs FinOps Radar

FinOps Radar — первый бесплатный инструмент для оптимизации расходов в Yandex Cloud. Просто даете ему доступ read-only, а он начинает собирать данные и искать проблемы. Это, кстати, ключевой момент. Сам Радар ничего не делает, так что можете не переживать.

Основных функций три:

• Поиск аномалий в тратах

• Поиск зомби-ресурсов (выключенные виртуалки, неприсоединенные диски, забытые IP-адреса, устаревшие снапшоты)

• Рассылка автоалертов с дайджестами о проблемах.

Удобно, что платформа сразу показывает сумму потенциальной экономии по каждой рекомендации. Что-то на 100 рублей, что-то на десятки тысяч. Увидел подозрительное — кликнул и попал прямо в консоль Yandex Cloud на страницу этого ресурса. А дальше решаешь сам: удалять, менять конфигурацию или оставить все как есть.

Для малого бизнеса вообще идеальный вариант. Дал доступ к аккаунту — и система сама нашла проблемы. Бесплатно.

Бюджет позволяет

Нужен еще один dev-сервер? Бюджет позволяет. GPU для экспериментов? Бюджет позволяет. Премиум SSD вместо обычного? А что? Бюджет же позволяет. Managed Kubernetes с автоскейлингом до небес? Ну, в общем, вы поняли.

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

И начинается разбор, в ходе которого выясняется, что половина ресурсов не используется вообще, еще четверть работает с загрузкой CPU на 5% и спокойно влезла бы в инстанс вдвое дешевле. И только оставшаяся четверть — это то, что реально нужно. Но пока бюджет позволял, никому до этого и дела не было.

Решение простое: не ждать, пока бюджет кончится, а внедрить базовые процессы сразу. Тегирование, автовыключение dev-сред по расписанию, мониторинг расходов с алертами – все это реально рабочие инструменты, которые сэкономят вам 25-30%. Даже когда денег много, лучше тратить их на рост и найм людей, а не на виртуалки впустую.

NAS вместо облака? Люблю рисковать

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

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

Облачные провайдеры обещают SLA 99,9-99,99%. Звучит как маркетинг, но на практике это означает 8 часов простоя в год или 52 минуты соответственно. У вас на своем железе такие показатели? Если да — отлично. Если нет — то где тут надежность?

К тому же российские облачные платформы подчиняются тем же законам о персональных данных и соответствуют ФЗ-152 и стандартам ФСТЭК. То есть с безопасностью и регуляторными требованиями там все в порядке. Найти приличного провайдера сегодня проще, чем организовать все самому.

Облака не существует: это чей-то чужой компьютер

Никакого "облака" не существует. Это просто чей-то чужой компьютер, на котором крутятся ваши виртуалки.

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

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

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