Что должно остаться у вас, а не у исполнителя: список из десяти пунктов

MAATRIX

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

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

Работа исполнителя — это действия: настроить сервер, написать код, запустить рассылку, подключить аналитику. Владение — это не действие, а факт регистрации: чей email указан как основной, чья карта привязана к биллингу, кто получает письмо от провайдера при подозрительной активности. Эти две вещи логически независимы. Можно нанять кого угодно администрировать аккаунт, оставаясь его юридическим владельцем, — большинство провайдеров прямо предусматривают это через роли доступа (owner, admin, collaborator и подобные).

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

Домен

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

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

Хостинг и сервер

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

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

Репозиторий кода

Система контроля версий (GitHub, GitLab, Bitbucket или self-hosted Git-сервер) должна жить в организации заказчика, а не в личном пространстве исполнителя. Практически все платформы поддерживают организации (organization) отдельно от личных аккаунтов разработчиков — репозиторий создаётся внутри организации заказчика, а исполнитель добавляется туда как участник с нужным уровнем прав.

Почему это важно: если репозиторий лежит в личном аккаунте исполнителя, весь код проекта — включая историю коммитов, issues, pull request'ы, настройки CI/CD и секреты в переменных окружения — юридически и технически принадлежит этому человеку. При смене исполнителя вы либо просите его перенести репозиторий (что требует добровольного участия), либо клонируете код без истории, теряя контекст решений, накопленный за месяцы разработки. Конкретный сценарий с личным аккаунтом фрилансера разобран в статье «Свой Git фрилансера на своём сервере»; там же — вариант с независимым self-hosted Git на инфраструктуре заказчика, который снимает вопрос владения аккаунтом в принципе.

SSL-сертификаты и связанные с ними учётные данные

Если сертификаты выпускаются автоматически через Let's Encrypt на сервере заказчика — это по умолчанию решает вопрос, потому что сертификат privately живёт на самом сервере и не требует отдельного аккаунта. Но если используются платные сертификаты от удостоверяющего центра, аккаунт в панели этого УЦ (со всей историей выпущенных сертификатов, привязанной оплатой и правом переоформления или отзыва) должен быть на заказчике.

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

Платёжные аккаунты сторонних сервисов

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

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

Почтовые ящики на домене

Почтовые ящики на корпоративном домене (info@, admin@, а тем более личные ящики сотрудников вида имя@компания) должны администрироваться через аккаунт заказчика — будь то собственный почтовый сервер на сервере заказчика или подписка на почтовый сервис (Google Workspace, Yandex 360 и подобные), оформленная на заказчика.

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

Данные аналитики и статистики

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

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

Документация и данные о конфигурации

Описание того, как устроена инфраструктура — какие сервисы запущены, где лежат конфигурационные файлы, какие переменные окружения используются, какая логика у cron-задач и деплоя, — должно существовать в виде документа или репозитория, доступного заказчику, а не только в памяти конкретного исполнителя.

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

Резервные копии

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

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

Учётные данные систем мониторинга и алертинга

Аккаунт в системе мониторинга (будь то SaaS-сервис уведомлений о падении сайта или самостоятельно развёрнутый стек вроде Prometheus/Grafana с уведомлениями) должен быть зарегистрирован на заказчика — с его контактами в списке получателей алертов, а не только с контактами исполнителя.

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

Общий принцип и как его применять с первого дня

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

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

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

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