Тупик: цена подписки, делённая на цену сервера
Расчёт почти всегда начинается одинаково: цену подписки делят на цену виртуалки и получают впечатляющую кратность. Дальше обычно следует вывод про переплату и «очевидную выгоду». Арифметика безупречна — и в этом беда: она создаёт ощущение законченного расчёта, хотя сравнили два числа из разных бюджетов.
Цена подписки — это почти вся стоимость SaaS-стороны. Вендор уже упаковал в неё обновления, безопасность, дежурство и восстановление после сбоев. Цена сервера — одна строка из многих на стороне self-hosted: только инфраструктура, без труда, без рисков, без будущих миграций. Сравнили целую цену с первым взносом.
Тупик держится не на ошибке в вычислениях, а на том, какие цифры легко достать. Цена подписки опубликована на сайте вендора, цена виртуалки — на сайте хостера. Труд инженера нигде не опубликован, поэтому из расчёта выпадает именно та строка, которая всё решает. Лёгкие цифры вытесняют трудные: чем проще цифру найти, тем больше она весит в решении — независимо от того, какую часть реальности она описывает.
И второй дефект того же хода: сравниваются два снимка, а сравнивать нужно два потока. Обе цены — по сути подписки, просто одна оплачивается картой, а вторая вниманием инженеров, регулярно и без права отмены. Честная модель — две суммы по общему горизонту и с общим периметром. Разберём, как их собрать.
Что на самом деле стоит подписка
Строка первая — сам платёж. Ловушка здесь в том, по чему индексируется тариф: одни растут вместе с числом рабочих мест, другие — с потреблением. Посмотрите, к чему привязана ваша цена, и считайте её на горизонте, а не на сегодня.
Дальше — администрирование. SaaS не отменяет эту работу: заводить и убирать людей, раздавать права, а ещё чинить интеграции, когда вендор меняет API. Работы меньше, чем при self-hosted, но она не нулевая, и кто-то её делает.
Третья строка — вход и выход. Вход — это перенос данных, обучение команды, интеграция с тем, что уже стоит. Выход — то же самое в обратную сторону, только дороже: данные накопились, привычки сложились. Это и есть lock-in — дешёвый вход, за который платят на выходе. Честный способ учесть его заранее: оценить стоимость ухода (экспорт, параллельная работа двух систем, переобучение) и размазать по ожидаемому сроку жизни решения. Получится скрытая надбавка к цене подписки.
И четвёртая строка — риск цены. Вендор может изменить тариф, и чем дольше вы внутри, тем дороже выйти. Платить за это заранее не нужно, но свой потолок знать стоит: подписка ограничивает худший сценарий деньгами. Это её главное преимущество, и его надо увидеть в цифрах, а не только почувствовать.
Календарь вместо процента инженера
Теперь сторона self-hosted. Инфраструктура — сервер или виртуалка, место под бэкапы, мониторинг — это строка, которую считают все, поэтому оставим её напоследок: она почти никогда не бывает решающей.
Решающая строка — труд. На глаз его оценивать нельзя. Популярный ход «это займёт часть времени одного инженера» не выдерживает встречи с инцидентами: проценты не делятся на ночные сбои. Когда система падает, дежурит не часть человека.
Честный способ — календарь. Выпишите всё, что придётся делать регулярно:
- обновления — не только мажорные: заплатки под уязвимости приходят без расписания;
- продление сертификатов;
- проверка бэкапов — не наличие файлов, а восстановление из них;
- разбор срабатываний мониторинга;
- чистка места и пересмотр лимитов.
Плюс редкие, но обязательные события: восстановление после сбоя, миграция на следующую мажорную версию, реакция на внезапно нашедшуюся уязвимость.
Для каждого действия оцените, как часто оно случается и сколько времени занимает. Если не знаете — спросите у того, кто делал похожее в последний раз, и возьмите его оценку вместе с переделками, а не в идеальном исполнении. Умножайте на ставку не самого дешёвого доступного человека, а того, кто реально будет это делать: обычно это самый занятой. И учтите, что час здесь не равен часу — прерывание стоит дороже своей длительности, потому что после него надо ещё вернуться к прерванной задаче.
Дежурство — отдельная строка. Даже если ничего не происходит, готовность — это расход: чей-то телефон, чей-то сон, чей-то отпуск, из которого могут вызвать. Если self-hosted добавляет новый класс ночных уведомлений, это статья бюджета, как бы её ни хотелось считать бесплатной.
Автобусный фактор — ещё одна. Если систему знает один человек, его отпуск — окно уязвимости, а заявление об уходе — незапланированная миграция. Лекарство известное: второй человек, который умеет, и документация, которую проверили на живом восстановлении. Это тоже время, и оно тоже входит в цену.
Настройку амортизируйте не до бесконечности, а до следующей мажорной миграции — примерно тогда снова придётся заплатить сравнимый кусок работы.
Последняя строка — ожидаемые потери от простоя. Способ оценки такой: возьмите срок, который команда переживает без инструмента без заметного ущерба, и умножьте на стоимость часа простоя тех, кто от него зависит. У подписки простой тоже случается, но чинит его вендор и за свой счёт. При self-hosted скорость восстановления — это ваша готовность, и её вы уже перечислили выше: дежурство, документация, второй человек.
Как свести суммы и не обмануть себя
Когда обе суммы собраны, сравнивать их надо аккуратно.
Горизонт общий. Берите срок, на котором обе стороны успеют предъявить разовые расходы: до следующей мажорной миграции, до пересмотра тарифа. На коротком горизонте self-hosted выглядит блестяще — просто потому, что разовые расходы ещё не наступили.
Периметр общий. К каждой строке одной стороны должен быть вопрос к другой. «Чей телефон звонит ночью, когда это падает?» — задайте его обоим вариантам. У подписки тоже есть ответ, просто он спрятан в цене.
Внимание конвертируется в деньги с потерями. Час инженера пересчитывается в ставку легко, а обратно — никак: когда календарь команды забит, этот час не купить. Если узкое место — не бюджет, а календарь, денежное сравнение занижает self-hosted. Это надо хотя бы проговорить словами, раз цифрами не получается.
Проверка чувствительности. Самая шаткая оценка в модели — труд. Подвигайте её в пределах правдоподобного. Если вердикт меняется, модель ничего не решает, и настоящий вопрос звучит иначе: есть ли в команде дежурная функция с запасом. Если есть, предельная цена ещё одной системы близка к цене инфраструктуры — и наивное деление из первого раздела случайно даёт правильный ответ. Если нет, каждый новый self-hosted сервис покупается по полной ставке плюс стоимость того, что инженер не сделает вместо этого.
И посчитайте обе суммы на горизонте, а не только на сегодня. Подписки, индексированные по числу мест, дорожают вместе с командой; труд self-hosted растёт с числом систем. Точка пересечения со временем сдвигается — полезно знать, в какую сторону.
Позиция редакции
Наша позиция: для типового инструмента — того, что не является ядром продукта и чем пользуются все подряд, — подписка обычно выгоднее. Причина арифметическая, а не вкусовая: дежурное внимание у вендора оптовое, размазанное по всем клиентам, а у вас оно розничное и оплачивается целиком. Отдельное исключение — инструмент, который и есть ядро продукта: там сравнение вообще не про деньги, а про скорость реакции и контроль.
И назовём условие, при котором эта позиция неверна: если в команде уже есть дежурная смена с запасом мощности, вывод «подписка обычно выгоднее» не работает. Предельная цена ещё одной системы близка к цене железа, арифметика разворачивается в пользу self-hosted, и честный расчёт это покажет. Так что проверять надо наличие резерва, а не кратность из первого деления.
Про то, какие статьи вообще стоит считать, а какие можно смело игнорировать, у нас есть отдельный материал о стоимости владения кодом — там разобран соседний вопрос: где проходит граница между ценой и шумом.
Последний вопрос, который стоит задать себе до всяких цифр: когда это упадёт в ночь на понедельник — чей телефон зазвонит и что этот человек будет делать? Если ответ «у вендора» — вы уже знаете свою цену. Если «мой» — теперь вы можете её посчитать.