Сначала выровняйте предмет сравнения
Два варианта должны решать одну задачу для одного числа пользователей, объёма данных, интеграций, доступности и recovery expectation. Если self-hosted вариант сравнивают без резервирования, а SaaS — с договорной поддержкой и георезервированием, разница не объясняет модель поставки. Запишите обязательные outcomes: какой процесс поддерживается, сколько времени допустим простой, кто отвечает на инцидент, какие данные хранятся, какой экспорт нужен и когда решение можно прекратить. Всё, чего нет в обязательном уровне, вынесите в отдельный сценарий.
Выберите горизонт. Для ранней проверки это может быть период до решения о масштабировании; для основной системы — несколько бюджетных циклов и отдельный exit-сценарий. Не подставляйте рыночную среднюю ставку или гипотетическую скидку. Используйте полную стоимость часа команды, фактические тарифы, договоры, инфраструктурные счета и диапазоны. Неизвестное фиксируйте как assumption с владельцем и датой проверки. Итоговая точность не может быть выше точности исходных данных.
Расчёт полной стоимости владения
Рабочая формула: TCO за горизонт = приобретение + внедрение + миграция + инфраструктура + эксплуатационный труд + безопасность и compliance + поддержка + ожидаемое влияние простоев + выход. Из суммы можно вычитать только подтверждённую остаточную ценность, например повторно используемую инфраструктуру, если она действительно понадобится. Не прячьте труд штатной команды в нуле: это ограниченный ресурс, который мог бы выполнять другую работу.
Категория | Open source/self-hosted | SaaS | Доказательство |
|---|---|---|---|
Приобретение | Лицензия, enterprise support, аудит условий | Тариф, минимальный объём, дополнительные модули | Текст лицензии, quote и договор |
Внедрение | Развёртывание, конфигурация, hardening, CI/CD | Настройка tenant, roles, policies и SSO | Оценка задач и пилот |
Миграция | Импорт, преобразование, очистка и сверка | Импорт, ограничения API и mapping | Тестовая выборка и reconciliation |
Инфраструктура | Compute, storage, network, backup, observability | Включено частично; overage и внешние компоненты | Billing data и архитектурная схема |
Эксплуатация | Обновления, on-call, recovery, capacity | Администрирование, vendor tickets, настройки | Часы по ролям и incident log |
Безопасность | Inventory, patches, scans, secrets, response | Vendor review, tenant config, logs, access | Control owner и evidence |
Простой | Вероятность × доказанное влияние в сценарии | То же, с учётом SLA и реального remedy | Свои incident и business data |
Выход | Экспорт, перенос customizations и демонтаж | Экспорт, API, identity migration и удаление данных | Пробный export и exit plan |
Три сценария вместо одного красивого числа
Base отражает подтверждённый текущий объём. Growth меняет только объяснённые drivers: пользователей, хранилище, запросы, интеграции, поддержку или требования доступности. Exit считает прекращение на выбранной дате. Не используйте одну строку «непредвиденные расходы» вместо причин: создайте ranges для спорных параметров и посмотрите, при каком значении меняется решение. Это sensitivity analysis, а не прогноз с вымышленной точностью.
Сценарий | Что меняется | Что остаётся одинаковым | Вопрос |
|---|---|---|---|
Base | Фактический текущий объём | Функция и уровень сервиса | Какова полная цена сегодня? |
Growth | Только подтверждённые cost drivers | Метод расчёта и контроль качества | Где возникает ступень стоимости? |
Incident | Время восстановления и участие команды | Одинаковое влияние на бизнес | Кто делает и оплачивает response? |
Exit | Экспорт, параллельный период и демонтаж | Требуемая целостность данных | Можно ли уйти в обещанный срок? |
Open source — это права, а не обещание бесплатности
Open Source Definition описывает права на использование, redistribution, source и derived works. Конкретные обязанности задаёт лицензия. Доступный репозиторий без подходящей лицензии не следует автоматически называть open source. Перед выбором зафиксируйте версию, license identifier, зависимости и способ распространения вашего решения. SPDX помогает структурировать сведения о компонентах и лицензиях, но не заменяет юридический вывод. Если продукт распространяется клиентам или модифицирует компонент, проверка условий особенно важна.
Оцените устойчивость проекта: активные maintainers, security policy, release cadence, поддерживаемые ветки, response на уязвимости, воспроизводимость artifacts и возможность собрать собственную версию. OpenSSF Scorecard даёт полезные автоматизированные сигналы практик репозитория, но score не доказывает безопасность и не оценивает соответствие вашей архитектуре. CISA отдельно подчёркивает зависимость организаций от критических OSS components и необходимость понимать их prevalence и sustainability.
Self-hosting означает назначить владельцев backup, patching, secrets, monitoring, capacity, incident response и recovery tests. Даже если инфраструктура уже существует, её shared cost нужно распределить: storage, observability, security tooling, on-call и platform team не становятся бесплатными. Если никто не способен назвать владельца обновления и время восстановления, сравнение ещё не готово.
SaaS — это перенос части работы, а не всех рисков
В SaaS пользователь работает с приложением провайдера, а underlying infrastructure управляется внешней стороной. Но клиент всё равно отвечает за выбор продукта, configuration, identities, role model, data input, интеграции и часть incident coordination. Точная граница находится в договоре и документации конкретного сервиса, а не в общем определении cloud. Проверьте support hours, status communication, backup/restore terms, audit evidence, data location, subprocessors и действия при прекращении договора.
Тариф часто не включает implementation, SSO, premium logs, API limits, sandbox, дополнительное хранение или сопровождение интеграций. Не обвиняйте поставщика заранее: запросите точный quote для вашего объёма и зафиксируйте, что включено. Сравните monthly recurring cost с трудом эксплуатации self-hosted на том же горизонте. Не смешивайте cash flow и TCO: предоплата влияет на бюджетирование, но не отменяет полную стоимость.
Синтетический пример без выдуманной рыночной цены
Команда из восьми пользователей сравнивает два варианта на двенадцать месяцев. Для self-hosted пилот показывает восемьдесят часов внедрения, десять часов эксплуатации в месяц и отдельные фактические счета инфраструктуры. Для SaaS пилот показывает шестнадцать часов настройки, два часа администрирования в месяц и цену P за пользователя. Это не рыночные данные, а обозначенные предположения примера. Пусть C — полная стоимость часа. Тогда труд self-hosted равен (80 + 10 × 12) × C, а SaaS — (16 + 2 × 12) × C + 8 × 12 × P. К обеим сторонам ещё добавляются свои migration, security, incident и exit.
Пример показывает не победителя, а чувствительность. При дефицитной platform-команде десять часов могут ограничивать развитие сильнее, чем их бухгалтерская стоимость. При строгой кастомизации SaaS может потребовать дорогих обходов. При большом росте per-user тариф меняется иначе, чем инфраструктура. Подставьте свои подтверждённые значения и проверьте точку, где решение переворачивается. Не публикуйте этот расчёт как статистику отрасли.
Не пропустите миграцию, качество данных и выход
До пилота полезно проверить качество данных перед миграцией: уникальность ключей, обязательные поля, кодировки, связи, history и правила reconciliation. Грязные данные создают одинаковые риски для обоих вариантов и не должны ошибочно считаться стоимостью одного продукта. Сделайте небольшой импорт и обратный экспорт, сравните количества и контрольные суммы, проверьте восстановление permissions.
Exit plan должен отвечать: в каком формате выгружаются данные и файлы, сохраняются ли audit trails, как переносятся identities, сколько длится параллельная работа, кто подтверждает удаление, что происходит с custom code и интеграциями. Для open source выход может означать fork, смену maintainership или замену инфраструктуры; для SaaS — экспорт и migration API. В обоих случаях непроверенная переносимость является риском, который имеет владельца и сценарий проверки.
Безопасность и долг входят в TCO
NIST рекомендует управлять компонентами, design decisions и vulnerability response на протяжении lifecycle. Для небольшой команды сначала нужно проверить минимальный контур безопасности команды: доступы, устройства, MFA, backup и offboarding. Затем распределите обязанности между своей командой и поставщиком. Сертификат или публичный код — evidence по отдельному вопросу, но не автоматическое соответствие вашей угрозе.
Кастомизация self-hosted решения, обходы ограничений SaaS и отложенные обновления создают будущую цену изменений. Поэтому важно учесть накопленный технический долг как отдельный список с последствиями и вероятным трудом, а не процентом «на всякий случай». Если обновление блокируется вашими modifications, это наблюдаемое следствие. Если поставщик только теоретически может повысить цену, оформите диапазон и условие, а не выдавайте опасение за факт.
Proof of concept с критериями остановки
Зафиксируйте одинаковый ключевой процесс, объём тестовых данных и роль пользователя.
Проведите импорт, настройте доступы и выполните рабочий сценарий без ручного обхода.
Снимите часы по ролям, инфраструктурные расходы, ограничения тарифа и обязательные security-действия.
Смоделируйте отказ или восстановление в безопасной среде и запишите, кто выполняет каждый шаг.
Сделайте экспорт и оцените время приведения данных к переносимому формату.
Сравните base, growth и exit; остановите пилот, если обязательный критерий не выполняется.
Ограничения и практический следующий шаг
Модель не является бухгалтерским стандартом или юридической консультацией. Некоторые эффекты — скорость команды, риск простоя, зависимость от редкой компетенции — сложно перевести в деньги без собственных данных. Не скрывайте их: храните рядом количественные расходы, qualitative risks и confidence. Для меняющихся тарифов, лицензий и условий поддержки укажите дату проверки.
Практический следующий шаг: создайте таблицу из восьми категорий TCO и заполните по одной подтверждённой строке для каждого варианта. Неизвестные значения пометьте владельцем и способом проверки. Затем проведите один тестовый экспорт. Если команда не может восстановить данные, назвать владельца обновлений или объяснить лицензию, отложите окончательное решение — вы пока сравниваете витрины, а не владение.
Обсуждение
Комментарии
Обсуждение загрузится при приближении к разделу.