Обслуживание сайта можно передать подрядчику, сохранив управление критичными ресурсами. Для этого недостаточно иметь пароль администратора CMS. Домен, DNS, аккаунт провайдера, исходный код, резервные копии и внешние интеграции находятся в разных местах и могут принадлежать разным учётным записям.
Задача владельца — обеспечить понятный доступ к проекту при смене исполнителя или недоступности одного человека. Это не требует самостоятельно выполнять технические работы. Нужны контроль над аккаунтами, распределение прав и актуальные сведения о том, как устроена эксплуатация. Такие правила полезны и заказчику, и добросовестной поддержке.
Проверьте владельцев ключевых ресурсов
Составьте перечень доменов, хостинга, облачных аккаунтов, репозиториев, почты и платёжных интеграций. Уточните, на кого оформлен каждый ресурс и кто способен восстановить доступ. Рабочая почта подрядчика не должна быть единственным способом вернуть управление системой, от которой зависит ваш бизнес.
Для домена отдельно проверьте данные администратора у регистратора. Передача пароля от кабинета и смена администратора домена — разные действия. Если сведения не соответствуют реальному владельцу, порядок исправления следует уточнять у регистратора. Зафиксируйте также даты продления и источник уведомлений, чтобы смена команды не привела к пропуску оплаты.
Выдавайте права под конкретную работу
Используйте персональные учётные записи и минимальный достаточный уровень доступа. Чтение журналов не всегда требует полного управления сервером, а публикация материалов — прав администратора WordPress. Когда задача заканчивается, дополнительные права нужно пересмотреть. Общий логин мешает понять, кто именно выполнил действие.
Если сервис позволяет приглашать участников, используйте штатное делегирование вместо передачи основного пароля. Для программных интеграций нужны отдельные отзываемые реквизиты. В WordPress пароль приложения связан с правами его пользователя, поэтому отдельная техническая запись с подходящей ролью важнее самого названия «пароль приложения». Подробнее о ролях — в статье о доступах WordPress.
Организуйте хранение секретов
Секреты передают через защищённое хранилище с разграничением доступа. В общей документации достаточно указать, где находится нужная запись и кто может её получить. Пароли не стоит дублировать в задачах, скриншотах и технических журналах. Чем больше копий, тем труднее отозвать скомпрометированные данные.
Заранее проверьте резервный доступ к самому хранилищу и второму фактору. Если все коды находятся только в телефоне одного сотрудника, устойчивость процесса ограничена его доступностью. Определите процедуру восстановления и способ подтвердить личность. Такой сценарий следует безопасно проверить до отпуска, увольнения или потери устройства.
Сохраняйте историю изменений
Для заметных изменений нужны дата, исполнитель, причина и результат проверки. Код полезно хранить в контролируемом репозитории, а конфигурацию — учитывать отдельно от секретов. Ручные действия в панели тоже должны оставлять запись: смена DNS или лимита сервера не обязательно видна в истории приложения.
Не требуйте отчёт о каждом движении мыши. Достаточно сведений, позволяющих восстановить последовательность при сбое. Например: обновлён модуль оплаты, перед работой создана копия, проверен тестовый заказ, обнаружено ограничение такого-то сценария. По этой истории следующая команда сможет продолжить обслуживание без догадок.
Убедитесь, что копии доступны независимо
Заказчик должен знать, что входит в резервную копию, где она хранится и как получить её при недоступности подрядчика. Доступ к архиву, ключу и инструкции не должен целиком зависеть от того же сервера, который восстанавливается. Ограничьте возможность удаления копий из обычной учётной записи приложения.
Периодически просите подтвердить тест восстановления и перечислить проверенные функции. Самостоятельно скачивать все архивы ежедневно необязательно, но понимание процедуры и контроль доступа нужны. Порядок проверки описан в материале о готовности резервных копий. Если состав данных изменился, обновите и правила копирования.
Подготовьте передачу другому исполнителю
Перечень передачи должен включать схему проекта, репозиторий, доступы, расписания, внешние сервисы и известные ограничения. Укажите незавершённые работы и ближайшие даты продления. При прекращении сотрудничества сначала проверьте доступ новой команды, затем отзывайте прежние права, сохраняя возможность восстановить сайт.
Не меняйте все секреты одновременно без списка потребителей. Пароль базы могут использовать сайт, импорт, фоновые отчёты и задания копирования. После замены проверьте каждый процесс. Старые токены, ключи и активные сессии следует отзывать отдельно: одной смены пароля бывает недостаточно для прекращения доступа.
Проверяйте контроль без вмешательства в работу
Раз в согласованный период сверяйте список аккаунтов, права и документацию. Убедитесь, что ответственный со стороны владельца может войти в основные кабинеты и получить инструкции. Для этого не требуется запускать рискованные команды или менять настройки рабочего сервера.
Обсуждайте контроль как обычную часть эксплуатации. Если для получения данных каждый раз нужны личные договорённости с единственным инженером, процедуру стоит упростить. Прозрачная передача сведений помогает быстрее подключать нужных специалистов и уменьшает количество срочных действий во время аварии.
Если хотите проверить, сохраняется ли у вас управление проектом, обратитесь в HOMEWEB. Перечислите CMS, провайдеров и текущие способы доступа. Поможем определить, какие сведения нужны для передачи на сопровождение.
