Агентство доросло до тридцати клиентских сайтов: пора съезжать с чужих хостингов

MAATRIX

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

Экономика разбросанной инфраструктуры

Типичная картина выросшего органически агентства: первый клиент когда-то сам выбрал shared-тариф у регионального хостера, второй пришёл с уже купленным VDS у другого провайдера, третий настоял на конкретной панели, потому что «так делал предыдущий подрядчик». К тридцатому клиенту за спиной десяток разных аккаунтов: где-то ISPmanager, где-то cPanel, где-то голый VDS без панели, где-то WordPress-хостинг с урезанной админкой без SSH.

Прямые деньги считаются легко: тридцать мелких тарифов почти всегда дороже суммарно, чем один сервер, который тянет тридцать небольших сайтов. Мелкий тариф редко утилизируется больше чем на 10-20% по CPU и памяти — сайт-визитка или средний Bitrix/WordPress с умеренным трафиком не грузит постоянно и одно ядро современного сервера. Вы платите за каждый тариф отдельно, оплачивая простаивающие ресурсы тридцать раз подряд.

Но главная статья потерь — не деньги за тарифы, а рабочее время команды на переключение между площадками (разбирается ниже). Если у вас уже больше десяти клиентских проектов на разных хостингах, стоит прикинуть, во что обходится час работы разработчика или админа, который тратится на переключение контекста между чужими панелями, и умножить на число инцидентов и рутинных задач в месяц. У большинства агентств на этом этапе цифра уже сопоставима с арендой собственного сервера, который закрыл бы всю эту рутину разом. Три клиента на трёх хостингах — не повод переезжать; проблема масштабируется нелинейно, и к пятнадцати-двадцати проектам разброс начинает буквально мешать работать быстро.

Переключение между панелями и диагностика инцидентов

Типичная неделя саппорт-инженера в агентстве с разбросанными хостингами: клиент А жалуется на медленную загрузку — ищем логи nginx в ISPmanager; клиенту Б нужен SSL — ищем раздел Let's Encrypt в cPanel, у этого хостера он называется иначе; у клиента В ошибка 500, а хостинг вообще без SSH — только FTP и веб-файлменеджер, логи смотреть неоткуда, остаётся писать в поддержку хостера и ждать.

Каждое такое переключение — это не только клик по кнопкам, но и вспоминание, где что лежит именно у этого хостера, разлогинивание из одной панели и вход в другую (часто с отдельным 2FA), адаптация к чужому интерфейсу. Разработчик, который десятки раз в неделю прыгает между разными окружениями, теряет на этом ощутимую долю дня — конкретную цифру каждое агентство должно прикинуть по своим тикетам, но это заведомо не «пять минут», если считать ещё и восстановление рабочего фокуса после.

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

При реальном инциденте разница ощущается острее всего. На собственном сервере вы заходите по SSH, смотрите docker compose logs или journalctl, htop — и за пару минут понимаете, в чём дело. На shared-хостинге без SSH системных логов вообще не видно, максимум логи PHP-ошибок через веб-панель; о том, что сайт лёг из-за соседа по общему CPU (этот сценарий разобран в статье про соседей по shared-хостингу), вы можете не узнать, пока хостер сам не признает проблему. Хуже всего — субаккаунт с урезанными правами, откуда эскалация в поддержку хостера идёт часами, пока клиент уже звонит вам, а не хостеру.

Безопасность и бэкапы, которые невозможно унифицировать

На разбросанной по хостингам инфраструктуре применить единую политику бэкапов и безопасности ко всем проектам физически невозможно — у вас просто нет одинаковых рычагов управления на всех площадках. На одном хостинге бэкапы делает сам хостер по непрозрачному расписанию, и вы узнаёте, что снапшот недельной давности, только когда он понадобился. На другом бэкапов нет вообще, и приходится ставить плагин уровня WordPress с выгрузкой во внешнее хранилище — если это вообще возможно у конкретного клиента. На VDS без панели бэкап настраивается руками через cron и restic, но индивидуально для каждого клиента, если вообще есть время это сделать.

В итоге у одних клиентов бэкапы надёжные и проверенные, у других — «есть в теории, но восстановление никто не тестировал», у третьих не бэкапится ничего, кроме того, что хостер делает для себя без гарантий клиенту. Это неприемлемо, если агентство отвечает перед клиентами за сохранность сайтов, но закрыть это системно на текущей архитектуре нельзя — только точечно, хостинг за хостингом, тратя те же дефицитные часы.

То же с безопасностью: обновления пакетов, файрвол, вход по SSH-ключам вместо паролей, мониторинг подозрительной активности — на своём сервере это делается один раз и распространяется на все сайты общим скриптом или плейбуком Ansible. На тридцати разных хостингах доступа к уровню ОС часто просто нет, а там, где есть — настраивать приходится тридцать раз по отдельности, и неизбежно где-то забудете или отложите.

Экономика перехода: выгода и риски консолидации

Экономия на масштабе здесь реальна: один сервер с достаточным запасом по CPU, RAM и диску почти всегда дешевле в пересчёте на сайт, чем тридцать отдельных мелких тарифов — при условии, что сайты небольшие и не конкурируют жёстко за ресурсы одновременно (это стоит проверить на реальных метриках, а не на глаз — методика разобрана в статье про то, как делить сервер по нагрузке, а не по красоте). Конкретную конфигурацию под тридцать сайтов нужно считать по факту, но десятки лёгких сайтов на одном хорошо утилизированном сервере почти всегда дают заметную экономию против тридцати недогруженных отдельных тарифов.

Вторая часть выгоды — унификация процессов. Один скрипт бэкапа (например, restic с выгрузкой в S3-совместимое хранилище) по cron сразу для всех проектов. Один набор правил файрвола и fail2ban. Один процесс обновления PHP, MySQL, сертификатов Let's Encrypt через certbot с автопродлением для всех доменов разом. То, что раньше делалось тридцать раз вручную с разной вероятностью что-то забыть, теперь делается один раз и работает для всех.

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

Это не отменяет выгоду, но требует запаса отказоустойчивости: рабочий бэкап с проверенным восстановлением (не «бэкапы есть», а «мы хотя бы раз восстанавливали из них на тестовом стенде»), план перехода на резервный сервер на случай долгой недоступности основного, и разумное распределение — если клиентов уже около сотни, вероятно, стоит говорить о двух-трёх серверах, распределяя риск, а не об одной точке отказа для всего портфеля.

Практический ориентир: если у вас больше пятнадцати-двадцати активных проектов на разных площадках, и хотя бы половина — типовые сайты без экзотических требований к окружению (WordPress, 1С-Битрикс, статика, небольшие PHP/Node-приложения), консолидация почти наверняка окупается за первые несколько месяцев за счёт экономии времени команды, даже если аренда сервера номинально стоит примерно столько же, сколько раньше уходило суммарно на мелкие тарифы.

План миграции: волнами, а не разом

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

• Волна 1 — низкий риск. Два-три сайта с наименьшей критичностью: статические визитки, лендинги без оплаты. Здесь отрабатывается сама методика — как разворачивается окружение, как переносится база и файлы, как проверить работоспособность до переключения DNS.
• Волна 2 — средняя сложность. Сайты с базой данных и умеренной посещаемостью, но без прямых денежных операций: корпоративные сайты с формами, блоги, каталоги. Отрабатывается перенос БД без потери данных и настройка автоматических бэкапов сразу после переноса — новый сайт не должен ни дня жить без бэкапа.
• Волна 3 — высокая критичность. Интернет-магазины, сайты с онлайн-оплатой, проекты с SLA переносятся последними, когда процесс уже обкатан. Для них стоит держать окно технических работ и предупреждать клиента заранее.

Общий план миграции, включая инвентаризацию сервисов и сценарий отката, стоит формализовать письменно ещё до первой волны — на что обратить внимание, разобрано в статье про план миграции на новый сервер; тот же каркас применим здесь, просто повторяется тридцать раз с разной степенью критичности.

Отношения с клиентами — отдельная забота. Большинству не нужны технические детали: важно, что сайт продолжит работать. Формулировка вида «мы переносим обслуживание вашего сайта на нашу собственную защищённую инфраструктуру, это повысит скорость и надёжность, работы пройдут в такое-то окно с минимальным простоем» снимает большинство вопросов. Клиентам с прямым доступом к панели старого хостинга нужно заранее объяснить, что доступ изменится, и выдать новый.

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

Изоляция клиентов на общем сервере

Консолидация не должна означать «все сайты в одной куче, один процесс на всех, одна общая база MySQL». Это худший вариант архитектуры — он создаёт эффект «шумного соседа» уже внутри собственного сервера: баг или всплеск трафика на сайте клиента А кладёт сайт клиента Б, хотя формально они уже не делят чужой shared-хостинг.

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

Следующий уровень — контейнеризация: каждый сайт в собственном Docker-контейнере (или наборе — веб-сервер плюс база плюс кэш) даёт изоляцию процессов, сети и файловой системы почти бесплатно с точки зрения администрирования. docker compose down для одного клиента не трогает остальных, лимиты CPU и памяти через deploy.resources.limits не дают одному прожорливому сайту забрать ресурсы у соседей. Сравнение подходов к размещению нескольких сайтов на одном VPS — виртуальные хосты nginx против контейнерной изоляции — разобрано в статье про мультисайт на одном VPS.

Отдельно стоит продумать базы данных: общая MySQL «для всех сразу с разными схемами» экономит немного памяти, но означает, что тяжёлый запрос одного клиента съедает CPU и I/O у базы, которой пользуются все остальные. Практичный компромисс для тридцати небольших сайтов — отдельный контейнер БД на клиента с явными лимитами памяти, а не общий инстанс на всех. Бэкапы при этом остаются едиными по механике (один скрипт, одно расписание, единый внешний storage), но раздельными по данным — каждый клиент бэкапится в свой префикс, чтобы восстановление одного сайта не требовало разбирать общий архив.

Частые вопросы