Аутсорс-команда против фрилансера с Kwork: без иллюзий

Вопрос звучит примерно раз в квартал: «Зачем платить команде, если можно найти хорошего фрилансера на Kwork за треть цены?» Вопрос честный. И ответ тоже должен быть честным — без отраслевого снобизма и без страшилок ради страшилок.

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

Что происходит, когда фрилансер исчезает

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

Что остаётся на вашей стороне: инфраструктура, которую он настроил, но её внутренняя логика живёт преимущественно в его голове. Пароли к нескольким сервисам — в его менеджере паролей или на рабочем ноутбуке. Доступы к облачному аккаунту выданы на его личный e-mail. Релиз назначен на завтра.

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

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

Один человек не закрывает всё

Хороший фрилансер — специалист. Хороший специалист всегда в чём-то силён и в чём-то слабее. Это нормально и честно. Проблема возникает тогда, когда от одного человека ожидают одновременно:

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

Это четыре разные специализации. Даже очень опытный инженер делает одно лучше остального. Встречается тип «умею всё» — но на практике это значит «достаточно разбираюсь, чтобы настроить базовое, но глубокого опыта нет ни в чём». А дежурить 24/7 в одиночку физически невозможно — человеку нужен сон. Это не недостаток конкретного фрилансера, это арифметика.

У нас под каждый контур работают инженеры с узкой специализацией, и они взаимозаменяемы. Ночной инцидент берёт дежурная смена, а не тот, кто случайно оказался онлайн. Безопасность разбирает специалист по безопасности, а не «DevOps, который немного умеет». Вопросы к базам данных — инженер с опытом именно в СУБД, которая стоит у вас в продакшне.

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

Бухгалтерская аналогия — коротко

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

Вопрос с DevOps устроен так же: не «отдавать ли», а «кому и на каких условиях». Фрилансер без договора — это не аутсорс, это надежда на порядочность конкретного человека.

Честный trade-off: когда фрилансер оправдан

Было бы нечестно не сказать об этом.

Фрилансер может быть правильным выбором, когда:

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

Продакшна пока нет. Стартап на ранней стадии, MVP без реальных пользователей, тестовая среда без данных. Риск инцидента есть, но последствия — не катастрофические. Экономия на этом этапе оправдана.

Есть внутренняя команда, которая владеет контекстом. Фрилансер приходит усилить конкретную экспертизу — не заменить всю инфраструктурную функцию. Знания остаются внутри.

Ловушка наступает тогда, когда разовая экономия незаметно превращается в системную зависимость. Фрилансер настроил одно, потом другое, потом третье — и вот он уже единственный, кто понимает, как это устроено. Это называется bus factor = 1, и это уже другая история.

Что меняет договор с юрлицом

Договор — не формальность. Если рассмотреть его содержательно, он фиксирует несколько вещей, которых у найма фрилансера нет по определению.

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

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

Владение доступами и кодом — на вашей стороне. Доступы выдаёте и отзываете вы. Инфраструктурный код в Terraform и Ansible принадлежит вам. Если мы расстаёмся — у вас остаётся воспроизводимое описание контура, а не настройки в чьей-то голове. Отзыв доступов — одна операция, несколько минут.

Юрисдикция и регуляторика. Работаем как юрлицо РФ, в рамках российского права. Для клиентов с требованиями 152-ФЗ, 187-ФЗ или категорированием объектов КИИ это не опционально — это условие работы. Договор с иностранным физлицом с Kwork в эту модель просто не вписывается структурно, вне зависимости от квалификации специалиста.

Что это выглядит на практике

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

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

Если ваш контур небольшой, продакшн есть, пользователи есть — и вы думаете о том, как выстроить эксплуатацию разумно, поговорите с нами. Обследование занимает 3–5 рабочих дней, NDA подписываем до начала технических переговоров. Подробнее о том, как это устроено — на странице DevOps-аутсорсинга.