Стоимость on‑prem‑развёртывания: что корпоративные сделки действительно добавляют

Почему запрос меняет условия сделки

Стандартная SaaS‑цена предполагает один общий продукт, единый процесс релизов и модель поддержки, которую вы контролируете. Запрос на on‑prem быстро ломает эту модель. Вы перестаёте запускать ПО только в своей среде и начинаете помогать клиенту запускать его в их среде — с их правилами, сетью и командой безопасности посередине.

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

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

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

Команды часто пропускают второй блок. Продажи слышат «self‑hosted» и думают «тот же софт, просто другое хостинг». Инженеры и служба поддержки обнаруживают реальные затраты позже, обычно во время закупки или сразу после подписания. Тогда клиент спрашивает, кто отвечает за обновления версий, как быстро вы реагируете на продакшен‑инциденты, поддерживаете ли их версию Kubernetes и что происходит, если их служба безопасности запрещает какую‑то зависимость.

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

Что покупатели имеют в виду под on‑prem

Корпоративные покупатели часто говорят «on‑prem», когда на самом деле имеют в виду «мы хотим больше контроля». Это звучит однозначно, но на деле это может означать очень разные варианты. Каждый из них меняет объём работ, риски и стоимость.

Четыре распространённых варианта

True on‑prem означает, что ПО работает на собственных серверах покупателя, в их офисе или дата‑центре. Их команда обычно контролирует сеть, хранилище и правила доступа.

Private cloud: ПО работает в выделённой среде в AWS, Google Cloud, Azure или другом провайдере. Это отделено от общего SaaS, но всё ещё облачная инфраструктура.

Single‑tenant означает, что покупатель получает изолированные экземпляры приложения и базы данных. Вы можете по‑прежнему хостить и выполнять большую часть сопровождения.

Air‑gapped — окружение с минимальным или отсутствующим доступом в интернет. Обновления, логи, проверки лицензий и удалённая поддержка становятся медленнее и более ручными.

Это не мелкие терминологические различия — они решают, кто несёт работу после подписания контракта.

Спросите, где будет запускаться ПО. Затем спросите, кто управляет доступом. Если покупатель владеет серверами, VPN, брандмауэром и админ‑аккаунтами, ваша команда зависит от их процессов почти при каждом изменении. Если вы хостите single‑tenant, вы сохраняете больше контроля, но и берёте на себя большую часть операционной нагрузки.

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

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

Обычный пример: закупка говорит «on‑prem», а команда безопасности позже соглашается на выделённый облачный аккаунт. Тогда это уже не true on‑prem, а private cloud, и цена на эксплуатацию и поддержку, как правило, ниже. Если не прояснить это заранее, ценообразование по on‑prem превращается в гадание.

Затраты на хостинг, которые нужно считать

Большинство команд оценивает лицензию и забывает про машины — именно там смета начинает расходиться с реальностью.

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

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

Реалистичный бюджет обычно включает вычисления, хранилище и сетевые резервы для обычной нагрузки и пиков; хранение бэкапов и тесты восстановления; стейджинг, тестовые и резервные окружения; мониторинг и логирование; а также инженерное время на установку, усиление, патчи и поддержку всего этого.

Инструменты часто упускают. Возможно, вы используете Grafana, Prometheus, Loki, Sentry или похожие инструменты в своём окружении, но заказчик может требовать отдельные инстансы, платные коннекторы или интеграцию с их внутренними инструментами. Это добавляет настройку и дополнительные компоненты для поддержки.

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

Небольшой пример. Покупатель просит self‑hosted приложение для 500 внутренних пользователей. Продажи оценивают один продакшен‑кластер. Операции позже добавляют стейджинг, реплику для отчётности, ночные бэкапы, хранение логов 90 дней и удалённую цель восстановления. Ежемесячный счёт изменится, но большая переменная — время сотрудников.

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

Работа поддержки после запуска

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

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

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

Первые 30–90 дней обычно самые насыщенные: пользователи просят сменить роли, админы просят помочь с логами, и кто‑то хочет доказательство, что бэкапы, алерты и запланированные задачи работают как нужно. Это нормальные запросы, но они стоят времени.

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

Практичное разделение простое. IT‑команда покупателя управляет сбросами паролей, онбордингом пользователей, локальным сетевым доступом и проблемами с устройствами. Ваша команда отвечает за баги продукта, ошибки развёртывания, проблемы с данными внутри приложения и конфигурации, за которые вы отвечаете. Для совместных проблем, например с SSO или доставкой почты, должен быть именованный контакт с обеих сторон.

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

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

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

Постоянная работа по обновлениям

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

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

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

Большинство on‑prem клиентов также отстают от вашего графика обновлений. Они могут оставаться на шести месяцах или году позади, потому что другой внутренний проект важнее или чтобы избежать переобучения пользователей. Тогда они всё равно просят исправления безопасности и выборочные обновления функционала. Ваша команда поддерживает два пути одновременно: текущую ветку и старую. Это означает кастомные патчи, дополнительное QA и решения о переносе исправлений.

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

Справедливая цена должна рассматривать обновления как продолжаемую услугу, а не одноразовую настройку. Если покупатель хочет квартальные обновления, патчи для старых версий и уикенд‑установки — внесите каждую позицию в коммерческое предложение. Иначе маржа будет съедаться по одному «маленькому» апгрейду за раз.

Работа по безопасности, которую продажи часто пропускают

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

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

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

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

Сканы уязвимостей и pentest‑ы требуют честного ценообразования. Сам тест стоит денег, но большая часть затрат часто появляется после отчёта: ваша команда объясняет принятые риски, исправляет средние findings, пере‑тестит и отвечает на новый раунд вопросов от безопасности и закупки.

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

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

Работа по проверке безопасности — часть цены enterprise on‑prem. Это не бесплатная надбавка.

Как по шагам оценить цену

Начните с листа объёма (scope sheet), где простым языком записаны все требования покупателя. Если чего‑то нет в этом листе — пока не оценивайте. Корпоративные покупатели часто говорят «on‑prem», имея в виду VPN‑доступ, SSO, аудиторские логи, кастомные правила бэкапа, поэтапные релизы и проверку безопасности.

Чистая смета делит работу на три блока. Setup — разовая работа по установке, конфигурации, документации и тестированию. Monthly operations — мониторинг, патчи, проверки бэкапов, поддержка и рутинная работа по безопасности. Change requests — всё, что покупатель добавляет позже: новый провайдер удостоверений, особое окно обновлений и т. п.

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

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

Стоимость инструментов важнее, чем многие думают. Вам могут понадобиться мониторинг, хранение логов, софт для бэкапа, VPN, приватный контейнер‑реестр или дополнительные CI‑раннеры. Некоторые покупатели также просят доказательства аудита, пентесты или длинные security‑анкеты. Эти запросы требуют времени, даже без изменений в коде.

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

Одна полезная привычка: прикладывайте короткую страницу с допущениями к каждой on‑prem‑предложению. Если потом покупатель просит SSO, обновления в air‑gapped режиме или отдельный стейджинг‑кластер, вы сможете выставить это как change request, а не поглощать бесплатно.

Простой пример с одним покупателем

Средняя SaaS‑компания продаёт софт для управления качеством промышленным клиентам. Один регулируемый производитель хочет продукт, но только если вендор разместит его в окружении покупателя, даст доступ через VPN и назначит двух именованных контактов поддержки для любых проблем в продакшене.

Это может выглядеть как обычный корпоративный запрос. На деле — нет. Команда уже не может относиться к доставке, поддержке и обновлениям как к стандартному облачному плану.

Первичная оценка может выглядеть так:

• Работа по setup и развёртыванию: примерно $29,000
• Месячная поддержка и управление доступом: примерно $5,000 в месяц
• Каждое плановое обновление: примерно $6,000
• Базовая подписка на ПО: $72,000 в год

Стоимость setup быстро растёт, потому что вендору нужно не просто установить приложение. Нужно упаковать его под окружение покупателя, пройти настройки VPN, протестировать бэкап и восстановление, подготовить план отката и участвовать в нескольких встречах с ИT и командой безопасности покупателя. Это легко может занять 150–170 часов до запуска.

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

Обновления — это то, где многие недооценивают поддержку self‑hosted. В обычном облаке вы выпускаете обновление и идёте дальше. Для этого покупателя каждый крупный релиз требует тестов в их окружении, утверждения изменений, назначенного окна установки и пост‑проверок. Если покупатель хочет два плановых обновления в год, это добавляет примерно $12,000.

Теперь цена выглядит по‑другому. Продажи сначала думали закрыть сделку за $72,000 в год с маленьким setup $10,000. После честного саутинга первый год ближе к $173,000: $72,000 за продукт, около $29,000 за setup, $60,000 за поддержку за 12 месяцев и примерно $12,000 за плановые обновления.

Эта разница — реальная стоимость on‑prem‑запроса. Если покупатель хочет контроля, вендор должен заложить оплату за работу. Если цена кажется слишком высокой, обе стороны могут сначала сократить объём: например, одного именованного контакта вместо двух или обновления раз в год.

Ошибки, которые съедают маржу

Проще всего терять деньги на корпоративной сделке, если считать on‑prem только как вариант хостинга. Это не так. Он меняет доставку, поддержку, проверку безопасности, обновления и кто несёт риск при сбое. Большая часть затрат — это труд, а не сервера.

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

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

Работу по безопасности тоже часто недооценивают. Продажи слышат «security review» и представляют один звонок. На практике покупатель может прислать длинные анкеты, требовать доказательств аудитских записей и задавать дополнительные вопросы инженерам. Даже небольшая сделка может съесть неделю на это.

Оценки поддержки часто проваливаются по простой причине: покупатель обещает низкий объём тикетов, но каждый тикет в on‑prem идёт медленнее. Для диагностики требуется окно обслуживания, VPN‑доступ, админ покупателя и согласование с их IT, прежде чем что‑то можно увидеть.

Худшая ошибка — сказать «да» до того, как ops и finance проверят числа. Этот обзор должен покрывать дополнительные часы инженеров до запуска, политику патчей и обновлений, объём проверок безопасности, правила отклика поддержки, лимиты доступа и маржу, если сделка затянется.

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

Быстрые проверки перед обязательством

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

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

Какие часы поддержки ожидаются? «Рабочие часы» и 24/7 — это разные затраты. Уточните времена отклика, пути эскалации и кто подключается к живому инцидент‑коллу.

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

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

Если объём всё ещё неясен, остановитесь и продайте платную фазу discovery прежде чем фиксировать цену.

Этот последний пункт важнее, чем многие признаются. Короткая discovery‑фаза быстро выявит скрытую работу: проверки брандмауэра, настройку VPN, аудит логов, отдельные стейджинг‑окружения, правила патчинга или дополнительную документацию для IT‑команды покупателя. Пропустите этот шаг — и «простая» сделка превратится в месяцы неоплачиваемой работы.

Вы оцениваете не только софт. Вы оцениваете время ожидания, координацию, согласования и ответственность, когда что‑то ломается.

Если ваша команда не часто оценивает кастомный хостинг, поддержку или работу по безопасности, возьмите второе мнение до подписания. На oleg.is Oleg Sotnikov работает со стартапами и небольшими командами именно по таким техническим вопросам: от инфраструктуры и архитектуры продукта до AI‑помогающих инженерных процессов. Короткий обзор до подписания контракта может сэкономить много денег после него.