Как принять сервер у подрядчика: акт приёмки, который защитит вас через год

MAATRIX

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

Почему акт «работы выполнены» ничего не защищает

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

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

Дальше — что должно быть внутри такого акта и как проверить каждый пункт до подписи, а не после.

Что обязательно должно быть в акте приёмки

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

• Перечень выполненных работ — не «настроен сервер», а конкретно: «установлен Ubuntu 24.04, развёрнут nginx как reverse proxy, настроен TLS через Let's Encrypt с автопродлением, развёрнуто приложение в Docker Compose, настроен ежедневный бэкап базы в 03:00 с хранением 14 копий».
• Способ проверки каждого пункта — команда или URL, которыми заказчик сам, без участия подрядчика, убеждается, что пункт действительно выполнен. Не «поверьте на слово», а systemctl status nginx, curl -I https://ваш-домен, docker compose ps.
• Список всех доступов и где они хранятся — не «доступы переданы», а конкретный файл или запись в менеджере паролей, куда заказчик может зайти и увидеть их сам.
• Описание принятых архитектурных решений — почему выбран именно такой стек, какие альтернативы рассматривались и отклонены, какие ограничения у текущей схемы.
• Список установленного ПО с версиями — снятый на сервере, а не переписанный из технического задания, потому что по факту часто ставится не совсем то, что планировалось на старте.
• Схема сети и открытых портов — что слушает на каких портах, откуда должен быть доступ, а откуда — нет.
• Контакты и порядок эскалации — что делать, если через месяц что-то сломается, а подрядчика уже нет: к кому идёт следующий подрядчик, с чего он начинает разбор.

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

Доступы: как убедиться, что они действительно у вас, а не только у подрядчика

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

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

• SSH-доступ к серверу. У вас должен быть собственный пользователь с sudo-правами, а не общий root, которым пользовался подрядчик. Проверка — зайти со своей машины под своим ключом и выполнить sudo whoami, не спрашивая ни о чём подрядчика:

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

• Аудит authorized_keys. До подписания акта посмотрите, чей ещё ключ стоит в системе — иногда там остаётся ключ самого подрядчика или ключ, забытый от предыдущего исполнителя:

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

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

• Пароль от панели хостинга или облачного провайдера. Не «подрядчик знает пароль», а вы сами можете зайти в панель под своей учётной записью или сменить пароль от единственной учётной записи и подтвердить вход. Если провайдер поддерживает отдельных пользователей с ограниченными правами (большинство современных панелей это умеют) — у подрядчика должен быть именно такой, отдельный, а не ваш основной логин.
• Домен и DNS. Отдельная и частая проблема: сервер настроен идеально, а регистратор домена и DNS-зона всё ещё оформлены на аккаунт подрядчика. Зайдите в панель регистратора и панель DNS сами, под собственными учётными данными, и убедитесь, что можете добавить тестовую TXT-запись и увидеть её через dig:

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

• Пароли приложений: базы данных, админки, панели мониторинга. Все они должны лежать не в переписке с подрядчиком, а в вашем менеджере паролей — Vaultwarden, 1Password, любом другом, до которого у подрядчика после закрытия проекта уже нет доступа. Если пароли создавались подрядчиком — на этапе приёмки их стоит перевыпустить самостоятельно, а не оставлять те, что знает кто-то ещё.
• SSL-сертификаты и ключи от них, если они не выпускаются автоматически через Let's Encrypt, а куплены отдельно — эти файлы должны лежать у вас, а не только на сервере в единственном экземпляре.
• Доступ к репозиторию с кодом и конфигурацией, если он использовался в процессе работ — учётная запись в GitHub/GitLab, права на организацию, а не личный аккаунт подрядчика с правами admin на ваш репозиторий.

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

Архитектурные решения: что фиксировать и зачем

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

В акт или приложение к нему стоит включить короткое, буквально на страницу, описание архитектуры:

• Общая схема: какие компоненты есть на сервере и как они связаны — приложение, база данных, кэш, reverse proxy, очередь задач. Схему удобно нарисовать даже в виде простого текстового списка со стрелками, не обязательно в специальном инструменте.
• Почему выбран именно такой стек, а не альтернативный — например, «Docker Compose вместо голой установки, потому что на сервере будет три независимых сервиса с разными версиями зависимостей» или «PostgreSQL вместо MySQL по требованию используемого фреймворка».
• Что сознательно не сделано и почему — например, «репликация базы не настроена, для текущей нагрузки достаточно ежедневного бэкапа; при росте нагрузки это нужно пересмотреть». Без такой оговорки решение «пока не делаем» через год читается как «забыли сделать».
• Как сервер масштабируется, если такая потребность возникнет — можно ли поднять второй инстанс приложения за тем же nginx, упирается ли текущая схема в единственный сервер по архитектуре, а не только по мощности.
• Схема сети и портов: что слушает извне, что только на localhost, через какой порт проходит трафик до приложения. Проверяется одной командой:

ss -tlnp

Сверьте вывод с тем, что описано в документации — если открыт порт, который никак не упомянут (например, отладочный порт БД, забытый открытым наружу), это повод спросить подрядчика, зачем он там, до подписания акта, а не после.

Список установленного ПО: снимаем сами, а не берём из ТЗ

Список ПО в акте почти никогда не стоит переписывать из технического задания или из переписки — по факту в процессе работы обычно ставится что-то ещё: вспомогательные утилиты для отладки, дополнительные зависимости, пакеты, которые в итоге не пригодились, но остались висеть в системе. Правильный список — тот, что снят на самом сервере в момент приёмки.

Для Ubuntu/Debian:

dpkg -l > packages-at-acceptance.txt
wc -l packages-at-acceptance.txt

Для систем на базе RHEL/AlmaLinux:

rpm -qa > packages-at-acceptance.txt

Список запущенных сервисов и таймеров systemd:

systemctl list-units --type=service --state=running
systemctl list-timers

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

docker compose -f /путь/к/docker-compose.yml config --images
docker images --format "{{.Repository}}:{{.Tag}}"

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

dpkg -l > packages-now.txt
diff packages-at-acceptance.txt packages-now.txt

Отдельно стоит зафиксировать версии ключевого прикладного ПО — СУБД, рантайма приложения (Node.js, PHP, Python), веб-сервера. Эти цифры не всегда попадают в общий список пакетов, если что-то ставилось вручную или через отдельный установщик, а именно они чаще всего важны при следующем обновлении.

Практическая проверка перед подписанием: пошаговый чек-лист

Акт подписывается после проверки, а не до неё. Ниже — последовательность, которую стоит пройти целиком, даже если подрядчик уверяет, что «всё и так работает»:

1. Пройти по каждому пункту из перечня работ и лично выполнить команду проверки, указанную в акте, а не поверить на слово. Если для пункта нет способа проверки — это повод его туда добавить, прежде чем подписывать.
2. Убедиться, что бэкап не просто настроен, а реально восстанавливается. Файл с бэкапом, который никогда не разворачивали обратно, — это не бэкап, а файл неизвестного качества. Разверните последнюю резервную копию в тестовое окружение (или хотя бы проверьте, что архив не битый и распаковывается) до подписания акта, а не после первого реального сбоя.
3. Проверить мониторинг и оповещения. Алерты должны приходить на ваш контакт, а не на почту или telegram-бот, привязанный к аккаунту подрядчика. Сгенерируйте тестовое событие (например, временно остановите нужный сервис) и убедитесь, что уведомление реально дошло до вас.
4. Сверить открытые порты firewall с документацией, как описано в предыдущем разделе — лишний открытый порт наружу закрывается сразу, не после того как его найдёт кто-то другой.
5. Проверить, что все административные пароли и ключи лежат в вашем менеджере паролей, а не только на сервере или в переписке с подрядчиком. Если для доступа использовались временные учётные записи, созданные под эту задачу, — на этапе приёмки их стоит либо удалить, либо перевести под ваш полный контроль.
6. Убедиться, что домен, SSL и DNS оформлены на вашу организацию, а не остаются в личном кабинете подрядчика — при следующем продлении это может стать неожиданной проблемой в самый неподходящий момент.
7. Прогнать базовый чек-лист безопасности нового сервера — обновления системы, статус firewall, отсутствие лишних открытых портов, актуальность SSH-конфигурации. Подробный разбор пунктов — в статье чек-лист безопасности нового сервера.
8. Отозвать доступ подрядчика сразу после подписания акта, если дальнейшая поддержка им не предполагается — учётные записи, ключи, временные пароли для тестов. Полный порядок закрытия доступа разобран отдельно — подрядчик закончил работу: как закрыть за ним двери.

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

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