Что будет с бюджетом на инфраструктуру, когда команда вырастет вчетверо

MAATRIX

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

Два способа считать инфраструктуру: за место и за мощность

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

Оплата за место (per-seat). Это модель большинства SaaS-продуктов: таск-трекер, CRM, корпоративный мессенджер, дизайн-инструмент, почта, VPN для команды. Цена почти всегда привязана к количеству учётных записей — платите за пользователя в месяц или в год, вне зависимости от того, сколько человек реально открывает продукт каждый день.

Оплата за мощность (per-capacity). Это модель собственной инфраструктуры — арендованного или купленного сервера, кластера баз данных, файлового хранилища. Здесь вы платите не за количество людей, а за CPU, память, диск, полосу пропускания. Один и тот же сервер может обслуживать и десять, и пятьдесят внутренних пользователей — до тех пор, пока не упрётесь в реальный потолок нагрузки.

Проблема в том, что на старте, пока команда маленькая, обе модели дают похожие числа, и разница в математике не заметна. Она проявляется именно на масштабе — когда команда действительно вырастает в несколько раз, а не на 10–15%.

Почему SaaS-подписка растёт строго линейно

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

Формально это выглядит так: если у вас 10 человек и подписка на мессенджер стоит X в месяц за место, то итог — 10X. Когда команда вырастает до 40 человек, итог механически становится 40X. Рост в четыре раза по головам почти всегда даёт рост в четыре раза по счёту — с той лишь оговоркой, что у части сервисов есть тарифные пороги (например, «до 50 мест» и «до 100 мест» по разной цене за место), которые могут слегка сгладить или, наоборот, обострить картину в моменте перехода через границу тарифа.

Из этой линейности вытекают два практических следствия, которые стоит держать в голове при планировании роста:

• Стоимость роста предсказуема, но неумолима. Финансовому директору легко спрогнозировать SaaS-бюджет на следующий год — достаточно знать штатное расписание. Но именно из-за этой предсказуемости в ней нет места приятным сюрпризам: подписки не «дешевеют на объёме» для конечного покупателя почти никогда, разве что вы отдельно выторговываете корпоративную скидку у поставщика при переходе на энтерпрайз-тариф.
• Стек подписок умножается сам на себя. Команда не растёт в одном инструменте — она обрастает новыми ролями (аналитик, QA, саппорт), а у каждой роли свой набор SaaS. Итоговый рост бюджета на подписки при росте команды в четыре раза часто оказывается даже больше, чем ровно в четыре раза, просто потому что количество используемых сервисов на человека тоже растёт.

Если хотите отдельно прикинуть, во что превращается набор подписок уже на команде в десяток человек, до масштабирования есть смысл посмотреть на то, как формируется бюджет на инфраструктуру стартапа на старте — там же видно, какая доля в нём приходится именно на подписки «за место», а какая — на серверную часть.

Почему собственная инфраструктура растёт медленнее

Себестоимость сервера устроена иначе — здесь есть настоящий эффект масштаба, и он работает в пользу покупателя, а не только продавца.

Есть несколько причин, почему увеличение мощности сервера в четыре раза почти никогда не стоит ровно в четыре раза дороже:

• Фиксированные компоненты не масштабируются линейно. У любого сервера есть часть стоимости, которая почти не зависит от его мощности: базовая стоимость шасси, сетевого порта, IP-адреса, лицензии на панель управления, стоимость администрирования на уровне «сервер как единица», а не «сервер как сумма ядер». Когда вы переходите с одного сервера на более мощный (или добавляете второй вместо четырёх), эта фиксированная часть не умножается на четыре — она просто переносится на больший объём ресурсов.
• Более мощная конфигурация часто дешевле в пересчёте на единицу ресурса. Ценообразование у большинства провайдеров устроено ступенчато: у старших тарифных планов цена за ядро, за гигабайт памяти или за терабайт диска обычно ниже, чем у младших. Это не гарантированное правило для каждого прайс-листа, но устойчивая тенденция на рынке аренды серверов — крупная конфигурация даёт больше ресурса на вложенный рубль или доллар, чем сумма нескольких маленьких.
• Одна мощная машина эффективнее нескольких маленьких по накладным расходам. Обслуживание одного сервера с учётверённым объёмом ресурсов почти всегда требует меньше человеко-часов, чем обслуживание четырёх отдельных серверов: меньше точек мониторинга, меньше отдельных циклов обновлений, меньше сетевой обвязки между узлами. Административная нагрузка растёт медленнее, чем количество единиц железа.
• Не вся нагрузка команды растёт линейно самому размеру команды. Часть инфраструктурной нагрузки — это фиксированные сервисы (внутренний портал, система сборки, почта, VPN-шлюз), которые при росте штата от 10 до 40 человек нагружаются заметно, но не обязательно ровно вчетверо: у многих внутренних систем нагрузка растёт скорее с количеством одновременных сессий и пиковой активности, чем строго пропорционально штату.

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

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

Сравнение двух кривых роста

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

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

Что конкретно проверить при планировании роста в 4 раза

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

1. Разметьте текущий стек на per-seat и per-capacity. Возьмите список всех используемых сервисов и серверов и для каждого честно отметьте, растёт ли его цена вместе с числом людей (тогда закладывайте линейный рост) или вместе с нагрузкой (тогда закладывайте более пологий рост с проверкой реального потолка мощности).
2. Проверьте тарифные пороги SaaS-сервисов заранее. У многих подписок цена за место меняется по мере пересечения границ (например, «до 50 пользователей» и «свыше 50»). Узнайте эти пороги заранее у поставщика, а не в момент, когда команда их уже перешагнула — так проще спланировать бюджет и, возможно, договориться о переходе на другой тариф до, а не после роста.
3. Оцените реальный запас мощности текущего сервера. Если сегодня инфраструктура утилизирована на 20–30%, рост команды в четыре раза не обязательно означает необходимость в четырёх новых серверах — возможно, хватит апгрейда текущей конфигурации, особенно если узкое место не в CPU, а, например, в дисковых операциях или в пропускной способности сети.
4. Заложите отдельно рост административной нагрузки. Даже при пологой кривой расходов на железо, растущей команде обычно требуется больше времени на резервное копирование, мониторинг, обновления и разграничение доступа. Это тоже статья бюджета, просто она обычно растёт медленнее, чем количество серверов, если инфраструктура спроектирована с самого начала как единая масштабируемая система, а не как россыпь разрозненных машин.
5. Пересчитайте сценарий "аренда против покупки" под новый масштаб. То, что было выгодно арендовать при команде в 10 человек, при команде в 40 человек может иметь другую точку окупаемости — стоит заново свериться с логикой из материала когда дешевле купить железо, а когда арендовать, потому что порог часто сдвигается вместе с ростом предсказуемости нагрузки.

Где решение приходится принимать раньше, чем кажется

Самая частая ошибка растущих команд — откладывать этот расчёт до момента, когда рост уже случился, и бюджет просто «оказался» вдвое или вчетверо больше, чем планировали. К тому моменту решение по факту уже принято — потому что миграция с одного набора SaaS-инструментов на собственную инфраструктуру (или наоборот) на живой команде из 40 человек намного дороже и болезненнее, чем то же решение, принятое заранее на команде из 10.

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

Отдельно стоит свериться с тем, где именно в текущем стеке компания платит за подписку по модели «за место», хотя могла бы получить более пологую кривую расходов на собственном сервере — разбор такой развилки на конкретном инструменте есть в материале своя Jira или облачная подписка: где ломается экономика, и логика оттуда переносится на большинство внутренних SaaS-инструментов растущей команды.

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