Настройка криптобота на VPS: systemd, мониторинг и безопасность

Настройка VPS для бота: где ломается окружение

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

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

Типовые сбои: обрыв сессии, перезагрузка, зависшие процессы

Вместе с процессом теряется состояние, жившее только в памяти — таймеры, незакрытые позиции, кэш ордеров, — и восстановление превращается в ручной разбор по логам. Зависшие экземпляры копятся ещё незаметнее: после очередного падения бота поднимают заново вручную, старый процесс остаётся висеть, держит соединение и порт, а новый не может занять тот же ресурс. Симптом всегда один — «бот не отвечает», а причин к этому моменту уже три-четыре.

Закрывается это переносом запуска в systemd-юнит: автозапуск при загрузке машины, политика перезапуска при аварии, отдельный лог на службу. Состояние выносится за пределы памяти процесса, а осиротевшие экземпляры гасятся по идентификатору службы, а не поиском в списке задач. Дальше разбираем, как это настраивается по шагам.

Что даёт управляемое окружение: измеримый эффект

Управляемое окружение отличается от запуска бота «в терминале» не удобством, а предсказуемым поведением при сбое. Ниже — то, что считается до и после, без формулировок «стало надёжнее».

Автозапуск и самовосстановление

Юнит systemd с политикой Restart=always поднимает процесс после падения, перезагрузки VPS и обрыва соединения с биржей; ограничение частоты перезапусков не даёт боту уйти в бесконечный цикл. Время восстановления после сбоя процесса сокращается с минут ручной работы до секунд — оператор узнаёт о факте, а не о последствиях.

Практический эффект: доля отказов, которые закрывает автозапуск, доходит до 80–90% — остаются ошибки конфигурации и исчерпанные лимиты API, их разбирают руками. Сторожевой таймер проверяет не «жив ли процесс», а отвечает ли бот на запросы, и перезапускает зависший экземпляр.

Наблюдаемость: логи и оповещения

Мониторинг бота строится на структурированных логах с ротацией: история сделок и ошибок не теряется при рестарте и не занимает диск целиком. Метрики — задержка ответа API, доля отклонённых заявок, размер очереди — уходят в оповещения с порогами, поэтому о деградации известно до того, как она превратится в потери.

Итог: ручные вмешательства переходят из режима «несколько раз в неделю» в «раз в месяц и реже», а путь от сбоя до работающего сервиса занимает секунды вместо десятков минут.

Варианты размещения бота: сравнение режимов

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

Когда хватает одного процесса

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

Когда нужно разделять роли и данные

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

Настройка VPS для бота: этапы инженерных работ

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

Аудит и схема размещения

1. Аудит запуска: как бот стартует сейчас, где лежат ключи доступа, куда пишутся логи, что произойдёт при перезагрузке. Фиксируем риски — ручной старт, секреты в открытом виде, отсутствие лимитов.
2. Схема размещения: раскладываем роли — торговая логика, обработчики очередей, база состояния. Отдельно решаем, что хранится на диске, а что в базе, чтобы рестарт не приводил к повторным ордерам.
3. Базовая защита: отдельный пользователь без прав администратора, вход по ключам, закрытые входящие порты кроме служебного, автоматические обновления и fail2ban против перебора.

Проверка на отказоустойчивость

• Автозапуск: юнит systemd с политикой перезапуска, лимитами памяти и отдельным файлом окружения, доступным только владельцу. Логи уходят в journald с ротацией — диск не забивается.
• Мониторинг: метрики процесса, задержка ответов биржи, проверка живости по расписанию, оповещения в мессенджер по порогам — падение, рост ошибок, простой дольше заданного.
• Сценарии отказа: гасим процесс, перезагружаем сервер, обрываем сеть, откатываем релиз — смотрим, восстанавливает ли бот соединение и не дублирует ли ордера. Прогоняем заново после каждого изменения.
• Передача в эксплуатацию: инструкция по обновлению, откату и типовым сбоям, доступы для команды заказчика, разбор на живом стенде.

Конфигурации, юниты и регламенты: состав передачи

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

Что лежит в репозитории

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

Регламенты: обновление, ротация ключей, бэкапы

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

Опишите задачу — вернёмся с оценкой и планом.

Кейс: как бот перестал падать и терять состояние

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

Что было до

У процесса не было службы-наблюдателя: при разрыве соединения с биржей или необработанном исключении бот завершался, и до утра об этом никто не знал. За месяц набиралось до семи ночных остановок по 40 минут и больше, а после ручного перезапуска позиции приходилось сверять с биржей глазами. Состояние держалось только в памяти, поэтому каждое падение означало потерю незакрытых сделок и расхождение учёта.

Что изменилось после

Кейс настройки свёлся к трём вещам: бот оформили как службу systemd с автоматическим перезапуском и ограничением частоты попыток, состояние вынесли в локальную базу с записью на диск после каждой сделки, а журналы событий и оповещения о сбоях направили в мессенджер — сигнал приходит в момент остановки, а не утром. Стабильный запуск перестал быть ручной операцией: доля времени в работе выросла с 92% до 99,9%, восстановление после сбоя занимает секунды, ручных перезапусков за квартал — ноль, расхождений с биржей по открытым позициям — тоже.

Что делать, если бот уже развёрнут на общем хостинге?

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

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

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

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

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

Технические сомнения: вопросы по эксплуатации бота

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

Как я узнаю, что бот упал?

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

Можно ли перенести бота без простоя?

Поднимаем второй контур рядом, переносим данные, переключаем нагрузку и только потом гасим старый. Простой укладывается в минуты, история сделок и настройки сохраняются полностью.

Зачем выносить данные на отдельный сервер?

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

Как обновлять логику без риска для рабочей версии?

Сборка идёт на тестовом контуре с историческими данными, затем выпуск на рабочий, а предыдущая версия остаётся готовой к откату. Изменения схемы данных делаем обратимыми.

Обсудим задачу: что прислать для оценки и плана

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

• Где сейчас работает бот: своя машина, облачный сервер или локальная станция, какая операционная система и как запускается процесс — вручную, через супервизор или службой.
• Какие сбои уже были: падения процесса, перезагрузки, обрывы связи с биржей, пропущенные сигналы — и как вы о них узнавали.
• Как хранятся данные: ключи доступа, состояние позиций, история сделок, резервные копии и место их хранения.
• Кто имеет доступ к серверу: сколько людей, по каким ключам, есть ли общий пароль или вход через панель управления.
• Требования к простоям: допустимое время недоступности, нужен ли автоматический перезапуск и как обрабатывать рассинхрон с биржей.
• Что должно попадать в мониторинг: уведомления об ошибках, ключевые метрики и кто из дежурных реагирует.

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