Обновления

Что было раньше

4 мая мы зашипили мульти-СРО («рулетка») — на определении суд иногда перечисляет 2–8 кандидатур СРО, и наша СРО может стоять не первой. Раньше система брала только первую СРО и молча теряла случаи, где наша на позиции 2–5.

Это работало для всех новых дел с 4 мая. Но для старых уведомлённых дел (до 4 мая) — мы видели в старом плоском поле sro_name только одну строку. Технически в PDF могло лежать 5 СРО, а ты видел одну. Никакого индикатора «здесь рулетка».

Ты это заметил 14 мая на деле А40-111932/2026 АО «РВС» (наше дело от 28 апреля) — там в PDF 5 СРО (ААУ ЦФОП АПК на позиции 2), а на дашборде показывалось только «ААУ ЦФОП АПК» — никакого сигнала, что это рулетка.

Что мы сделали

1. Backfill — заполнили мульти-СРО для исторических дел

Прошлись по всем 489 определениям в базе. Прочитали кэшированный PDF, прогнали через тот же экстрактор СРО, который работает в живом пайплайне с 4 мая (словарь + регекс), и записали все найденные СРО в таблицу ruling_sros с правильными позициями.

Результат:
- 361 определение уже имело мульти-СРО данные (это всё что после 4 мая — система их пишет автоматически)
- 91 определение не имело — и при пересборке нашлись СРО (от 1 до 8 на дело)
- 166 строк мульти-СРО добавилось в базу
- 35 определений прочитались, но СРО там действительно нет (отказы / возвраты без перечисления СРО — это правильное поведение)

Бэкфилл идемпотентный — повторный запуск ничего не дублирует.

2. Бейдж 🎰 в карточке дела

В колонке СРО рядом со старым тегом теперь появляется amber-бейдж, когда определение содержит ≥2 СРО:

• 🎰 ЦФОП — №2 из 5 — если наша СРО (ААУ ЦФОП АПК) в списке. Цифра — её позиция, вторая — общее количество. Это самый сильный сигнал: «здесь несколько кандидатур, и мы среди них».
• 🎰 8 СРО — если в списке нашей нет, но кандидатур несколько. Тоже полезный сигнал — рулетка крутится, можно зайти и побороться.

3. Фильтр «🎰 Несколько СРО (≥2)»

В выпадайке по статусу notified добавилась четвёртая опция (рядом с «Наши / без СРО» и «Чужие СРО»):

🎰 Несколько СРО (≥2)

Кликаешь — таблица сужается до дел, где в определении 2 и более СРО. На текущий момент таких дел 72.

Что ты увидишь

Открываешь denis.ownmail.dev → в шапке таблицы кликаешь Status → notified → 🎰 Несколько СРО (≥2).

Или сразу по прямой ссылке: https://denis.ownmail.dev/?status=notified&sro_filter=multi_sro

72 дела, отсортированные по дате — наверху самые свежие. У каждого видно полный список СРО (наведи курсор на бейдж — увидишь tooltip) и позицию нашей среди них.

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

«Без ЦФОП» дела — это контекст. Мы там борьбу не ведём, но если хочешь ручную ревизию закрома — теперь можешь.

Что дальше

• Watchpoint на 24-48 часов: новые дела продолжают писать мульти-СРО в реальном времени (так уже работает с 4 мая, не меняется). Если за неделю новые multi-SRO кейсы перестанут появляться — это сигнал, что экстрактор что-то поломал и надо смотреть. Цифра «72» на фильтре должна потихоньку расти.
• Telegram-уведомление с позицией («(позиция X из N)») приходит только на дела, обработанные после 4 мая. Старые дела бэкфилл не ре-уведомляет — старые сообщения в Telegram остаются как были. Это намеренно: не хочу спамить тебя дублями.
• Если в карточке дела видишь, что СРО в ruling_sros неполный (например, в PDF реально 5 СРО, а у нас в базе только 3) — это или словарь не знает редкую СРО, или регекс не справился. Скинь номер дела — добавим в словарь, бэкфилл можно прогнать повторно.

Технические детали

Что заказывали

На звонке 5 мая ты сказал:

«давай попробуем, две штыки»

≈ 100 писем × 2 батча, чтобы посмотреть отдачу. Никакого SaaS, никакой автоматизации до сигнала — просто понять, конвертится ли холодный outbound в кейсы.

Под это собирался OUT — отдельная подсистема внутри проекта: 10 тикетов (OUT-01..OUT-10), которые превращают «есть телефон лида в outreach_contacts» в «письмо ушло, ответ классифицирован, кейс в воронке».

Что мы сделали

Pivot Coldy → Smartlead

Изначальный план был на Coldy.ai — российский cold-email-первичный сервис. На неделе они заблокировали API за самым дорогим тарифом (₽9 400/мес) + у саппорта неудобные часы. Архитектура у нас специально была сделана с swap'абельным ESP-адаптером, поэтому смена провайдера прошла без боли.

Пивотнули на Smartlead.ai Basic ($35/мес ≈ ₽3 300) — те же возможности, Inbox Rotation «из коробки» (несколько ящиков на одну кампанию), cold-permissive policy. Свой собственный mailbox denis@127-fz.com на Yandex 360 «Бизнесе» — провели полную DNS-настройку (MX/SPF/DKIM/DMARC, всё green по mxtoolbox), создали custom tracking-домен emailtracking.127-fz.com, две кампании-заготовки уже там.

9 тикетов выкачены отдельными ветками на GitHub

Каждый тикет проехал по протоколу Codex review → fixes → APPROVE → commit + push. Ни одна ветка ещё не вмержена в main — это для твоего ревью на GitHub.

Что нового на дашборде

Когда смержим ветки в main и задеплоим:

• /outreach/queue — твоя главная страница для outbound. Видишь pending-кандидатов, читаешь черновики, одобряешь либо отклоняешь. Bulk-approve кнопка («штык 100» одним кликом).
• /outreach/funnel — built → approved → sent → delivered → opened → replied → positive — с фильтрами по source/template/variant. Видишь, какой шаблон работает.
• /u/<key>/<token> — публичная страница отписки. Когда лид жмёт «отписаться» в письме, попадает сюда → суппресс-роу + русская страница «Отписка зарегистрирована» с упоминанием ст. 18 ФЗ-152.
• PATCH /api/outreach/messages/{id}/reply_classification — когда regex угадал неправильно, ты в очереди жмёшь «изменить ярлык» (positive ↔ negative ↔ unclear).

Защитные слои

В OUT-05 sender реализованы семь стадий перед каждой отправкой:

1. Malformed-guard — если в кандидате нет email или тело пустое → failed, без вызова ESP.
2. Suppression gate (первая) — если email/domain/INN уже в outreach_suppression → suppressed, без вызова ESP. Это срабатывает ПЕРЕД дневным капом и pacing'ом — отписки приоритетнее.
3. Daily cap — если за UTC-сутки уже отправлено OutreachConfig.daily_global_cap (по умолчанию 200) → кандидат остаётся approved (отложен на следующий тик), без отправки.
4. Pacing — задержка между кандидатами (30 сек по умолчанию). В рамках лимита Smartlead Basic 50 req/min.
5. Idempotency claim — INSERT в outreach_send_attempts с ключом outreach-c<id>-a<retry>. UNIQUE-индекс ловит дубликаты, если cron перезапустится в неудачный момент.
6. Resolve campaign_id — берёт OutreachConfig.smartlead_campaign_id_<source>. Если None и адаптер не manual_copy → failed.
7. ESP send — Smartlead. На 2xx → пишем outreach_messages, статус кандидата → sent. На отказ → бамп retry_count. На третьем фейле → failed (terminal).

Плюс kill-switch: OutreachConfig.auto_send_globally_enabled=false коротко замыкает всё ещё до фетча кандидатов — на случай ЧП.

Reply-классификатор знает русские падежи

Тонкость: «не интересно» содержит подстроку «интересно» — regex без правил отнёс бы это к positive. Поэтому отрицательный regex проверяется первым:

• не\s*(интересн|пиш|нуж|хоч) или отпи[сш] / удалит / спам / стоп → negative
• Если негатив не сработал, интересн / давайте обсуд / свяж / готов(ы|а)? / подробн → positive
• Иначе → unclear

Класс отпи[сш] покрывает обе формы — инфинитивный корень («отписаться») и повелительный («отпишите меня»). Слова отпис/удалит дополнительно триггерят авто-suppress — суппресс-роу прилетает сразу, без твоего вмешательства. спам/стоп относятся к negative, но автомат не давит — это спорные сигналы, ты решаешь руками через PATCH-override.

Smartlead — что прямо сейчас

Smartlead Basic         ✅ оплачен с корп-карты Ivinco
mailbox denis@127-fz.com ✅ SMTP+IMAP green, warmup ACTIVE
DNS                      ✅ MX/SPF/DKIM/DMARC verified mxtoolbox
tracking domain          ✅ emailtracking.127-fz.com → Smartlead
campaign rouletka_v1     ✅ id 3325689, DRAFTED, mailbox linked
campaign obezdvizhka_v1  ✅ id 3325690, DRAFTED, mailbox linked
warmup-фаза              🟡 14 дней (стартовала 2026-05-12)

14-day warmup — Smartlead будет нагревать ящик от ~5 писем/день до ~50/день. Это нужно чтобы Gmail/Yandex/mail.ru видели рост репутации постепенно, не пометили как спам. Через 14 дней (около 2026-05-26) — flip на active sends.

Что осталось до запуска

OUT-10 (последний тикет)

Smoke-харнесс: end-to-end проверка по всем 10 шагам спеки. Прогон в shadow-mode (send_adapter='manual_copy') на dev-БД, потом один тестовый send живьём на твой адрес, чтобы убедиться что цепочка не разорвалась. Шипну в течение недели.

Твои шаги, когда warmup закончится

1. Залить SQL триггеров в config/outreach_sources.yaml — какие именно кейсы должны попадать в рулетка_v1 (no-SRO leads) и обездвижка_v1 (stalled cases). Сейчас там stubs.
2. Заполнить тело шаблонов в БД — outreach_templates для cession_offer@v2 и т.п. Голос — твой; я могу помочь черновиком.
3. Дать команду flip-кнопке — OutreachConfig.auto_send_globally_enabled=true в config.yaml на Hetzner + рестарт web-сервиса. После этого Approve в очереди начинает реально отправлять.
4. Первая «штык 100» — ты заходишь в /outreach/queue?status=pending, читаешь черновики, жмёшь Bulk Approve. Sender cron в течение 5-10 минут (pacing=30s × 100 = ~50 мин) отправит всё через Smartlead.

Технические соображения

Multi-branch вместо одного epic-merge

Все 9 тикетов лежат отдельными ветками на origin. Можно мержить по одной в порядке OUT-01 → OUT-02 → ... → OUT-08 (или одной большой PR'кой с тага OUT-07, который содержит все предыдущие в истории).

IMAP пароль уже на Hetzner

YANDEX_IMAP_PASSWORD положен в /opt/scrapers/bankruptcy-monitor/.env сегодня. Залогинились — OK LOGIN Completed, 5 сообщений в INBOX (вероятно, тестовые от Smartlead warmup). Когда OUT-07 cron активируется, эти 5 классифицируются как unclear (нет матча в outreach_messages — мы пока ничего не отправляли) → orphan-skip, marked SEEN, без записей в БД. Чистая разминка.

Метрики проекта

Что было раньше

У нас 4 источника данных: kad.arbitr (определения суда), fedresurs (намерения о банкротстве), pb.nalog (налоговая задолженность через «Прозрачный Бизнес»), egrul (ЕГРЮЛ). Каждый когда-то писался отдельно — kad самый старый и боевой, egrul самый новый.

Проблема, которую ты сам не видишь, но которая ест время:

• У каждого источника свой стиль ошибок. kad может «лечь» из-за DDoS-Guard, fedresurs из-за Qrator, pb.nalog из-за CAPTCHA, egrul из-за лимита запросов. Каждый раз когда что-то падает, я лезу в логи и должен помнить, как именно этот конкретный источник обозначает «упал».
• Если по конкретному определению пришёл странный результат (например, СРО не та или ничего не нашли), нет простого способа «пересчитать с нуля». Нужно лезть в БД и крутить SQL.
• Не было видно, что вообще происходит. Все 4 шли через cron-скрипты, и единственный показатель здоровья — «есть ли свежие записи в БД». Если источник молчит — это потому что он сломался или потому что просто новых дел нет?

Это всё операционка, которая копится. Каждый раз когда мы добавляли новую функцию (вроде EN-cascade недавно), приходилось решать вопросы заново для каждого источника.

Что мы сделали

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

1. Единый контракт для всех источников

Теперь все 4 источника живут под одним «договором»:

Это значит — когда мы в следующий раз будем менять, например, регекспы для извлечения СРО, я не лезу в 4 разных файла, а правлю один. И тесты автоматически прогоняются через все 4 адаптера.

2. Replay-кнопка на /ops/sources/{name}

На страницах /ops/sources/kad.arbitr, /ops/sources/fedresurs_spa, /ops/sources/pb.nalog, /ops/sources/egrul.nalog теперь видны последние 50 событий — что было сделано, когда, с каким результатом. Рядом с каждым событием — кнопка «Replay».

Зачем это нужно: если ты когда-нибудь заметишь, что по конкретному определению пришёл странный результат (например, парсер посчитал что СРО ЦФОП АПК, а ты вручную посмотрел — там МСРО Содействие), нажми Replay. Система пересчитает событие с текущей версией логики. Если регекспы или dict обновились — увидишь новый результат сразу. Без меня и без SQL.

3. Цветные бейджи здоровья на /ops/sources

На общей странице /ops/sources теперь у каждого источника видна цветная плашка:

• 🟢 зелёный (ok) — источник отвечает, латентность нормальная
• 🟡 амбер (degraded) — отвечает, но медленно или с ошибками (часто = CAPTCHA, временный rate-limit)
• 🔴 красный (failed) — упал, нужен оператор
• ⚪ серый (unknown) — нет данных о состоянии (например, мы ещё не делали health-check, или у источника нет дешёвого ping-эндпоинта как у EGRUL)

Это полезно когда я не у компьютера: ты сам можешь зайти и увидеть, что красное — это уже сигнал «звони Юджину».

4. Canary на kad.arbitr в shadow-режиме

Самая аккуратная часть. Старый монитор по kad.arbitr продолжает работать как обычно — ничего не меняется. Параллельно с ним мы запустили новый адаптер в shadow-режиме: он каждые 15 минут делает ровно то же самое, что старый монитор, но в БД ничего не пишет. Только сравниваем результаты.

Цель: 24 часа наблюдать, не разъезжается ли новый адаптер со старым. Если разъезжается больше 5% циклов — откатываемся, разбираемся, чиним. Если в пределах нормы — следующим шагом промоутим новый адаптер на место старого. Это уже отдельная задача после 24-часового окна.

Этот же подход применим к fedresurs/pb.nalog/egrul, но мы их пока не canary'им — у них тестовое покрытие через сравнения и контракт-харнесс, а risk-budget для shadow-сравнения на проде мы тратим аккуратно, по одному.

Что ты увидишь

Сегодня вечером и завтра

• На /ops/sources появятся цветные бейджи у kad.arbitr / fedresurs_spa / pb.nalog / egrul.nalog. На старте часть может быть серой — это норма, после первого health-цикла обновится.
• Зайдёшь на /ops/sources/kad.arbitr — увидишь таблицу последних 50 событий и кнопки Replay. Можно тыкать — это безопасно, не сломает прод. На каждый клик в БД остаётся след «replay started → success/failed», я смогу разобрать ретроспективно если что-то пойдёт не так.

В ближайшие 24 часа

Каждые 15 минут срабатывает canary по kad.arbitr — пишет одну запись в pipeline_events с пометкой step='canary'. Через сутки я гляну логи и:

• Если расхождений со старым монитором < 5% → планируем замену старого монитора новым адаптером (это будет следующий пост).
• Если ≥ 5% → откатываю canary, разбираюсь почему.

По остальным трём источникам

fedresurs / pb.nalog / egrul пока работают по-старому — старые скриптовые цепочки никто не трогал. Новые адаптеры готовы и протестированы, но включим их в прод следующим этапом, по одному, через тот же shadow-режим, чтобы не рисковать.

Что дальше

Через 24 часа: ретро по kad.arbitr canary, решение по flip-to-primary.

Следующая неделя: если kad.arbitr canary прошёл — повторяем для fedresurs / pb.nalog / egrul в той же последовательности.

Параллельно: теперь когда платформа есть, проще будет добавлять новые источники когда они нам понадобятся (например, ЕФРСБ через платный API, если решим, что оно того стоит — отдельный разговор).

Технические детали

1361795 cp5-10  canary cron + scope-boundary gate
52c5d66 cp5-09  health-status display + replay taxonomy validation
0b4d3da cp5-07  pb.nalog + egrul.nalog adapter migrations
a90e984 cp5-06  fedresurs_spa adapter migration
e6cb42c cp5-08  replay button UI
b42a409 cp5-05  replay dispatcher endpoint
82b1976 cp5-04  kad.arbitr adapter migration
7f87772 cp5-03  conformance test harness
8f59031 cp5-02  source registry auto-discovery + badge
d1b72fb cp5-01  BaseSource ABC + Pydantic v2 types

Что было раньше

Ты заметил, что с раннего утра 8 мая Telegram молчал — никаких новых уведомлений. Это не потому что нечего слать. Мониторинг упал в 06:23 UTC и 14 часов подряд каждый 15-минутный тик crash-ился на старте — браузер не мог открыть kad.arbitr.ru.

Когда я начал разбираться, всё выглядело как «прокси умер»: сайт Evomi у тебя не открывался, мне казалось — провайдер лёг. Но проверки показали другое:

• Evomi отвечал HTTP 200 за 122 мс на запрос их собственного сайта
• curl через тот же Evomi-прокси открывал kad.arbitr.ru без проблем (TLS handshake, 200 OK)
• А Chrome через тот же прокси падал с ERR_TUNNEL_CONNECTION_FAILED

Прокси работал. Падал именно браузер.

Параллельно у нас была другая задача — новый слой проверки должников через DaData (EN-cascade). Когда наша основная база bo.nalog возвращает 404 на ИНН (а это бывает у банков, страховых, недавно открытых ООО), мы помечали кейс как inn_not_in_db и забывали. Получалось, что жирные ACTIVE-юрлица тихо проваливались мимо, и ты их не видел в воронке. Этот слой был готов, но не «прожжён» в проде до сегодня.

Что мы сделали

1. Починили мониторинг (P0)

Корень проблемы оказался хирургическим: библиотека playwright-stealth, которую мы накладывали поверх patchright (наш undetected-движок). Patchright инжектит скрипт через свой внутренний URL patchright-init-script-inject.internal. С прокси на уровне браузерного контекста этот internal-запрос шёл через Evomi — а Evomi (как и любая residential-сеть) не умеет резолвить такие нерутируемые *.internal хосты. Каждый запрос ронялся, а с ним — вся загрузка страницы.

Patchright и так stealthed — двойной патчинг был антипаттерном. Убрали playwright-stealth из обоих клиентов (kad-monitor и casebook-discovery). Воспроизвели на проде минимальным репро и подтвердили — без stealth Chrome через Evomi проходит DDoS-Guard и открывает kad.arbitr.ru за 7 секунд.

Результат: прод восстановился в 03:37 UTC. Накопившиеся 488 кейсов сейчас догоняются. К утру 9 мая по Москве Telegram опять должен зашевелиться.

2. Активировали DaData identity layer

Логика проста: если bo.nalog не нашёл ИНН — спроси у DaData. Их ответ говорит:

• ИНН относится к ACTIVE юрлицу (ООО/АО/ПАО, не ИП и не физлицо) → мы зря его пропускали, надо мониторить
• ИНН найден, но юрлицо в LIQUIDATED / BANKRUPTCY / UNKNOWN → это уже не наша целевая аудитория, исключаем явно
• ИНН не найден вообще → оставляем как было, на будущий слой (web-search, PDF-parse)

3. Прогнали репетицию по существующим 152 кейсам

Это всё кейсы, помеченные inn_not_in_db за последние 4 месяца — из тех, что когда-то прошли первичный фильтр, но провалились на финансовой проверке.

Подчеркну: 109 кейсов — это потенциальные сделки, которые ты бы не увидел старой логикой. Прогон сделан в режиме «только посмотреть» (dry-run) — пока никаких изменений в базе нет.

Что ты увидишь

Сегодня вечером и завтра утром (МСК)

• В Telegram пойдут уведомления, которые накопились за 14 часов простоя — это backlog мониторинга, а не новые кейсы. Ничего не теряется, всё просто отложилось.
• На дашборде «watching» цифра колыхнётся вниз: за 14 часов часть кейсов ушла в notified/returned/rejected без Telegram, и теперь обработается пакетно.

Через ~24 часа (после стабильного наблюдения)

Я запущу второй прогон по тем же 152 ИНН в режиме «применить» — и 109 «жирных» кейсов перейдут в watching с отметкой «найдено через DaData identity». Дальше они работают как обычные watching-кейсы: monitor каждые 15 минут проверяет, не появилось ли определение, и шлёт тебе Telegram если СРО подходит.

На дашборде

• В «Сkipped» появится новая под-категория inn_not_in_db_dadata_inactive (35 кейсов) — это явно мертвые юрлица, чтобы ты не путал их с настоящими «не нашли»
• В «Watching» — новые 109 кейсов с пометкой qualified_by_dadata_identity

Что дальше

Ход 1 (через 24h): запуск backfill в режиме --apply. Тебя дёрну в Telegram когда буду готов — глянешь dry-run output (109 имён) на разумность.

Ход 2 (через 7 дней): замер реального recovery rate. Если из 109 в watching-статусе у нас будет приличная конверсия в notified (например, ≥30%) — слой DaData оправдал себя, движемся к следующему: web-search для тех 8% которые DaData не нашла.

Если recovery rate окажется низким (< 30%) — добавим следующий слой (Tavily / Perplexity web-search) для этих 8 «оставшихся». Это уже отдельный эпик.

Что было раньше

Предыдущие шаги дали два слоя видимости:

• CP-1 — реестр запусков. Таблица pipeline_runs, страница Ops · Runs. Видно когда стартанул cron_monitor или intention_stream, сколько шёл, упал или нет.
• CP-3 — админ-страницы поверх реестра. Расписание (Ops · Jobs), реестр источников и расходов (Ops · Sources), заглушка под детальный пробег /ops/runs/{id} с amber-плашкой «Per-event drill-down requires CP-2 ship».

Дыра в середине: «а что задача внутри себя сделала?» Прошёл ли intention-sweep по 700 компаниям? Сколько раз LLM вызывался и зачем? На каком шаге catalog-скрейпер уперся в Qrator-блок? Был ли это уже третий fetch_timeout подряд? — Всё это жило в логах в /var/log/bankruptcy-monitor/*.log. Чтобы что-то найти — grep-ать на сервере. Структурированного «а сколько у нас было intention.fetch_fail за вчера» — не было.

Плюс ошибки: если cron упал — в pipeline_runs.status='failed', exit_code какой-то, и всё. Стектрейс — найди его в логе. Никаких алертов.

Что мы сделали

Восемь подзадач, все на проде. Эпик #185 закрыт.

1. Таблица событий

Новая pipeline_events в data/observability.sqlite (отдельный файл от cases.sqlite — чтобы запись событий не конкурировала за блокировку с основной БД). 16 колонок: run_id (linkage с pipeline_runs), source/step/action (saved/dropped/errored/started/finished), reason_code (catalog.qrator_block, llm.over_budget, etc.), payload_hash + payload_size, error_msg, created_at, seq для упорядочивания внутри пробега.

Реестр валидных reason_codes — отдельный файл src/observability/event_reasons.py с 20 кодами, по семантическим доменам: catalog.* (6 кодов), intention.* (2), llm.* (8), provider.* (2), run.* (2). Любой неизвестный код в dev-режиме крашит ассерт; в проде — логируется в stderr и пропускается (fail-open).

2. Hot-path API

Функция track_event(...) синхронная, async-safe by construction: на горячем пути только in-memory append + микросекундный лок, ноль I/O. Воркер-тред каждые 200мс / 100 событий / на severity=high сливает буфер в SQLite одним батч-инсертом. Если процесс падает — atexit-хук сливает оставшееся.

run_step — контекстный менеджер обёртка вокруг произвольного блока кода — автоматически парные started/finished или started/errored события, замеряет latency_ms, ловит исключения.

3. Sentry init с PII-скраббером

init_sentry() в src/observability/sentry_init.py. Lazy import — sentry-sdk не подгружается если DSN не настроен. На инициализации: дефолтные интеграции отключены (никакие фреймворковые хуки не успеют схватить тело request'а до нашего скраббера); единственный хук — before_send, который:

• проходит по всему event (extra / contexts / tags / request / user / breadcrumbs / stacktrace.vars) и заменяет значения по ключам, матчящим PII-регекс — phone|email|inn|ogrn|kpp|passport|address|fio|otchestvo|surname|familia плюс кириллические эквиваленты фио|отчество|адрес|инн|кпп|огрн|телефон|почта|паспорт|счет|фамилия — на [REDACTED]
• считает стабильный fingerprint = SHA-256 от (exception_type, message[:200], top-3 stack frames «module::function») и режет до 10 событий per-fingerprint per-час. Sentry-шный event_id — UUID4 на каждое срабатывание, для группировки бесполезен; наш fingerprint склеивает повторы из одного места кода

Результат: даже если кто-то случайно сунет ИНН в logger.info(...) — в Sentry улетит [REDACTED]. И если runaway-цикл будет генерить одно и то же исключение 1000 раз в минуту — Sentry получит ровно 10 за час.

4. Ретенция

Суточный cron 35 4 * * * запускает scripts/cron_observability_retention.sh → удаляет события старше 90 дней и пробеги старше 365 дней. Пишется log в /var/log/bankruptcy-monitor/observability_retention.log. Если data/observability.sqlite залочен — таймаут 60с (busy_timeout PRAGMA), потом лог + следующий тик попробует снова.

5. Инструментация: 5 чокпоинтов

Места, где пишется событие на каждое решение — расставлены по «горячим» точкам пайплайна:

• catalog-скрейпер (_CatalogScraperBase): на каждой странице — started; на каждой строке — saved (записалось) или dropped catalog.freshness_unchanged (запись не изменилась); на ошибках — errored catalog.qrator_block / catalog.fetch_timeout / catalog.parse_error; при попадании в watermark — finished catalog.watermark_caught_up; при date_from-cutoff — dropped catalog.before_date_from
• intention-sweep: started / finished бэндят сам пробег; errored intention.fetch_fail на каждый failed snapshot fetch или per-guid publication fetch; dropped intention.filter_miss если discovery-filter отказал кейсу
• LLM-обёртка (call_with_audit): 11 точек — errored llm.api_key_missing / llm.over_budget / llm.prompt_template_error / llm.openrouter_exception / llm.parse_failed; dropped llm.confidence_low / llm.captcha_unsupported. Успешный вызов НЕ пишет в pipeline_events — для этого есть llm_extractions (cost, latency, raw_quote)
• provider health: errored provider.degraded только в момент пересечения порога (когда threshold впервые крестится за час). Single-probe failure → пишется только в provider_health_log, в pipeline_events не дублируется
• refresh-оркестраторы (refresh_catalog, refresh_cession_matches): started / finished на каждый пробег; errored run.early_abort если что-то упало до основной работы (например, BrowserSession.__aenter__ не смог поднять браузер)

6. Бенчмарк под нагрузкой

Перед деплоем — scripts/benchmark_observability_writes.py: на копии observability.sqlite запускается синтетическая нагрузка: Worker A симулирует cron-tick раз в 5 секунд, Worker B пишет 4 потока × 250 событий в секунду, Worker C читает. Замеряется p50/p95/p99 latency для pipeline_runs И pipeline_events. Verdict-функция: ratio > 1.5 → BLOCK; > 1.0 → APPROVE_WITH_CAVEATS; ≤ 1.0 → APPROVE. На бейслайне: APPROVE.

Что ты увидишь

В верхнем меню как было — три Ops-кнопки. Визуально на дашборде ничего не поменялось.

Под капотом — на текущий момент уже 137+ событий в pipeline_events за первый час после деплоя (события набегают на каждый cron_intention_stream, cron_p5_bl_* и cron_monitor тик). Каждое событие имеет run_id, который джойнится с pipeline_runs.id для того же пробега — это означает, что когда CP-3-страница /ops/runs/{id} подключит этот источник, на ней будет live-таймлайн.

Sentry уже подключён. Тестовое событие проверено — пришло в дашборд с правильным release (git-SHA), environment=production, тегом smoke_test=true чтобы фильтровать «не это», и со скрабленным контентом. Если что-то реально упадёт в проде — увидишь его в Sentry как Issue с email-нотификацией.

Что дальше

• CP-3-страница /ops/runs/{id} уже шипалась с amber-плашкой «Per-event drill-down requires CP-2 ship». Эта плашка теперь устарела — следующий шаг (отдельный мини-эпик) подключает источник pipeline_events к шаблону страницы и рисует гистограмму типов событий + raw-таймлайн. Спека готова, в очереди.
• Бейслайн lock-contention на cases.sqlite снят перед деплоем: p95=0ms, max=8ms, 0 таймаутов на 100К попыток за 30 секунд. Через 7-14 дней под реальной нагрузкой пересниму и сравню — если p95 уйдёт за 50% бейслайна, значит пишущий воркер событий бьётся за блок с основной БД (хотя они в разных файлах — поводов для контеншна не должно быть).
• Бэкапы data/observability.sqlite.backup-pre-cp2-20260508T182456Z (184КБ) + cases.sqlite.backup-pre-cp2-... (52МБ) лежат на Hetzner на случай отката. Снять можно после 15 мая.
• Sentry квота — Developer-план, 5К событий/мес. С нашим per-fingerprint rate-limit (10/час/класс) этого хватит на ~50 разных классов ошибок постоянно работающих. Если упрёмся — апгрейд на Team-план $26/мес.

Технические детали (для интересующихся)

Что было раньше

Прошлый шаг (CP-1) дал страницу Ops · Runs — список запусков всех 32 фоновых задач. Видно, что когда стартовало, сколько шло, упало или нет.

Но оставались дыры:

• «А когда они запустятся в следующий раз?» — расписания крона жили в crontab -l на сервере, не в UI. Чтобы посмотреть когда следующий пробег monitor, нужно было лезть по SSH.
• «Сколько мы тратим на каждый источник?» — Evomi-прокси, AstroProxy, 2captcha, OpenRouter, ЕГРЮЛ, Контур — расходы рассыпаны по разным таблицам. Не было единого ответа на вопрос «что у нас вообще есть и что почём».
• «Что именно сделал этот конкретный запуск?» — клик по строке в Ops · Runs ничего не давал. Только имя + длительность + статус.

Что мы сделали

Три новые страницы плюс реестр источников под капотом.

Ops · Jobs — расписание всех 32 задач

Читает cron_manifest.yaml (декларативный реестр всех cron-задач, заведённый в CP-1) и для каждой строки показывает:

• имя + русское описание
• расписание (cron-выражение */15 * * * * и т.п.)
• когда следующий запуск в UTC — посчитано через библиотеку croniter
• источники данных — какие именно сайты/API задача дёргает (например monitor → kad.arbitr)
• тип лока (single-instance / parallel)
• путь к bash-обёртке для отладки

Если cron-выражение битое или cron_manifest.yaml не парсится — страница не падает 500-кой, а показывает плашку с ошибкой и рендерит остальные строки.

Ops · Sources — реестр источников и расходы

Самая «жирная» страница. Группирует 24 источника по категориям:

• Источники данных (17) — kad.arbitr, casebook.ru, fedresurs.ru/backend, pb.nalog.gov.ru, ЕГРЮЛ, ФНП, Контур.Фокус и т.д.
• Инфра-провайдеры (7) — Evomi (residential proxy), AstroProxy, Hetzner, Selectel, 2captcha, OpenRouter (LLM fallback), Sentry

По каждой строке: тип (бесплатный скрейп / платный API / гибрид), статус (активный / устарел / отключён), коммит-бюджет в месяц, фактический расход с 1-го числа, дата последнего обновления записи.

Особый случай — три прокси-провайдера: их трафик пишется в общую таблицу без атрибуции по провайдеру (так исторически устроено), поэтому сверху рендерится строка «Unallocated proxy MTD: $X», а в каждой из трёх отдельных строк — заглушка (included above). Это не баг, это честное отображение данных.

2captcha считается отдельно — там MTD это сумма положительных дельт баланса (фильтрует пополнения, оставляет только реальный сжог). Если снапшотов меньше двух — показывается «balance only — burn calc requires 2 snapshots» вместо мусора.

Если cases.sqlite залочена долгим cron-ом — таймаут 5 секунд, потом ячейки MTD рендерятся как «Cross-DB read unavailable». Страница всё равно открывается.

Ops · Runs/{id} — детальная страница по одному запуску

Клик по любой строке в Ops · Runs теперь открывает детальную страницу. Рендерит все метаданные конкретного пробега: имя, статус, время старта/финиша, сколько шёл, сколько ждал блокировку основной БД, какой git-SHA крутился, путь к лог-файлу, код выхода.

Если CP-2 (следующая фаза, расширение телеметрии — детализация по обработанным записям) ещё не докатилась — страница показывает амбер-плашку «Per-event drill-down requires CP-2 ship». Когда CP-2 приедет, на той же странице сверху появится гистограмма по типам событий, снизу — пагинированный raw-таймлайн.

Реестр источников под капотом

Заведена новая таблица source_registry в data/observability.sqlite. 24 строки засеяны: имя, отображаемое имя, тип, категория, кост-модель (JSON), путь к Python-модулю-владельцу, статус. Имена нормализованы — twocaptcha (а не 2captcha), kontur_basic (а не kontur_focus), proxy_seller помечен deprecated (мигрировали на Evomi 30 апреля).

Cross-validation между реестром и cron_manifest.yaml: если cron-задача упоминает source_keys: ["kad.arbitr"], но в реестре такого имени нет — линтер ругается. Это защита от очепяток.

Что ты увидишь

В верхнем меню дашборда теперь три кнопки на префиксе Ops:

• Ops · Runs (с CP-1) — список запусков
• Ops · Jobs (новое) — расписание
• Ops · Sources (новое) — источники и расходы

И клик по любой строке в Ops · Runs теперь ведёт на детальную страницу /ops/runs/{id} — раньше это была пустая ссылка.

На текущий момент Ops · Sources уже показывает живые цифры:

• Evomi-прокси — $49.99/мес коммит, фактический расход с 1 мая в строке Unallocated proxy MTD
• AstroProxy — $20/мес коммит
• 2captcha — текущий баланс + сжог за месяц через дельты
• OpenRouter (LLM fallback) — фактический MTD из таблицы llm_extractions WHERE accepted=1
• Hetzner — $8/мес
• Selectel (RU-фасад) — $9/мес

И 17 строк источников данных — kad.arbitr, casebook, fedresurs, pb.nalog и остальные — у них $0/мес коммит (бесплатный скрейп), но видна дата последнего обновления записи и владелец модуля для отладки.

Что дальше

• 24-часовой watch до 9 мая ~07:00 МСК — следим чтобы /ops/sources не таймаутил на cases.sqlite под нагрузкой (там сейчас ~50 МБ и параллельные мониторинговые писатели)
• CP-2 (следующая фаза) уже частично замёрджена — пишет события на каждый шаг внутри запуска. Когда докатится полностью, страница /ops/runs/{id} оживёт: гистограмма событий + raw-таймлайн вместо текущей амбер-плашки
• Бэкапы /var/backups/bankruptcy-monitor/{observability,cases}_cp3_pre_*.sqlite лежат на Hetzner до 15 мая на случай отката, потом удалю вручную

Технические детали (для интересующихся)

Что было раньше

У нас 32 фоновых процесса, которые крутятся по расписанию: одни каждые 15 минут (мониторинг kad.arbitr), другие раз в день (поиск новых дел на casebook.ru, парсинг определений), третьи раз в неделю (обновление "Прозрачного бизнеса"), четвёртые раз в месяц (ЕГРЮЛ, ФНП).

Если что-то ломалось — узнавали либо из Telegram-алерта (если алерт настроен), либо случайно при просмотре логов в tail -f data/logs/*.log. Не было общего ответа на вопрос «всё ли запустилось сегодня?» — приходилось проверять каждый лог-файл отдельно.

Что мы сделали

Каждый раз, когда запускается любая из 32 задач, теперь записывается отдельная строка в журнал запусков:

• имя пайплайна (например monitor, discovery, p5_bl_biddings)
• когда запустился (с миллисекундной точностью)
• сколько шёл (длительность)
• статус: ok (отработал чисто) / failed (упал с ошибкой) / running (ещё идёт)
• код выхода (0 = успех, 1 = ошибка, 130 = прерван по Ctrl+C, 143 = убит сигналом TERM)
• git SHA — какая версия кода крутилась
• путь к лог-файлу для детальной отладки

Журнал хранится в отдельном файле базы (data/observability.sqlite), чтобы не мешать основной бизнес-БД (data/cases.sqlite). Это важно: даже если журнал сломается, сами задачи продолжат работать как обычно — телеметрия никогда не блокирует прод.

При сбое задачи (исключение в коде, kill -9, Ctrl+C) трап-обработчик в bash успевает записать failed + код ошибки прежде чем процесс завершится. Если же существующая задача уже имела свой обработчик выхода (например, cron_monitor.sh снимает lockfile при выходе) — наш обработчик корректно вызывает её первой и только потом пишет в журнал.

Что ты увидишь

Новая кнопка Ops · Runs в верхнем меню дашборда (https://denis.ownmail.dev) → откроет страницу со списком всех запусков:

• На каждой строке: что за пайплайн (русское описание простым языком), когда запустился (московское время), сколько шёл, успешно или нет (цветной индикатор)
• Фильтры: только running / только failed / по имени / лимит количества
• Сортировка: новые сверху или старые сверху
• Под капотом — это реалтайм из новой таблицы pipeline_runs

Например, на текущий момент уже видно:
- monitor → "kad.arbitr.ru мониторинг каждые 15 минут — новые определения по watching делам", запустился 03:52 МСК, шёл 1 мин 29 сек, статус ok
- archive_old_no_sro → "Архивация notified-без-СРО старше 14 дней", запустился 03:39, шёл 1 сек, ok (заархивировал 1 кейс)

Что дальше

• 24-часовой watch-период до 8 мая ~04:00 МСК — все 32 задачи должны зарегистрироваться хотя бы раз
• После — финальная проверка: не выросло ли время блокировок основной БД из-за новой телеметрии. Pre-deploy замер показал p95 = 1 мс, 0 таймаутов на 950 тыс попытках — должно остаться так же
• В планах CP-2 (расширение телеметрии — детализация по обработанным записям внутри каждого запуска) и CP-3 (детальная страница по конкретному запуску — drill-down + replay button)

Технические детали (для интересующихся)