Запуск BAS по расписанию: автозапуск, планировщик и работа без человека

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

Расписание живёт снаружи

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

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

Отсюда практический вывод: скомпилируйте проект в приложение и запускайте его как обычную программу.

Планировщик задач Windows

Штатный способ. Создаёте задачу, указываете путь к собранному .exe и расписание. Несколько настроек, которые обычно и определяют, взлетит схема или нет:

• «Выполнять вне зависимости от регистрации пользователя» - иначе задача не запустится, пока вы не войдёте в систему.
• Рабочая папка. Если не задать, приложение стартует не из своей директории и не найдёт ресурсы, которые лежат рядом. Это причина №1, по которой бот «работает руками, но не работает по расписанию».
• Что делать, если предыдущий запуск ещё идёт. По умолчанию можно получить два экземпляра разом. Для бота с потоками это удвоенная нагрузка и, скорее всего, гонка за одни и те же данные.
• Запуск при пропущенном времени - если машина спала в назначенный час.

Автозапуск при старте системы

Если бот должен работать постоянно, а не по часам, разумнее вешать его на старт системы: VPS перезагрузился после обновления - бот поднялся сам, без вашего участия.

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

VPS: где это должно жить

Домашний компьютер плох для автоматизации по расписанию не из-за мощности, а из-за непредсказуемости: спящий режим, обновления Windows, пропавший интернет, случайно выключенная машина.

Практические требования к VPS под BAS скромные и определяются в основном памятью: считайте по 150-400 МБ на браузерный поток плюс запас системе. Отдельный момент - не работайте на VPS через постоянно открытый RDP: сессия остаётся активной, потребляет ресурсы, а при обрыве соединения может утащить за собой процессы. Запустили задачу, отключились, зашли проверить результат.

Перезапуск после падения

Даже надёжный бот однажды упадёт: сайт лёг, кончилась память, оборвалась сеть. Вопрос не в том, случится ли это, а в том, восстановится ли он без вас.

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

Как узнать, что бот отработал

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

Поэтому каждый автономный прогон должен оставлять след:

• Уведомление о результате. Короткий итог в Telegram после каждого прогона - обработано столько-то, ошибок столько-то.
• Сигнал о самом факте запуска. Важнее, чем кажется: отсутствие сообщения - это тоже информация. Если вечернего отчёта нет, значит задача не стартовала вовсе.
• Статистика по прогонам. Не только «сколько сделал», но и «сколько обычно делает». Прогон, который отработал вдвое быстрее обычного, чаще всего означает не ускорение, а пустой список на входе.
• Лог в файл. Разбирать вчерашний сбой можно только по логам, написанным вчера.

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