Час админа против экономии на тарифе: где проходит граница выгоды

MAATRIX

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

Почему «дешевле» не значит «выгоднее»

Когда сравнивают тарифы или решения — managed-сервис против самостоятельно поднятого аналога на VPS, дешёвый план против дорогого, self-hosted против SaaS-подписки, — почти всегда в расчёт попадает только прямая денежная разница. Условно: managed-база стоит на N рублей в месяц дороже, чем такая же СУБД, поднятая вручную на обычном сервере. Вывод «поднимем сами, сэкономим N рублей» выглядит очевидным.

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

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

Формула-каркас: экономия против стоимости времени

Смысл методики укладывается в одно неравенство. Экономия на тарифе или на самостоятельном решении оправдана только тогда, когда:

Денежная экономия за период
    >
Часы администратора за тот же период × Стоимость часа специалиста

Если правая часть больше левой — вы не сэкономили, а купили себе неоплаченную работу. Формально это записывается так:

E = P_дорогой - P_дешёвый        # экономия в деньгах за период
C = H × R                        # стоимость затраченного времени
                                  # H — часы администратора за период
                                  # R — стоимость часа специалиста

Если C > E → «экономия» на самом деле убыток
Если C < E → экономия реальна, дешёвый вариант оправдан
Если C ≈ E → граница выгоды, решение зависит от прочих факторов
    (риск, время реакции на инциденты, стратегическая ценность контроля)

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

Из чего на самом деле состоит H — часы администратора

Чтобы формула работала, H нужно раскладывать на компоненты, а не оценивать интуитивно. На практике в H входят как минимум:

• Первоначальная настройка — установка, конфигурация, интеграция с остальной инфраструктурой. Разовые часы, но их всё равно нужно учесть в первый период сравнения.
• Регулярное обслуживание — обновления пакетов и ядра, ротация сертификатов, проверка резервных копий, чтение логов на предмет аномалий. Это повторяющиеся часы, и именно они чаще всего недооцениваются, потому что каждое отдельное действие кажется мелким.
• Реакция на инциденты — время, которое уходит не только на само устранение проблемы, но и на то, чтобы её заметить, если нет нормального мониторинга. Здесь же — цена downtime, о которой мы отдельно писали в материале про автопродление и простой с нуля: время настройки часто оценивают заниженно именно потому, что не учитывают доводку системы до рабочего состояния после первых сбоев.
• Масштабирование и миграции — по мере роста нагрузки самостоятельно поднятое решение почти всегда требует ручных доработок, которых managed-версия избегает по определению.
• Обучение и передача знаний — если администрированием занимается не один человек, а команда, сюда добавляется время на документирование и онбординг новых людей в специфику самодельной настройки.
• Стоимость ошибок — время на восстановление после человеческого фактора: опечатка в конфиге, забытый бэкап, ручной деплой без проверки. Это не гипотетическая статья: практика ручных решений системно недооценивает именно этот пункт.

Честная оценка H — это сумма этих компонентов за весь период, на который вы сравниваете варианты, а не только за первый месяц.

Как оценить R — стоимость часа специалиста

Вторая переменная тоже требует аккуратности. Есть три способа её посчитать, и они дают разные, иногда сильно расходящиеся числа.

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

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

Альтернативная стоимость времени основателя. Самая коварная категория. Если админит сам предприниматель или единственный разработчик, формально его час «бесплатен» — зарплата всё равно выплачена. Но пока он настраивает резервное копирование вручную, он не занимается продуктом, продажами или тем, что реально двигает бизнес. Здесь R — это не оклад, а стоимость упущенной альтернативы: сколько стоил бы этот час, потраченный на профильную задачу.

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

Пример расчёта: как выглядит граница на практике

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

Период сравнения:            12 месяцев
E (экономия в деньгах):      условно X руб./мес → 12·X за год
H_настройка (разовая):       условно A часов в первый месяц
H_поддержка (ежемесячно):    условно B часов/мес → 12·B за год
R (стоимость часа):          зависит от того, кто администрирует

C (итоговая стоимость времени) = (A + 12·B) × R

Если C > 12·X — самостоятельный вариант дороже managed,
несмотря на более низкий счёт от провайдера.

Дальше подставляете свои реальные A, B, R и X — они у каждой команды свои, и именно поэтому нет универсального ответа «self-hosted всегда дешевле» или «managed всегда дороже». Есть только конкретный расчёт для конкретной ситуации. Похожая логика применима и к сравнению собственной VPS-базы с managed-СУБД — там доплата за managed фактически покупает готовые H_поддержка, и это стоит явно сопоставить с их стоимостью, если считать самому.

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

Где чаще всего теряют деньги, считая только тариф

Практика показывает несколько типовых точек, где расчёт без учёта времени администратора обманывает сильнее всего.

Рост команды. Решение, которое было дешевле при одном пользователе или одном сервере, может перестать быть дешёвым при десяти — не потому что вырос счёт от провайдера, а потому что B (часы поддержки) растёт вместе с масштабом быстрее, чем ожидалось.

«Бесплатное» время владельца. Если R занижен до нуля из-за того, что администрирует сам основатель, формула всегда будет показывать выгоду self-hosted — но это методическая ошибка, а не реальная экономия. Стоит хотя бы раз посчитать с рыночным R, чтобы увидеть настоящую картину.

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

Downtime как скрытая R-компонента. Время, потраченное на диагностику простоя, который управляемый сервис обработал бы автоматически (failover, автоматическое восстановление), — это тоже H, просто оно проявляется нерегулярно и потому легко выпадает из расчёта, пока не случится.

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

Практическая методика: как считать перед решением

Чтобы формула работала не только в теории, применяйте её по шагам при каждом сравнении «дешевле, но самому» против «дороже, но готово»:

1. Зафиксируйте период сравнения. Год — разумный минимум, чтобы не потерять сезонные и накопительные эффекты.
2. Оцените E. Прямая разница в деньгах между вариантами за этот период — это единственная часть, которую обычно и так считают.
3. Разложите H на компоненты из списка выше: настройка, регулярная поддержка, инциденты, масштабирование, обучение, ошибки. По каждому — честная, а не оптимистичная оценка часов.
4. Выберите правильный R для вашего сценария: рыночная ставка, внутренняя себестоимость или альтернативная стоимость времени — в зависимости от того, кто реально администрирует и чем он занимался бы вместо этого.
5. Посчитайте C = H × R и сравните с E. Если C заметно меньше E — самостоятельный вариант оправдан. Если близко или больше — managed или более дорогой тариф, скорее всего, выгоднее, даже если это неинтуитивно.
6. Пересчитывайте при изменении масштаба. Граница выгоды не статична: рост нагрузки, числа серверов или пользователей меняет H быстрее, чем E, поэтому расчёт стоит повторять при значимых изменениях, а не полагаться на решение, принятое год назад.
7. Явно проговаривайте допущения. Если R занижен искусственно (время основателя считается «бесплатным»), зафиксируйте это как допущение, а не как факт — так решение останется пересматриваемым, когда обстоятельства изменятся.

Эта методика не даёт готового ответа «берите managed» или «настраивайте сами» — она даёт способ проверить интуицию цифрами, специфичными для вашей ситуации, вместо того чтобы полагаться на общий совет из статьи в интернете.

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