Приёмка сервера от подрядчика: чек-лист владельца бизнеса

MAATRIX

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

Что вы можете проверить сами: работает ли всё снаружи

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

• Откройте сервис с трёх разных точек: с рабочего компьютера, с телефона через мобильный интернет (не через офисный Wi-Fi — офисная сеть может «видеть» сервис не так, как весь остальной мир), и попросите кого-то не из компании прислать скриншот со своего устройства. Если сайт открывается у вас, но не у постороннего человека, это тревожный сигнал сам по себе.
• Проверьте доступность через независимый онлайн-сервис вроде check-host.net — это обычная форма на странице, отвечает ли сервер из разных регионов, без вводимых команд.
• Пройдите путь реального пользователя от начала до конца, а не только откройте главную страницу: оформите тестовый заказ, отправьте форму, войдите под тестовым логином, скачайте файл. Если этой системой ежедневно будет пользоваться сотрудник — пусть пройдёт путь вместе с вами, его практический взгляд ценнее вашего.
• Сверьте видимый результат с тем, что заказывали изначально — откройте переписку или техзадание и пройдитесь пунктами: этот раздел обещали — он есть, эта функция обсуждалась — она работает. Расхождения бывают и у добросовестных подрядчиков, но о них вы должны узнать от них, а не обнаружить сами.
• Проверьте замок в адресной строке браузера — рядом с адресом должен быть значок закрытого соединения. Если его нет или браузер предупреждает об опасности при заходе на сайт, спросите об этом прямо, не дожидаясь, пока то же увидит клиент.
• Откройте сайт в режиме инкогнито (Ctrl+Shift+N на Windows, Cmd+Shift+N на Mac) — это исключает ситуацию, когда сайт кажется рабочим только потому, что в обычном окне вы уже авторизованы или у вас закеширована старая версия страницы.

Все эти проверки занимают меньше часа и не требуют звонка подрядчику — вы делаете их сами, до разговора с ним, а не полагаясь на демонстрацию через шеринг экрана, где показывают ровно то, что хотят показать.

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

Формулировка «доступы переданы» на практике ничего не гарантирует: она может означать как полноценный личный аккаунт, так и один общий пароль в мессенджере, а всё остальное осталось у подрядчика. Разница всплывает не в момент сдачи, а через полгода, когда что-то ломается, а связаться с подрядчиком уже не получается.

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

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

Документация: проверяем факт наличия, а не содержание

Понимать содержание технической документации не нужно, чтобы проверить, что она вообще существует, лежит в понятном месте и написана не только для автора.

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

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

Что нужно поручить независимому специалисту

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

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

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

Не закрывайте оплату сразу — возьмите пробный период

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

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

Сводный план: что и в каком порядке делать

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

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