Когда счет за облако приходит в конце месяца, а финдир молча передает вам распечатку с суммой на 40% больше прошлого месяца, это верный признак того, что проблемы начались и сами собой не решатся. Не будет такого, что сегодня перерасход есть, а завтра все вдруг придет в норму. Не придет. Данных со временем становится больше, пайплайны запускаются чаще, хранилище разрастается, а понимания куда уходят деньги из ниоткуда не появляется. И, чтобы навести порядок, используют практики DataOps и FinOps.
DataOps выстраивает процессы работы с данными между командами: автоматизацию пайплайнов, контроль качества, управление изменениями и единые правила работы с данными на всех этапах обработки. FinOps делает стоимость инфраструктуры прозрачной для инженерных команд и позволяет понимать, сколько стоят архитектурные и технические решения. Когда данные о потреблении и стоимости становятся видны, появляется возможность управлять расходами и принимать обоснованные решения по инфраструктуре.
Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram. Там уже собрались гуру, которые знают, как экономить на инфраструктуре.
Хранилище: горячее, теплое, холодное
Начнем, пожалуй, с банального. Не все хранимые данные используются одинаково часто. Есть те, к которым обращаются тысячи раз в секунду. Например, логи в реальном времени, данные кэша или активные пользовательские сессии. Но есть и архивы трехлетней давности,, которые могут не трогать буквально годами, но они все равно хранятся. Зачем? На всякий случай. Вдруг понадобится.
Облачные провайдеры давно это поняли и придумали многоуровневое хранилище. Горячий слой, теплый и холодный, которые отличаются друг от друга скоростью доступа к данным и, конечно же, ценой.
Горячий слой — это файловые системы на основе быстрых твердотельных накопителей (SSD) или высокоскоростные классы объектного хранилища. В том же Яндекс Облаке это Object Storage Standard. Стоимость обслуживания в таком хранилище составляет пару рублей за гигабайт в месяц. Дорого? Ну, в общем, да. Зато доступ к данным максимально быстрый. Да и данные обычно лежат тут недолго: как правило, от недели до трех месяцев.
Теплый слой — это что‑то среднее. Тут уже используются файловая система на основе классических жёстких дисков (HDD) или чуть более медленное объектное хранилище соответствующего класса. Пример такого хранилища — Cold Storage в Яндекс Облаке за рубль‑с-чем‑то за гигабайт в месяц. То есть примерно вдвое дешевле горячего. Сюда обычно складывают данные, которые нужны не постоянно, а эпизодически, например, раз в неделю или раз в месяц. Они могут храниться вплоть до нескольких месяцев, то есть дольше, чем в горячем, но меньше, чем в холодном слое.
Холодный слой — это архив для данных, к которым обращаются совсем редко или не обращаются вообще. В Яндекс.Облаке это тот самый Ice Storage за приблизительно 50 копеек за гигабайт в месяц. То есть в 4 раза дешевле горячего хранилища. Правда, операции дороже и есть минимальный срок тарификации.
Вроде все понятно. Но это пока не начать пользоваться. Практика показывает, что мало кто настраивает эти слои правильно. Надо только провести аудит.
Что дает первый аудит хранилища
Первый FinOps‑аудит почти везде выглядит одинаково. Открываешь Object Storage, смотришь метрики использования хранилища — и вот оно:
60–80% занимают файлы старше 3–6 месяцев;
Терабайты логов и staging‑данных, к которым никто не обращался;
файлы в форматах Parquet и несжатые CSV, которые остались после выгрузок или экспериментов;
Бэкапы бэкапов на бэкапы;
Временные выгрузки, которые просто забыли после экспериментов.
При этом все это почему‑то лежит в Standard‑классе, как будто данные активно используются каждый день. Ну и платить, естественно, приходится по максимальному тарифу, хотя по факту можно было отправить все в холодное хранилище и экономить 4 конца.
Дальше смотрим access‑логи. На этом этапе чаще всего выясняется, что большая часть объектов вообще не читалась несколько месяцев. В целом, проблемы нет. Если правильно расслоить это дело:
Свежие данные оставляем в Standard;
Объекты, к которым не обращались 20–30 дней, автоматически переводим в Cold через правила жизненного цикла объектного хранилища (Lifecycle rules);
Данные старше 90 дней автоматически переносить в холодное хранилище;
временные и staging‑данные ставим на автоматическое удаление через 7–14 дней.
Вот, собственно, и все. Никакой магии. Просто настроить правила жизненного цикла объектного хранилища (Lifecycle rules) и регулярный пересмотр типов и назначения данных. Но даже такая базовая схема обычно снижает расходы на хранение уже в первый месяц.
Работает это потому, что используется не одна функция, а система: понятная архитектура хранения данных, правила жизненного цикла объектов (lifecycle rules) и прозрачная организация хранения — например, тегирование, чтобы видеть, какие команды и сервисы используют хранилище и кто за него платит. Такой подход часто называют «FinOps для данных».
ETL: где реально платят за вычисления
Хранение данных — это одно. Но данные нужно ещё и обрабатывать. ETL (Extract, Transform, Load) — это конвейер, который извлекает данные из источников, трансформирует их и загружает в хранилище. Само собой, не бесплатно.
В том же Yandex Data Proc стоимость вычислений складывается из используемых ресурсов и времени работы кластера. Например:
1,44 ₽ за час работы 100% vCPU + 0,37 ₽ за каждый гигабайт оперативной памяти в час + стоимость диска
То есть задание, которое выполняется около 15 минут на небольшом кластере, может стоить меньше 50 рублей. Звучит недорого. Но таких заданий в день может быть и 100, и 200. А это уже тысячи рублей в месяц. А за год?
Есть способы снизить стоимость обработки. Например, использовать форматы данных, которые уменьшают объем сканирования при запросах, такие как Parquet. Колонночный формат позволяет читать только нужные поля, поэтому системы обработки данных сканируют значительно меньше данных. За счет этого уменьшается объем вычислений и стоимость обработки.
Есть, впрочем, и альтернативный подход — не ETL, а ELT. Буквы те же, но порядок операций другой: данные сначала загружаются в хранилище, а затем преобразуются при выполнении запросов. В ETL трансформации происходят до загрузки данных, а в ELT — после, на этапе обработки. При этом вычисления в любом случае выполняются отдельным вычислительным движком, и за них также приходится платить.
Сам по себе переход от ETL к ELT не гарантирует снижения расходов. Стоимость зависит от архитектуры обработки данных, объема вычислений и того, как организованы таблицы и партиции.
Хотя и здесь расходы могут сильно различаться. Все зависит от того, какие SQL‑запросы выполняются и как устроено хранение данных. Если таблица спроектирована неудачно или партиционирование настроено неправильно, система может сканировать всю таблицу вместо одной партиции — и тогда стоимость обработки легко вырастает в разы. Такое на практике встречается регулярно.
Data Lake, Data Warehouse или Lakehouse
После того как разобрались с ETL и вычислениями, возникает следующий вопрос: как организовать хранение и аналитическую обработку данных.Здесь важно не путать уровень физического хранения данных и архитектуру аналитической системы. На практике используют три основных архитектурных подхода.
Data Lake — это хранилище для больших объемов сырых данных. Обычно оно строится на объектном хранилище и позволяет сохранять данные в разных форматах: логи, JSON, Parquet, CSV и другие.
Главное преимущество — гибкость и низкая стоимость хранения. Но без каталогов, схем и правил управления такое хранилище легко превращается в так называемое data swamp, где данные есть, но найти и использовать их сложно.
Data Warehouse — это система аналитического хранения данных со строгой структурой. Таблицы, схемы, оптимизация запросов и индексы позволяют быстро выполнять аналитические запросы.
Такие системы изначально проектируются для BI‑аналитики и отчетности. Они обычно дороже в эксплуатации, поскольку включают не только хранение данных, но и вычислительные ресурсы для обработки запросов.
Lakehouse — архитектурный подход, который пытается объединить оба мира: дешевое хранение данных из Data Lake и возможности аналитики из Data Warehouse.
В таких системах данные хранятся в объектном хранилище, но поверх него используются форматы и метаданные, позволяющие выполнять транзакции, управлять схемами и оптимизировать запросы. Один из распространенных подходов — многослойная организация данных (например, Bronze, Silver, Gold), где данные постепенно очищаются и структурируются.
Когда удалять данные
Архитектуру выбрали. Отлично. Теперь вопрос: как долго хранить данные и когда их удалять. Это определяется правилами хранения данных, которые задают сроки хранения и момент удаления.
Компании часто держат данные «на всякий случай», хотя на практике значительная часть этих данных никогда больше не используется. Они просто продолжают копиться, потому что удалять их боятся. Но так делать не обязательно.
Стандартная стратегия по срокам выглядит так:
0–30 дней — горячий слой. Тут идет активный анализ, быстрые запросы, вся оперативная работа.
30–90 дней — теплый слой. Периодические запросы, отчеты, которые строятся раз в неделю или месяц.
90–365 дней — холодный слой. Обращаемся редко, но данные еще под рукой.
365+ дней — либо архив, либо вообще удаление.
Возьмем пример. 100 терабайт логов за год в Standard‑классе Yandex Object Storage — это больше 2,6 миллиона рублей в год за хранение данных. В Ice‑классе — около 700 тысяч рублей в год. Разница почти в 2 миллиона. Спросите, откуда? Просто в первом случае правила игнорировали, а во втором один раз настроили как надо. И все. Дальше система работает сама без вашего участия.
Но дело не только в стоимости хранения данных. Есть еще юридический контекст, и он часто оказывается строже любых требований к экономии.
152-ФЗ требует хранить персональные данные ровно столько, сколько нужно для цели обработки. А дальше — либо удалять, либо обезличивать. Для банковских транзакций этот срок составляет три года. Для бухгалтерии — пять лет по НК РФ. То есть тут уже решаете не вы, а закон.
Главное — понять и принять, что разные типы данных требуют разного подхода, и уже на основе этого строить дальнейшую работу:
Логи приложений можно чистить агрессивно: 30 дней в горячем, 90 в холодном, дальше удаление.
Метрики инфраструктуры лучше агрегировать: детальные данные храним 7 дней, почасовые агрегаты — 90 дней, суточные — год.
Персональные данные пользователей привязывать к жизненному циклу их учетных записей и добавлять срок хранения в соответствии с требованиями законодательства.
Финансовые документы хранить строго по требованиям регулятора.
Само собой, руками с этим разбираться не будешь. Обычно используют правила жизненного цикла хранения данных. В Yandex Object Storage Lifecycle механизм простой: указываем правило (объекты старше 30 дней с тегом log_type=application переносить в Cold, старше 90 — в Ice, старше 365 — удалять), и система делает все сама. Настраивается всего один раз, а работает годами. Красота.
Но здесь возникает другая проблема. Такие правила обычно настраивают один раз и потом забывают. Если через год требования меняются, а правила хранения никто не пересматривает, можно либо удалить данные раньше срока, либо хранить их дольше, чем нужно. Поэтому правила хранения данных стоит регулярно пересматривать.
TCO: считаем полную стоимость владения
Пока вроде ничего сложного. Но рано или поздно встает вопрос: а не поставить ли свое собственное железо и жить без всяких облаков? Вот тут‑то и становится нужен расчет TCO (Total Cost of Ownership) — полной стоимости владения.
Считается он по формуле:
TCO = CAPEX + (OPEX × период в годах)
То есть разовые затраты плюс среднегодовые операционные расходы, помноженные на срок эксплуатации.
Давайте посчитаем на условном примере (у вас числа будут свои, но порядок понятен). Сравним собственный сервер и облако на горизонте трех лет.
Собственный сервер: 600 000 ₽ единоразово (железо, коммутатор, охлаждение, монтаж в стойку) плюс 3 500 000 ₽ в год на операционку (электричество, зарплата админа, интернет‑канал). Умножаем на три года: 600 000 + (3 500 000 × 3) = 11 100 000 ₽.
Облако: 70 000 ₽ в месяц, умножаем на 36 месяцев = 2 520 000 ₽. При этом охлаждение уже включено, админить инфраструктуру не надо, и аптайм обещают на уровне 99.99% по SLA.
Понятное дело, что числа грубые и какие‑то аспекты не учтены вообще. Но не надо быть математиком, чтобы понять, что облако получается дешевле, даже если добавить сюда все скрытые расходы. Правда, справедливо это лишь для переменных нагрузок, когда сервера то загружены, то простаивают. А если у вас утилизация стабильная и высокая (процентов 80–90) круглый год, без просадок и пиков, то на собственном железе можно сэкономить до 30%. Но таких сценариев в реальной жизни явно не большинство.
FinOps: культура, а не инструмент
А теперь самое интересное — FinOps. Если по‑простому, он нужен для того, чтобы не превратить ваши расходы в черную дыру.
По факту это никакой не софт и не набор скриптов, которые можно поставить и забыть. Это культура, подход к работе. Образ жизни, если хотите.
Вот три столпа, на которых все держится:
Inform — данные о расходах доступны каждый день, в реальном времени;
Optimize — на основе этих данных принимаются конкретные решения (выключить сервер с нагрузкой 10%, переместить редкие данные на холодный слой);
Operate — автоматизация управления инфраструктурой: использование тегов для распределения расходов и правил управления ресурсами, настройка бюджетов с уведомлениями и автоматическое отключение неиспользуемых ресурсов.
Нет, конечно, на одном энтузиазме далеко не уедешь. Кое‑какие инструменты все‑таки нужны. Хотя бы для наглядности. Но, что касается их выбора, то тут все up to you.
Можно взять встроенные инструменты самих провайдеров:
Yandex Cloud Cost Explorer
Мониторинг биллинга от Cloud.ru
Встроенные инструменты от Selectel и РТК‑ЦОД
А можно выбрать что‑то стороннее. Например, FinOps Radar для Яндекс.Облака.
Исследования показывают, среди крупных компаний FinOps‑инструментами пользуются почти так же часто, как и инструментами ИБ. То есть за деньгами принято следить не хуже, чем за безопасностью. Короче, с приоритетами у людей все нормально.
Хотя само по себе наличие инструмента тоже еще ничего не гарантирует. Во всяком случае, есть компании, которые умудряются сливать деньги в самых неожиданных местах даже с FinOps‑инструментами:
Auto‑scaling с утечкой памяти
Dev‑окружения, про которые все забыли
Балансировщики нагрузки, которые со временем накапливались без реального трафика
Зарезервированные мощности без реальной нагрузки
Сжатие данных: где выиграть еще 3–10x
Это все были примеры того, как деньги уходят просто так, из‑за невнимательности. Но есть и позитивная сторона — места, где гарантированно можно сэкономить. Одно из них — сжатие данных.
Почему именно оно? Ну, хотя бы потому, что сжатие покрывает три статьи расходов сразу:
Хранение (меньше гигабайт = меньше платишь за диск);
Вычисления (меньше данных читается и передается между сервисами);
Трафик (меньше данных гонять между сервисами туда‑сюда).
Чем сжимать:
Gzip дает коэффициент сжатия 2.7–3x для текстовых данных — JSON, CSV, логи.
Zstd выдает 2.8–3.2x и при этом быстрее распаковывается, что важно при частых чтениях.
Snappy сжимает не так плотно (всего 2x), но имеет преимущество в скорости, поэтому его используют в Hadoop и Spark, когда важнее время обработки, чем экономия места.
Это база. Но есть и следующий уровень сжатия, когда меняется сам формат хранения.
Колоночные форматы типа Parquet и ORC дают двойное преимущество. Во‑первых, лучшее сжатие за счет того, что данные в столбце однотипные (все числа, все строки, все даты). Во‑вторых, при запросах читается только нужный столбец, а не вся строка целиком.
Допустим, у нас есть таблица на 50 колонок, а запрос использует всего 5 из них. В Parquet сканируется в 10 раз меньше данных. Если платите за объем сканирования (а в большинстве аналитических платформ именно так), то запрос по 10 ТБ CSV может обойтись в разы дороже того же самого запроса по Parquet. Экономия раз в 10 на ровном месте. Нравится.
Конкретный пример с цифрами. CSV без сжатия — 100 ГБ. CSV с Gzip — 35 ГБ (в 3 раза меньше). Parquet с Zstd — 12 ГБ (в 8–9 раз от исходного CSV). И это только хранение. При обработке выигрыш еще больше, потому что меньше I/O операций, меньше трафика по сети, быстрее декомпрессия.
Партиционирование по датам или другим полям позволяет читать только релевантные куски данных. Логи партиционированы по дням, делаете запрос на последние три дня — читается 3 партиции из 365. Экономия на сканировании в 120 раз. Еще больше нравится!
Ну, и дедупликация. Она убирает повторяющиеся блоки на уровне хранилища. Этот подход отлично работает на бэкапах и снапшотах.
Проблема лишь в том, что все это нужно настраивать руками. По умолчанию данные пишутся как есть — CSV, JSON, без всякого сжатия. И, чтобы получить экономию, нужно переписать пайплайн под Parquet, добавить компрессию на лету, настроить партиции. На это уходят инженерные ресурсы и время. Автоматизировать тут что‑то весьма и весьма проблематично. Поэтому только ручками. Но окупается обычно за месяц‑два. А дальше просто работает и экономит вам деньги, пока вы спите, едите или занимаетесь чем‑то более интересным.
Выгоден ли FinOps
А ведь и правда? Давайте‑ка возьмем и посчитаем на конкретном примере, чтобы стало понятнее, о каких суммах вообще речь.
Возьмем обычный сценарий: компания обрабатывает 50 терабайт логов в месяц, плюс хранит исторический архив в 2 петабайта.
Первый вариант — без FinOps, когда все лежит в горячем слое как попало: 50 ТБ текущих логов плюс 2000 ТБ архива в Standard‑классе Yandex Object Storage — это около 4,6 миллиона рублей в месяц.
Второй вариант — с FinOps и правильными политиками: свежие логи остаются в Standard (они действительно нужны быстро), логи возрастом 30–90 дней переезжают в Cold (обращаемся редко, но иногда нужны), старые логи и весь архив уходят в Ice (практически не трогаем). Итого примерно 1,4 миллиона рублей в месяц.
Экономия получается больше 3 миллионов рублей в месяц, или около 38 миллионов в год. Да, из этой суммы надо вычесть зарплату FinOps‑инженера и стоимость инструментов мониторинга, но чистая экономия все равно исчисляется десятками миллионов рублей в год. И это только на хранилище, без учета оптимизации вычислений.
Что делать прямо сейчас
Цифры, конечно, красивые. Но как начать? С чего вообще взяться за эту оптимизацию? Вот конкретный план действий, который можно запустить уже завтра.
Первое — внедрите теги на все ресурсы в облаке. Без этого вы вообще не поймете, кто за что платит и где утечки. Каждый сервис должен иметь минимум три тега: проект, владелец (команда или человек), окружение (prod/dev/staging). Настройте мониторинг расходов — Yandex Cloud Cost Explorer, инструменты от Cloud.ru, Selectel или что там у вас. И каждый день смотрите графики. Каждый. День. Не раз в неделю на планерке, а именно каждый день. Ищите аномалии, задавайте вопросы командам, разбирайтесь.
Второе — Lifecycle Policies для хранилища. Они дают 50–75% экономии практически сразу. Для Data Lake настройте автоматическое перемещение данных на холодные слои по возрасту и частоте обращения. Одно только это изменение может сэкономить сотни тысяч рублей в год, а настраивается один раз и работает годами вообще без вашего участия.
Третье — переходите на Parquet с компрессией для аналитических данных. Это 3–10x экономия на вычислениях и хранении одновременно. Колоночные форматы с Zstd или Snappy уменьшают объем сканирования и ускоряют обработку. Да, придется переписать часть пайплайнов и потратить инженерочасы. Но оно того стоит, поскольку окупается за месяц‑два максимум.
Четвертое — используйте spot‑инстансы или прерываемые VM для задач, которые терпят перезапуски. Они режут расходы на 60–90% для batch‑обработки, ETL‑джобов, рендеринга и прочего. Яндекс, например, дает скидку до 70% на прерываемые виртуалки. Для продакшен‑сервисов с требованием к аптайму это, конечно, не подходит. Но для ночных пайплайнов, которые обрабатывают данные раз в сутки — самое то.
Важный нюанс про spot‑инстансы: их могут отозвать когда угодно, без предупреждения. Yandex preemptible VM может остановиться в любой момент, и после stop‑сигнала обычно дается всего до 30 секунд на graceful shutdown. Если ваша задача не умеет сохранять промежуточное состояние и восстанавливаться с места остановки, она просто сломается и придется перезапускать с нуля. Нужна либо полная идемпотентность (те, кто смеялся в школе с многочлена, не смейтесь, это такой термин), либо checkpointing. Без этого spot‑инстансы использовать нельзя.
Пятое — автоматическое выключение dev‑серверов и тестовых окружений в нерабочее время. Это экономит до 65% времени работы, ну и денег, конечно. Это можно поручить Cloud Functions или Lambda. Они мониторят теги на ресурсах, выключают инстансы в 19:00, а включают обратно в 9:00. Тестовые окружения для CI/CD при этом тоже поднимаются только по требованию, когда тесты реально запускаются, и убиваются сразу после прогона. Сами.
Шестое — инкрементальная загрузка данных вместо full reload каждый раз. Благодаря этому снижается объем обрабатываемых данных в десятки, а то и сотни раз. Просто грузите только новые и измененные строки, а не всю таблицу целиком каждый день заново. 100 миллионов строк ежедневно против 500 тысяч новых записей — разница в 200 раз по объему. Для инкрементальной загрузки нужны либо timestamp‑поля в таблицах (created_at, updated_at), либо CDC (Change Data Capture) на уровне самой базы данных.
Седьмое — используйте reserved instances, но осторожно. Для стабильных нагрузок они дают скидку 30–70% от обычной цены. По факту от вас вообще ничего не требуется: просто резервируете мощность на год или три вперед, получаете хороший дисконт от on‑demand. Проблема в том, что с этой телеги потом просто так не слезешь. Если через три месяца нагрузка у вас поменялась или проект свернули — все равно будет сидеть с неиспользуемыми ресурсами и платить за них по фул‑прайсу. Поэтому reserved имеет смысл только для baseline‑нагрузки, которая точно стабильна круглый год. Для всего остального лучше on‑demand или spot‑инстансы.
FinOps — всему голова
DataOps и FinOps вместе решают реальную проблему: облако стало дорогим для тех, кто не управляет затратами. Но для тех, кто внедрил правильные процессы и инструменты, облако — самый дешевый вариант инфраструктуры. Экономия 25–40% без потери производительности — это, как говорила Елена Малышева, норма.
Звучит вроде пафосно, но самое главное — начать с малого. Потому что так это и работает. Выберите один проект, включите мониторинг, настройте Lifecycle Policies, проведите первый аудит. Уже через две недели вы поймете, где именно утекают деньги. За месяц получите первые результаты. А за полгода FinOps войдет в привычку, так что отдавать не захотите.
И, да: облако дешевле собственной инфраструктуры, но только если вы это понимаете и управляете затратами так же серьезно, как разработчики управляют качеством кода. Иначе будете каждый месяц получать от финдира распечатку со счетом и играть роль Незнайки.
