Инфраструктура как процент от выручки: какие ориентиры считать нормой

MAATRIX

Рано или поздно в разговоре с инвестором, партнёром или самим собой всплывает вопрос: а сколько мы вообще должны тратить на серверы, трафик и хостинг по отношению к тому, что зарабатываем? Кто-то ищет магическую цифру — 5%, 10%, 15% выручки — чтобы приложить её к своим счетам и понять, всё ли в порядке. Проблема в том, что такой универсальной цифры не существует, и попытка её найти уводит от вопроса, который реально имеет значение.

Зачем вообще считать эту метрику

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

Считается метрика просто: берёте все расходы, прямо связанные с инфраструктурой (серверы, трафик, CDN, бэкапы, мониторинг, лицензии на системное ПО, оплату дежурных инженеров, если хотите включить и операционную часть) за период, делите на выручку за тот же период и умножаете на 100. Проблема начинается не на этапе расчёта, а на этапе интерпретации результата.

Доля инфраструктуры (%) = (Инфраструктурные расходы за период / Выручка за период) × 100

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

Почему единого ориентира не существует

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

Продукт, который гоняет терабайты видео или больших файлов на пользователя, структурно обречён тратить на инфраструктуру заметно больше, чем текстовый SaaS с редкими API-запросами и лёгкой базой данных. Это не значит, что видеосервис управляется хуже — у него просто другая физика затрат. Точно так же маркетплейс с миллионами товарных карточек, индексацией, поиском и рекомендательной системой будет закономерно тяжелее по инфраструктуре, чем B2B-инструмент с несколькими сотнями активных пользователей в день, даже если оба зарабатывают сопоставимую выручку.

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

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

Что действительно стоит отслеживать: динамику, а не уровень

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

Три возможных сценария:

• Процент стабилен (колеблется в узком коридоре без выраженного тренда) — это признак того, что инфраструктура масштабируется вместе с бизнесом. Рост выручки тянет за собой пропорциональный рост расходов, и это нормально: больше пользователей — больше запросов — больше серверов.
• Процент снижается — обычно хороший знак: либо сработал эффект масштаба (фиксированные расходы размазываются на растущую базу), либо инженерная команда провела оптимизацию, которая опередила рост нагрузки. Стоит разобраться, за счёт чего именно это произошло, чтобы не потерять эффект случайно.
• Процент растёт от периода к периоду — вот это сигнал, требующий внимания. Он означает, что для каждого следующего рубля выручки вы платите инфраструктуре больше, чем платили для предыдущего. Если тенденция продолжится, в какой-то момент инфраструктурные расходы начнут съедать маржу быстрее, чем растут продажи.

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

Откуда берётся растущий процент: типичные причины

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

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

Расползание тарифов на управляемые сервисы. Облачные базы данных, очереди, поисковые движки в managed-варианте часто выставляют счёт нелинейно относительно объёма данных или запросов. Пока данных мало — это незаметно. Когда объём переваливает за определённый порог, тарифная сетка начинает расти быстрее, чем растёт бизнес-метрика, которая эти данные генерирует.

Скрытая стоимость исходящего трафика (egress). Особенно заметно у бизнесов с большим объёмом данных, отдаваемых пользователю: видео, изображения, файлы, API-ответы с большими payload. Плата за исходящий трафик у облачных провайдеров часто растёт линейно с объёмом, а выручка с каждого дополнительного пользователя может расти медленнее — например, из-за скидок за объём или демпинга у конкурентов.

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

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

Как разложить метрику на составляющие, чтобы найти причину

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

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

Часто оказывается, что общий процент растёт не равномерно по всем статьям, а тянется одной-двумя категориями — например, стоимостью хранения логов, которые никто не чистит, или трафиком CDN, который можно частично заменить кешированием на своей стороне (сравнение экономики разобрано в статье про свой кеширующий узел вместо коммерческого CDN). Разложение по категориям превращает абстрактный "процент вырос" в конкретную задачу для инженерной команды.

Как считать инфраструктурные расходы, чтобы цифры не врали

Прежде чем строить график динамики, стоит навести порядок в самом подсчёте — иначе тренд может оказаться артефактом методологии, а не реальности.

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

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

Третье: если выручка сама по себе волатильна (сезонность, крупные разовые контракты), точечные месячные значения процента будут скакать независимо от инфраструктуры. В этом случае разумнее смотреть на скользящее среднее за 3 или 6 месяцев — так тренд читается яснее, чем по сырым помесячным точкам.

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

Что делать, когда тренд подтвердился

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

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

Дальше выбор обычно между несколькими путями: оптимизировать код и архитектуру (убрать N+1, добавить кеш, сжать данные), пересмотреть инфраструктурные решения (перейти с почасовой аренды на постоянные мощности при устойчивой нагрузке — тема разобрана в статье про то, когда докупить ресурсов дешевле, чем переписывать код), или пересмотреть саму бизнес-модель ценообразования, если инфраструктурная нагрузка на клиента объективно выросла и это нужно закладывать в тариф.

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

Частые вопросы