На старте многие ищут «технического администратора» по очень простой логике: разбирается в плагинах, умеет запускать сервер - значит, подойдёт. Но на практике хороший тех. админ - это не просто человек, который может поставить ядро и закинуть папку plugins. И уж тем более не тот, кому стоит бездумно отдать все доступы в первый же день.
Где обычно ошибаются
Почти все проблемы вырастают из двух сценариев: берут человека «по знакомству», не проверив его вообще, или выдают полный доступ уже после пары сообщений в личке. В итоге вместо админа можно получить того, кто плохо понимает устройство сборки, ломает конфиги и совместимость, не умеет искать причину лагов и пропадает в самый важный момент. А в худшем случае - сливает сборку, плагины, доступы или внутреннюю информацию проекта.
Что вообще должен уметь тех. админ
Нормальный специалист понимает не отдельные плагины, а систему целиком:
как работает серверное ядро и где его ограничения как диагностировать лаги, ошибки и конфликты как работать с плагинами, конфигами, правами и зависимостями как безопасно обновлять сервер как вести бэкапы и снижать риски
Если человек умеет только «поставить сборку с YouTube» - это не тех. админ, а максимум начинающий сборщик.
Как проверить квалификацию
Абстрактный вопрос «что ты умеешь?» почти ничего не даёт - на него легко ответить заученными словами. Куда полезнее три конкретных шага.
Первое - дайте реальный кейс, а не теорию. Опишите ситуацию и посмотрите на ход мысли:
| Ситуация | Что показывает ответ |
|---|---|
| 1. TPS просел - что проверишь первым? | Умеет ли искать причину, а не гадать |
| 2. После обновления плагина сломались права - где искать ошибку? | Понимает ли зависимости и порядок загрузки |
| 3. Лаги и откаты, но TPS в норме - какие гипотезы? | Видит ли разницу между TPS, сетью и клиентом |
| 4. Два плагина конфликтуют - как локализуешь проблему? | Есть ли методика диагностики, а не тыканье палкой в какашку |
Второе - спросите про прошлые проекты. Нормальный специалист расскажет, какие сервера вёл, что именно делал, с какими проблемами сталкивался и за что отвечал лично. Если всё сводится к «ну я много где помогал» без деталей - это повод насторожиться.
Третье - оцените само техническое мышление, а не знание названий. Важно, ищет ли человек причину, задаёт ли уточняющие вопросы и понимает ли, что не всё лечится «переустановкой».
Как не нанять того, кто сольёт сборку
Правило простое: не давайте доступов больше, чем нужно на текущем этапе. Разница между осторожным и беспечным подходом видна сразу:
 Безопасно |
 Рискованно |
|---|---|
| 1. Разделять роли и доступы | Выдать всё и сразу |
| 2. Выдавать доступ поэтапно | Полный root с первого дня |
| 3. Хранить бэкапы отдельно | Бэкапы там же, где сервер |
| 4. Ограничивать важные файлы | Открытый доступ ко всему |
| 5. Логировать действия | Никакого контроля действий |
| 6. Тестовый контур на пробу | Боевой сервер со всеми секретами |
Исходники, приватные плагины и полную сборку не стоит передавать без реальной необходимости. Если человек нужен на тестовый период - дайте ему тестовый контур, а не боевой сервер со всеми секретами проекта.
Красные флаги
Насторожиться стоит, если кандидат:
просит полный доступ сразу не может внятно объяснить, что и зачем будет делать говорит слишком общими фразами обещает решить всё «за 5 минут» начинает давить на срочность обижается на базовые вопросы про опыт и безопасность
Логика тут простая: нормальный тех. админ понимает, почему вы осторожны, и относится к проверке спокойно. Странный - начинает нервничать именно на этом этапе.
Испытательный срок
Даже если кандидат хорошо показал себя на проверке, не спешите выдавать ему всё сразу. Хорошая практика - испытательный срок в несколько недель с ограниченными правами. В это время тех. админ работает на тестовом сервере или с отдельными задачами на основном, а вы смотрите, как он ведёт себя в реальной работе: насколько аккуратно вносит изменения, предупреждает ли о рисках, сообщает ли, что именно поменял.
Хороший признак - когда специалист сам ведёт записи изменений и предлагает сделать бэкап перед обновлением. Плохой - когда что-то меняется без предупреждения, а на вопрос «что ты сделал?» звучит «да так, поправил немного».
🔐 Доступы и после найма
Даже проверенному тех. админу лучше выдавать отдельный аккаунт, а не общий пароль владельца. Так видно, кто и что делал, а если человек уйдёт из проекта, достаточно отключить его аккаунт, не меняя все пароли. Важные вещи вроде доступа к оплате хостинга и домену стоит оставить только за собой. Технический администратор может управлять сервером, но владельцем проекта остаётесь вы.
Помните, что хороший тех. админ - это не только навыки, но и ответственность. Человек, который честно говорит «я не знаю, но разберусь» и предупреждает о рисках, ценнее того, кто уверенно обещает всё и сразу.
Наш взгляд
Тех. админ - это не человек «на доверии», а роль с доступом к критически важной части проекта. Поэтому проверять нужно не только знания, но и адекватность, прозрачность и отношение к безопасности.
Вывод: сначала - кейсы, вопросы, тестовый доступ и ограничения. И только потом - работа с более чувствительной частью проекта. Лучше потратить время на проверку, чем потом восстанавливать сервер, доступы и репутацию.
А вы как проверяете тех. админов перед тем, как дать доступ к серверу?
