VPS для первого платного SaaS: какие расходы появятся кроме аренды сервера

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

Разница принципиальная. Эксперимент можно остановить, если стало дорого или скучно. Обязательство перед платящим человеком останавливать неудобно: придётся объясняться, возвращать деньги, терять репутацию. Поэтому вопрос «сколько стоит VPS» быстро уступает вопросу «сколько стоит выполнить одну оплаченную операцию и удержать её в рабочем состоянии весь месяц». Ответ на второй вопрос почти всегда больше строки в счёте за аренду сервера, и в этой статье мы разложим его по частям.

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

Одна кнопка и пять счетов

Клиент нажимает «Сформировать отчёт». Что происходит дальше, если смотреть глазами бухгалтера, а не разработчика?

1. Запрос приходит на ваш VPS. Здесь работают процессор, память, диск и сетевой канал. Это единственная часть цепочки, которая выглядит как постоянная аренда.
2. Приложение обращается к внешнему API за данными для обогащения. Провайдер, скорее всего, считает вызовы, объём или тарифный пакет. Этот счёт растёт вместе с числом операций и вам неподконтролен.
3. Готовый отчёт сохраняется. Если файлы лежат на диске VPS, они занимают место, которое вы уже купили. Если вынесены в объектное хранилище, появляется отдельный счёт.
4. Клиенту уходит письмо. Письмо отправляет не ваш процесс сам по себе, а почтовая инфраструктура, и она тоже где-то учитывается.
5. Через платёжный сервис вы получили деньги за подписку, и у него своя комиссия.

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

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

Методология оптимизации затрат AWS (Cost Optimization Pillar) связывает стоимость с функциональными требованиями, использованием ресурсов и согласованием спроса с мощностью. Это написано про облачные архитектуры, но мысль годится и для небольшого проекта на VPS: сначала решаем, что именно сервис обязан выполнять, затем смотрим, какая мощность под это нужна и насколько она загружена. Не наоборот. Цифры в такой методологии не ваши, и страница не определяет цены ни одного хостинга, включая MAATRIX; от неё берём порядок рассуждения.

Внешний API: расход, который не вы выбираете

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

Отсюда несколько практических вопросов, которые стоит задать до запуска, а не после первого счёта:

• Как считается вызов? За запрос, за строку данных, за объём, за пакет в месяц? От этого зависит, как модель поведёт себя, если клиент загрузит не сто строк, а сто тысяч.
• Что происходит при повторе? Если запрос завис и приложение повторило его, провайдер может посчитать оба. Сама по себе новая попытка не гарантирует, что вторая оплата не возникнет: это зависит от того, умеет ли конкретный сервис распознавать повторы. Прочитайте его документацию и заложите в смету долю неудачных попыток как переменную.
• Какие лимиты скорости и объёма? Когда лимит достигнут, операция либо ждёт, либо падает. И то и другое влияет на то, что вы обещаете клиенту.
• Может ли провайдер изменить условия? Тариф стороннего сервиса не контролируется вами, а значит, цена вашей услуги должна иметь запас или механизм пересмотра.

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

Письмо тоже стоит денег, хотя копейки

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

Страница цен Amazon SES показывает такую структуру: отдельно учитываются отправленные сообщения и объём исходящих данных, а дополнительные функции могут оплачиваться отдельно. Это пример состава счёта, а не тариф MAATRIX и не правило для всех почтовых провайдеров. Но урок полезен: даже у простой отправки два измерения. Короткое письмо со ссылкой и письмо с вложенным отчётом на несколько мегабайт стоят неодинаково, потому что во втором растёт объём данных.

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

Есть и скрытая часть: репутация отправителя. Письма, которые попадают в спам, означают, что клиент не получил ссылку и написал в поддержку. Стоимость одного такого случая — время человека, а оно дороже письма. К этому вернёмся в разделе о труде.

Копии: цена хранения и цена проверки

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

Важно не предполагать, что копии уже есть. В публичных фактах о VPS MAATRIX подтверждены NVMe-диски, процессоры AMD EPYC и root-доступ; автоматические резервные копии во всех тарифах среди подтверждённого не значатся. Поэтому в смете копии нужно заложить отдельной строкой и проверить в форме заказа, что именно входит в выбранную конфигурацию.

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

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

У инструмента restic в документации по восстановлению есть полезная для такой проверки возможность: restore извлекает выбранный снимок в отдельный каталог назначения. Фильтр --path отбирает снимок, а --include и --exclude ограничивают извлекаемые файлы; это разные действия, и путать их не стоит. Есть и фильтры для выбора последнего снимка конкретного хоста и пути. Для нашего разговора важно следствие: можно восстановить данные в отдельную директорию и сначала посмотреть результат, не трогая рабочую систему. Значит, учебная проверка может выглядеть как восстановление одного клиентского отчёта в пустой каталог и сравнение с ожидаемым содержимым. Выборочное извлечение ещё и снижает объём переданных данных, а значит, в моделях с платным извлечением дешевле.

Домен и наблюдение: мелкие платежи, большой смысл

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

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

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

Запуск и ежемесячные платежи — два разных кошелька

Одна из частых ошибок сметы — сложить всё в одну колонку «расходы». Затраты на запуск и регулярные платежи ведут себя по-разному и закрываются из разных источников.

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

Если вы работаете как индивидуальный предприниматель и вам важно, как отнести расходы на сервер в учёте, смотрите отдельный материал: как ИП принять расходы на сервер к учёту. Здесь мы говорим про экономику услуги, а не про налоговый порядок.

Человеческое время: самая дорогая и самая невидимая строка

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

У обслуживания первого SaaS есть постоянная часть и часть, растущая с числом клиентов. Постоянная часть — это то, что нужно делать, даже если клиент один: обновлять систему, проверять копии, смотреть логи, реагировать на оповещения, отвечать на вопросы по оплате. Растущая часть — письма в поддержку, разбор нестандартных данных, помощь с настройкой. У первых клиентов она особенно велика: они находят то, что вы не предусмотрели, и каждая такая находка стоит нескольких часов.

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

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

Внешние лимиты и что они делают с обещанием

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

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

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

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

Что даёт VPS и почему его ресурсы не равны ёмкости

Теперь вернёмся к серверу. В публичном предложении MAATRIX перечислены конфигурации: Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Указаны локации UK, US, RU и FR, оплата картой РФ и СБП, автоматическое создание VPS в течение пары минут после оплаты, а также root-доступ. Подробности и текущее наличие смотрите на странице аренды VPS MAATRIX. Цены здесь не названы намеренно, а наличие конкретных образов и операционных систем проверяется в форме заказа.

Эти цифры — описание ресурсов, а не обещание, сколько клиентов выдержит сервер. Сколько отчётов в минуту обработает 2 vCPU и 4 ГБ, зависит от вашего кода, объёма данных и поведения клиентов, и узнать это можно только замером на ваших данных. Конфигурацию из списка стоит считать отправной точкой для теста, а не итогом расчёта.

Как связать ресурсы с расходами? Через простой вопрос: что в вашей операции упирается в сервер? Если обработка данных тяжёлая и идёт в самом приложении, ограничением станут процессор и память. Если вы храните много клиентских файлов на самом диске, потолок задаст размер NVMe, и тогда вопрос выбора между диском и внешним хранилищем становится вопросом денег. Если основное время тратится на ожидание ответов внешнего API, сервер будет простаивать, а узким местом станет не мощность, а лимит провайдера. В этом смысле принцип согласования спроса с мощностью из методологии AWS выглядит очень приземлённо: не покупайте запас, который нечем загрузить, и не экономьте на том, что реально ограничивает операцию.

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

Учебная модель: один, три, десять, двадцать клиентов

Теперь соберём всё в цифры. Все числа ниже условные, в условных единицах (у.е.): они нужны, чтобы показать форму расчёта, а не чтобы сообщить цену какого-либо сервиса, курс или ставку. Подставьте свои значения.

Допущения модели. Подписка: 30 у.е. в месяц с клиента. Каждый клиент в среднем делает 40 отчётов. Вызов внешнего API на отчёт: 0,05 у.е. Письмо на отчёт: 0,001 у.е. Хранение файлов клиента: 0,10 у.е. в месяц. Комиссия платёжного сервиса: 3% подписки. Постоянные платежи инфраструктуры: VPS 10, домен в месячной доле 1, наблюдение 5, хранилище копий 3, почтовая база 1, всего 20 у.е. в месяц. Труд: 8 часов в месяц постоянной части и 0,5 часа на клиента, час оценён в 5 у.е.

Переменные расходы на одного клиента: 2,00 на API, 0,04 на письма, 0,10 на хранение и 0,90 комиссии, итого 3,04 у.е. Вклад одного клиента после переменных расходов: 26,96 у.е.

Что здесь видно. Если учитывать только инфраструктуру, то есть сервер и сопутствующие платежи, достаточно одного клиента: его вклад в 26,96 перекрывает постоянные 20. Именно поэтому создаётся иллюзия, что дешёвый сервер делает проект прибыльным. Но стоит добавить время человека, и картина меняется: одного клиента мало, при двух остаток всё ещё отрицательный, а в точку безубыточности модель выходит на третьем клиенте. Тот же итог получается формулой: постоянные 20 плюс труд 40 дают 60, а вклад клиента за вычетом его доли труда равен 26,96 − 2,5 = 24,46, значит, нужно примерно 2,45 клиента, то есть три.

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

Ещё одна оговорка про строку «остаток после всех строк». Здесь нет налогов, потому что их ставка зависит от вашего статуса и режима, и нет окупаемости запуска. Пусть запуск стоил 40 часов по 5 у.е., то есть 200 у.е., плюс 15 разовых платежей: итого 215. При десяти клиентах остаток 184,60 в месяц вернёт запуск чуть больше чем за месяц, но при трёх клиентах и остатке 13,38 тот же возврат растянется больше чем на шестнадцать месяцев. Это тоже часть экономики: цена подписки, число клиентов и срок окупаемости связаны между собой.

Чувствительность к внешней цене

Посмотрим, как модель реагирует на изменение самой уязвимой переменной. Если провайдер API поднимет цену вызова с 0,05 до 0,10, расход на клиента вырастет на 2 у.е., а вклад упадёт с 26,96 до 24,96. Для десяти клиентов остаток снизится на 20 и составит 164,60. Это терпимо. Но если клиенты делают не 40 отчётов, а 400, а подписка остаётся прежней, расход на API станет 20 у.е. на клиента при старой цене и 40 при новой, и вклад клиента съедается почти полностью. Поэтому тарифу нужен предел отчётов: он превращает неограниченный риск в ограниченный.

Какую цену услуги команда в состоянии выдержать

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

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

На практике удобно держать в голове короткий порядок проверки. Какая операция оплачена и сколько она стоит вам в переменных расходах. Что случится с ценой, если провайдер API изменит тариф или клиент превысит ожидаемый объём. Проверяли ли вы восстановление данных хотя бы раз, а не только настроили копии. Сколько часов в месяц вы реально тратите и чьи это часы. Сколько клиентов нужно до безубыточности с учётом труда, а не только сервера. И последнее: на каждое из этих чисел у вас есть замер или хотя бы явная гипотеза, помеченная как гипотеза.

Тогда выбор VPS становится одним из решений в цепочке, а не её началом. Конфигурация из списка, например Ba или Uab, подбирается после замера нагрузки, и её стоимость входит в смету как одна из строк рядом с почтой, копиями, внешним API и временем. Сервер, на котором работает ваша услуга, должен быть таким, чтобы вы могли выполнить обещание клиенту, а цена этой услуги — такой, чтобы вы могли выполнять его и в следующем месяце.