Автоматизация и парсеры редко требуют большого сервера, но страдают от отсутствия логов, лимитов и контроля ошибок. Эта статья нужна не для выбора “самого большого” тарифа, а для подготовки заказа: какие компоненты разнести, какие метрики снять до оплаты и что проверить перед переносом production.
Когда подходит
- n8n
- cron worker
- low-rate parser
Практическая схема
- Соберите схему вокруг сценария: n8n, cron worker, low-rate parser. Отдельно опишите публичную точку входа, данные, фоновые задачи, backup и доступ администратора.
- Для БД выделите отдельный приватный доступ от application-сервера, ограничьте bind/listen адреса и заранее решите, где живут WAL/binlog, dumps и offsite backup.
- Не держите единственный backup на том же диске и в той же учетной записи, где работает основной сервис. Минимум: отдельный backup-путь, отдельный ключ доступа и понятный retention.
- Разделите доступы: публичные порты, SSH/VPN, панель управления, приватные сервисы и мониторинг. Все, что не должно быть доступно клиентам, закрывайте firewall до переноса.
Как выбрать ресурсы
- Начните с проверки: частота запусков; ограничения API; хранение логов и результатов.
- Главный расчет для PostgreSQL/MySQL: hot data и индексы в RAM, latency диска под запись, место под WAL/binlog, backup и рост данных.
- Если база уже живая, проверьте slow query log, top queries, locks, connections, cache hit ratio и время полного restore.
- 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-правила.
- Сделайте тестовую репликацию или dump/restore, проверьте grants, extensions, charset/collation, timezone и connection limits до смены приложения.
- Сделайте backup до миграции, проверьте restore на тесте и заранее зафиксируйте rollback: DNS назад, старая база, остановка фоновых jobs или временная read-only пауза.
- Перед переносом снизьте DNS TTL, проверьте RDNS/hostname, SSL, cron, очереди, SMTP/webhook callbacks, monitoring alerts и доступ по аварийному каналу.
- Переключайте production только после проверки сети, диска, backup restore и основного пользовательского сценария: вход, заказ/оплата/API-запрос, запись в базу и уведомления.
Ошибки, которые ломают запуск
- переносить БД без теста restore и без проверки extensions/charset/timezone
- открывать порт БД наружу вместо private/VPN доступа
- выбирать тариф только по цене, не считая CPU, RAM, disk latency, backup, трафик и рост нагрузки
- переносить production без staging, backup restore и rollback-плана
- оставлять открытыми лишние порты или переносить старые firewall-правила без проверки
- забывать про DNS TTL, RDNS, SSL, cron, SMTP, webhooks, очереди, мониторинг и уведомления
- открывать тикет без версии ОС, панели, стека, IP/ASN требований, окна работ и ожидаемой даты запуска
Что написать в тикет
- сколько workflows
- какие API используются
- нужна ли база или Redis/queue
