Привет, Хабр! Сегодня с вами Екатерина Чичкова, сертифицированный FinOps-специалист, руководитель направления FinOps во Flowwow, и Марина Андреева, FinOps-специалист Flowwow.
Чем активнее растет ИТ-инфраструктура, тем выше риск незаметно превысить бюджет. Мы во Flowwow решили не дожидаться ситуаций в духе «проснулся, на счету ноль, все упало» и сыграли на опережение. В этой статье расскажем, как мы выстроили систему мониторинга облачных затрат в корпоративном мессенджере с помощью FinOps-ботов и какой эффект это дало бизнесу.
Перед тем как перейти к реализации, коротко объясним, что такое FinOps и зачем он нужен.
Проблемы с управлением ИТ-расходами, которые решает FinOps
Раньше ИТ-расходы контролировались на этапе закупки: инфраструктуру (серверы, лицензии, оборудование) покупали раз в несколько лет. Бюджет утверждали заранее, а дополнительные мощности проходили через согласования с CTO и финансами. Теперь все иначе: вместо плановых закупок серверов и лицензий ресурсы потребляются «по кнопке» в облаках и AI-сервисах, а стоимость выявляется постфактум — в биллинге. Инженеры не отслеживают траты ежедневно, а финансовые команды узнают о росте расходов в начале следующего месяца, когда деньги уже потрачены.
Там, где классический финансовый контроль перестает работать, появляется FinOps. Это фреймворк и культурная практика, которая помогает максимизировать бизнес-ценность технологий, обеспечивает своевременное принятие решений на основе данных и формирует финансовую ответственность через взаимодействие инженерных, финансовых и бизнес-команд.
FinOps-мониторинг во Flowwow
На старте мы работали с биллингом так же, как и все: приходил счет от провайдера — мы его оплачивали. Это выглядело вполне логично: раз инфраструктура разворачивается под реальные задачи, а команды работают ответственно, значит, в облаке используется только то, что действительно нужно бизнесу. При этом счета медленно, но верно росли от месяца к месяцу. Но в какой-то момент мы поняли, что без регулярного анализа расходов эффективно управлять ими невозможно.
Мы начали с ежемесячного разбора затрат. На этом этапе удалось сократить стоимость облаков примерно на 15% за счет обнаружения неиспользуемых ресурсов и лишних конфигураций. Однако быстро выяснилось, что такого контроля недостаточно. Так, если аномалия возникала в начале месяца (например, 3 числа), до следующего разбора она могла оставаться незамеченной. То есть все это время инфраструктура продолжала потреблять больше ресурсов, чем необходимо.
Тогда мы добавили и еженедельный мониторинг: проверяли расходы по четвергам. Однако проблема полностью не исчезла: если рост затрат начинался в пятницу, переплата снова накапливалась, теперь уже неделю. Поэтому следующим шагом стало добавление ежедневного контроля затрат.
Боты мониторинга
Идея ежедневно проверять биллинги сама по себе правильная: чем быстрее замечаешь аномалию, тем дешевле ее исправить. Но на практике это быстро превращается в рутину, которая отнимает время и внимание сотрудника. Поэтому мы настроили систему ежедневного алертинга прямо внутри корпоративного мессенджера. Теперь оповещения о затратах на облака приходят каждое утро в чат, и их видит не только FinOps-специалист, но и команда — они сразу реагируют на изменения.
Все сообщения организованы в формате светофора. Таким образом, даже не вникая в цифры, сотрудники видят, на что требуется обратить внимание в данный момент.
Важно: расходы становятся управляемыми только тогда, когда у каждого сервиса или каталога появляется понятный владелец, то есть проведена аллокация трат. Если это произошло, сотрудники понимают, что сигнал относится именно к ним и нужно действовать. Если нет — воспринимают сообщения как фоновый шум.
Все данные бот присылает за вчерашний день: 20 марта мы видим то, что происходило 19 числа. С помощью ботов можно настроить и почасовой алертинг, и за выбранный период (например, скользящее среднее за 3 часа). Мы поняли, что нам хватает ежедневного алертинга для поиска аномалий (пока что).
С чем работали:
Low-code-платформа для создания программ и автоматизаций.
Таблицы в облачном сервисе для сравнения значений с базовой линией и хранения исторических данных.
API облаков.
API корпоративного мессенджера.
Сами оповещения делим на ежедневные и ситуационные. Ежедневные уведомления присылают общие расходы по облаку и расходы по группам за предыдущий день. Алгоритм их работы:
Каждое утро бот:
запрашивает данные о затратах;
сравнивает их с ожидаемыми значениями;
отправляет сообщение со светофорным статусом.
Сначала бот собирает полную стоимость облака — это первая ветка сценария. Дальше агрегирует данные по группам (командам), сравнивает с ожидаемыми значениями, формирует и отправляет сообщение — это вторая ветка.
Этот бот подключен как в канале #finops для мониторинга общей ситуации, так и в каналах конкретных команд (они получают информацию только о своих расходах).
Ситуационный формат — это алерты, которые приходят только в случае заметного превышения затрат. Здесь срез уже глубже: мы видим траты по отдельным ресурсам в облаке.
Мы используем более 80 сервисов, поэтому вместо сравнения с базой оцениваем фактическую разницу между днями.
Бот работает так: каждое утро запрашивает данные от облака по ресурсам. Значения записываются в таблицу с отметкой даты. Для будней и выходных используется разная логика из-за автоскейлинга, так как мы не хотим получать ложные срабатывания по понедельникам. На следующем этапе бот сравнивает вчерашний день с позавчерашним. После сработки настроено удаление — в таблице хранятся данные только за одну неделю использования.
Мы получаем алерты на те превышения, которые составляют 30% от стоимости сервиса, но не менее Х рублей или более Х рублей при любом проценте (планки установлены FinOps-командой). Если превышения нет, сообщение также приходит, но в таком случае просто подсвечивает, что проверка прошла успешно без выявленных отклонений. Это позволяет отличить отсутствие аномалий от ошибки работы бота.
Сложности, с которыми столкнулись при настойке:
Нехватка стандартных библиотек на low-code-платформе. Ключ доступа в API биллинга должен обновляться каждые 12 часов, и эту защиту не удавалось обойти без установки новых библиотек. Установка новых библиотек = перезапуск всего прода платформы, что не очень удобно при наличии критичных автоматизаций для работы бизнеса.
Формат вывода данных, который чувствителен к изменениям. При запуске нового сервиса логика выдачи данных поменялась, что обвалило привязки «строка/стоимость», которые были настроены изначально. Пришлось создавать словарь с ID и названием для каждой группы.
Боты алеритинга по тратам — это только часть экосистемы FinOps-ботов. Есть и другие, в том числе подсвечивающие неиспользуемые ресурсы и недозагруженные виртуальные машины.
Наши рекомендации тем, кто начинает этот путь:
Убедитесь, что для каждого пункта светофора есть ответственный и понимание того, что делать, если светофор красный.
Используйте только те уровни детализации затрат, которые реально применяются в работе. Мы выбрали только 3 из 8 возможных срезов.
Используйте автоматический алертинг, но не забывайте о ручной проверке сервисов, где это необходимо. Мы оставили по четвергам ритуал проверки аномалий трат человеком в дополнение к автоматическому ежедневному алертингу.
Расширяйте используемый арсенал FinOps-практик, который намного шире алертинга и включают в себя резервирование ресурсов, райтсайзинг, формирование культуры ответственности за затраты внутри команды и многое другое.
Подключайтесь к профессиональному сообществу «Практики FinOps» для поиска идей и обмена опытом с коллегами.
Самое интересное: стоит ли овчинка выделки?
Важно понимать: FinOps в целом не про сокращение расходов любой ценой, а про грамотное и осознанное использование технологических ресурсов. Алертинг — лишь один из инструментов, который помогает быстрее замечать отклонения и вовремя на них реагировать.
Реальный эффект появляется тогда, когда алертинг становится частью более широкой системы: есть прозрачность затрат, понятны владельцы сервисов, команды регулярно анализируют причины роста расходов и принимают решения на основе этих данных. В таких условиях совокупный результат от внедрения FinOps-подхода может достигать 20–30% бюджета на облачную инфраструктуру за счет устранения избыточных ресурсов, оптимизации конфигураций и более осознанного использования сервисов. Так, например, общий объем сэкономленных средств благодаря FinOps-подходу во Flowwow в 2025 году составил более 20 млн рублей.
Подведем итоги:
FinOps начинается не с инструментов, а с прозрачности расходов, а автоматизация помогает эту прозрачность масштабировать.
Экономия от внедрения FinOps-практик может составлять 20–30% бюджета.
Алертинг без культуры оптимизации расходов, аллокации затрат и ответственных — белый шум. Они обязательно должны идти в связке.
А вы уже внедряете FinOps-практики в своих компаниях? Поделитесь своим опытом и результатами в комментариях.