Подрядчик сдал сервер: 12 вопросов, которые задать до оплаты

MAATRIX

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

Почему это не про недоверие к подрядчику

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

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

Двенадцать вопросов ниже сгруппированы по четырём темам: кому реально принадлежит сервер, работают ли защитные механизмы на практике, задокументировано ли сделанное и соответствует ли оно задаче, и не осталось ли на сервере того, чего там быть не должно.

Кому принадлежит сервер и доступы к нему

Вопрос 1. На чьё имя и на чей аккаунт зарегистрирован сам сервер — ваш или подрядчика?

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

Вопрос 2. Переданы ли вам все пароли и ключи доступа целиком, включая root/administrator — и можете ли вы прямо сейчас зайти без участия подрядчика?

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

ssh your_admin_user@ваш-сервер
sudo whoami
# ожидаемый вывод: root

Вопрос 3. Кто владеет доменом и DNS-записями, привязанными к серверу?

Отдельная и частая проблема: сервер настроен идеально, а домен и DNS-зона всё ещё числятся в аккаунте регистратора, которым управляет подрядчик. Через год, когда домен потребует продления или переноса NS-записей, это может стать неожиданной проблемой в самый неудобный момент — вплоть до того, что домен просто не продлят вовремя, потому что письмо от регистратора ушло на почту подрядчика, а не вам. Проверка не сложнее, чем зайти в панель регистратора под собственным логином и добавить тестовую TXT-запись, которую потом видно через dig:

dig TXT test.ваш-домен +short

Работают ли бэкапы и мониторинг на практике, а не на словах

Вопрос 4. Готов ли подрядчик прямо сейчас продемонстрировать восстановление из бэкапа, а не просто сказать «бэкапы настроены»?

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

Вопрос 5. Как часто бэкапы реально проверялись на восстановимость — и есть ли этому подтверждение, а не только расписание в cron?

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

Вопрос 6. Куда именно идут алерты мониторинга — на контакт подрядчика или на ваш, и можно ли это проверить тестовым событием?

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

Документация и соответствие изначальной задаче

Вопрос 7. Есть ли документация того, что установлено и настроено — список ПО с версиями, схема сети и портов?

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

dpkg -l > packages-at-acceptance.txt
systemctl list-units --type=service --state=running
ss -tlnp

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

Вопрос 8. Зафиксировано ли, почему приняты конкретные архитектурные решения — и что сознательно не сделано?

Вопрос не про «что установлено», а про «почему именно так». Почему база вынесена в отдельный контейнер, а не установлена нативно; почему выбран Redis, а не RabbitMQ; почему репликация базы не настроена — потому что для текущей нагрузки достаточно ежедневного бэкапа, или потому что просто не успели. Без этой оговорки решение «пока не делаем» через год читается как «забыли сделать», и следующий человек, который будет обслуживать сервер, потратит время не на работу, а на реконструкцию логики, причём иногда неверную. Развёрнутый разбор того, что должно попасть в такой документ и как его проверить перед подписью, — в статье «Как принять сервер у подрядчика: акт приёмки».

Вопрос 9. Соответствует ли итоговая конфигурация исходному техническому заданию — и если есть расхождения, чем они объясняются?

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

Лицензии и незакрытые хвосты перед продакшеном

Вопрос 10. Используются ли на сервере платные или лицензионные компоненты — и на чьё имя они оформлены?

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

Вопрос 11. Остались ли на сервере тестовые, отладочные или временные доступы, которые нужно закрыть перед продакшеном?

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

grep -H "ssh-" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

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

Вопрос 12. Прошёл ли сервер базовую проверку безопасности перед сдачей — обновления системы, firewall, отсутствие лишних открытых портов?

Последний вопрос — контрольная сверка. Попросите подрядчика показать дату последнего обновления пакетов, статус firewall и список портов, которые слушают снаружи, и сверьте это с тем, что должно быть по документации из вопроса 7. Полный порядок такой проверки — по шагам, с конкретными командами — в статье «Чек-лист безопасности нового сервера». Если сервер уходит в продакшен с портом, который никто не может объяснить, лучше закрыть этот вопрос до оплаты, а не после первого инцидента.

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