Зомби в проде: почему торговые боты и сервисы почти никогда не падают с ошибкой

Октябрь 2022 года, четверг, три часа ночи. На рынке резкий пролив, ликвидность свистит, волатильность зашкаливает. Мой торговый бот должен был за сорок минут переставить сетку ордеров минимум шестьдесят раз, собрать спред и выйти в нейтраль. Утром я открыл терминал и увидел минус 1 840 долларов на ровном месте. При этом демон в systemd светился жизнерадостным зеленым: active (running). Процесс не упал. Никакого core dump, никаких фатальных исключений в логах. Просто внутри Python-скрипта намертво завис websocket-коннект к биржевому шлюзу из-за необработанного таймаута на сокете.

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

Это классическая ловушка, в которую попадают разработчики и владельцы проектов. Мы привыкли думать о сбоях бинарно: либо система работает, либо вылетает HTTP 500, память переполняется и OOM killer прибивает процесс. Но реальные системы — от криптоботов до интернет-магазинов — почти никогда не умирают шумно. Они умирают молча, продолжая отдавать статус 200 OK.

Иллюзия зеленого чекбокса: UptimeRobot, Kuma и Zabbix

Каждый второй фаундер или соло-разработчик решает вопрос надежности за пять минут: идет и регистрирует какой-нибудь базовый сервис, чтобы получить мониторинг сайта бесплатно. Ставится пинг раз в пять минут на корневой URL. Если сервер ответил за две секунды — ура, всё в порядке. Появился красивый бейдж, где гордо красуется цифра 99.9% uptime.

Только вот что такое uptime на самом деле? В сухом техническом смысле uptime это всего лишь показатель непрерывной работы машины или службы без перезагрузки. Но какое значение имеет время аптайма сервера Nginx, если база данных под ним встала в deadlock, пул коннектов исчерпан, а бэкенд на любой запрос возвращает пустую белую страницу с кодом 200?

Кто-то пытается копнуть глубже. Разворачивают локальный uptime kuma в Docker-контейнере или настраивают uptimerobot на проверку ключевого слова в HTML. Продвинутые команды поднимают тяжелый мониторинг сайта zabbix, навешивают датчики на загрузку процессора, I/O дисков, температуру сокетов и свободный swap. Я сам годами администрировал такие стенды. И знаете что? Zabbix будет показывать идеальные графики с нагрузкой на CPU в скромные 8%, пока ваш скрипт тихо висит в бесконечном цикле, не трогая сеть и не обрабатывая очередь сообщений.

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

Где тихий отказ бьет больнее всего

В алгоритмической торговле цена мертвого цикла — мгновенный убыток. Мы в NEXUS Algo регулярно разбираем логи людей, которые приходят к нам учиться или настраивать готовые решения. Девять из десяти инцидентов происходят не потому, что упал сервер в дата-центре. Причина в другом: отвалился сторонний API, брокер изменил лимиты на частоту запросов, протек дескриптор файла, база данных SQLite заблокировалась на запись долгим чтением. Процесс жив, а логика парализована.

За пределами финтеха ситуация не лучше. Возьмем performance-маркетинг. Предприниматель запускает рекламу, подключает штатный мониторинг сайта яндекс директ. Автоматика Яндекса периодически шлет GET-запрос: страница открывается, значит, показы можно продолжать, деньги списываются. Но штатный мониторинг сайта директ не знает, что у вас сломалась JS-библиотека корзины, отвалился AJAX-запрос к платежному шлюзу или слетела авторизация через SMS. Клиенты заходят, тыкают в мертвую кнопку оформления и закрывают вкладку. Директ бодро крутит бюджет в пустоту.

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

Но как только внутри появляется состояние (state), транзакции, интеграции с внешними API и реальные деньги — поверхностный мониторинг сайта онлайн становится опасным самообманом.

Как перестать верить статусу 200 OK

Если вы строите автономного торгового агента или сложный веб-сервис, забудьте про проверку главной страницы. Вот три принципа, которые спасли моим проектам больше денег, чем любые тесты:

1. Dead Man's Switch вместо опроса извне. Пассивный пинг плох тем, что он стучится снаружи. Гораздо надежнее принцип «кнопки мертвеца». Сам бот обязан каждые 60 секунд отправлять сигнал в независимый сервис: «Я жив, последний тикер обработан 2 секунды назад, позиция синхронизирована». Если сигнал не пришел за 90 секунд — система поднимает тревогу и принудительно рубит процесс.

2. Контроль бизнес-инвариантов. Не проверяйте базу данных пингом порта 5432. Проверяйте, что в таблице ордеров за последние N минут появилась хотя бы одна запись, или что latency между получением тика и реакцией алгоритма не превышает пороговые миллисекунды. Зависание почти всегда предваряется деградацией времени отклика (latency drift).

3. Изоляция контекста и асинхронные сторожевые таймеры (watchdog). Любое сетевое действие обязано иметь жесткий timeout на уровне сокета, а не только на уровне HTTP-клиента. Если задача в asyncio или треде зависает дольше допустимого, отдельный поток-сторож должен убивать процесс целиком, вызывая перезапуск окружения, а не надеяться на благополучный выход.

Мы строим софт именно по такой логике, подтверждая надежность публичными отчетами вроде нашего live proof RVV. Программа должна непрерывно доказывать, что она вменяема, а не просто занимать место в оперативной памяти.

Честный вывод

Написать рабочий код сегодня может каждый второй с помощью базовых нейросетей. Заставить его стабильно жить в непредсказуемой среде — задача совсем другого порядка. Если у вас нет времени вручную писать сторожевые таймеры, настраивать сбор метрик логики и дежурить по ночам у терминала, посмотрите на наш сервис Guardian — мониторинг 24/7. Мы сделали его специально для отслеживания глубокого состояния сервисов, ботов и нестандартной инфраструктуры, чтобы вам больше никогда не приходилось просыпаться с убытками от бота, который тихо завис с идеальным аптаймом.