Автономные боты и проверка на истории: инженерия надёжности

Bash не отцепляет демон на macOS — это проверено, а не мнение

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

• nohup … & disown — классика, которая не работает
• set -m + disown, запуск в подоболочке, вложенные варианты форка — тот же результат
• в macOS нет setsid(1), поэтому «правильного» шелл-способа просто не существует

Решение — один общий запускатор на Python: fork → setsid → fork → execvp, внук гарантированно получает PPID=1. Все перезапуски в проекте идут только через него; для задач под macOS дополнительно выставлен AbandonProcessGroup, иначе система прибирает потомков вместе с завершившимся скриптом.

Живучесть меряется по каждому типу события отдельно

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

Но это лечит только полную смерть соединения. Реальный инцидент был тоньше: перестал приходить один тип события, остальные текли как обычно — и общий счётчик тишины не сработал ни разу. Отсюда правило, которое теперь применяется ко всем сервисам: liveness — это не «процесс жив», а «когда я последний раз получил то, ради чего я живу». У каждого критичного типа события свой счётчик, в отчёт о состоянии выводится «сколько минут назад» по каждому потоку, плюс превентивная переподписка по таймеру.

Проверка «процесс жив» должна быть честной

Шаблоны pgrep -f обязаны быть заякорены на конец аргументов (…/book_recorder\.py$). Без якоря проверка матчит любой соседний шелл, у которого искомая строка оказалась в командной строке — включая сам вызывающий скрипт. Мониторинг, который сам себя считает живым процессом, хуже отсутствия мониторинга: он выдаёт зелёный статус на мёртвую систему.

Сначала SQL и происхождение каждой строки

Правило для всего нового кода: данные пишутся в базу, а файлы JSONL допустимы только как скользящий буфер с ретеншеном ≤48 ч и ежедневной ротацией. У каждого датасета — строка в data_provenance (источник, статус данных, заметки аудита, можно ли удалять), у каждой записи — ingested_at и ссылка на исходный датасет. Повод был предельно бытовой: аудит нашёл десятки гигабайт дубликатов, которые никто не мог удалить, потому что никто не мог доказать их происхождение.

• живые писатели открывают соединение на flush и сразу закрывают — блокировка держится миллисекунды, а не всё время жизни процесса
• база с непрерывной записью — single-writer; аналитические подключения только read_only=True
• новый живой писатель получает отдельный файл базы, а не делит его с существующим

Записи о решениях не удаляются никогда

Постмортем, из которого выросло отдельное правило: около пяти недель истории решений исчезли под давлением на диск — штатная ротация архивов снесла файлы, которые невозможно восстановить. Ответ — хранилище, куда можно только дописывать: все записи о входах и закрытиях собираются из живых прогонов и из архивов, дедуп по хешу строки (операция идемпотентна, можно гонять хоть каждые 15 минут), синхронизация на офсайт-копию. Главное правило вшито в код чистки: харвест выполняется до любого удаления, и если он не удался — удаление отменяется целиком. Диск дешевле данных, всегда.

Событийная реакция вместо опроса по таймеру

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

• подключение и подписка — ~40 мс; запрос детали — ~26 мс; чтение внешнего состояния — ~35 мс; отправка — ~41 мс
• криптографическая подпись — 0,24 мс после перехода с реализации на чистом Python на встроенную в систему; до этого она была на три порядка дороже и съедала весь выигрыш
• фоновые кэши и параллельные запросы вместо последовательных ожиданий — ещё десятки миллисекунд
• быстрый путь целиком — 250–350 мс; ниже без смены архитектуры не опуститься, дальше упор в сеть

Журнал инвариантов вместо устной памяти

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

Проверка на истории, которая не льстит

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

• сначала метрики без допущений — распределения и доли достижения уровней; если движения нет вообще, никакая настройка выходов не поможет
• дедуп реплик: один и тот же сигнал размножается по конфигурациям примерно в 12 раз — без дедупа выборка фиктивно раздувается
• сегментация по режиму рынка и по типу сигнала; смешанное число прячет, что система выигрывает в одном режиме и проигрывает в другом
• границы для неоднозначных случаев: если порядок событий внутри бара неизвестен, считаются оптимистичная и пессимистичная оценки; вывод принимается, только если он одинаков в обеих
• контроль случайным входом: та же логика выхода на случайных входах должна проигрывать — иначе «эффект» создан не сигналом, а механикой выхода
• n ≥ 30 в каждой ячейке, out-of-sample и walk-forward, поправка на множественную проверку гипотез

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

Риск-контур выключает раньше человека

Многослойный монитор ходит по расписанию и проверяет несколько независимых условий остановки. Останов оформляется файлом-маркером, который видят все процессы, — это простой и надёжный kill-switch без сетевой зависимости. Дальше действует дисциплина: маркеры остановки не редактируются руками, возврат в работу — только через штатный скрипт, который проверяет причину останова. И отдельное правило для новых фильтров: сначала audit-режим, где фильтр только логирует своё решение, и лишь после накопления данных он получает право блокировать.