В последний рабочий день сотрудник передал пароль от сайта. Через неделю выясняется, что уведомления регистратора по-прежнему приходят на его личную почту. Новый администратор может менять тексты, но продлить домен через привычную форму уже сложнее. Доступы к сайту распределены между несколькими сервисами, и один пароль описывает лишь небольшую часть этой системы.
Передачу стоит начать с карты владельцев. Для каждой записи укажите сервис, рабочую учётную запись, роль, способ восстановления и человека, который проверил вход. Пароли храните в корпоративном менеджере паролей. В таблице достаточно ссылки на запись, чтобы документ можно было безопасно обсуждать с руководителем.
Ниже восемь групп доступов и порядок передачи. Он подойдёт для планового увольнения, смены подрядчика и ситуации, когда сайт годами поддерживал один человек. В срочном случае сначала закрывают рискованные входы и сохраняют журнал событий. Остальную инвентаризацию продолжают с новым ответственным.
1. Домен и настройки адресов
Откройте кабинет регистратора домена с учётной записью компании. Проверьте, кому принадлежит договор, какая почта получает уведомления и откуда списывается оплата. У сотрудника мог быть удобный рабочий вход, связанный с личным номером телефона. Такой способ восстановления надо заменить до завершения передачи.
Затем найдите управление DNS, то есть записями, которые направляют домен на сайт и почтовый сервер. Оно иногда находится у другого поставщика. Сохраните актуальный список записей и сведения о том, кто имеет право их менять. Само увольнение обычно не требует переноса DNS: лишнее изменение маршрутов создаёт отдельный риск для сайта и почты.
Убедитесь, что новый ответственный может прочитать уведомление о продлении и увидеть срок регистрации. Если домен оформлен на физическое лицо, владельца меняют по процедуре регистратора. Смена пароля в кабинете сама по себе ничего не говорит о том, на кого оформлен домен.
Для сайта, который одновременно меняет подрядчика, пригодится порядок выбора студии и передачи проекта. Обсуждение владельца домена лучше закончить раньше работ над дизайном: адрес продолжает обслуживать уже запущенный бизнес.
2. Хостинг, сервер и консоль восстановления
Проверьте кабинет хостинга, облачные проекты и отдельные серверы. У каждого могут быть собственные участники, ключи доступа и платёжные настройки. Человек, удалённый из панели сайта, способен сохранить доступ через консоль сервера. Поэтому список входов составляют по фактическим системам.
На сервере администратор проверяет персональные учётные записи, SSH-ключи для удалённого входа и права запуска команд. Удалять ключи следует по владельцу и назначению. Если тот же ключ используется автоматическим развёртыванием сайта, сначала выделяют для этой операции отдельный технический доступ и проверяют его работу.
Особого внимания требует консоль восстановления у провайдера. Она полезна, когда обычный вход сломан, поэтому новым ответственным нужно проверить собственный путь входа заранее. Вместе с ним передают доступ к резервным копиям и сведения о том, как восстановить сервер в отдельном окружении.
После изменения прав откройте сайт с обычного устройства и отправьте тестовую заявку. Если сервер обслуживает несколько проектов, отметьте их в акте передачи. Отключение общей учётной записи способно затронуть соседний сайт, о котором кадровая служба ничего не знает.
3. Панель управления сайтом и личные сессии
В системе управления контентом просмотрите весь список пользователей. У сотрудника иногда есть две записи: персональная для ежедневной работы и старая административная, созданная при запуске. Проверьте обе по истории изменений и рабочей переписке. Общий логин постепенно замените персональными учётными записями с понятными ролями.
Перед блокировкой сохраните сведения об авторстве материалов и назначьте нового владельца черновиков. Некоторые системы удаляют связанные данные вместе с пользователем либо предлагают выбрать получателя. Действуйте по документации конкретной CMS и сначала проверьте результат на копии проекта, если поведение удаления неизвестно.
Завершите активные сессии уходящего сотрудника средствами сервиса. Смена пароля и отзыв сессий могут быть отдельными действиями. Проверьте также пароли приложений, сохранённые интеграции и вход через корпоративного поставщика авторизации. Таблица должна содержать результат каждого действия, чтобы статус «передано» имел проверяемый смысл.
Если новому редактору требуется только менять цены и фотографии, выдайте права на эти разделы. Повседневная IT-поддержка сайта проще, когда редактор понимает границы своей роли и знает, кому передать техническую задачу.
4. Исходный код и автоматическая публикация
Найдите репозиторий с кодом и убедитесь, что он принадлежит компании либо организации, которой компания управляет. Локальная папка разработчика содержит только часть истории. Для продолжения работы нужны исходники, инструкции запуска, используемые версии зависимостей и настройки сборки без открытых секретов.
В репозитории проверьте участников, установленные приложения и ключи развёртывания. Отдельно посмотрите личные токены сотрудника: они могли запускать сборку или загружать файлы. Замена технических доступов требует пробной публикации в тестовое окружение. Новый сотрудник должен суметь повторить её по инструкции без участия прежнего владельца.
Журнал событий помогает установить, какие права и подключения менялись. Например, GitHub описывает просмотр журнала безопасности учётной записи. Для командного проекта дополнительно проверяют доступные журналы организации и учитывают действующие права просмотра.
В IT-поддержке Feature IT передачу проекта можно начать с такой инвентаризации. По её результатам составляют список доступов, которые компания контролирует, и отдельный перечень зависимостей от личных аккаунтов. Это даёт конкретный объём работ для администратора.
5. Почта, телефоны и восстановление входа
Рабочая почта часто оказывается главным средством восстановления сразу нескольких сервисов. Сначала найдите адреса, которые получают письма от регистратора, хостинга и платёжных систем. Затем назначьте ответственного за эти ящики и убедитесь, что резервные способы входа принадлежат компании.
Передачу содержимого почты проводите по внутренним правилам компании и утверждённому объёму. Для технической непрерывности обычно достаточно обеспечить получение уведомлений сервисов, обработку новых обращений и доступ уполномоченных сотрудников. Личные переписки и произвольная пересылка всей почты требуют отдельного решения, которое выходит за рамки настройки сайта.
Проверьте двухфакторную защиту, когда после пароля нужен дополнительный код. У компании должен оставаться согласованный путь восстановления. Резервные коды размещают в защищённом хранилище с ограниченным доступом. После передачи их обновляют, если прежний сотрудник мог сохранить копию.
Телефон в профиле сервиса и номер на странице контактов решают разные задачи. Смена публичного номера не меняет способ восстановления кабинета. Обе записи внесите в перечень с понятными названиями, иначе проверяющий легко отметит неверную строку как выполненную.
6. Аналитика, реклама и внешние кабинеты
Посмотрите участников счётчиков аналитики, рекламных аккаунтов, сервисов карт и кабинетов для вебмастеров. Право смотреть отчёт отличается от права выдавать доступ другим людям. Передайте владение и административные роли тому, кто отвечает за эти системы, затем уберите ненужные разрешения.
Сохраните номера счётчиков и привязки к сайту. При смене сотрудника обычно можно продолжить работу с существующей историей. Создание нового счётчика только ради нового владельца разрывает привычные отчёты и требует дополнительных настроек целей. Такое решение должно иметь отдельную причину.
Если рекламой занималось агентство, составьте список прав каждого представителя. После увольнения одного менеджера договор с агентством может продолжать действовать. Решение по доступу принимают по рабочей роли и текущему поручению, чтобы случайно не остановить согласованную кампанию.
После передачи откройте отчёт под новой учётной записью и убедитесь, что нужные ресурсы видны. Проверку получения обращений можно провести по порядку проверки заявок с сайта. Так команда подтвердит, что реклама, сайт и обработка запросов продолжают работать вместе.
7. Интеграции, боты и платёжные подключения
Сайт может отправлять заявки в CRM, сообщения в Telegram и письма через внешний сервис. Для таких связей часто используются токены, то есть секретные значения, которые дают программе право выполнять определённые действия. Они живут дольше рабочей сессии человека и требуют отдельной проверки.
Для каждого секрета запишите назначение, место хранения и потребителей. Перед заменой определите порядок обновления. Например, новый ключ сначала добавляют в защищённые настройки приложения, проверяют отправку тестового сообщения и затем отзывают прежний. Конкретная последовательность зависит от возможностей сервиса и допустимого перерыва.
У платёжного подключения проверьте владельцев кабинета, доступ к возвратам и контактам поддержки. Боевые операции используйте только по согласованной процедуре проверки. Если доступен тестовый режим, проверьте в нём обмен уведомлениями и обработку результата оплаты, сохранив сведения о времени проверки.
После замены ключей и паролей проверьте, что новые значения доступны только действующим ответственным сотрудникам. Старые ключи отзовите средствами соответствующих сервисов. Пароль в старом чате остаётся известным даже после удаления человека из нового проекта. Отзыв прежнего значения закрывает этот путь; одна перестановка файлов его не закрывает.
8. Копии, инструкции и аварийные контакты
Получите доступ к резервным копиям и выясните, кто оплачивает их хранение. Архив на личном диске сотрудника следует перенести в согласованное хранилище компании. Проверьте шифрование и наличие ключа восстановления: защищённый архив без доступного ключа бесполезен при аварии.
Инструкция должна содержать порядок восстановления, список зависимых сервисов и способ связи с поддержкой поставщиков. Попросите нового администратора пройти её в отдельном тестовом окружении. Он запишет отсутствующие шаги и точное место, где понадобилась устная подсказка. Именно эти пробелы стоит закрыть до завершения передачи.
Контакты также проверяют действием. Новый ответственный должен понимать, от чьего имени обратиться к провайдеру и какие сведения подтверждают полномочия. Заранее найденный договор полезнее переписки о том, кто когда-то заказывал сервер.
Как зафиксировать передачу в один рабочий документ
У каждой строки реестра должны быть владелец проверки, время и результат. Формулировку «вроде всё работает» замените наблюдением: новый администратор вошёл в кабинет, увидел нужный проект, получил тестовое письмо. Для закрытого доступа укажите, что именно отозвано, включая сессии и отдельные ключи.
Оставшиеся вопросы вынесите в отдельный раздел с ответственным и сроком. Например, домен пока находится в процессе передачи, а автоматическая сборка временно использует старый технический токен. Такая запись требует согласованного следующего действия. Она не должна растворяться в общей отметке о завершении увольнения.
Для первого прохода назначьте встречу прежнего и нового ответственных с руководителем проекта. По каждому сервису последовательно подтвердите вход компании и закрытие ненужных разрешений. После встречи новый администратор самостоятельно публикует тестовое изменение и проверяет заявку. Результат этой проверки приложите к документу передачи.
Если карта доступов ещё не собрана, закажите проверку инфраструктуры сайта. Передайте список известных сервисов и рабочих контактов: с него можно начать поиск остальных зависимостей без массовой смены настроек в действующем проекте.
Читайте также
