Windows/RDP VPS и browser automation требуют больше RAM и аккуратнее относятся к диску. Для light node или watchtower важнее uptime и сеть. Эта статья нужна не для выбора “самого большого” тарифа, а для подготовки заказа: какие компоненты разнести, какие метрики снять до оплаты и что проверить перед переносом production.
Когда подходит
- Windows/RDP VPS
- browser automation
- blockchain light node или validator/watchtower
Практическая схема
- Соберите схему вокруг сценария: Windows/RDP VPS, browser automation, blockchain light node или validator/watchtower. Отдельно опишите публичную точку входа, данные, фоновые задачи, backup и доступ администратора.
- Для Windows/RDP ограничьте доступ по IP/VPN, включите обновления и отделите рабочие файлы от временного профиля. Для node/watchtower отдельно планируйте data dir и monitoring.
- Не держите единственный backup на том же диске и в той же учетной записи, где работает основной сервис. Минимум: отдельный backup-путь, отдельный ключ доступа и понятный retention.
- Разделите доступы: публичные порты, SSH/VPN, панель управления, приватные сервисы и мониторинг. Все, что не должно быть доступно клиентам, закрывайте firewall до переноса.
Как выбрать ресурсы
- Начните с проверки: нужна ли Windows лицензия; RAM под браузер; требования к uptime и storage.
- Windows и browser automation требуют больше RAM и диска, чем обычный Linux VPS. Для light node считайте storage growth, snapshot size и uptime.
- CPU выбирайте по пиковому сценарию, а не по среднему idle. Для web/API смотрите RPS и worker count, для баз данных - slow queries и CPU wait, для игр - single-thread и tickrate.
- RAM считайте по рабочему набору: ОС, приложение, база/cache, панели, фоновые jobs и запас под пик. Если swap уже используется постоянно, тариф мал.
- Диск выбирайте по двум параметрам: объем через 3-6 месяцев и задержка/IOPS. Для БД, search, CI и backup важна не только емкость, но и скорость записи/чтения.
- Сеть считайте отдельно: месячный трафик, пиковый Mbit/s или Gbit/s, география пользователей, CDN/cache и требования к дополнительным IPv4.
Что выбрать в заказе
- OS - для обычного Linux-стека выбирайте актуальные Debian/Ubuntu; для панели проверьте совместимость панели с версией ОС; для нестандартного образа выбирайте Custom ISO и указывайте ссылку/требования в тикете.
- Локация - для VPS без GPU выбирайте NL, DE, RU, UK, USA или SG по latency и аудитории. Для GPU VPS локация фиксирована тарифом, для dedicated требования к региону лучше написать в тикет.
- IPv4 - дополнительные адреса или подсеть нужны для отдельных сервисов, RDNS, virtualization, reseller hosting, BGP или изоляции клиентов. Если заказываете подсеть под BGP, заполните ASN.
- Панель - cPanel/Plesk/Virtualizor добавляйте только если она реально нужна для управления клиентами, сайтами или виртуализацией. Для простого VPS часто достаточно SSH и автоматизации.
Проверка перед переносом
- Поднимите сервис на новом сервере как staging: та же ОС, версии runtime, база, расширения, панель и firewall-правила.
- Проверьте RDP firewall, сильный пароль/ключи, Windows updates, timezone, автозапуск automation и monitoring node sync/lag.
- Сделайте backup до миграции, проверьте restore на тесте и заранее зафиксируйте rollback: DNS назад, старая база, остановка фоновых jobs или временная read-only пауза.
- Перед переносом снизьте DNS TTL, проверьте RDNS/hostname, SSL, cron, очереди, SMTP/webhook callbacks, monitoring alerts и доступ по аварийному каналу.
- Переключайте production только после проверки сети, диска, backup restore и основного пользовательского сценария: вход, заказ/оплата/API-запрос, запись в базу и уведомления.
Ошибки, которые ломают запуск
- оставлять RDP открытым для всего интернета
- не считать рост blockchain/node данных и падать из-за заполненного диска
- выбирать тариф только по цене, не считая CPU, RAM, disk latency, backup, трафик и рост нагрузки
- переносить production без staging, backup restore и rollback-плана
- оставлять открытыми лишние порты или переносить старые firewall-правила без проверки
- забывать про DNS TTL, RDNS, SSL, cron, SMTP, webhooks, очереди, мониторинг и уведомления
- открывать тикет без версии ОС, панели, стека, IP/ASN требований, окна работ и ожидаемой даты запуска
Что написать в тикет
- нужная OS
- тип автоматизации или node
- сколько диска и RAM нужно
