Виртуальный сервер для агентства: как размещать сайты клиентов и не смешивать их риски

Для веб-студии или маркетингового агентства сервер VDS позволяет собрать клиентские сайты в одном управляемом окружении. Здесь можно разместить рабочие проекты, тестовые копии, базы данных и внутренние инструменты команды, не создавая отдельную инфраструктуру для каждого небольшого заказа. Но общий сервер не должен означать общие пароли, каталоги и ресурсы без ограничений. Иначе неудачное обновление одного плагина, зараженный файл или тяжелый импорт товаров затронет не один сайт, а всю группу.

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

Как разделить клиентские проекты внутри одного VPS

Каждый сайт стоит изначально воспринимать как отдельный объект. Он должен иметь собственные файлы, базу, журналы, настройки и границы использования ресурсов. Тогда его можно обновлять, переносить или восстанавливать независимо от соседних проектов.

Базовую схему размещения лучше стандартизировать и применять ко всем новым клиентам:

создавать отдельного системного пользователя, каталог и PHP-пул для каждого сайта;
использовать отдельную базу данных и аккаунт без доступа к чужим таблицам;
устанавливать лимиты памяти, процессорного времени, количества процессов и дискового пространства;
разделять рабочее и тестовое окружения;
вести отдельные журналы ошибок и запросов для каждого проекта;
не хранить пароли и ключи доступа в открытых файлах или общих таблицах команды.

Отдельный системный пользователь нужен не только для порядка в каталогах. Если несколько сайтов запускаются с одинаковыми правами, вредоносный скрипт на одном из них может читать или изменять файлы соседних проектов. В рекомендациях по защите WordPress также советуют ограничивать права файловой системы и не позволять процессам записывать там, где это не нужно.

Так же опасно подключать все сайты к базам данных через одного пользователя с широкими правами. Компрометация одного конфигурационного файла в таком случае открывает доступ к данным других клиентов. Для каждой CMS стоит создавать собственный аккаунт и позволять ему работать только с соответствующей базой.

Ограничивайте ресурсы отдельных сайтов

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

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

Выдавайте доступ только к нужному проекту

Общий root-пароль, который знают все разработчики и подрядчики, лишает агентство контроля. Невозможно установить, кто вносил изменения, быстро закрыть доступ одному человеку или ограничить его работу конкретным сайтом.

Для управления доступами стоит ввести несколько правил:

выдавать персональные SSH-ключи вместо одного пароля для всей команды;
не предоставлять root-доступ, если специалисту достаточно прав на отдельный каталог;
вести перечень активных доступов с датой выдачи и ответственной персоной;
удалять аккаунты и ключи после завершения работ;
раз в квартал проверять, кто до сих пор имеет доступ к серверу и панелям управления;
использовать двухфакторную аутентификацию для аккаунтов с расширенными правами.

Внешнему SEO-специалисту обычно нужны CMS, аналитика и поисковые консоли, но не файловое окружение всего VPS. Контент-менеджеру не нужен доступ к базе, а разработчик одного сайта не должен видеть каталоги других клиентов. Это соответствует принципу наименьших привилегий: пользователь получает только те права, без которых не может выполнить свою работу.

Защищайте staging не слабее рабочего сайта

Если staging размещен в одном аккаунте с другими сайтами, его взлом может открыть доступ не только к тестовой копии. Злоумышленник может добраться до соседних каталогов, найти конфигурационные файлы с паролями или изменить файлы других проектов.

Поэтому доступ к staging стоит ограничить паролем, IP-адресами или частной сетью. Запрет индексации в robots.txt от сторонних посетителей не защищает.

Также проверьте интеграции: тестовая версия не должна отправлять реальные письма, проводить платежи, создавать сделки в CRM или изменять остатки товаров.

Как поддерживать инфраструктуру после запуска

Хорошо разделить сайты на старте недостаточно. Количество клиентов растет, в проектах появляются новые модули, меняются подрядчики и графики обновлений. Без регулярного контроля даже аккуратно организованный VPS постепенно превращается в цифровые джунгли, где никто не знает, какие процессы работают и кому принадлежат доступы.

Настройте отдельное резервирование для каждого сайта

Одна резервная копия всего VPS удобна для восстановления сервера после полной аварии, но плохо подходит для ежедневной работы агентства. Если из-за неудачного обновления сломался один проект, откатывать вместе с ним еще пятнадцать исправных сайтов нельзя.

Рабочая схема резервирования должна учитывать:

отдельные копии файлов и баз данных для каждого клиента;
частоту копирования в зависимости от темпа обновления информации;
хранение хотя бы одной копии вне основного VPS;
шифрование архивов с персональными данными;
автоматический контроль завершения задач и размера файлов;
периодическое тестовое восстановление на чистом окружении.

Частоту резервирования определяют не по размеру сайта, а по объему информации, которую допустимо потерять. Корпоративному ресурсу, где новости выходят несколько раз в месяц, может хватить ежедневной копии. Для магазина с постоянными заказами один бэкап в сутки уже означает риск потерять значительную часть операций.

Отслеживайте, какой сайт создает пиковую нагрузку

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

Настройте уведомления о пиках CPU и памяти, заполнении диска, ошибках 5xx и увеличении времени ответа. Когда найдете источник нагрузки, остановите проблемный процесс и проверьте логи, плагины, cron и запросы к базе.

Если нагрузка вызвана ошибкой, ее нужно устранить. Если сайт действительно требует больше ресурсов, ограничьте его потребление или перенесите на отдельный виртуальный сервер, чтобы он не влиял на других клиентов.

Ведите техническую карточку каждого проекта

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

Полезно также отметить, какие процессы создают наибольшую нагрузку. Если известно, что магазин ежедневно в 03:00 импортирует каталог, команде не придется каждый раз расследовать короткий скачок использования CPU. А если нагрузка появилась в другое время, ее уже можно рассматривать как отклонение.

Техническую карточку следует обновлять после изменения серверной конфигурации, подключения новой интеграции или передачи проекта другой команде. Это упрощает поддержку и сокращает время восстановления после ошибки.

Когда клиентский сайт нужно вынести на отдельный сервер

Увеличивать конфигурацию всего VPS из-за одного тяжелого сайта не всегда выгодно. Агентство начинает оплачивать дополнительные ресурсы для всей группы, хотя потребляет их преимущественно один клиент. В такой ситуации логичнее отделить проект.

Простой проекта имеет высокую цену

Небольшой сайт-визитка и интернет-магазин, через который проходит большинство продаж компании, не должны иметь одинаковую модель размещения только потому, что оба работают на WordPress. Для критического сервиса важны отдельное резервирование, собственный запас ресурсов и возможность проводить технические работы независимо от других клиентов.

Для большого магазина, портала или системы с значительными объемами данных следующим этапом может стать аренда выделенного сервера. Однако решение не стоит привязывать к количеству доменов. Десятки простых сайтов иногда требуют меньше ресурсов, чем один каталог со сложными фильтрами, поиском, синхронизацией остатков и постоянной обработкой файлов.

Проект регулярно забирает значительную часть ресурсов

Если один магазин использует половину памяти VPS в обычный день, во время распродажи, рекламной кампании или массового импорта запаса уже не будет. Перенос лучше запланировать до пикового периода, оставив время на тестирование, синхронизацию базы и обновление DNS.

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

Сайту нужно особое программное окружение

Один клиент может требовать другой версии системных библиотек, собственного веб-сервера, нестандартных модулей или отдельного графика обновлений. Подстраивать под него общий VPS рискованно: изменение конфигурации способно нарушить работу остальных сайтов.

Отдельное окружение также уместно, когда клиент хочет иметь административный доступ. Выдавать его на сервер, где размещены сторонние проекты, нельзя даже при условии хороших отношений и подписанных соглашений.

Один VPS может годами оставаться удобным центром для клиентских сайтов. Стабильность зависит не от максимального запаса мощности, а от правил, по которым агентство создает проекты, выдает доступы, настраивает резервные копии и реагирует на рост нагрузки. Когда эти процессы описаны и выполняются последовательно, проблема одного клиента не превращается в общую аварию.