Начните с эксплуатационных требований
До сравнения конфигураций соберите для каждого проекта стек приложений, базу данных, загрузки, запланированные задачи, интеграции и ожидаемые изменения. Определите, кому нужен доступ к контенту, доступ к развёртыванию и администрирование хоста. Это разные задачи. Клиенту, редактирующему страницу, может быть нужна только учётная запись приложения; подрядчику, обслуживающему операционную систему, нужны существенно более широкие полномочия.
Также зафиксируйте допустимое окно обслуживания, кто одобряет простой, где хранятся копии восстановления и кто платит за эксплуатационную работу. Отметьте любое требование клиента об отдельном сервере или учётной записи как ограничение решения. Таблица ресурсов не может урегулировать требование о владении или доступе.
- Назовите основного оператора и замену для каждого проекта.
- Перечислите общие зависимости: доступ к DNS, учётные данные развёртывания, сервисы баз данных и места назначения резервных копий.
- Отметьте неизвестные требования для решения клиента перед принятием обязательств по соглашению.
Выберите границу доступа до размера сервера
OWASP рекомендует предоставлять только те разрешения, которые необходимы для выполнения рабочих обязанностей, и проверять, что предполагаемые ограничения соблюдаются. Примените этот принцип к хостинг-плану: используйте отдельные учётные записи, учётные данные приложений для конкретных проектов и документированный путь развёртывания. Каталог, названный в честь клиента, — это организационное удобство, а не политика доступа.
Если вы используете Docker, относитесь к доступу к его демону как к ответственности на уровне хоста. Документация по безопасности Docker объясняет, что доверенный оператор демона может монтировать и изменять файлы хоста. Поэтому предоставление внешнему подрядчику неограниченного контроля над Docker плохо сочетается с хостом, содержащим данные другого клиента.
Отдельные экземпляры VPS позволяют раздельно администрировать операционную систему и принимать решения о выпуске. Они по-прежнему требуют тщательных разрешений внутри каждого проекта. Общие учётные данные агентства или общая учётная запись развёртывания могут воссоединить риски, которые вы намеревались разделить.
Проработайте два вымышленных клиентских брифа
Приведённые ниже клиенты — вымышленные примеры, а не истории реальных заказчиков. Агентство ведёт оба проекта сегодня, но их требования к доступу и срокам различаются.
Совместное размещение этих двух проектов сделало бы доступ подрядчика Morrow и график запуска частью операционного риска Aster. Решение о раздельных серверах следует из этих ограничений; оно не утверждает, что Morrow нуждается в определённом количестве процессоров или что Aster свободен от рисков.
Прокрутите по горизонтали, чтобы увидеть все столбцы таблицы.
| Фактор решения | Aster Furniture: сайт-брошюра | Morrow Workshops: сайт регистрации |
|---|---|---|
| Нагрузка | Публичные страницы и периодические обновления контента | Формы, база данных и запланированные экспорты регистраций |
| Доступ | Клиент редактирует контент; агентство развёртывает | Внешнему разработчику требуется администрирование хоста |
| Обслуживание | Согласованное вечернее окно | Никаких запланированных изменений во время запуска бронирования |
| Влияние инцидента | Временный простой страницы можно обсудить | Потерянные или дублированные заявки требуют расследования |
| Требование к выходу | Экспортировать контент и перенести приложение | Передать независимо управляемую среду |
| Предварительное решение | Рассмотреть возможность совместного использования с совместимыми сайтами агентства | Использовать отдельный VPS и отдельные учётные данные проекта |
Сравните полную стоимость обоих вариантов
Создайте два бюджетных варианта с помощью текущего конфигуратора: одну общую конфигурацию и одну конфигурацию для каждого проекта. Для каждого отдельно укажите общую стоимость хостинга за выбранный период, регулярные опции, внешние сервисы и время на обслуживание агентством. Не копируйте старую цену в бриф клиента. Зафиксируйте, когда была подготовлена конфигурация и кто утвердил распределение.
Для общего хоста согласуйте, как клиенты делят фиксированные расходы и что происходит, когда один уходит или требует обновления. Равные доли просты, но могут не подходить, когда один проект вызывает большую часть роста хранилища или операционной работы. Отдельные серверы делают атрибуцию яснее, добавляя отдельные задачи по установке обновлений, мониторингу и восстановлению.
Оставляйте запас ресурсов для выпусков, резервных копий и временных работ. Контейнеры Docker по умолчанию не имеют ограничений по процессору или памяти; настройте соответствующие лимиты и оцените совокупную нагрузку. Один список контейнеров не демонстрирует жизнеспособный бюджет ресурсов.
Сделайте обслуживание и восстановление специфичными для проекта
На общем хосте перезагрузка операционной системы затрагивает каждый размещённый проект. Внесите обслуживание хоста в общий календарь и определите, кто связывается с каждым клиентом. По возможности разделяйте выпуски приложений и избегайте планирования экспорта данных одного проекта во время важного запуска другого.
Заметки о восстановлении должны определять базу данных проекта, файлы, конфигурацию и необходимые учётные данные, не копируя секреты в заметки. Планируйте восстановление на отдельный тестовый ресурс. Восстановление всего общего хоста в качестве первого действия может заменить здоровые изменения, принадлежащие другому клиенту.
При отдельных экземплярах VPS фиксируйте общие сервисы, которые остаются. Общая учётная запись DNS, назначение резервных копий или оператор всё ещё могут влиять на оба проекта. Разделение серверов не является доказательством независимой физической инфраструктуры или гарантированной доступности.
Проверьте схему и задайте триггеры пересмотра
Перед принятием соглашения попросите второго оператора проверить, что идентификатор проекта может выполнять назначенную работу и не может читать файлы, резервные копии или секреты другого проекта. Проверьте разрешения базы данных и развёрнутые учётные данные, а также экраны приложения. Используйте безвредные тестовые данные в согласованной среде; не исследуйте производственные данные другого клиента.
Зафиксируйте результат как принятый, отклонённый или ожидающий указанного исправления. Если изоляцию не удаётся продемонстрировать, сузьте доступ или переместите проект перед предоставлением более широких разрешений. Успешный ответ главной страницы не является проверкой доступа или восстановления.
- Ведите запись решения с выбранной схемой, утверждённым распределением затрат, владельцами и нерешёнными вопросами.
- Пересмотрите выбор, когда присоединяется внешний администратор, меняется окно запуска, растёт хранилище или клиент готовится уйти.
- Используйте руководство по ответственностям, чтобы превратить технический выбор в операционное соглашение.
Источники и проверка
Технические ссылки были проверены 12 сентября 2026 года. Примеры являются планировочными упражнениями; документация упомянутого программного обеспечения не подтверждает возможности услуг PrivateHostLab.