Разбор бюджета инфраструктуры с реальным контекстом продукта

Почему строки расходов дают ложную картину

Облачный счет показывает, за что вы заплатили. Но почти никогда не показывает, почему.

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

Именно поэтому строки расходов сами по себе подталкивают команды к неверным решениям. Одни и те же лишние $8,000 могут означать три совершенно разные вещи: больше активных пользователей, которые пользуются нужной функцией; разовые запросы клиента, которые не должны определять ядро продукта; или рабочие привычки команды, которые добавляют стоимость, но не помогают клиентам.

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

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

Простой пример это хорошо показывает. Если расходы на базу данных выросли после запуска audit logs для крупных клиентов, это может быть честной платой за нужную ценность. Если тот же рост вызван заброшенными preview-средами и дублирующими бэкапами, это нужно быстро убрать. Статья расходов выглядит одинаково. Бизнес-смысл — нет.

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

Как выглядит контекст продукта

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

Две команды могут тратить одинаковую сумму по совершенно разным причинам. Одна платит за реплики базы данных, потому что клиентам нужна стабильная скорость отклика в течение всего дня. Другая платит за них, потому что никто не убрал старую схему. Статья расходов одна и та же. Причина — нет.

Когда вы добавляете контекст продукта, расходы становится проще объяснить. Смотрите на четыре области: функции, которые создают реальный трафик или выполняют тяжелые задачи; решения по надежности, такие как бэкапы и failover; клиентские запросы, которые добавляют хранилище или вычисления; и рабочие привычки команды, такие как preview-среды и долго живущие тестовые системы.

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

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

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

Сопоставляйте расходы с работой, которую видит клиент

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

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

Не обязательно иметь идеальные цифры с первого дня. Грубые категории часто лучше, чем фальшивая точность. Разделите расходы на три группы: общие затраты платформы, например основная база данных и мониторинг; расходы на функции, например индексацию поиска или генерацию отчетов; и кастомную работу под клиента, например приватную интеграцию или выделенную среду.

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

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

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

Отделяйте разовую работу для клиентов от ядра продукта

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

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

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

Задайте несколько прямых вопросов. Что именно попросил клиент? Сколько это стоит каждый месяц? Как часто он этим пользуется? Сколько времени поддержки это создает? Окупается ли это выручкой?

Сравнение часто оказывается неудобным. Один enterprise-клиент может попросить отдельную среду, которая стоит $1,200 в месяц облачных расходов и еще 6–8 часов инженерного времени. Если этот аккаунт добавляет лишь небольшую прибавку к контракту, математика быстро перестает сходиться.

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

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

Проверьте привычки доставки, прежде чем резать расходы

Разбор бюджета инфраструктуры становится точнее, когда вы смотрите на то, как команда выпускает работу. Две команды могут тратить одинаково и получать совсем разный результат. Одна часто выкатывает маленькие изменения и убирает лишнее после каждого релиза. Другая релизится реже, перезапускает сборки весь день и держит лишние среды онлайн неделями.

Частота релизов тихо влияет на стоимость. Каждый релиз может запускать build runners, хранение артефактов, тестовые базы, прогрев кэша и дополнительный объем логов. Если разработчикам нужно три-четыре попытки, чтобы провести одно небольшое изменение через CI, счет растет даже тогда, когда клиенты ничего не замечают.

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

То же самое происходит в build-пайплайнах. Команды часто оставляют старые задания, потому что так спокойнее, а не потому, что они помогают. Медленный pipeline, который запускает все тесты на каждый commit, может каждый день сжигать часы вычислений. Во многих продуктах меньший набор проверок находит большую часть проблем быстрее и дешевле.

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

Чаще всего лишние расходы создают несколько типичных паттернов: preview-приложения остаются включенными после закрытия pull request, тестовые среды работают по ночам и в выходные, pipeline снова и снова пересобирает одни и те же образы, логи хранят слишком много деталей слишком долго, а мониторинг собирает данные, которые никто не проверяет.

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

Проведите разбор в пять шагов

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

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

1. Выберите два месяца по понятной причине. Один должен отражать спокойную обычную работу. Второй должен показывать всплеск, спад или необычную картину, которую команда может объяснить.
2. Положите рядом три источника: биллинг, использование продукта и заметки о релизах. Когда вы видите расходы на вычисления рядом с активностью пользователей и историей релизов, разговор становится заметно яснее.
3. Помечайте самые крупные расходы по причине, а не по названию сервиса. Счет за базу данных сам по себе ничего не объясняет. Привяжите каждую крупную статью к функции, запросу клиента или привычке команды, например частым пересборкам, слишком большим preview-средам или долгому хранению логов.
4. Спросите, что изменилось, и продолжайте спрашивать, пока не получите простой ответ. Новая функция увеличила фоновые задачи? Одному клиенту каждую ночь нужен кастомный процессинг? Команда выпустила пять релизов за неделю и создала дополнительный расход на сборки и тесты?
5. Закончите коротким списком действий на следующий разбор. Выберите два-три шага, которые можно проверить в следующем месяце: ограничить срок хранения логов, убрать один клиентский workflow с горячего пути или изменить время жизни preview-сред.

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

Простой пример SaaS

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

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

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

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

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

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

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

Ошибки, которые тратят время и деньги

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

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

Команды также режут бэкапы, мониторинг, failover или отслеживание ошибок, не проверив, во сколько обойдется инцидент: возвраты денег, потеря доверия или задержки релизов. Часто это самый дорогой способ сэкономить.

Еще одна проблема — смешивать тестовые стенды, demo-системы, test-среды и короткие эксперименты с production-итогами. Тогда ядро продукта выглядит дороже, чем есть на самом деле. То же касается времени сотрудников. Компания может одновременно поддерживать Docker Compose и Kubernetes для работы, которой не нужны оба инструмента. Облачный счет — это только часть истории. Команда еще платит временем на настройку, разбор проблем и трения в релизах.

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

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

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

Что делать после разбора

Разбор бюджета инфраструктуры важен только тогда, когда он меняет то, как вы ведете продукт. Результаты должны сразу попасть в три места: ценообразование, roadmap и архитектуру.

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

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

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

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

Хорошо работает простой месячный ритм. Смотрите самые большие изменения в расходах, сопоставляйте их с продуктовыми или delivery-решениями, проверяйте, сработали ли прошлые изменения, и решайте, что тестировать дальше.

Некоторым командам нужен нейтральный человек, который проведет такой процесс правильно, особенно когда продукт, инженерия и финансы читают одни и те же расходы по-разному. Именно такую работу Oleg Sotnikov делает через oleg.is как Fractional CTO и startup advisor: он связывает расходы на инфраструктуру с архитектурой продукта, системами доставки и реальными компромиссами, которые стоят за счетом.

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