Свой админ или аутсорс: считаем на цифрах для команды до двадцати человек

MAATRIX

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

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

Для совсем маленькой команды — два-пять человек — вопрос обычно не стоит: нагрузки на администрирование там на несколько часов в неделю, полноценная ставка была бы явно избыточна, и аутсорс или почасовая помощь напрашиваются сами собой. Мы разбирали эту ситуацию отдельно в статье про минимальную схему администрирования для стартапа без штатного админа — там решение почти всегда в пользу managed-сервисов и точечной помощи со стороны.

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

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

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

Аргументы в пользу штатного администратора

У найма в штат есть три сильных стороны, которые сложно получить в полном объёме на аутсорсе.

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

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

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

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

Аргументы в пользу аутсорса

У внешнего специалиста или агентства свои сильные стороны, и они не менее весомые.

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

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

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

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

Как оценить реальную загрузку задачами администрирования

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

Практический способ это сделать — не выдумывать формулу заранее, а последовательно пройти несколько шагов:

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

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

Критичность немедленной доступности: второй ключевой фактор

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

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

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

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

Как свести факторы в решение: практический фрейм

Когда оба фактора — реальная загрузка и критичность немедленной доступности — оценены отдельно, решение обычно складывается почти само:

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

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

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

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