- Опубликовано: 3 авг 2026
- 19
Когда виртуальный хостинг стал тесен: пора на VPS или ещё можно остаться
Часть 14 из 14 · Серия «Хостинг без магии»
Интернет-магазин несколько лет работает на виртуальном хостинге.
Сначала всё было просто:
- несколько тысяч товаров;
- обычная CMS;
- один импорт остатков ночью;
- десятки заказов в месяц;
- стандартная почта;
- ежедневные резервные копии.
Затем проект вырос.
Появились:
- интеграция с CRM;
- частое обновление цен;
- генерация документов;
- обмен с несколькими складами;
- очереди;
- поиск по большому каталогу;
- мобильное приложение;
- API;
- фоновые уведомления.
В часы нагрузки сайт периодически достигает лимита PHP-процессов. Импорт работает дольше своего интервала. Один внешний сервис иногда отвечает несколько секунд, занимая обработчики. Поддержка предлагает перейти на старший тариф.
Разработчик отвечает:
Нам уже давно нужен VPS. Виртуальный хостинг несерьёзный.
Владелец открывает тарифы VPS и видит:
4 vCPU
8 ГБ RAM
160 ГБ NVMe
root-доступ
Ресурсов заметно больше, чем на текущем тарифе. Цена выглядит приемлемо.
Но остаются вопросы:
- кто установит операционную систему;
- кто настроит веб-сервер;
- кто обновляет пакеты безопасности;
- кто следит за базой;
- кто организует резервные копии;
- кто перезапустит очередь ночью;
- кто заметит переполненный диск;
- кто восстановит сервер после аварии;
- что произойдёт во время отпуска единственного администратора.
Переход на VPS действительно может быть следующим правильным шагом.
Но не потому, что VPS «профессиональнее».
Он нужен, когда проекту требуется то, чего виртуальный хостинг принципиально не предоставляет, либо когда его измеренная нагрузка больше не помещается в разумные управляемые тарифы.
Главный вопрос заключительной статьи:
Проект упёрся в недостаточный тариф или в саму модель виртуального хостинга?
В первом случае часто достаточно оптимизации или перехода на старший план.
Во втором потребуется среда с большим контролем: управляемый VPS, собственный сервер, платформа приложений или облачная инфраструктура.
VPS и VDS: есть ли разница
На рынке используются оба названия:
- VPS — Virtual Private Server;
- VDS — Virtual Dedicated Server.
Провайдеры могут вкладывать в них разные маркетинговые смыслы, но на практике обе услуги обычно представляют собой виртуальную машину с собственной операционной системой.
Для выбора важнее не название, а конкретные характеристики:
- тип виртуализации;
- объём RAM;
- процессор;
- дисковые лимиты;
- наличие root-доступа;
- резервные копии;
- управление;
- политика нагрузки;
- возможность масштабирования;
- ответственность провайдера.
В этой статье будем использовать термин VPS как общий.
Виртуальный хостинг не является «младшим сервером»
Виртуальный хостинг и VPS — не просто два тарифа разной мощности.
Это разные модели обслуживания.
Виртуальный хостинг
Провайдер управляет общей серверной средой:
- операционной системой;
- веб-сервером;
- PHP;
- базами данных;
- изоляцией аккаунтов;
- системными обновлениями;
- SSL;
- частью резервного копирования;
- мониторингом инфраструктуры.
Клиент управляет сайтом внутри предоставленных возможностей.
VPS
Клиент получает собственную операционную систему.
Если услуга неуправляемая, он отвечает практически за всё внутри неё:
- установку и обновление Linux;
- nginx или Apache;
- PHP-FPM;
- базу данных;
- Redis;
- firewall;
- SSH;
- TLS;
- резервное копирование;
- мониторинг;
- ротацию логов;
- защиту;
- восстановление.
VPS даёт свободу, но не превращает эту работу в автоматическую.
Первый вопрос: что именно не помещается
Плохое обоснование:
Сайт стал большой.
Полезное обоснование:
В рабочие дни с 11:00 до 15:00
аккаунт достигает 100% лимита PHP-процессов.
Среднее время одного запроса после оптимизации:
250–400 мс.
CPU:
80–100%.
База:
самые медленные запросы оптимизированы.
Текущий тариф:
максимальный доступный shared-план.
Для следующего этапа нужны:
40–60 PHP workers и отдельная очередь.
В таком описании понятны:
- ресурс;
- время проблемы;
- проведённые проверки;
- предел текущего решения;
- требования следующей среды.
Без этих данных VPS покупается на основании ощущения.
Четыре типа ограничений
Причины перехода удобно разделить на четыре группы.
1. Не хватает ресурсов
Проект регулярно упирается в:
- CPU;
- память;
- PHP-процессы;
- I/O;
- соединения с базой;
- размер базы;
- inode;
- время выполнения.
2. Не хватает функций
Проекту нужны:
- постоянные workers;
- Redis-сервер;
- WebSocket;
- Supervisor;
- Docker;
- системный пакет;
- собственная версия базы;
- отдельный поисковый движок;
- открытый сетевой порт;
- нестандартная конфигурация nginx.
3. Не хватает изоляции и контроля
Нужны:
- собственные правила безопасности;
- отдельный системный пользователь;
- выделенная конфигурация;
- контроль обновлений;
- закрытая сеть;
- предсказуемое окружение;
- специальные требования к доступу и журналированию.
4. Не устраивает экономика
Старшие тарифы виртуального хостинга, внешние сервисы и обходные решения вместе стоят дороже управляемого VPS, а проект уже имеет специалиста по инфраструктуре.
Каждая группа требует отдельного анализа.
Признак №1. Проект постоянно достигает ресурсных лимитов
Кратковременный пик не обязательно означает, что хостинг стал тесен.
Например:
- ночью создаётся резервная копия;
- один раз импортирован крупный каталог;
- пришла необычная волна ботов;
- после деплоя прогревается кэш;
- генерируются новые миниатюры.
Но если лимиты достигаются регулярно и влияют на пользователей, это серьёзный сигнал.
Что значит «регулярно»
Например:
CPU выше 90% несколько часов в день.
Все PHP-процессы заняты во время обычной нагрузки.
I/O достигает лимита при каждом импорте.
Памяти не хватает каждую ночь.
Ошибки 503 появляются несколько раз в неделю.
Особенно важно, если:
- проблема воспроизводима;
- причина измерена;
- код уже проверен;
- запросы к базе оптимизированы;
- фоновые задачи разведены по времени;
- кэш работает;
- боты ограничены;
- старший тариф не даёт нужного запаса.
Тогда проекту действительно требуется больше ресурсов или другая архитектура.
Но сначала исключите неисправность приложения
Один неоптимальный запрос может полностью загрузить и виртуальный хостинг, и будущий VPS.
Пример:
SELECT *
FROM orders
WHERE DATE(created_at) = '2026-07-25';
Функция над индексированным полем может мешать эффективному использованию индекса.
Более подходящий вариант:
SELECT *
FROM orders
WHERE created_at >= '2026-07-25 00:00:00'
AND created_at < '2026-07-26 00:00:00';
Но окончательное решение зависит от структуры таблицы и плана выполнения.
Перед переходом проверьте:
- самые медленные SQL-запросы;
- N+1;
- внешние API;
- debug-режим;
- кэш;
- фоновые задания;
- размер изображений;
- вредоносный трафик;
- логи;
- повторяющийся cron.
Если причина находится в коде, VPS лишь увеличит время до следующего кризиса.
Признак №2. Нужны постоянные фоновые процессы
На виртуальном хостинге cron обычно запускает короткие команды:
php artisan schedule:run
или:
php bin/console app:import
Процесс стартует, выполняет задачу и завершается.
Но некоторые приложения требуют постоянно работающих служб:
php artisan queue:work
php artisan horizon
php bin/console messenger:consume async
node server.js
Такие процессы должны:
- работать непрерывно;
- автоматически перезапускаться;
- запускаться после перезагрузки;
- контролироваться;
- писать журналы;
- получать сигналы остановки;
- обновляться без потери заданий.
Обычно ими управляют:
- systemd;
- Supervisor;
- контейнерная платформа;
- специализированный процесс-менеджер.
Если хостинг не поддерживает постоянные процессы, cron не всегда является полноценной заменой.
Когда cron ещё достаточен
Если очередь:
- небольшая;
- не требует мгновенной обработки;
- безопасно выполняется пакетами;
- запускается раз в минуту;
- завершает работу после опустошения,
можно использовать:
php artisan queue:work \
--stop-when-empty
через cron.
Когда cron уже не подходит
Если нужно:
- обрабатывать задания почти без задержки;
- держать несколько очередей;
- назначать им разные приоритеты;
- автоматически перезапускать workers;
- использовать Horizon;
- масштабировать обработчики;
- непрерывно принимать события,
нужна среда с постоянными процессами.
Это один из самых ясных архитектурных признаков перехода.
Признак №3. Приложению нужен собственный Redis
Важно различать:
- PHP-расширение Redis;
- Redis-сервер.
Расширение позволяет PHP подключаться к Redis.
Но само по себе оно не создаёт работающий сервис.
Redis может использоваться для:
- кэша;
- сессий;
- очередей;
- блокировок;
- rate limiting;
- Laravel Horizon;
- временных данных.
Если виртуальный хостинг не предоставляет Redis-сервер, варианты такие:
- использовать файловый или базовый кэш;
- подключить внешний управляемый Redis;
- перейти на среду, где Redis можно запустить самостоятельно.
VPS оправдан, если Redis является обязательной частью архитектуры и команда готова управлять:
- памятью;
- доступом;
- persistence;
- резервированием;
- обновлениями;
- мониторингом.
Установить пакет командой — простая часть. Обеспечить надёжную работу сервиса — более сложная.
Признак №4. Нужен WebSocket или постоянно работающий Node.js
Node.js на виртуальном хостинге может использоваться только для сборки:
npm ci
npm run build
После этого сайт обслуживается PHP.
Но приложение может требовать постоянно работающий сервер:
node server.js
Например:
- WebSocket;
- realtime-уведомления;
- чат;
- live-dashboard;
- серверный JavaScript;
- SSR;
- отдельный API;
- обработчик событий.
Такой процесс:
- слушает порт;
- работает постоянно;
- должен перезапускаться;
- требует reverse proxy;
- имеет собственные логи;
- использует память;
- нуждается в мониторинге.
Стандартный PHP-хостинг обычно не предназначен для этого.
Варианты:
- VPS;
- управляемая платформа Node.js;
- внешний realtime-сервис;
- контейнерная платформа.
Необязательно переносить весь PHP-сайт. Иногда достаточно вынести realtime-компонент в отдельную услугу.
Признак №5. Нужны системные пакеты и собственная конфигурация
На виртуальном хостинге нельзя произвольно выполнить:
sudo apt install ...
Это нормальное ограничение общей среды.
VPS нужен, если приложение требует:
- нестандартную системную библиотеку;
- собственную версию ImageMagick;
- LibreOffice для генерации документов;
- FFmpeg;
- особый драйвер;
- headless browser;
- специальный модуль nginx;
- сервис распознавания;
- собственный демон;
- VPN-подключение;
- монтирование файловой системы.
Но сначала проверьте альтернативы.
Например:
- PDF можно генерировать библиотекой PHP;
- изображения — внешним сервисом;
- видео — специализированной платформой;
- браузерные задачи — удалённым API;
- поиск — управляемым сервисом.
VPS не всегда является самым дешёвым способом получить одну системную программу.
Признак №6. Нужна нестандартная конфигурация веб-сервера
Виртуальный хостинг позволяет менять только предусмотренные настройки.
Проекту может потребоваться:
- собственная конфигурация nginx;
- специфический reverse proxy;
- проксирование нескольких приложений;
- нестандартные тайм-ауты;
- gRPC;
- WebSocket;
- особые правила кэширования;
- несколько upstream;
- собственные заголовки безопасности;
- сложная маршрутизация;
- ограничение запросов по правилам приложения.
Часть задач решается через панель, .htaccess или настройки приложения.
Но если архитектура требует контроля над глобальным веб-сервером, shared-среда становится неподходящей.
Признак №7. Требуется Docker
Docker полезен, когда приложение состоит из нескольких компонентов:
PHP
nginx
PostgreSQL
Redis
worker
scheduler
search
и команда хочет одинаково описывать среду для разработки, тестирования и production.
Обычный виртуальный хостинг не даёт доступа к Docker daemon.
Поэтому Docker-проект обычно размещается на:
- VPS;
- управляемой контейнерной платформе;
- Kubernetes;
- PaaS.
Но Docker не является обязательным признаком «современного проекта».
Если обычное PHP-приложение прекрасно работает в предоставленной среде, переносить его на VPS только ради контейнера может быть лишним усложнением.
Docker не отменяет:
- обновление образов;
- резервирование volumes;
- мониторинг;
- управление секретами;
- сеть;
- безопасность;
- восстановление.
Признак №8. Нужна собственная база данных
На виртуальном хостинге провайдер управляет общей MySQL или PostgreSQL.
Это удобно, пока подходят:
- версия;
- расширения;
- лимиты соединений;
- объём;
- производительность;
- конфигурация.
Переход может потребоваться, если нужны:
- специальная версия СУБД;
- собственные параметры;
- расширения PostgreSQL;
- репликация;
- point-in-time recovery;
- отдельный сервер базы;
- большой
buffer pool; - десятки или сотни постоянных соединений;
- сложная аналитика;
- выделенная производительность.
Но база на том же небольшом VPS конкурирует за ресурсы с PHP и веб-сервером.
Представим VPS с 4 ГБ RAM:
операционная система
веб-сервер
PHP-FPM
MySQL
Redis
workers
мониторинг
Каждый компонент требует память.
Иногда управляемая база или старший виртуальный хостинг работает надёжнее самостоятельной MySQL на слишком маленьком VPS.
Признак №9. Нужен отдельный поисковый сервис
Большой каталог может использовать:
- Elasticsearch;
- OpenSearch;
- Meilisearch;
- Typesense;
- Sphinx;
- другой поисковый движок.
Такой сервис:
- постоянно работает;
- хранит индекс;
- использует память;
- обновляется;
- требует резервирования;
- может быть доступен только из внутренней сети.
На обычном хостинге его обычно нельзя запустить.
Но размещать поиск на том же маленьком VPS, что и магазин, не всегда разумно. Индексация способна занять CPU и память, ухудшив работу сайта.
Возможные варианты:
- отдельный VPS;
- управляемый поисковый сервис;
- внешний API;
- оптимизация встроенного поиска базы.
Архитектурная потребность в отдельном сервисе является более весомым аргументом, чем просто большой каталог.
Признак №10. Нужна специальная сеть
Проекту может потребоваться:
- VPN до офиса;
- приватная сеть;
- доступ к базе только с конкретных серверов;
- site-to-site tunnel;
- собственные firewall rules;
- allowlist внешних систем;
- закрытые внутренние сервисы;
- несколько сетевых интерфейсов;
- отдельные порты.
Виртуальный хостинг скрывает сетевую инфраструктуру и предоставляет ограниченный набор возможностей.
Если сеть является частью архитектуры приложения, VPS или облачная инфраструктура становятся логичным выбором.
Признак №11. Нужна повышенная изоляция
На хорошем виртуальном хостинге аккаунты изолированы.
Однако проекту могут требоваться:
- собственная ОС;
- отдельный kernel namespace;
- собственная политика обновлений;
- полное разделение клиентов;
- отдельный журнал доступа;
- собственные агенты безопасности;
- контроль установленных пакетов;
- закрытый административный интерфейс.
Это может быть связано с:
- внутренними требованиями компании;
- аудитом;
- договором с заказчиком;
- особенностями обработки данных;
- необходимостью подтвердить конфигурацию.
Сам VPS не гарантирует безопасность или соответствие требованиям.
Он лишь даёт больше контроля. Этим контролем ещё нужно правильно воспользоваться и подтвердить результат.
Признак №12. Нагрузка стала предсказуемо высокой
Виртуальный хостинг особенно удобен для переменной веб-нагрузки.
Сайт может кратковременно использовать ресурсы и затем освобождать их.
Если проект круглосуточно выполняет:
- импорт;
- генерацию;
- расчёты;
- обработку очереди;
- индексацию;
- API-запросы;
- массовую конвертацию,
он перестаёт соответствовать типичному профилю shared-хостинга.
Даже если текущий тариф технически выдерживает нагрузку, правила допустимого использования могут ограничивать постоянное потребление CPU.
Для непрерывной предсказуемой работы лучше подходит:
- VPS с гарантированной долей;
- выделенный сервер;
- вычислительный сервис;
- отдельный worker-узел.
Веб-сайт и вычислительная задача не обязательно должны находиться на одном сервере.
Признак №13. Нужны разные версии и разные окружения
В одном проекте могут работать:
старый PHP-сервис
новое PHP-приложение
Node.js API
Python worker
PostgreSQL
Redis
Виртуальный хостинг может поддерживать разные версии PHP для сайтов, но не произвольную комбинацию системных служб.
VPS или контейнерная платформа позволяют изолировать компоненты.
Однако чем больше технологий, тем выше стоимость сопровождения:
- обновления;
- совместимость;
- мониторинг;
- логирование;
- безопасность;
- документация.
Сложная среда оправдана только реальными требованиями продукта.
Что не является достаточной причиной перехода
«У сайта много посетителей»
Количество посетителей само по себе ничего не определяет.
Сто тысяч просмотров статических страниц из кэша могут создавать меньшую нагрузку, чем сто тяжёлых административных запросов.
Нужны данные:
- динамические запросы в секунду;
- TTFB;
- cache hit ratio;
- CPU;
- workers;
- база;
- трафик;
- размер ответа.
«Сайт занимает много места»
Большой фотоархив может требовать больше хранилища, но не отдельную операционную систему.
Альтернативы:
- старший тариф;
- объектное хранилище;
- CDN;
- отдельное файловое хранилище;
- оптимизация изображений.
VPS с большим локальным диском может усложнить резервное копирование.
«Сайт однажды показал ошибку 503»
Единичная ошибка может быть вызвана:
- обновлением;
- атакой;
- кратким сбоем;
- резервным копированием;
- временным API;
- ошибкой кода.
Сначала найдите причину.
«Разработчик хочет root»
Root полезен только для конкретных задач.
Вопрос:
Какое обязательное требование невозможно выполнить без root?
Ответ:
Так удобнее
недостаточен для принятия инфраструктурного решения.
«VPS лучше для SEO»
Поисковой системе важны:
- доступность;
- скорость;
- корректный HTTPS;
- отсутствие ошибок;
- качество страниц;
- стабильность.
Название услуги не является фактором ранжирования.
Плохо настроенный VPS способен быть медленнее виртуального хостинга и чаще становиться недоступным.
«На VPS нет соседей»
VPS тоже обычно работает на общем физическом узле.
Изоляция ресурсов выше, но физическая инфраструктура всё равно может быть общей.
Если нужны полностью выделенные ресурсы, рассматриваются:
- dedicated CPU;
- выделенный сервер;
- специальные облачные экземпляры.
«На VPS можно настроить всё один раз»
Сервер не остаётся неизменным.
Постоянно появляются:
- обновления безопасности;
- новые версии PHP;
- уязвимости;
- изменения сертификатов;
- рост логов;
- новые боты;
- изменения приложения;
- ошибки диска;
- новые требования к резервным копиям.
Администрирование — регулярный процесс, а не однократная установка панели.
Что попробовать до VPS
1. Перейти на старший тариф
Это лучший первый шаг, если:
- проекту хватает функций;
- не нужны системные службы;
- основная проблема — измеренный ресурс;
- повышение выполняется без миграции;
- стоимость приемлема;
- поддержка и резервирование устраивают.
Преимущество — увеличение мощности без принятия серверного администрирования.
2. Оптимизировать код и базу
Проверьте:
- медленные SQL;
- N+1;
- кэш;
- внешние API;
- сессии;
- очередь;
- debug;
- ботов;
- изображения;
- старые плагины;
- повторные задачи.
После оптимизации проект может остаться на виртуальном хостинге ещё несколько лет.
3. Разнести тяжёлые задачи по времени
Не запускайте одновременно:
импорт
резервное копирование
индексацию
рассылку
генерацию изображений
Даже без изменения тарифа расписание способно убрать пики.
4. Вынести статические файлы
Изображения и документы можно хранить в:
- объектном хранилище;
- CDN;
- отдельном файловом сервисе.
Это уменьшает:
- диск;
- трафик;
- inode;
- нагрузку на веб-сервер;
- размер резервной копии.
Но добавляет внешний компонент и отдельную стоимость.
5. Использовать внешний SMTP
Массовая или важная транзакционная почта не обязана отправляться средствами хостинга.
Внешний SMTP уменьшает зависимость от:
- лимитов почты;
- общей репутации IP;
- локальной очереди;
- настройки PTR.
6. Вынести одну службу
Вместо полного переезда можно вынести:
- Redis;
- поиск;
- очередь;
- обработку видео;
- генерацию документов;
- frontend;
- API;
- базу.
Получается гибридная архитектура:
основной PHP-сайт
→ виртуальный хостинг
тяжёлый worker
→ отдельный VPS
поиск
→ управляемый сервис
изображения
→ объектное хранилище
Это может быть дешевле и надёжнее полного самостоятельного сервера.
Но нужно учитывать сетевую задержку, безопасность и доступность внешних компонентов.
7. Рассмотреть PaaS
Platform as a Service позволяет запускать приложение без полного управления Linux.
Платформа может предоставлять:
- deploy из Git;
- HTTPS;
- процессы;
- workers;
- логи;
- масштабирование;
- переменные окружения;
- управляемую базу.
Это промежуточный вариант между виртуальным хостингом и самостоятельным VPS.
Недостатки:
- особые правила платформы;
- более высокая стоимость ресурсов;
- ограничения файловой системы;
- привязка к сервисам;
- отдельная модель деплоя.
Для команды разработчиков без системного администратора PaaS иногда подходит лучше VPS.
Если переходить — управляемый или неуправляемый VPS
Неуправляемый VPS
Провайдер отвечает за:
- физический сервер;
- виртуализацию;
- сеть;
- доступность виртуальной машины.
Клиент отвечает за всё внутри ОС.
Подходит, если есть специалист, который умеет:
- администрировать Linux;
- защищать SSH;
- настраивать firewall;
- обновлять систему;
- конфигурировать PHP и базу;
- делать мониторинг;
- восстанавливать сервер;
- реагировать на инциденты.
Управляемый VPS
Провайдер или отдельный подрядчик может выполнять:
- первоначальную настройку;
- обновления;
- мониторинг;
- установку панели;
- резервирование;
- реакцию на сбои;
- оптимизацию;
- восстановление сервисов.
Но состав управления нужно читать внимательно.
Фраза:
Полное администрирование
может не включать:
- исправление кода;
- оптимизацию SQL;
- настройку Docker;
- обслуживание пользовательских сервисов;
- восстановление после взлома;
- круглосуточную реакцию;
- поддержку сторонней панели.
Запросите точный перечень работ и время реакции.
Как это устроено на Siteko. Эта граница проходит ровно там, где мы её проводим на протяжении всей серии. Обычные сайты и современные PHP-проекты (Laravel, Symfony) с SSH, Composer, Git, Node.js и cron-очередью живут на виртуальном хостинге — тарифы Master и Expert. Как только проекту нужен Redis-сервер, постоянные worker-процессы, Laravel Horizon, WebSocket, Docker или системный пакет — это уже VDS, и мы честно говорим об этом, а не пытаемся втиснуть такие задачи в shared. VDS у нас есть в двух вариантах: обычный (root и SSH, окружение настраиваете сами) и управляемый — подготовим Linux, веб-сервер, PHP, базу, SSL, бэкапы и базовый мониторинг под проект, с администрированием за отдельную плату. Но порядок из этой статьи мы не отменяем: если дело в измеренном ресурсе, а не в архитектуре, сначала имеет смысл старший тариф хостинга или оптимизация — VDS не ускоряет медленный SQL сам по себе.
Реальная стоимость VPS
Нельзя сравнивать только:
виртуальный хостинг — 30
VPS — 20
К VPS могут добавиться:
- панель управления;
- системный администратор;
- резервное хранилище;
- мониторинг;
- SMTP;
- защита;
- управляемая база;
- снимки;
- лицензии;
- время разработчика;
- аварийные работы;
- дополнительный IP;
- CDN.
Полная стоимость:
аренда сервера
программные лицензии
резервное копирование
мониторинг
администрирование
стоимость аварий
Если сервер обслуживает разработчик вместо работы над продуктом, это тоже расход.
Как подобрать размер первого VPS
Не переносите проект сразу на максимально большой сервер.
Соберите данные текущего окружения:
пиковый CPU
средний CPU
пиковая память
число PHP-процессов
память одного процесса
размер базы
активный набор базы
объём файлов
рост диска
I/O
сетевой трафик
Затем добавьте:
- операционную систему;
- веб-сервер;
- PHP-FPM;
- базу;
- Redis;
- workers;
- мониторинг;
- резерв на пики.
Пример оценки памяти
Допустим:
12 PHP-процессов × 100 МБ = 1,2 ГБ
MySQL = 1,5 ГБ
Redis = 300 МБ
ОС и веб-сервер = 500 МБ
workers = 500 МБ
резерв = 1 ГБ
Итого требуется около:
5 ГБ RAM
Ближайший разумный тариф может иметь 8 ГБ.
Это упрощённая оценка. Реальные процессы используют память неравномерно, а база может требовать другой объём.
Но такой расчёт полезнее выбора по принципу:
Возьмём 4 ГБ, наверное хватит.
VPS с 1–2 ГБ не всегда мощнее хостинга
На маленьком VPS память используют:
- ОС;
- база;
- PHP;
- веб-сервер;
- системные службы.
На виртуальном хостинге база и системная среда работают на инфраструктуре провайдера и не обязательно входят в пользовательский лимит тем же способом.
Поэтому:
2 ГБ VPS
не всегда превосходят:
1 ГБ лимита процессов на виртуальном хостинге
по реальной способности обслуживать сайт.
Сравнивать нужно работающую конфигурацию, а не одну строку RAM.
Что должно быть готово до переезда на VPS
Ответственный специалист
Должно быть известно:
Кто обновляет сервер?
Кто получает уведомления?
Кто реагирует ночью?
Кто восстанавливает бэкап?
Кто заменяет специалиста во время отпуска?
Ответ:
Разработчик разберётся, если что
слишком неопределённый.
План обновлений
Нужно регулярно обновлять:
- операционную систему;
- OpenSSH;
- веб-сервер;
- PHP;
- базу;
- Redis;
- панель;
- агенты мониторинга;
- Docker;
- приложения.
Обновления следует сначала проверять и иметь план отката.
Но бесконечное откладывание патчей безопасности ещё опаснее.
Защита SSH
Минимально:
- вход по ключам;
- ограничение root-доступа;
- отдельные пользователи;
- актуальный OpenSSH;
- firewall;
- защита от перебора;
- журналирование;
- MFA или bastion при повышенных требованиях.
Смена стандартного порта уменьшает шум в логах, но не заменяет настоящую защиту.
Firewall
Разрешайте только необходимые порты.
Для обычного веб-сервера публично могут быть нужны:
80/tcp
443/tcp
SSH лучше ограничить известными адресами или защищённым способом доступа, если это возможно.
База, Redis и внутренние сервисы не должны быть открыты всему интернету без необходимости.
Резервные копии
Нужно решить:
- что копируется;
- как часто;
- куда;
- сколько хранится;
- как шифруется;
- как проверяется;
- кто восстанавливает.
Snapshot VPS не заменяет независимый бэкап базы и пользовательских файлов.
Мониторинг
Минимально контролируйте:
- доступность сайта;
- HTTP-коды;
- срок сертификата;
- CPU;
- RAM;
- disk space;
- inode;
- I/O;
- load average;
- базу;
- PHP-FPM;
- Redis;
- очередь;
- cron;
- возраст последнего бэкапа.
Мониторинг без уведомлений не помогает.
Уведомления без ответственного тоже не помогают.
Ротация логов
Без неё каталог:
/var/log
или журналы приложения могут занять весь диск.
Проверьте:
- logrotate;
- срок хранения;
- размер;
- сжатие;
- отдельное хранение аудита;
- защиту от записи секретов.
План восстановления
Перед запуском production выполните учебный сценарий:
VPS недоступен полностью.
Нужно уметь:
- создать новую виртуальную машину;
- установить окружение;
- восстановить конфигурацию;
- импортировать базу;
- вернуть файлы;
- обновить DNS;
- запустить приложение;
- проверить критические функции.
Если восстановление требует старого сервера, который уже потерян, план не работает.
Документация
Запишите:
Версия ОС
Установленные службы
Порты
Пути проектов
Пользователи
Cron
systemd units
Supervisor
PHP-FPM pools
Базы
Бэкапы
DNS
Сертификаты
Мониторинг
Порядок деплоя
Порядок восстановления
Документация должна находиться вне самого VPS.
Как безопасно перейти
Переезд на VPS выполняется по тем же принципам, что и любая миграция:
подготовить среду
↓
предварительно перенести данные
↓
проверить через hosts или --resolve
↓
остановить запись
↓
финально синхронизировать
↓
переключить DNS
↓
контролировать старую среду
Но добавляется больше инфраструктурных проверок.
До переноса
- настроить ОС;
- установить обновления;
- закрыть лишние порты;
- создать пользователей;
- настроить PHP;
- настроить базу;
- включить резервирование;
- установить мониторинг;
- проверить логи;
- настроить автоматическое продление SSL;
- подготовить очередь;
- задокументировать всё.
Не переносите production на только что созданный VPS, на котором ещё не проверено восстановление.
Отдельный VPS не означает высокую доступность
Один VPS остаётся одной точкой отказа.
Если он недоступен, останавливаются:
- сайт;
- база;
- Redis;
- очередь;
- файлы.
Облачный или VPS-провайдер может быстро заменить физический узел, но приложение всё равно должно восстановиться.
Для высокой доступности понадобятся дополнительные элементы:
несколько экземпляров приложения
балансировщик
отдельная база
репликация
общее файловое хранилище
мониторинг
автоматическое переключение
Это намного сложнее одного VPS.
Не обещайте бизнесу отказоустойчивость только на основании переезда с shared-хостинга.
Иногда выделенный сервер лучше большого VPS
Если проект:
- стабильно использует много CPU;
- требует большой объём RAM;
- активно работает с диском;
- нуждается в выделенной производительности;
- постоянно оплачивает крупный VPS,
выделенный сервер может оказаться экономически выгоднее.
Но он добавляет вопросы:
- замена оборудования;
- RAID;
- запасные компоненты;
- время восстановления;
- удалённое управление;
- резервный сервер.
Решение принимается по нагрузке и требованиям, а не по престижу.
Иногда облако лучше VPS
Облачная инфраструктура полезна, если нужны:
- быстрое масштабирование;
- управляемая база;
- объектное хранилище;
- балансировщик;
- несколько зон;
- API;
- временные среды;
- автоматизация.
Но облако не отменяет архитектуру и контроль расходов.
Один облачный сервер без дополнительных сервисов остаётся обычной виртуальной машиной, которую нужно администрировать.
Иногда лучше остаться на виртуальном хостинге
Остаться разумно, если:
- проект поддерживается тарифом;
- нагрузка укладывается с запасом;
- редкие пики контролируются;
- не нужны постоянные службы;
- не требуется root;
- резервное копирование работает;
- поддержка помогает;
- стоимость предсказуема;
- у команды нет администратора;
- переход не решает конкретную проблему.
Простая инфраструктура является преимуществом.
Она:
- легче восстанавливается;
- требует меньше специалистов;
- имеет меньше точек отказа;
- дешевле в обслуживании;
- позволяет сосредоточиться на приложении.
Не нужно уходить с виртуального хостинга только потому, что проект стал успешным.
Матрица принятия решения
| Ситуация | Что делать сначала |
|---|---|
| Заканчивается диск | Удалить мусор, проверить логи и uploads |
| Много изображений | Рассмотреть объектное хранилище и CDN |
| Один раз достигнут CPU | Найти процесс и повторяемость |
| CPU постоянно на пределе | Оптимизация, затем старший тариф или VPS |
| Все PHP workers заняты | Измерить длительность запросов |
| Медленный внешний API | Тайм-аут, кэш, очередь |
| Нужны постоянные workers | VPS, PaaS или отдельный worker |
| Нужен Redis | Внешний сервис или VPS |
| Нужен Docker | VPS или контейнерная платформа |
| Нужен WebSocket | Отдельный realtime-сервис, VPS или PaaS |
| Нужен системный пакет | Внешний сервис или VPS |
| Нужна собственная MySQL | VPS или управляемая база |
| Слишком много cron-задач | Разнести расписание и проверить архитектуру |
| Нужно больше сайтов | Старший тариф или разделение аккаунтов |
| Нужна изоляция клиентов | Отдельные аккаунты, контейнеры или VPS |
| Нужен root «на всякий случай» | Остаться до появления конкретного требования |
| Нет администратора | Управляемый хостинг, VPS или PaaS |
| Старший shared-план достаточен | Не усложнять |
| Shared-модель запрещает нужный сервис | Переходить на другую среду |
Дерево решения
Начните с вопроса:
Проект упирается в измеренный ресурс?
Нет.
VPS пока не является решением проблемы.
Да.
Проверьте оптимизацию и старший тариф.
После оптимизации текущего тарифа недостаточно?
Нет.
Оставайтесь.
Да.
Сравните стоимость старшего тарифа и управляемого VPS.
Нужна функция, которой нет на shared-хостинге?
Например:
root
Redis
workers
Docker
WebSocket
системный пакет
собственный веб-сервер
Нет.
Вероятно, можно остаться в управляемой среде.
Да.
Рассматривайте VPS, PaaS или отдельный сервис.
Есть кто-то, кто будет обслуживать сервер?
Нет.
Выбирайте управляемую услугу.
Да.
Можно рассматривать неуправляемый VPS.
Подготовлены бэкап, мониторинг и восстановление?
Нет.
Переход пока не готов.
Да.
Можно планировать миграцию.
Оценка готовности проекта
Поставьте по одному баллу за каждый ответ «да».
Архитектурная необходимость
Нужны постоянные процессы.
Нужен собственный Redis.
Нужен Docker.
Нужен WebSocket.
Нужны системные пакеты.
Нужна специальная сеть.
Нужна собственная конфигурация базы.
Измеренная нагрузка
Лимиты достигаются регулярно.
Проблема влияет на пользователей.
Узкое место измерено.
Код и база проверены.
Старший shared-тариф недостаточен.
Операционная готовность
Назначен администратор.
Настроены независимые бэкапы.
Есть мониторинг и уведомления.
Есть план обновлений.
Есть runbook восстановления.
Миграция отрепетирована.
Учтена полная стоимость.
Большое число баллов в первой или второй группе указывает, что VPS может быть нужен.
Низкое число баллов в третьей группе означает, что проект ещё не готов безопасно его эксплуатировать.
Это не математическая формула, а способ не забыть операционную сторону решения.
Красные флаги перед покупкой VPS
Никто не отвечает за обновления
Значит, сервер начнёт устаревать сразу после установки.
Бэкап хранится только на том же VPS
Авария сервера уничтожит и рабочие данные, и копию.
Мониторинг — ручное открытие сайта
Проблему заметит клиент.
Все службы устанавливаются под root
Увеличивается ущерб от компрометации.
Нет ограничения сетевых портов
База или Redis могут случайно стать публичными.
Нет плана восстановления
Snapshot воспринимается как универсальная страховка.
На VPS переносят сразу десять проектов
Один неудачный сайт может повлиять на остальные, если изоляция не настроена.
Выбирается минимальный объём RAM
После запуска базы и системных служб приложению почти ничего не остаётся.
Не учтена почта
После переезда оказывается, что нужно самостоятельно обслуживать ещё и почтовый сервер.
Для большинства сайтов лучше оставить почту у специализированного провайдера.
Грабли перехода на VPS
| Грабля | Что происходит | Как избежать |
|---|---|---|
| VPS покупают без измерений | Сайт остаётся медленным | Найти узкое место |
| Root считают бесплатным преимуществом | Появляется постоянное администрирование | Назначить ответственного |
| Выбирают слишком маленький VPS | ОС и база съедают память | Рассчитать полный стек |
| Переносят неоптимальную базу | Новый сервер быстро перегружается | Проверить SQL заранее |
| Не настраивают firewall | Внутренние службы открыты интернету | Разрешить только нужное |
| Оставляют парольный SSH | Растёт риск перебора | Использовать ключи |
| Не обновляют систему | Накапливаются уязвимости | Регулярный patch management |
| Хранят бэкап на том же диске | Потеря сервера уничтожает всё | Внешняя копия |
| Не проверяют restore | Архив оказывается бесполезным | Учебное восстановление |
| Не настраивают мониторинг | Проблему сообщает клиент | Внешние проверки |
| Логи растут без ротации | Заполняется диск | logrotate и ограничения |
| База, Redis и PHP открыты публично | Возможна компрометация | Приватная сеть и firewall |
| Переносят почтовый сервер без необходимости | Письма не доходят | Внешний SMTP и почта |
| Устанавливают Docker и забывают об образах | Контейнеры остаются уязвимыми | Обновление и сканирование |
| Считают один VPS отказоустойчивым | Авария останавливает всё | План восстановления |
| Нет документации | Всё зависит от одного человека | Runbook вне сервера |
| Запускают cron и workers на двух средах | Дублируются операции | Один активный production |
| Меняют архитектуру во время переезда | Диагностика усложняется | Переносить поэтапно |
Что спросить у VPS-провайдера
Ресурсы
- CPU разделяемый или выделенный?
- Есть ли ограничение постоянной нагрузки?
- Как ограничиваются IOPS и I/O?
- Можно ли увеличить RAM и диск без переезда?
- Возможна ли обратная смена тарифа?
Хранение
- Как устроены диски?
- Есть ли snapshots?
- Где они хранятся?
- Входят ли они в стоимость?
- Есть ли автоматические бэкапы?
- Можно ли скачать независимую копию?
Сеть
- Какая скорость порта?
- Как считается трафик?
- Есть ли защита от DDoS?
- Доступна ли приватная сеть?
- Можно ли настроить PTR?
- Предоставляется ли IPv6?
Управление
- Что входит в администрирование?
- Кто обновляет ОС?
- Кто реагирует на недоступность?
- Каково время реакции?
- Обслуживаются ли Docker, Redis и база?
- Помогает ли поддержка после взлома?
Восстановление
- Что произойдёт при отказе физического узла?
- Как быстро запускается VPS на другом оборудовании?
- Есть ли SLA?
- Как получить доступ через консоль при ошибке сети?
- Можно ли загрузиться в rescue mode?
Безопасность
- Есть ли MFA для панели?
- Есть ли журнал действий?
- Можно ли ограничить API-ключи?
- Как удаляются диски после отмены услуги?
Что приложить к запросу на подбор VPS
Плохой запрос:
Какой VPS нужен для Laravel?
Полезный:
Приложение:
Laravel, PHP 8.x
Текущая нагрузка:
до 20 динамических запросов в секунду
PHP:
среднее потребление процесса — 90 МБ
пиковое число процессов — 25
База:
MySQL
объём — 18 ГБ
рост — около 2 ГБ в месяц
Файлы:
40 ГБ
в основном пользовательские изображения
Фоновые задачи:
4 постоянных queue worker
scheduler раз в минуту
Дополнительные сервисы:
Redis
Meilisearch
Текущая проблема:
виртуальный хостинг не поддерживает
постоянные процессы и Redis-сервер.
Требования:
ежедневные внешние бэкапы
мониторинг
управляемые обновления ОС
возможность увеличить RAM
Теперь инфраструктуру можно подбирать под реальные компоненты.
Минимальный чек-лист перед переходом
Причина
Какое конкретное ограничение решает VPS?
Измерено ли оно?
Исключены ли ошибки приложения?
Альтернативы
Проверен старший тариф?
Можно ли вынести один сервис?
Подходит ли PaaS?
Подходит ли управляемая база?
Ответственность
Кто администрирует ОС?
Кто реагирует на аварии?
Кто заменяет основного специалиста?
Безопасность
SSH по ключам?
Firewall?
Отдельные пользователи?
Закрыты база и Redis?
Настроены обновления?
Данные
Независимые бэкапы?
Проверочное восстановление?
Известны RPO и RTO?
Наблюдаемость
Мониторинг сайта?
CPU и RAM?
Диск?
База?
Очереди?
SSL?
Бэкапы?
Миграция
Подготовлен новый сервер?
Проведена репетиция?
Есть maintenance window?
Есть план отката?
Стоимость
Учтена панель?
Учтено администрирование?
Учтено хранилище?
Учтены внешние сервисы?
Если большинство ответов неизвестно, покупать VPS пока рано.
Что в итоге
Виртуальный хостинг становится тесным в двух основных случаях.
Первый: проекту объективно не хватает ресурсов
Это подтверждается измерениями:
- CPU регулярно достигает лимита;
- PHP-процессы заняты полезной нагрузкой;
- памяти недостаточно;
- дисковые ограничения мешают работе;
- старший тариф не даёт нужного запаса.
Второй: проекту нужна другая архитектура
Например:
- постоянные workers;
- Redis;
- WebSocket;
- Docker;
- системные пакеты;
- собственный веб-сервер;
- специальная база;
- поисковый сервис;
- приватная сеть.
В остальных ситуациях сначала стоит проверить:
- код;
- SQL;
- кэш;
- ботов;
- cron;
- внешние API;
- старший тариф;
- отдельные управляемые сервисы.
VPS не является автоматическим ускорителем. Он предоставляет контроль, но одновременно передаёт владельцу ответственность за операционную систему, безопасность, обновления, резервные копии, мониторинг и восстановление.
Главный принцип заключительной статьи:
Переходите на VPS не тогда, когда виртуальный хостинг кажется несолидным, а когда можете назвать конкретное ограничение, которое VPS устранит, и конкретного человека, который будет отвечать за новую инфраструктуру.
Иногда правильное решение — отдельный сервер.
Иногда — управляемый VPS.
Иногда — внешний Redis, SMTP или объектное хранилище.
А иногда лучший выбор — остаться на виртуальном хостинге и не покупать себе вторую работу.
Итоги серии «Хостинг без магии»
За четырнадцать статей мы прошли весь путь сайта:
выбор модели хостинга
↓
чтение характеристик тарифа
↓
понимание безлимитов
↓
подключение DNS
↓
настройка HTTPS
↓
доставка почты
↓
окружение PHP-фреймворка
↓
деплой через Git
↓
диагностика ошибки 500
↓
поиск причин медленной работы
↓
проверка бэкапов
↓
безопасный переезд
↓
решение о переходе на VPS
Главная мысль всей серии остаётся той же, с которой она начиналась:
Выбирайте не максимальное количество ресурсов и не самое технологичное название, а минимально достаточную среду с понятной границей ответственности.
Хороший хостинг не обязан давать root-доступ каждому проекту.
Хороший VPS не обязан подходить владельцу сайта без администратора.
Большой диск не заменяет PHP-процессы.
HTTPS не исправляет уязвимости приложения.
SPF не гарантирует попадание писем во «Входящие».
Наличие бэкапа не гарантирует восстановление.
А переезд на новый сервер не исправляет медленный SQL автоматически.
Хостинг перестаёт быть магией, когда каждая проблема разбивается на конкретные уровни, измерения и зоны ответственности.
Была статья полезной:
