Нанимаете админа-фрилансера: 15 вопросов, которые задать до оплаты

MAATRIX

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

Опыт со стеком и техническая совместимость

Вопрос 1. Работали ли вы именно с этим стеком — не «с серверами вообще», а конкретно с этой связкой ОС, СУБД и веб-сервера?

«Опытный администратор» — расплывчатая формулировка. Человек может быть сильным специалистом по Windows Server и Hyper-V и одновременно ни разу не настраивавшим Linux-контейнеры, или наоборот. Спрашивайте прямо про технологии вашего проекта: если у вас Ubuntu 24.04, PostgreSQL, Nginx и Docker Compose — так и спросите, приходилось ли с этим работать, и попросите пример задачи, где это применялось. Общий ответ «да, конечно, с чем угодно работал» без конкретики — повод попросить уточнение.

Вопрос 2. Можете описать похожий по масштабу и стеку проект, который вы вели или ведёте сейчас?

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

Вопрос 3. Что вы будете делать, если в процессе работы столкнётесь с компонентом стека, с которым раньше не работали?

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

Референсы и проверяемая репутация

Вопрос 4. Можете дать контакты двух-трёх предыдущих заказчиков, с которыми я мог бы поговорить?

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

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

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

Доступы, аккаунты и передача дел по завершении

Вопрос 6. Сервер и связанные сервисы будут зарегистрированы на моём аккаунте или на вашем?

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

Вопрос 7. Что именно и в каком виде будет передано по завершении работы — доступы, документация, история изменений?

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

Вопрос 8. Готовы ли вы подписать NDA и договориться письменно об условиях доступа к серверу до начала работы?

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

Прозрачность процесса: тикеты, предупреждения, документация

Вопрос 9. Делаете ли вы точечный бэкап перед рискованным изменением, отдельно от планового расписания?

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

Вопрос 10. Как вы предупреждаете о рискованных изменениях до того, как их вносите — и что происходит, если что-то пошло не так?

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

Вопрос 11. Готовы ли вы вести работу через явные задачи или тикеты — с описанием, что сделано и когда?

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

Вопрос 12. Как вы документируете собственную работу — по ходу дела или только в конце, если попросят?

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

Доступность в нерабочее время и деньги

Вопрос 13. Как вы работаете с экстренными ситуациями вне обычных часов — доступны ли вы вообще, и на каких условиях?

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

Вопрос 14. Что произойдёт, если вы станете недоступны на несколько дней в процессе работы — есть ли у вас запасной вариант для этого проекта?

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

Вопрос 15. Как структурирована оплата — есть ли разделение на аванс и оплату по этапам с проверяемым результатом?

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

Как читать ответы: уклончивость — самостоятельный сигнал

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

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

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