Своя DevOps-экспертиза против managed-услуг: считаем на год

MAATRIX

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

Почему это вообще нужно считать

Managed-услуги продают избавление от рутины: не нужно самому настраивать репликацию базы, следить за апдейтами Kubernetes control plane, поднимать алертинг с нуля. За это провайдер берёт наценку — иногда прозрачную (отдельная строка в счёте), иногда скрытую в цене тарифа. Штатный DevOps-инженер продаёт ту же рутину, но за фиксированную годовую стоимость независимо от того, сколько сервисов он обслуживает.

Проблема в том, что обе стоимости считают неправильно. Managed-наценку сравнивают с ценой одного сервера, забывая, что она копится по каждому сервису отдельно — база, очередь, Kubernetes, мониторинг, CDN. А стоимость инженера считают как "оклад умножить на двенадцать", забывая налоги, рабочее место, отпуска, больничные и время на онбординг. При таком сравнении managed почти всегда выглядит дороже там, где на самом деле дешевле, и наоборот.

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

Методика: как считать полную стоимость своего специалиста

Оклад — это меньше половины реальной стоимости штатного инженера. Полная формула на год выглядит так:

Полная стоимость DevOps в год =
    Оклад × 12
  + Налоги и взносы работодателя (зависят от юрисдикции и формы найма)
  + Стоимость рабочего места (техника, лицензии на ПО, доступ к инструментам)
  + Обучение и сертификации (курсы, конференции, время на них)
  + Компенсация простоя на отпуск и больничные
    (обычно 1-1.5 месяца в год, когда задачи либо стоят, либо их закрывает кто-то другой)
  + Стоимость найма и онбординга, разложенная на первый год
    (рекрутинг, испытательный срок с пониженной эффективностью)
  - Экономия на managed-наценках, которые инженер заменяет

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

Отдельно стоит учесть, что один инженер — это отсутствие резервирования. Если он в отпуске или уволился, а на проде инцидент, managed-провайдер держит дежурную поддержку 24/7 по контракту, а штатный специалист — нет, если вы не наняли второго или не выстроили процесс передачи знаний. Это не довод против найма, но статья расходов, которую часто забывают: либо второй специалист (частичная занятость, аутсорс на подхвате), либо смирение с риском простоя в его отсутствие.

Методика: как считать сумму managed-наценок

Вторая часть уравнения — сколько вы платите сверх голой инфраструктуры за то, что провайдер управляет ей за вас. Наценка складывается по каждому managed-сервису отдельно, и здесь легко занизить сумму, если считать по одному сервису вместо всех.

Практический способ найти реальную наценку — сравнить свой счёт с ценой аналогичных ресурсов без managed-слоя:

Точные суммы наценок у каждого провайдера свои и меняются, поэтому подставлять "усреднённые по рынку" цифры в эту таблицу бессмысленно — важен сам принцип: пройтись по каждой строке своего счёта и явно выписать, за что именно вы платите сверх сырых вычислительных ресурсов. Отдельно managed-Kubernetes против своего k3s и managed-база против своей на VPS разбирают наценку по конкретным сервисам подробнее — если у вас несколько managed-сервисов, посчитайте наценку по каждому отдельно и сложите: сумма обычно выше, чем кажется на глаз, потому что каждая наценка сама по себе выглядит небольшой.

Годовая сумма всех managed-наценок — это и есть та цифра, с которой нужно сравнивать полную стоимость своего инженера. Не с ценой инфраструктуры целиком, а именно с переплатой за управление ею.

При каком масштабе найм становится оправданным

Прямого ответа "нанимайте при X серверах" быть не может — слишком много переменных: сложность стека, юрисдикция найма, квалификация нужного специалиста. Но есть три ориентира, по которым можно понять, в какую сторону смещается баланс.

Число managed-сервисов, а не число серверов. Один сервер с managed-базой почти никогда не окупит найм — наценка на один сервис обычно меньше стоимости даже части ставки инженера. Но если у вас managed-база, managed-очередь, managed-Kubernetes и managed-мониторинг одновременно, наценки складываются, и сумма может приблизиться к стоимости специалиста, который заменит все четыре сразу одним найм.

Растущая частота изменений инфраструктуры. Managed-услуги оптимизированы под стабильную нагрузку и редкие изменения — они дорожают быстрее, если вы часто добавляете новые окружения, тестовые стенды, региональные копии. Своя экспертиза окупается быстрее там, где инфраструктура не статична, а меняется еженедельно: инженер один раз строит автоматизацию (Terraform, Ansible, CI/CD), и дальше добавление окружения стоит его времени в часах, а не новой строки в managed-счёте.

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

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

Что даёт свой специалист сверх экономии на наценках

Даже если сумма managed-наценок сегодня меньше стоимости найма, у своей экспертизы есть ценность, которая не сводится к деньгам за год.

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

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

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

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

Промежуточный вариант: частичная занятость и аутсорс

Дилемма "штат целиком или managed целиком" не единственная. Есть промежуточные модели, которые снимают часть рисков обеих крайностей.

DevOps на part-time или по подписке (DevOps-as-a-service). Специалист или небольшая команда обслуживает инфраструктуру за фиксированную ежемесячную плату, но не в штате. Дешевле полной ставки, но без полного погружения в вашу специфику — где-то между "своя экспертиза" и managed по глубине понимания системы.

Автоматизация как замена части рутины. Если основная часть работы инженера — не архитектурные решения, а повторяющиеся операции (раскатка окружений, ротация сертификатов, применение патчей), их можно автоматизировать один раз и дальше поддерживать силами существующей команды без выделенного найма. Это снижает точку перелома в пользу того, чтобы оставаться на managed дольше — автоматизация окупается быстрее найма там, где задачи однотипны и предсказуемы.

Гибридная схема по критичности сервиса. Некритичные и стабильные части инфраструктуры (например, статический сайт, тестовые окружения) остаются на managed, а критичный и часто меняющийся продакшен переходит под своего специалиста. Это позволяет не платить за найм ради всего стека сразу, а закрыть наймом только ту часть, где экономия и ценность специалиста максимальны.

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

Практический план расчёта для своей команды

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

1. Выпишите все managed-сервисы и их годовую стоимость по счетам за последние 6-12 месяцев — не тарифную цену "с сайта", а фактические платежи с учётом роста нагрузки.
2. Для каждого сервиса оцените стоимость "голой" альтернативы — сколько будет стоить VPS/выделенный сервер сопоставимой мощности без managed-слоя.
3. Сложите разницу по всем сервисам — это и есть годовая сумма managed-наценки, которую потенциально заменяет свой специалист.
4. Посчитайте полную стоимость найма по формуле из второго раздела для вашей конкретной юрисдикции и формы оформления — не берите чужие ориентиры, узнайте реальные цифры у своей бухгалтерии или HR.
5. Добавьте к решению нефинансовые факторы — скорость реакции, гибкость, нестандартные требования — и решите, перевешивают ли они разницу в деньгах, если она в пользу managed.
6. Пересчитайте на горизонте 12-18 месяцев, а не только на сегодня — managed-наценки растут с масштабом, стоимость инженера в первом приближении фиксирована.

Если по итогам расчёта разница невелика в любую сторону — это нормальный результат: значит, вы примерно на точке перелома, и выбор стоит делать по нефинансовым факторам, а не пытаться выжать точность там, где её не может быть по определению задачи. С похожей механикой расчёта, но для более узкой задачи — сравнение подписки на внешний GitLab с self-hosted версией — можно свериться в статье про свой GitLab и точку перелома по числу разработчиков: там та же логика "наценка за managed против стоимости своей поддержки", только в масштабе одного сервиса, а не всей инфраструктуры.

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