Картостроители, разработчики, сборщики, дизайнеры, технические администраторы - без подрядчиков большинство Minecraft-проектов просто не запускается. Один человек редко умеет всё: строить, писать плагины, настраивать сервер и рисовать интерфейсы. Но вместе с помощью приходят и риски: утечки файлов, слив сборки, потеря доступов, поломки на боевом сервере.
И проблема обычно не в подрядчиках, а в том, как вы выстраиваете доступ и процесс работы. Даже честный и опытный специалист может случайно что-то сломать, если работает на живом сервере с полными правами. А нечестный получит всё, что нужно, чтобы унести вашу сборку.
Главная ошибка
Самый опасный сценарий выглядит так: «Человек вроде нормальный, давайте быстро дадим ему всё - пусть делает». Это кажется удобным: не нужно разбираться, какие права ему нужны, не нужно поднимать отдельный сервер, можно просто скинуть пароль и ждать результата.
В итоге подрядчик получает полный FTP, доступ к панели хостинга, все конфиги, базу данных с аккаунтами игроков, все плагины, включая платные и самописные, а иногда ещё и права администратора в Telegram и Discord. Это уже не работа над задачей - это передача контроля над проектом человеку, которого вы, возможно, знаете всего пару дней.
Даже если всё закончится хорошо, такие доступы часто забывают забрать. Через полгода в панели хостинга всё ещё висят аккаунты людей, с которыми вы давно не работаете, и никто уже не помнит, у кого какие пароли.
Как работать безопаснее
Минимальные доступы. Подрядчик должен получать ровно тот доступ, который нужен для задачи, а не больше. Билдеру не нужны плагины и база данных - ему достаточно мира и WorldEdit. Дизайнеру вообще не нужен доступ к серверу: он может прислать готовые файлы, а установите их вы. Разработчику отдельного модуля не нужен весь проект - достаточно описания, как его модуль должен взаимодействовать с остальным. Чем меньше доступов, тем ниже риск, и тем проще потом разобраться, кто что менял.
Не работайте на боевом сервере. По возможности поднимайте тестовый сервер или копию сборки, где подрядчик может спокойно экспериментировать. Если что-то сломается, это не заметит ни один игрок, а основные файлы останутся в безопасности. Тестовый сервер не обязательно должен быть мощным - для проверки плагинов или постройки хватит и минимального тарифа. Готовый результат вы переносите на основной сервер сами, после проверки.
Бэкапы отдельно. Бэкапы не должны храниться там же, где основная сборка, и не должны быть доступны подрядчикам. Если кто-то получил доступ к серверу и решил навредить, он не должен иметь возможности удалить заодно и резервные копии. Возможность откатиться должна оставаться всегда, что бы ни случилось с основной машиной.
Фиксация договорённостей. Даже при работе «по знакомству» важно записать, что именно нужно сделать, к какому сроку, какие материалы передаются подрядчику, кому принадлежат права на результат и можно ли ему показывать или продавать вашу работу кому-то ещё. Это не формальность: такие записи снижают хаос и защищают обе стороны в спорных ситуациях. Хороший подрядчик сам предложит зафиксировать договорённости, потому что это защищает и его от бесконечных правок.
Работа по этапам. Не передавайте всё сразу и не оплачивайте работу полностью наперёд. Разбейте её на части: задача, результат, проверка, следующий этап. Так вы контролируете и качество, и риски: если на втором этапе что-то пошло не так, вы потеряете только часть времени и денег, а не всё.
🔐 Когда работа закончена
Об этом часто забывают, но окончание работы - такой же важный момент, как начало. Заберите все выданные доступы, смените пароли, к которым у подрядчика был доступ, удалите его аккаунты в панели хостинга и права в Discord. Проверьте, не осталось ли в плагинах или конфигах чего-то лишнего: незнакомых команд, операторов, странных файлов. Это занимает полчаса, но закрывает возможность неприятных сюрпризов в будущем.
Красные флаги
Стоит насторожиться, если подрядчик просит полный доступ сразу, ещё до того, как вы обсудили задачу. Если давит на срочность: «давай быстрее, у меня скоро другой заказ». Если отказывается работать на тестовом сервере и настаивает на боевом. Если избегает конкретики в сроках и объёме работ. Если негативно реагирует на вопросы о безопасности или говорит что-то вроде «дайте доступ - я всё быстро сделаю, не переживайте».
Адекватный специалист понимает важность безопасности и спокойно работает в тех рамках, которые вы задали. Проблемные исполнители начинают сопротивляться именно этому - и это само по себе хороший фильтр.
Пример
Владелец сервера заказал новый спавн у билдера. Вместо того чтобы дать доступ к основному серверу, он поднял отдельный строительный сервер с копией мира и выдал билдеру только права на постройку. Оплата шла в три этапа: эскиз, основа, детали. Когда спавн был готов, владелец сам перенёс его схематикой на основной сервер и удалил строительный. Даже если бы билдер оказался недобросовестным, максимум, что он мог бы унести, - это свою же постройку.
Наш взгляд
Безопасная работа с подрядчиками - это не недоверие, а базовая гигиена проекта. Так же, как вы не оставляете дверь квартиры открытой, даже если соседи хорошие люди. Чем лучше у вас выстроены роли, доступы, этапы работы, бэкапы и договорённости, тем меньше шанс, что одна ошибка или один человек приведут к серьёзным проблемам. А хорошие подрядчики такой подход только уважают.
А вы работаете через тестовый контур или всё ещё часто пускаете подрядчиков сразу в боевой сервер?
