Передача сайта новому подрядчику: технический паспорт и чек-лист доступов
Передача сайта новому подрядчику завершается тогда, когда новая команда может выполнить согласованные задачи поддержки: проверить состояние, выпустить изменение, найти ошибку и восстановить нужную функцию. Получение архива и вход в административную панель — только часть этой работы. Для эксплуатации нужны сведения о компонентах, доступах, зависимостях и принятых процедурах.
Типичная сложность обнаруживается после смены исполнителя: код передали, но отправка писем связана с чужим аккаунтом; резервная копия есть, но никто не проверял восстановление; уведомления продолжают приходить бывшему специалисту. Эти пробелы удобно выявить заранее через технический паспорт сайта и проверяемый чек-лист приёмки.
Ниже — практическая схема для сайта услуг, магазина и небольшого веб-приложения. Она позволяет принять поддержку на существующей инфраструктуре. Таблицы и учебный пример можно адаптировать под проект; конкретные действия выполняют в пределах согласованных полномочий и без воздействия на реальные клиентские операции.
Сначала согласуйте результат и границы передачи
Запишите, что именно принимает новая команда: приложение, хостинг, обновления CMS, интеграции, формы, резервное копирование или только часть этих задач. Если владелец считает поддержку полной, а исполнитель отвечает только за контент, даже аккуратно собранные доступы не устранят разрыв ожиданий.
В модели передачи эксплуатационной ответственности Google SRE предусмотрены оценка готовности, обучение и постепенное принятие задач. Для небольшого сайта этот подход можно сократить до перечня систем, совместного разбора и нескольких практических проверок. Важен подтверждённый результат каждой проверки.
Назначьте представителя владельца, передающего специалиста и принимающего исполнителя. Согласуйте дату перехода, период доступности прежней команды для вопросов и место фиксации пробелов. До подтверждённой передачи должно быть понятно, кто реагирует на сбои и кто вправе изменять рабочую систему.
Отдельно перечислите работы, которые пока не входят в приёмку. Например, сопровождение учётной системы может оставаться за другой компанией. Укажите её контакт и границу взаимодействия, чтобы новый подрядчик мог отличить собственную задачу от обращения к владельцу зависимости.
Составьте реестр компонентов и внешних зависимостей
Реестр отвечает на вопросы «из чего состоит сайт», «где это находится» и «кто управляет». Начните с пути важного действия: посетитель открывает страницу, отправляет форму, приложение сохраняет обращение и передаёт его менеджеру. Для каждого этапа запишите используемый компонент и зависимость.
| Часть проекта | Что зафиксировать | Что легко пропустить |
|---|---|---|
| Домен и DNS | Провайдеры, административный владелец, нужные зоны, контакт поддержки | Записи для почты, проверки владения и внешних сервисов |
| Размещение | Панель, проект, окружения, ответственные, ограничения тарифа | Отдельные хранилища файлов, прокси и CDN |
| Приложение | CMS или фреймворк, версии среды, расположение исходников и конфигурации | Локальные правки, не попавшие в репозиторий |
| Данные | Базы, файловые каталоги, способы копирования и восстановления | Загрузки пользователей и данные вне основной базы |
| Фоновые процессы | Расписание, очереди, обработчики, назначение задач | Запуск с личного компьютера прежнего исполнителя |
| Интеграции | CRM, почта, платежи, доставка, аналитика, назначение подключений | Личные токены и уведомления в старые каналы |
Не превращайте реестр в перечень всех файлов. Для поддержки важнее связи: какое действие перестанет работать при отказе компонента, кто может его проверить и где находится инструкция. Отметьте отдельно production и тестовые окружения, чтобы одинаковые названия не приводили к вмешательству не в тот проект.
Оставьте управление аккаунтами под контролем бизнеса
Проверьте, кто может управлять доступом к каждому ключевому сервису и восстанавливать его. Аккаунт, который существует только на личной почте бывшего подрядчика, создаёт зависимость даже при наличии рабочего пароля. Владелец бизнеса должен иметь предусмотренный платформой контроль: организацию, роль владельца либо другой документированный способ управления.
Новых специалистов добавляют персональными пользователями с нужными ролями. В рекомендациях OWASP по авторизации используется принцип минимально необходимых привилегий. Для приёмки это означает практическое разделение: просмотр журналов, публикация изменений и управление пользователями не обязательно должны быть разрешены всем одинаково.
Составьте матрицу: сервис, назначенный сотрудник, роль, разрешённые действия, основание и срок пересмотра. Отдельно учтите машинные подключения — ключи развёртывания, сервисные учётные записи, токены интеграций. Они могут продолжать работать независимо от персонального входа разработчика.
Если платформа поддерживает только ограниченную модель доступа, зафиксируйте это как ограничение и согласуйте её штатный способ передачи управления. Не пересылайте личную учётную запись целиком и не считайте общую пару логин–пароль полноценной заменой персональных ролей.
Как передать доступ без отключения MFA и таблицы паролей
Каждый участник настраивает собственный разрешённый способ входа и второй фактор. Для критичных сервисов проверьте, кто контролирует восстановление доступа и где находится утверждённая аварийная процедура. Она должна работать при потере основного устройства, но не обходить защиту произвольным обращением в чат.
OWASP отдельно разбирает восстановление MFA и отмечает необходимость учитывать безопасность выбранного механизма. Возможности отличаются у платформ: это могут быть резервные коды, дополнительные факторы или проверка владельца поддержкой. Запишите предусмотренный порядок и ответственного, а секретные материалы храните в предназначенном для них защищённом месте.
В техническом паспорте достаточно ссылки на объект хранилища секретов и указания, кому разрешён доступ. Сам пароль, API-токен, закрытый ключ или резервный код в таблицу не вставляют. Даже если документ сейчас доступен двум людям, позже его могут отправить в задачу, выгрузить или передать следующему исполнителю.
Не используйте отключение MFA как способ ускорить приёмку. Проверьте обычный вход нового пользователя и согласованный резервный сценарий без блокировки действующего владельца. Одноразовые материалы, использованные при проверке, учитывайте по правилам конкретной платформы; не оставляйте отметку «резерв проверен» без понимания, что осталось доступно после теста.
Технический паспорт сайта: шаблон для заполнения
Паспорт должен помогать найти достоверную информацию, а не дублировать всю документацию. Ниже — заготовка. Поля в квадратных скобках заменяют проверенными данными; ссылки ведут на материалы с подходящими правами доступа. Сам паспорт тоже содержит внутреннюю информацию и не предназначен для публичной публикации.
| Раздел | Что заполнить |
|---|---|
| Идентификация | [Название проекта], [основные адреса], [владелец], [дата проверки паспорта] |
| Важные действия | [Заказ или заявка], [условие успеха], [допустимый срок], [владелец процесса] |
| Окружения | [Production], [стенд], [назначение], [различия и ограничения] |
| Компоненты | [Ссылка на реестр], [версии среды], [внешние зависимости] |
| Управление доступом | [Владелец аккаунта], [матрица ролей], [место секретов без их значений], [порядок восстановления входа] |
| Исходники и выпуск | [Репозиторий], [идентификатор рабочей версии], [инструкция сборки и выпуска], [кто согласует] |
| Возврат и восстановление | [Процедура], [ограничения совместимости], [копии и срок хранения], [последняя проверка] |
| Наблюдение | [Проверки], [журналы], [получатели уведомлений], [контроль свежести данных] |
| Поддержка | [Часы работы], [основной и резервный контакты], [ссылка на регламент инцидентов] |
| Открытые вопросы | [Пробел], [влияние], [временная мера], [ответственный], [срок устранения] |
| Приёмка | [Проверенные действия], [доказательства], [принятая область], [дата перехода ответственности] |
У каждой существенной записи должен быть источник: просмотренная настройка, подтверждение владельца или результат проверки. Формулировку «кажется, резервные копии делает хостинг» оставьте открытым вопросом. Она не равна сведениям о расположении копии, её составе и возможности восстановления.
Проверяйте доступ полезным и безопасным действием
Успешный вход подтверждает аутентификацию, но не достаточность прав для поддержки. Пользователь может видеть панель и при этом не иметь доступа к нужному проекту, журналам или резервным копиям. Для каждой необходимой роли выберите действие, которое показывает её пригодность без изменения рабочей системы.
| Область | Пример проверки | Что записать |
|---|---|---|
| Репозиторий | Прочитать код согласованной версии и открыть инструкцию сборки | Проект, версия, доступные права |
| Размещение | Открыть нужное окружение и просмотреть параметры без изменения | Подтверждённое окружение и ограничения роли |
| Журналы | Найти заранее выбранное безопасное диагностическое событие | Источник, время, способ повторить поиск |
| Резервные копии | Проверить состав и дату копии; выполнить отдельную проверку восстановления на стенде | Охваченные данные и результат испытания |
| Выпуск | Собрать и развернуть согласованную версию в тестовом окружении | Исполнитель, версия, результат проверки |
| Мониторинг | Найти текущую проверку и получить согласованное учебное уведомление | Получатель, маршрут доставки, время результата |
Не доказывайте право на удаление удалением рабочего объекта. Для привилегированных действий проверьте назначение роли и, где это возможно, используйте отдельный тестовый ресурс. Если безопасная практическая проверка недоступна, укажите способ проверки и остаточную неопределённость, а не ставьте безусловное «готово».
При сверке журналов и данных не собирайте лишнюю клиентскую информацию в отчёт. Обычно достаточно идентификатора тестового события и подтверждения результата. Доступ к данным предоставляют по задаче, а не автоматически всем участникам передачи.
Передайте воспроизводимый выпуск и понятный возврат
Новая команда должна знать, из чего получена работающая версия сайта. Сопоставьте исходники, сборку и production. Если прежний специалист менял файлы прямо на сервере, зафиксируйте эти отличия: запуск стандартного выпуска может затереть ещё не перенесённую функциональность.
Инструкция должна описывать необходимые версии среды, зависимости, источник конфигурации, последовательность сборки, проверки и публикации. Укажите, какие шаги выполняет автоматизация, а какие остаются ручными. Секретные значения не включают в команды, примеры и общие журналы передачи.
В главе Google SRE о надёжном выпуске продуктов подчёркивается польза конкретных и применимых проверок. Для приёмки сайта это можно проверить просто: новый исполнитель по инструкции самостоятельно выпускает согласованную версию на стенде и объясняет критерий успешности.
Отдельно опишите возврат: какая версия доступна, какие изменения данных совместимы с ней и что делать с операциями, начатыми после выпуска. Возврат кода не всегда отменяет миграцию базы или внешний платёж. Возможность восстановления подтверждают для конкретного сценария, не общей фразой «есть кнопка отката».
Докажите пригодность резервной копии к восстановлению
Список архивов полезен, но не отвечает на вопрос, можно ли вернуть из них сайт. Уточните состав: база данных, пользовательские файлы, конфигурация, необходимые ключи и внешние зависимости. Частоту и хранение копий сопоставьте с требованиями проекта к потере данных и сроку восстановления.
Приёмочное восстановление выполняют в разрешённом изолированном окружении. До запуска отключите реальные отправки писем, CRM-операции, платежи, расписания и другие побочные действия восстановленной копии либо переведите их на согласованные тестовые зависимости. Используйте разрешённый состав данных и необходимые меры их защиты.
Проверьте не только распаковку, но и запуск приложения, наличие нужных данных и ключевое действие в пределах тестового сценария. Запишите использованную копию, дату, выполненные шаги и обнаруженные ограничения. Производственный сайт ради приёмки не удаляют и не заменяют восстановленной копией.
Если проверка не состоялась, не приравнивайте наличие файла к готовности восстановления. Создайте конкретный открытый пункт: что мешает, кто устраняет и какие действия до этого ограничены. Приёмка может быть частичной, если её границы явно поняты владельцем и исполнителем.
Передайте мониторинг, получателей и историю проблем
Сверьте, какие адреса и действия контролируются, что означает успешный результат и куда приходит предупреждение. Новый подрядчик должен уметь отличить сбой сайта от устаревших измерений, найти историю и понять, какие паузы или исключения сейчас действуют.
Проверьте доставку учебного сообщения по согласованному маршруту. Адрес нового специалиста в настройках ещё не подтверждает получение уведомления. Порядок смены получателей определяйте так, чтобы в переходный момент был известен действующий ответственный. Старый контакт удаляют после подтверждения новой схемы и завершения согласованного периода участия.
История передачи должна содержать значимые инциденты, временные обходные меры, повторяющиеся ошибки и незавершённые технические задачи. Не требуется выгружать все чаты: полезнее короткий перечень симптомов со ссылками на подтверждённые решения и действующие инструкции.
Для каждого используемого сервиса уточните штатные возможности добавления участников, сохранения истории и смены получателей. Если перенос между аккаунтами не предусмотрен, согласуйте доступный вариант отдельно. Существование такой функции у одной платформы не подтверждает её наличие у другой.
Как завершить переход и закрыть старые доступы
Сначала подтвердите, что новая схема работает и бизнес сохраняет управление. Затем по согласованному плану прекращают ненужные полномочия прежних участников. Проверяют персональные роли, активные сеансы, ключи подключения, интеграции и автоматизацию, которая могла использовать учётные данные уходящего специалиста.
OWASP описывает жизненный цикл секретов, включая ротацию и отзыв. Для передачи сайта практический вывод — знать назначение каждого машинного секрета и его потребителей. Удаление пользователя не гарантирует, что отдельно созданный токен или ключ перестал действовать.
Если секрет доступен прежней команде и больше не должен предоставлять ей возможность подключения, запланируйте замену и отзыв старого. Учтите зависимости: сначала настройте допустимый способ перехода, проверьте работу потребителей, затем завершите отзыв. Если платформа не поддерживает одновременные ключи, согласуйте своё окно и процедуру.
Не оставляйте переходный доступ бессрочно. Запишите основание, ограниченную роль, дату окончания и владельца проверки. После завершения сверяйте фактическое состояние с реестром, а не только с отправленным письмом о прекращении работ.
Что делать, если часть сведений не передали
Пробелы удобно разделить по влиянию на работу. Отсутствие описания редко используемого отчёта и отсутствие доступа к восстановлению приложения требуют разных решений. Для каждого пункта запишите, какая операция поддержки невозможна, какой процесс остаётся под риском и кто может предоставить недостающую информацию.
Не заполняйте неизвестные поля предположениями. Если рабочая версия не сопоставлена с репозиторием, так и отметьте. Если прежний специалист сообщил о резервной копии, но её нельзя найти, сохраните это как неподтверждённое сведение. Новый подрядчик сможет восстановить часть документации через разрешённый просмотр настроек и собственные проверки, однако результат каждой такой работы должен иметь источник.
При недоступности административного владельца используйте официальный порядок восстановления контроля у соответствующей платформы. Представитель бизнеса готовит необходимые подтверждения, а новый исполнитель помогает собрать технические сведения в пределах своей роли. Обход защиты или использование чужой личной учётной записи не должны становиться частью процесса передачи.
Если нет исходников отдельного модуля или понятной процедуры его обновления, укажите ограничения сопровождения этого компонента. Решение может состоять в получении материалов, подключении его владельца или отдельном проекте замены. Само наличие работающей страницы не означает, что новый исполнитель способен безопасно изменить любой её участок.
На период устранения пробела полезна конкретная временная мера: например, не выпускать изменения в неизвестный компонент, сохранить предусмотренную связь с прежним специалистом или добавить наблюдение за важным действием. У меры должны быть владелец и срок пересмотра. Так ограниченная приёмка остаётся управляемым решением, а не бессрочным отказом от проверки.
Чек-лист приёма сайта на поддержку
Для каждого пункта используйте состояния «проверено», «не проверено» и «ограничение принято». Последнее требует описания влияния, ответственного и срока следующего действия. Такой формат помогает принять реальную область поддержки без скрытых обещаний.
- Владелец и новый исполнитель согласовали компоненты, задачи и часы поддержки.
- Ключевые аккаунты контролируются бизнесом, персональные роли и восстановление входа проверены.
- Технический паспорт отражает актуальное окружение, версии и зависимости.
- Исходники сопоставлены с рабочей версией; существенные отличия зафиксированы.
- Новый исполнитель выполнил разрешённые проверки необходимых прав.
- Выпуск, возврат и восстановление проверены в согласованной области либо отмечены как открытые ограничения.
- Получатели мониторинга подтверждены, известные проблемы и временные меры переданы.
- Для оставшихся пробелов назначены владельцы, сроки и временные ограничения.
- Зафиксированы момент перехода ответственности и план прекращения прежних доступов.
Учебный пример: агентство принимает сайт услуг. Доступ к CMS и коду подтверждён, но отправка писем использует личный токен прежнего разработчика, а восстановление пользовательских файлов не проверено. Корректный результат — перечень принятых задач и два открытых пункта с владельцами. Подпись «сайт полностью передан» до их оценки скрыла бы реальные зависимости.
Подтверждение приёмки должно называть проверенные действия и оставшиеся ограничения. После перехода назначьте владельца паспорта: обновление интеграции, способа выпуска или состава команды должно отражаться в документе. Так следующая передача начинается с актуальной основы, а не с восстановления знаний по переписке.
Подключите SiteGuard для внешнего HTTP-контроля доступности сайта и включите проверяемые URL в технический паспорт.