56 commits

Author	SHA1	Message	Date
bot-backend	b90872b5d7	feat(ops/metrics): инфра-алерты уезжают в тему «метрики», клиенты остаются в «алертах» ... Форумная группа имеет три темы, но тема «метрики» была пуста: оба прямых получателя Alertmanager — telegram и telegram-heartbeat — брали топик из той же переменной METRICS_TELEGRAM_TOPIC_ID, что и сервис alert-ack. Развести их было нечем, и heartbeat вместе со всем инфраструктурным шумом падал в ленту клиентских инцидентов. Смешанные в одной теме, инфраструктура и клиентский инцидент не равны по срочности и приучают пролистывать обе. Вводится METRICS_TELEGRAM_INFRA_TOPIC_ID для прямых получателей Alertmanager. alert-ack и вебхук GlitchTip остаются на прежней переменной, тема поддержки не тронута. Пока новая переменная не задана, берётся старая — до этого момента поведение ровно прежнее, а не сломанное. Клиентская METRICS_TELEGRAM_TOPIC_LINE убрана целиком: после переезда обоих получателей на инфраструктурную строку шаблон её не содержит, а деплой продолжал бы её собирать и объявлять в envsubst. Тест, закрепляющий сборку такой строки, зеленел бы вечно и мешал бы её убрать. Проверено рендером, а не чтением: при заданной теме telegram и telegram-heartbeat дают 245, telegram-clients уходит вебхуком без темы; при незаданной — поля message_thread_id нет вовсе (пустое значение уронило бы Alertmanager целиком). Логика отката прогнана во всех трёх состояниях переменных. backend/tests/ops — 86 passed. Closes #3163	2026-08-27 21:50:51 +03:00
bot-backend	99125b8093	fix(ops/metrics): Prometheus не видел ни одного Alertmanager — цель file_sd осталась пустой ... Профиль alerts включили, а файл целей `alertmanager_targets.yml` остался плейсхолдером `[]`. Снаружи всё зелёное: alertmanager и alert-ack Up/healthy, деплой зелёный, в логах ни одной ошибки — при этом `activeAlertmanagers: []` и 1568 уведомлений в `prometheus_notifications_dropped_total`. Горящий с 26.08 `Watchdog` не доехал никуда, как и HostAgentDown с RemoteWriteStalled. Причина в том, что включатель профиля и цель для Prometheus лежали в разных местах: профиль поднимает deploy-metrics.yml по наличию токена и чата, а файл целей правился руками. Разъезд не ловится ничем — `[]` штатен при выключенном профиле, поэтому ни валидация, ни healthcheck, ни лог на него не реагируют. Файл становится производным (`alertmanager_targets.gen.yml`, в .gitignore) и рендерится деплоем тем же условием, что включает профиль: цель при включённых алертах, `[]` при выключенных. Рендер идёт до `up` и пишет усечением на месте, поэтому инод сохраняется и работающий Prometheus подхватывает цель сам — та же ловушка одиночного бинд-маунта, что уже описана в этом workflow у Alertmanager. Пустой список пишется явно, а не удалением файла: несуществующий путь docker подменяет каталогом, и Prometheus не стартует вовсе. Closes #3155	2026-08-27 21:10:25 +03:00
bot-backend	de940c7534	feat(ops): off-box копия рантайм-конфига — зашифрованной, иначе никак ... Четвёртый пункт приёмки #2203. В дампах есть колонки под pgp_sym_encrypt, ключ к ним лежит на самой машине и никуда не уезжает: потеря машины означает «дампы есть, расшифровать нечем». Ради этой связки шифрование в базе и заводилось. КУДА И ПОЧЕМУ ИМЕННО ТУДА. В тот же S3, отдельным префиксом env/, и только зашифрованным. Разобранные варианты: - рядом с дампами открытым — нельзя: ключ рядом с шифротекстом обнуляет шифрование, одна утечка доступа к бакету отдаёт и то и другое; - на соседний хост по SSH — потребовало бы завести доверие между машинами, которого нет (проверено: Permission denied (publickey)), то есть РАСШИРИТЬ периметр ровно тогда, когда #3075 его сужает; - отдельный бакет с отдельными ключами — правильнее всего, но требует новых учётных данных. Выбран единственный исполнимый без расширения доступа: шифротекст в S3, парольная фраза — вне S3. FAIL-CLOSED. Без фразы скрипт не выгружает файл открытым, а падает с явным сообщением и алертом. Молчаливая выгрузка ключа в бакет с дампами хуже отсутствия копии: создаёт ложное чувство защищённости. Фраза уходит через дескриптор, а не аргументом — иначе видна в ps любому пользователю машины. После шифрования файл проверяется обратной расшифровкой: без этого можно годами возить нечитаемый мусор и узнать в тот момент, когда он понадобился. Прогон на хосте 27.08 (подставной исходник, боевой не трогался): без фразы → код 1, файлов создано 0 с фразой → «Зашифровано и проверено расшифровкой», 110 байт своей фразой читается, чужой — нет ОДИН ШАГ ЗА ВЛАДЕЛЬЦЕМ, и он неустраним: фраза обязана жить там, где переживёт смерть машины, иначе копия бесполезна — расшифровать будет нечем. Сгенерировать её здесь и оставить на хосте нельзя по построению. Инструкция — в шапке скрипта. Пять тестов сторожат ровно те свойства, ради которых всё сделано. Прогон: 85 ops-тестов зелёные, ruff чист. Refs #2203	2026-08-27 16:32:27 +03:00
lekss361	4f77197f01	Merge pull request 'chore(ops): restore-дрель для базы tradein — она не покрывалась вовсе' (#3141) from chore/3xxx-restore-drill-tradein into main	2026-08-27 12:00:56 +00:00
bot-backend	ec6181b7b3	chore(ops): restore-дрель для базы tradein — она не покрывалась вовсе ... Дрель восстановления стоит в cron с #3085, но её строка берёт только `gendesign_*`. База tradein — клиентские оценки, листинги, дома, сделки — автоматически на восстановимость не проверялась ни разу: дампы снимались, уезжали в S3, и никто не знал, разворачиваются ли они. Сам `ops/restore-drill.sh` менять не пришлось — он с самого начала умеет оба проекта: находит globals по своей схеме имён (`tradein-globals-<ts>`), подставляет свой список таблиц для сверки. Не хватало ровно строки в cron. Прогнал на боевом дампе 27.08 перед тем, как добавлять (оповещение заглушено, чтобы не слать ложную тревогу): tradein-20260827-111102.sql.gz, 343 МБ → 58 c GRANT-ы применены, материализованные представления обновлены PostGIS 3.4.3, таблиц в public: 76 listings 109978 · listing_sources 106704 · deals 108623 houses 10400 · trade_in_estimates 1121 Сверка с боевой базой: houses, listings, deals, osm_poi сходятся точно; trade_in_estimates и user_events больше на проде ровно на строки, созданные ПОСЛЕ снятия дампа. То есть дамп верен. Еженедельно, а не раз в месяц: две минуты работы против месяца, в течение которого битый дамп остаётся незамеченным. Понедельник 03:00 — после дрели gendesign (02:15 первого числа) и до ночных бэкапов в 03:30.	2026-08-27 14:57:40 +03:00
bot-backend	053a5fb75c	feat(observability): кнопка «Принял в работу» под клиентским инцидентом (#3078) ... Alertmanager инлайн-клавиатуру не поддерживает, а без кнопки нет обратной связи «человек увидел и взял в работу»: 27.08 продукты лежали 10 часов, и вопрос «а кто-нибудь это читает» было не к кому адресовать. ГДЕ ЖИВЁТ. Рядом с Alertmanager, на инфраструктурной машине. У бота МЕРЫ уже есть приём обновлений, и повесить обработку туда было бы дешевле, но он работает на продуктовом хосте: при падении продукта кнопка оказалась бы мёртвой ровно тогда, когда нужна. ССЫЛКА, А НЕ CALLBACK. Callback требует читателя обновлений бота. Бот один, и его обновления уже читает МЕРА — второй читатель получил бы 409 Conflict и отобрал бы сообщения у поддержки. БЕЗ ПАРОЛЯ НА /ack/*, ОСОЗНАННО. Кнопку жмут ночью с телефона, когда лежит прод; требование пароля даст ноль нажатий. Защита — 128-битный токен под конкретное сообщение, живущий сутки; максимум, чего добьётся угадавший, — ложная отметка в чате, где сразу видно, что её поставил не человек. ТОЛЬКО КЛИЕНТСКИЙ МАРШРУТ идёт через сервис. Прочие алерты сохраняют прямой путь в Telegram: чем меньше звеньев, тем надёжнее. Если сервис лёг, Alertmanager повторяет доставку и переуведомляет каждые 30 минут — алерт задерживается, но не теряется. Дублировать вторым прямым каналом не стали: шум в канале тревог опаснее задержки. Девять тестов дёргают настоящие функции, подменяя один шов — вызов Bot API. Важнейший: при отказе отправки с клавиатурой сообщение уходит БЕЗ неё — алерт важнее кнопки.	2026-08-27 13:56:00 +03:00
lekss361	0f09c47418	Merge pull request 'fix(ops): оповещения уходят в тему «алерты», а не в переговорку (#2203)' (#3129) from fix/2203-notify-topic into main	2026-08-27 10:50:55 +00:00
bot-backend	8945ea5d04	fix(ops): оповещения уходят в тему «алерты», а не в переговорку (#2203) ... Канал включили — и алерты бэкапов посыпались в ОБЩУЮ тему форума. В форуме Telegram адрес сообщения это пара «чат + тема»: без message_thread_id всё попадает в General, причём без единой ошибки. sendMessage возвращает 200, доставка «успешна», просто не туда. Отказ того же класса, что и всё остальное сегодня: зелено везде, а человек, которому адресован алерт, его не видит. Оба отправителя (ops/lib-backup.sh и ops/uptime-healthcheck.sh) получили условную подстановку ${TELEGRAM_TOPIC_ID:+-d "message_thread_id=..."}. Условная намеренно: пустой message_thread_id= Telegram отвергает вместе со всем сообщением, а молчащий алерт хуже алерта не в той теме. Нет переменной — нет параметра, поведение прежнее бит в бит. Тест ИСПОЛНЯЕТ настоящий notify(), извлечённый из файла построчно, подсовывая подставной curl и проверяя, что реально ушло бы в сеть. Проверять подстроку в файле бессмысленно: она может стоять в мёртвой ветке. Копировать функцию в тест — тоже: копия разойдётся с оригиналом на первой правке. Сорсить файл целиком нельзя: у uptime-healthcheck.sh нет guard'а по BASH_SOURCE, и сорсинг запустил бы настоящие сетевые проверки.	2026-08-27 13:12:10 +03:00
bot-backend	6f120c6605	feat(observability): клиентский инцидент зовёт дежурного поимённо + чинит сломанное продолжение команды (#3078) ... Две вещи, вторая — исправление собственной ошибки из #3127. ## Дежурного зовут по имени 27.08 продукты лежали 10 часов, и в канале «диск занят на 86 %» и «клиенты не могут открыть сайт» выглядели одинаково. Появился отдельный маршрут: severity=critical И host=apps, то есть критично на ПРОДУКТОВОЙ машине — значит людям недоступна МЕРА и Site Finder, а не «где-то в инфраструктуре тесно». У такого сообщения другой текст (🚨 КЛИЕНТЫ ЗАТРОНУТЫ), упоминание дежурного и repeat_interval 30 минут против 3 часов у прочего критичного: пока инцидент не погашен, напоминание должно быть неудобным. Сужение по host=apps существенно. Без него дежурного звали бы на каждую инфраструктурную мелочь, и тег перестал бы что-либо значить за неделю. Сам аккаунт в репозиторий не попадает — берётся из METRICS_TELEGRAM_ONCALL. Дежурный меняется, конфиг в git — нет. Пустая переменная = сообщение без тега, поведение не ломается. ## Починка: комментарий внутри продолжения команды В #3127 блок rm -f вместе с комментарием встал МЕЖДУ строками, каждая из которых заканчивалась обратным слешем. Строки склеиваются, и весь вызов envsubst уехал в комментарий — конфиг Alertmanager перестал бы рендериться вовсе, при полностью зелёном деплое. Синтаксически это корректный шелл, bash -n такое не ловит, а в диффе не видно: строки выглядят как отдельные. Поэтому проверка структурная и применяется ко ВСЕМ shell-блокам workflow, а не только к месту ожога.	2026-08-27 13:05:32 +03:00
bot-backend	efaab2efda	chore(ops): адрес Poincare — 188.124.37.140 вместо заменённого 188.246.224.93 (#3110) ... Selectel заменил адрес сервера в ночь на 27.08 по нашей заявке: старый 188.246.224.93 фильтровался российскими операторами и не открывался ни с домашнего интернета, ни с мобильного (#3110). Новый адрес фильтрации не имеет — проверено с машины владельца после переключения DNS. Замена уронила сервер на 10 часов: адрес на порте сменился, а в ОС остался прежний (разбор и восстановление — #3119). Здесь только то, что осталось в репозитории. Единственное функциональное вхождение — дефолт HOST_IP в ops/selectel-ci-access.sh: скрипт открывает раннеру доступ на прод-хост, и с прежним значением он молча настроил бы доступ на адрес, которого у нас больше нет. Остальные семь — тексты комментариев в Caddyfile-секциях, compose, bootstrap-скриптах и раннбуке крона; они не исполняются, но именно по ним сверяются при переезде, и разошедшийся адрес в них дороже, чем кажется.	2026-08-27 11:23:37 +03:00
bot-backend	c093eaafe5	fix(observability): пароли не уезжают в Loki — скруббер учётных данных (#3114) ... postgres_exporter при неудачном скрейпе печатает полный DSN вместе с паролем. Замер по Loki за сутки: 104 такие строки на инфра-хосте и 106 на продуктовом. При ретенции 30 дней это порядка 6000 строк с паролями БД в хранилище, доступ к которому даёт вход в Grafana - причём внешний basic_auth с витрины сегодня же снят (#3113). Проверено экспериментом, а не предположено. Напрашивалось передать пароль отдельно от строки подключения (DATA_SOURCE_URI + DATA_SOURCE_USER + DATA_SOURCE_PASS_FILE). Прогон на скретч-контейнерах с настоящим файлом запросов показал: НЕ помогает - экспортер собирает строку сам и логирует её целиком. Первые три попытки воспроизведения были неинформативны (контейнер падал сразу; скрейпа не было; не подключён файл кастомных запросов) - утечка воспроизводится только при неудачном скрейпе с нашим queries.yml. Стало: ступень loki.process между источником журнала и loki.write, маскирует пароль в любом URL вида scheme://user:pass@host. Пользователь и адрес остаются - без них строка ошибки перестаёт годиться для диагностики. Ровно одна группа захвата: Alloy заменяет содержимое групп, вторая затёрла бы имя пользователя. Это защита в глубину, а не замена причине. Конкретно эта ошибка уходит грантом pg_monitor (запрос pg_wal_bytes в нашем queries.yml требует pg_ls_waldir) - это боевая БД и остаётся за владельцем. Скруббер же ловит любой пароль в URL, включая компоненты, о которых мы ещё не знаем. Регулярка без экранирования намеренно: Alloy не принимает \s в строке (unknown escape sequence), поэтому класс задан явным пробелом. Оба конфига прогнаны через `alloy fmt` образом grafana/alloy:v1.6.1 - синтаксис ok. Тесты (8) берут выражение ИЗ КОНФИГА и применяют к настоящей строке из прода: пароль исчезает; пользователь и адрес остаются; обычные URL и почтовые адреса не портятся; журнал направлен в скруббер, а не мимо него. Фальсификация: на исходных конфигах краснеют все 8. tests/ops целиком - 43 passed.	2026-08-26 15:50:57 +03:00
bot-backend	5b7ef161e3	feat(observability): алерты адресуются в топик форумной группы (#3078) ... Бот, которым шлются тревоги, — тот же, что пересылает сообщения поддержки, а его чат форумный. Без message_thread_id Alertmanager кладёт тревоги в общую тему, вперемешку с клиентской перепиской. Поле поддерживается: проверено amtool check-config на том же образе, что поднимается в проде (prom/alertmanager:v0.28.0). Схема Alertmanager строгая и неизвестные поля отвергает, так что успешная проверка означает именно поддержку, а не молчаливое игнорирование. Подставляется ЦЕЛАЯ СТРОКА, а не значение: envsubst не умеет условий, и при шаблоне вида `message_thread_id: ${TOPIC_ID}` незаданный топик дал бы `message_thread_id:` без значения. Это не деградация - Alertmanager с таким конфигом не стартует вовсе, то есть алертинг исчезает целиком. Деплой формирует либо всю строку с отступом, либо пустую. Топик необязателен: без него поле отсутствует, алерты уходят в общую тему, поведение прежнее. Попутно добавлена проверка конфига через amtool ДО подъёма стека - по образцу `caddy validate` ниже в этом же файле. amtool берётся из того же образа, что и сам Alertmanager, иначе проверялась бы не та версия схемы. Битый конфиг теперь роняет деплой громко, а не выключает алертинг тихо. Тесты (4) рендерят шаблон обоими способами и разбирают результат как YAML - проверяется фактический конфиг, а не наличие нужных слов в тексте. Отдельно проверено, что переменная объявлена в списке envsubst: забыть её - значит оставить в конфиге литерал плейсхолдера. Фальсификация: на исходных файлах краснеют 3 из 4; проходит только тест, фиксирующий сохранённое поведение при незаданном топике. tests/ops целиком - 35 passed.	2026-08-26 14:10:56 +03:00
bot-backend	a72d39d74d	fix(observability): cAdvisor 0.55.1 — 0.52 не видит контейнеры на Docker 29 ... #3108 не починил пустые панели по контейнерам, и правило relabel там было ни при чём. Настоящая причина глубже: Docker 29 на обоих хостах работает через containerd-snapshotter (Storage Driver = overlayfs), а cAdvisor 0.52 ищет метаданные слоя в легаси-хранилище: failed to identify the read-write layer ID for container "<id>" - open /rootfs/var/lib/docker/image/overlayfs/layerdb/mounts/<id>/mount-id: no such file or directory При снапшоттере этого каталога нет вовсе — в /var/lib/docker/image/ лежит только identity-cache.db, метаданные слоёв живут в containerd. Обработчик контейнера не создаётся, и наружу уходит ровно один ряд: корневой cgroup container_last_seen{id="/"}. Отсюда и «нодата» на панелях контейнеров при живых node/postgres/app метриках. 0.55.1 умеет читать containerd-снапшоттер. Проверено пробами с ПРОДОВЫМИ флагами на обоих хостах (одноразовые контейнеры, убраны за собой): Beget (Docker 29.4.1): 22 ряда, все с name=, ошибок rw-layer 0 Poincare (Docker 29.7.2): 23 ряда, все с name=, ошибок rw-layer 0 Примеры рядов — name="gendesign-alloy", name="gendesign-backend-1", name="gendesign-osrm-1", с лейблом image. То есть именно то, чего не хватало панелям. Заодно поправлен комментарий, который я же вписал в cadvisor_trim в #3108: он объяснял пустые панели трактовкой пустого regex, а это оказалось неверно. Правило корректно и остаётся (корневой ряд приходит с name="" и должен отсеиваться), но объяснение рядом с ним вводило в заблуждение. Почему тег .1, а не .0: в реестре нет ни v0.53.0, ни v0.54.0, ни v0.55.0 — только v0.54.1 и v0.55.1. Проверял по списку тегов, а не подбором. Проверки: yaml.safe_load compose — ok; alloy fmt обоих .alloy в grafana/alloy:v1.6.1 — exit 0.	2026-08-26 13:40:03 +03:00
bot-backend	c6e15954ba	fix(observability): контейнерные метрики терялись целиком + два хвоста стека ... Три независимых дефекта, найденных на живом проде после подъёма стека метрик. 1. cAdvisor-метрики не доезжали ВООБЩЕ. В Prometheus ноль имён container_* при 2034 именах всего, хотя cAdvisor отдаёт 880 рядов, scrape-таргет в alloy health=up с последним скрейпом 10 мс назад, а remote_write рабочий (node/postgres идут через него же и доезжают). Методом исключения — потери в prometheus.relabel.cadvisor_trim, во втором правиле: rule { source_labels = ["name"], regex = "", action = "drop" } Замысел был выкинуть безымянные cgroup-ряды (id="/"). Но regex в Alloy документированно дефолтится в (.*), и пустая строка неотличима от незаданного значения — такой drop рискует выкидывать вообще всё, что и наблюдалось. Заменено на однозначное keep regex=".+" — тот же замысел, без зависимости от того, как трактуется пустой regex. 2. healthcheck alloy не мог пройти никогда: дёргал wget, которого в образе grafana/alloy нет (как и curl, и nc). Контейнер вечно unhealthy при полностью исправном alloy — ложная тревога, маскирующая настоящие сбои. Заменено на сырой HTTP через bash /dev/tcp, без внешних утилит. 3. Prometheus раз в минуту писал "lookup alertmanager: no such host" и держал up{job="alertmanager"}=0. Alertmanager намеренно за профилем alerts до решения #3078 — дефект не в профиле, а в безусловной ссылке на сервис. Оба места (alerting.alertmanagers и job_name: alertmanager) переведены на file_sd_configs с файлом целей, по умолчанию пустым: целей нет — ошибок тоже нет. Prometheus перечитывает file_sd на лету, поэтому включение профиля сведётся к наполнению файла, без рестарта и правки конфига. Файл целей смонтирован в сервис prometheus явным volume. Проверено на живом хосте, не на глаз: - alloy fmt обоих .alloy в одноразовом контейнере grafana/alloy:v1.6.1 - exit 0 - promtool check config в prom/prometheus:v3.1.0 - valid, 16 rules found - механизм нового healthcheck выполнен внутри работающего gendesign-alloy: первая строка ответа "HTTP/1.0 200 OK", grep матчится, RESULT=HEALTHY - наличие bash/head/grep/printf в образе alloy подтверждено command -v	2026-08-26 13:14:28 +03:00
bot-backend	124cfb3d5d	feat(observability): /metrics в обоих бэкендах — счётчики, задержка, дашборд ... Третья часть #3078 и единственная, трогающая прод-код. До неё числовых рядов у приложений не было вовсе: только логи и исключения в GlitchTip. Класс отказов «отвечает, но медленно» и «отдаёт 401 потоком» в такой картине невидим — исключения нет, строка в логе выглядит обычной, а продукт при этом не работает. Метка route — ШАБЛОН маршрута, а не путь запроса. Это несущее решение, а не деталь: кадастровый номер или идентификатор заявки в метке даёт новый временной ряд на каждую сущность, а ряд у Prometheus стоит памяти постоянно, а не в момент запроса. Самый известный способ уронить мониторинг тем самым мониторингом. Незаматченные пути (404, сканеры) сведены в одну метку, иначе тот же взрыв устроит любой бот, перебирающий адреса. Оба свойства сторожатся тестами, а не комментарием: тест бьёт тремя разными идентификаторами и требует ОДИН ряд. Слой регистрируется последним и потому оказывается самым внешним. Изнутри RBAC-гварда не видно ни отказов авторизации, ни времени, которое он тратит на резолв сессии в БД auth, — а именно этот путь уже давал инцидент с блокирующим I/O в middleware (#1202). Упавший исключением запрос считается как 500 в finally: без этого он просто отсутствовал бы в счётчике, то есть ровно тогда, когда метрики нужнее всего. Путь публичен ВНУТРИ и закрыт СНАРУЖИ — это два разных периметра. Скрейп идёт из docker-сети, где заголовка X-Authenticated-User нет ни у кого, поэтому /metrics внесён в _PUBLIC_PATHS обоих бэкендов; иначе агент получал бы 401 и метрик не было бы вовсе. Наружу путь не открывается ни через gendsgn.ru, ни через meraocenka.ru, и вдобавок закрыт явным respond 404 в обоих site-блоках — чтобы закрытость осталась решением, а не следствием текущего порядка директив. Ограничитель частоты и аудит «Меры» не трогались: оба смотрят только на пути под /api/, скрейп под них не попадает. Проверено тестом, а не чтением. Прод-поведение не меняется ничем, кроме нового публичного пути: ни один существующий обработчик, гвард или маршрут не тронут. Refs #3078	2026-08-26 11:30:18 +03:00
lekss361	afd881d6b1	Merge pull request 'feat(observability): стек метрик и логов — Prometheus, Loki, Grafana на Beget, агенты на обоих хостах' (#3099) from feat/observability-metrics-stack into main	2026-08-26 08:25:23 +00:00
bot-backend	7b6832e90f	feat(observability): дашборд баз данных — раздутие, горизонт vacuum, WAL ... Вторая часть #3078. Конфигурация экспортеров приехала первым коммитом, но смотреть на неё было негде: без витрины ряды есть, а ответа на вопрос нет. Панели подобраны по разборам постфактум, а не по списку «что обычно рисуют». Доля апдейтов мимо HOT — потому что у listings она была 0,43 % при 198 апдейтах на строку, и именно это дало 15 ГБ TOAST при 230 МБ живого содержимого (#2992/#2989), копившиеся 91 день. Возраст самой старой транзакции — потому что осиротевшие запросы висели 46 часов и держали горизонт видимости, из-за чего autovacuum не убирал мёртвые строки во всей базе (#2607). WAL за сутки — потому что 7,02 ГБ при четырёх пользовательских расчётах это диспропорция, заметная только на ряде. Размер баз — потому что у GlitchTip нет политики ретенции вовсе, и он растёт без ограничения. Размеры разложены на heap / индексы / TOAST: суммарный размер таблицы не объясняет ничего, а именно это разделение объяснило, куда ушли 19 ГБ. Отдельная панель «экспортер отвечает»: пустой график и упавшая база выглядят одинаково, и различать их должно что-то явное. Refs #3078	2026-08-26 11:23:33 +03:00
bot-backend	309d273f3f	feat(observability): стек метрик и логов — Prometheus, Loki, Grafana, агенты на обоих хостах ... Метрик в проекте не было ни одной: ни экспортеров, ни /metrics в бэкендах, единственный канал наблюдения — journald, единственный сигнал об аварии — исключение в GlitchTip. Из-за этого целый класс отказов невидим в принципе: задача рапортует done, строк ноль, исключения нет. Так протухли данные на семь месяцев (#2998), 34 дня был мёртв house_imv_backfill (#2698), 8 суток писал ноль newbuilding_enrich (#2767), 91 день копилось раздутие listings (#2992). Grafana не заменяет GlitchTip: ошибки остаются там. Grafana OSS не принимает Sentry DSN ни одним компонентом, а скрубберы в before_send — требование 152-ФЗ. Здесь появляется другой класс данных: ряды и алерты по трендам. Наблюдатель поставлен у ДРУГОГО провайдера, чем наблюдаемое: серверная сторона на Beget, рядом с GlitchTip. Если ляжет Poincare, мониторинг должен об этом сказать, а не лечь вместе с ним. Транспорт push, а не pull: агент на Poincare шлёт remote_write и логи исходящим HTTPS, поэтому там не открывается ни одного входящего порта сверх 22/80/443. При обрыве канала Alloy копит в WAL и досылает — pull-скрейп в той же ситуации терял бы точки именно в аварии, ради которой мониторинг и нужен. Два контура доступа с разными учётками. Пароль приёмника по построению лежит открытым на продуктовом хосте, значит его компрометация неизбежна вместе с хостом; будь это учётка витрины, утёк бы и доступ к дашбордам. GlitchTip читается прямым SQL, а не Sentry-плагином: у плагина на 6.1.6 stats_v2 отдаёт 500 (баг GlitchTip #381), Events/Discover — 404 (#416), а в grafana/sentry-datasource слово glitchtip не встречается ни разу. Схема сверена на живой базе: колонка времени называется timestamp, а не received, и отдельной таблицы IssueIndex не существует — агрегаты лежат на самой issue_events_issue. Алерты за профилем alerts: канал доставки — открытый вопрос #3078, и стек не должен на нём стоять. Деплой предупреждает, что уведомлять пока некому. Каждая настройка, способная отказать молча, закрыта явно: ретенция Prometheus задана и по времени и по размеру, retention_enabled у компактора Loki (без него retention_period не работает вовсе), путь к журналу и запуск Alloy от root (иначе агент читает ноль записей без ошибки), проверка Caddy до перезагрузки (на этом хосте тот же Caddy держит git, errors и obsidian). Refs #3078	2026-08-26 10:45:54 +03:00
bot-backend	c7df2732bd	fix(ops): алерт не теряется от одного сетевого отказа (#3059) ... Путь Selectel-Telegram теряет соединения. Замер 26.08 с Poincare, 40 подключений к закреплённому (#3093) 149.154.167.220: успешно 37 из 40, отказов 3 (7.5%) - все TimeoutError время успешных: min 0.14s, медиана 0.15s, max 0.17s Отказы происходят на стадии ПОДКЛЮЧЕНИЯ - быстрые стабильные успехи на фоне редких таймаутов. Три остальных дата-центра Telegram с Selectel недостижимы вовсе, так что закрепление адреса потери убрать не может: запасного адреса нет. Бот это переживает своими ретраями (106 таймаутов за сутки, 97 лечатся первой же повторной попыткой), а вот алерты - нет. uptime-healthcheck.sh: был один curl и `|| log WARN` - каждый отказ терял уведомление целиком. Сторож, который не может дозваться, - худший вид самоскрывающейся поломки: чем хуже дела на проде, тем выше шанс, что о них не сообщат. Ирония в том, что ниже в этом же файле HTTP-проверки уже повторяются циклом: ретраили то, что измеряют, но не то, чем докладывают. lib-backup.sh: тоже один curl, но с падением в почту (#3070). Алерт не терялся, зато каждый транзиентный таймаут впустую сжигал последнее средство вместо простого переподключения. Стало: цикл из трёх попыток в обеих notify(). Не `curl --retry` - семантика --max-time при ретраях зависит от версии curl, а цикл даёт таймаут на КАЖДУЮ попытку и повторяет идиому, уже принятую в uptime-healthcheck.sh. Дубль вместо потери - осознанный размен: sendMessage не идемпотентен, но отказ случается ДО отправки запроса, так что повтор почти никогда не продублирует доставленное. Лишний алерт безвреден, пропущенный - нет. Тесты (backend/tests/ops/test_3059_alert_retry.py, 7 шт) исполняют РЕАЛЬНЫЕ notify(), извлечённые из обоих скриптов, с подставным curl, отказывающим заданное число раз, и считают фактическое число попыток. Фальсификация: на исходных скриптах краснеют 6 из 7. Проходит только test_backup_falls_back_to_mail_when_telegram_is_really_down - он фиксирует сохранённое поведение, а не регресс. Проверено: `bash -n` обоих скриптов (та же проверка, что в CI - shellcheck там нет); конструкция `[[ ]] && cmd` в конце тела цикла безопасна под `set -euo pipefail`, который стоит в uptime-healthcheck.sh:25 (проверено исполнением, не рассуждением); tests/ops целиком - 22 passed.	2026-08-26 10:02:46 +03:00
lekss361	12e48a7783	fix(ops): страж повторной заливки перестал молча пропускаться (#3092)	2026-08-25 06:44:41 +00:00
lekss361	00d434f88d	chore(ops): backup-couchdb.sh исполняемый, как остальные бэкапы (#3091)	2026-08-25 05:48:41 +00:00
lekss361	bffec49434	feat(ops): у волта Obsidian появился автоматический бэкап (#3090)	2026-08-25 05:44:16 +00:00
lekss361	d99f733f41	fix(ops): восстановление не падает в хвосте из-за незаведённых ролей (#3089)	2026-08-25 05:18:53 +00:00
lekss361	2feb0de446	fix(ops): бэкап без выгрузки в S3 падает, а не рапортует успех (#3086)	2026-08-24 17:50:18 +00:00
lekss361	536137d460	feat(ci): деплой проверяет, к тому ли хосту подключился (#3079)	2026-08-24 16:36:50 +00:00
lekss361	be2e07d9c3	feat(ops): лёгкий Postgres на Beget под forgejo и glitchtip (#3080)	2026-08-24 16:31:12 +00:00
lekss361	f52601de41	feat(ops): бэкапить конфигурацию Forgejo, а не только его содержимое (#3073)	2026-08-24 03:49:58 +00:00
lekss361	0ba52e55db	chore(ops): развести crontab по хостам под переезд (#3072)	2026-08-24 02:04:40 +00:00
lekss361	3a7fc2ff65	feat(ops): запасной канал алертов на случай недоступного Telegram (#3070)	2026-08-23 23:55:40 +00:00
bot-backend	05e82989a8	fix(ops): закрепить рабочий адрес api.telegram.org на новом хосте ... Замер 2026-08-23 с Poincare: у api.telegram.org семь публикуемых адресов, отвечает РОВНО ОДИН — 149.154.167.220 (302 за 0.11 с). Резолвер при этом отдаёт 149.154.166.110, который мёртв. Скан всего 149.154.167.0/24 подтвердил: живой он один во всём блоке. Это не блокировка Selectel и не наш файрвол: с Beget отвечают три адреса из тех же семи, включая тот, что отдаёт DNS там. Telegram частично фильтруется у ОБОИХ провайдеров, просто Beget попадает на живой адрес. Через прокси ASocks Telegram не проходит ни с одного из четырёх узлов (все 000) — узлы российские, путь закрыт. Без закрепления tradein-tgbot на long-polling резолвит мёртвый адрес, виснет и умирает МОЛЧА: restart поднимает его заново, он снова виснет, ни краша, ни строки в логе. Закреплены все три потребителя Telegram, а не только бот: - tgbot и backend — extra_hosts в новом docker-compose.selectel.yml. backend тоже ходит в Telegram: пересылка алертов GlitchTip (api/v1/glitchtip.py) и support-чат (api/v1/support.py). - хостовые скрипты ops/lib-backup.sh и ops/uptime-healthcheck.sh — шаг 11 в selectel-bootstrap.sh кладёт запись в /etc/hosts. Им compose не помогает, они идут из cron, не из контейнера. Отдельный override-файл, а не правка docker-compose.prod.yml: на Beget закрепление не нужно, и менять поведение действующего прода ради будущего хоста нельзя. Файл просто не передаётся в -f. Адрес вынесен в TELEGRAM_API_IP с текущим дефолтом — если он умрёт, правка в одну переменную окружения без релиза. Шаг bootstrap проверяет не факт записи, а что Bot API отвечает 401 на фиктивный токен, и при другом коде печатает команду поиска нового живого адреса. Проверено: docker compose config даёт ровно две вставки extra_hosts (tradein-backend, tradein-tgbot) и ничего больше; TELEGRAM_API_IP подставляется в обе. Refs #3059, #3057	2026-08-23 23:32:35 +03:00
bot-backend	fb75bce22d	fix(ops): hardening sshd молча не применялся из-за приоритета cloud-init ... Найдено при первом живом запуске на Poincare. Ubuntu кладёт в /etc/ssh/sshd_config.d/ файл 50-cloud-init.conf с PasswordAuthentication yes. sshd берёт ПЕРВОЕ встреченное значение директивы, а не последнее, поэтому наш 60-hardening.conf проигрывал по имени: после reload парольный вход для root остался бы открытым. Коварство в том, что `sshd -t` при этом отвечает «конфиг валиден», и скрипт рапортовал об успехе. Сервер уже под перебором (fail2ban держал 6 адресов), так что тихий отказ здесь стоил бы дорого. Три правки: - файл называется 00-hardening.conf и читается первым; старый 60-* удаляется, чтобы повторный запуск не оставил два конфликтующих; - после записи проверяется не синтаксис, а ИТОГ через `sshd -T`: если passwordauthentication != no, скрипт падает и НЕ перезапускает sshd; - комментарий про версии Docker приведён в соответствие с поведением — ставится последняя из репозитория, версии прода служат ориентиром для предупреждения (приехали 29.7.2 / 5.5.0 против 29.4.1 / v5.1.3).	2026-08-22 12:56:22 +03:00
bot-backend	6484116079	chore(ops): скрипты аудита и первичной настройки выделенного сервера Selectel ... Сервер Poincare (SPB-4, 188.246.224.93) поднят 22.08.2026. Два скрипта под переезд (#2989, #3027-#3032). selectel-audit.sh — только чтение. Отвечает на вопрос, который надо закрыть до установки чего бы то ни было: собраны ли диски в зеркало. Переставить ОС можно только пока сервер пустой. Результат первого прогона: RAID1 на всех трёх разделах ([2/2] [UU] на /boot, swap и /), память non-ECC подтверждена (Error Correction Type: None), 910G свободно из 924G. selectel-bootstrap.sh — идемпотентная настройка: пользователь с ключом, ufw, Docker версий текущего прода (29.4.1 / v5.1.3), лимит журналов контейнеров, sysctl, unattended-upgrades, fail2ban, ужесточение sshd. Порядок шагов выбран так, чтобы не потерять доступ: правило для SSH добавляется ДО включения файрвола, а sshd в конце намеренно НЕ перезапускается — сначала проверяется вход по ключу в отдельном окне. При выключенном PasswordAuthentication ошибка означала бы IP-KVM за 1320 руб. Два умолчания выставлены по факту, а не по привычке: - часовой пояс Europe/Moscow, а не UTC — оба хоста сейчас на MSK, и смена пояса сдвинула бы все шесть cron-задач (бэкапы, геокодинг) на три часа; - swap не создаётся, если он уже есть — установщик Selectel отдаёт раздел 4.7G в зеркале, добавлять файл поверх незачем при 62G памяти. .gitattributes: *.sh с LF — иначе скрипт, отредактированный под Windows, падает на удалённом хосте с `$'\r': command not found`.	2026-08-22 12:49:09 +03:00
lekss361	e80c9e08df	Merge pull request 'ops(backup): missed-run detection + Forgejo code/DB backup to S3' (#3025) from feat/2203-backup-staleness-and-forgejo into main	2026-08-21 17:12:03 +00:00
bot-backend	b588278923	fix(ops): дрилл восстановления ждал БД по сокету и умирал на старте настоящего сервера ... `ops/restore-drill.sh` проверял готовность через `pg_isready -U postgres`, то есть по unix-сокету. Образ postgres во время инициализации поднимает временный сервер, который на сокете уже отвечает "accepting connections". Проба зеленела посреди initdb, восстановление начиналось в этот временный сервер и погибало, как только entrypoint гасил его ради настоящего: [12:26:22Z] Restoring dump into 'drill' (ON_ERROR_STOP=1 ...) FATAL: terminating connection due to administrator command server closed the connection unexpectedly Воспроизведено на проде 2026-08-21 на живом дампе `tradein-20260821-013001`: падение через 6 секунд после старта. С `-h 127.0.0.1` тот же дамп проходит восстановление и доходит до сборки индексов — временный сервер TCP не слушает, поэтому по TCP проба зеленеет только на настоящем сервере. Ровно та же проба и ровно по той же причине уже стоит в `.forgejo/workflows/ci-tradein.yml:137-141`. Тот же дефект живёт и в `.forgejo/workflows/deploy-tradein.yml:718-721` — там его чинят в PR #3011, здесь не трогаю. Refs #2203, #2989	2026-08-21 15:42:36 +03:00
bot-backend	c6b408e483	fix(ops): restore +x on new ops/*.sh (exec bit lost in prior commit, Windows core.filemode=false)	2026-08-21 15:38:31 +03:00
bot-backend	83be088263	feat(ops): missed-run detection for backups + Forgejo code/DB backup to S3 ... Deliverable 1: ops/backup.sh and tradein-mvp/deploy/backup-tradein-db.sh now write a sentinel file on every verified-good run. A new ops/check-backup- staleness.sh (separate cron entry, hourly) alerts via the existing Telegram channel (same TELEGRAM_BOT_TOKEN/TELEGRAM_CHAT_ID idiom as ops/uptime- healthcheck.sh, transition-tracked so it doesn't spam) if a sentinel goes stale. Shared logic (notify/sentinel/state) factored into ops/lib-backup.sh so it isn't triplicated; the two existing scripts' own hardening (integrity checks, retention, etc.) is untouched. Deliverable 2: ops/backup-forgejo.sh — Forgejo (git.gendsgn.ru) has no backup today. Dumps the shared-postgres `forgejo` DB + tars the bare-repo tree, both off-box to s3://gendsgn-backups/forgejo/ under a SEPARATE, narrower S3 key (root-of-bucket writer key stays out of this). The key doesn't exist yet — the script refuses to run and exits non-zero, loudly, until the four FORGEJO_S3_* vars are filled in (see the example env file and PR description for the exact bucket policy JSON to create it with). Refs #2203, #2989	2026-08-21 15:37:19 +03:00
bot-backend	95db3f44c8	fix(ops): бэкапы — +x на deploy-скриптах при деплое tradein, тихий s3 cp (#3005) (#3019)	2026-08-21 10:35:10 +00:00
bot-backend	70f3c0a88a	fix(ops): проверка трейлера дампа падала на grep — ведущие -- принимались за опции (#2203) ... verify_dump_integrity() в ops/backup.sh и tradein-mvp/deploy/backup-tradein-db.sh делала `grep -qF "$trailer"`, где $trailer = "-- PostgreSQL database dump complete". Ведущие -- в аргументе grep трактует как конец опций/флаг, без разделителя команда падает: `grep: unrecognized option '-- PostgreSQL...'`. Проверка из-за этого ВСЕГДА возвращала "трейлера нет" — не потому что дамп оборван, а потому что сама проверка не могла выполниться. Вызывающий код удалял только что созданный валидный дамп и завершался с ошибкой; ретеншен не успевал отработать (ранний exit) — свежие бэкапы не создавались никогда, старые копии оставались молча. Воспроизведено вручную на проде: bash /opt/gendesign/tradein-mvp/deploy/backup-tradein-db.sh удалил свежий дамп с сообщением "дамп оборван?". Фикс: `grep -qF -- "$trailer"` — `--` явно завершает список опций grep. Регрессионный тест (backend/tests/ops/test_2203_backup_trailer_grep_dashdash.py) исполняет РЕАЛЬНУЮ verify_dump_integrity() из обоих скриптов на настоящем gzip-потоке через gunzip|tail|grep — не читает исходник текстом. Проверено локально: падает на добаговой версии с тем же "unrecognized option", зелен на исправленной.	2026-08-20 23:38:45 +03:00
bot-backend	74d503fe36	fix(ops): выгрузка бэкапа в S3 не проходила TLS — у aws-cli свой CA-бандл (#2203) ... aws-cli v2 (образ amazon/aws-cli:latest) использует собственный набор корневых сертификатов из botocore, а не системное хранилище контейнера. В нём нет корня, которым подписан сертификат Selectel S3 (s3.ru-1.storage.selcloud.ru), поэтому docker run падал на SSL validation failed / CERTIFICATE_VERIFY_FAILED: self-signed certificate in certificate chain — и ночной S3-upload не проходил каждый раз, хотя ключи и bucket были верны. Проверено на проде: без AWS_CA_BUNDLE — SSL validation failed; с AWS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt (системное хранилище контейнера, содержит нужный GlobalSign-корень) — upload 11 МБ проходит, код возврата 0, объект подтверждён чтением вторым ключом. Правка — одна переменная окружения в docker run в обоих скриптах: - ops/backup.sh (main DB backup) - tradein-mvp/deploy/backup-tradein-db.sh (tradein DB backup, #3004)	2026-08-20 23:09:28 +03:00
bot-backend	7691db8d2c	chore(ops): восстановить +x на ops/restore-drill.sh ... core.filemode=false на Windows-чекауте молча создал файл как 100644; остальные ops/*.sh — 100755, restore-drill.sh должен быть исполняемым так же (cron/deploy конвенция ops/backup.sh).	2026-08-20 22:14:21 +03:00
bot-backend	770492b8b3	fix(ops): бэкап не теряет роли, не глотает ошибки и умеет уезжать с машины (#2203) ... - ops/backup.sh и tradein-mvp/deploy/backup-tradein-db.sh теперь дампят globals (pg_dumpall --globals-only) отдельным файлом с той же ретенцией и той же S3-выгрузкой — pg_dump по определению не включает роли/GRANT. - Обе выгрузки проходят gzip -t + проверку трейлера дампа перед тем как считаться успешными; при провале файл удаляется, ретенция не трогается, выход ненулевой. - Убран 2>/dev/null у pg_dump в обоих скриптах — ошибка дампа теперь видна в логе, а не глотается молча. - tradein-backup.sh получил S3-выгрузку (по образцу ops/backup.sh, те же 4 переменные, тот же способ через aws-cli контейнер) и env-переопределяемый порог минимального размера дампа; источник переменных — /etc/default/tradein-backup с фолбэком на /etc/default/gendesign-backup. - Новый ops/restore-drill.sh — учебное восстановление в одноразовый postgis-контейнер без прод-томов, никогда не трогает боевую БД (в отличие от ops/restore.sh, который восстанавливает В БОЕВУЮ базу).	2026-08-20 22:13:58 +03:00
bot-backend	09c815930a	chore(ops): снятие зависших job-контейнеров раннера + лимит journald + мёртвый Caddy-блок ... Три независимые правки инфраструктурной гигиены прод-VPS, замеренные живьём 2026-08-15 (ssh gendesign, read-only). 1. ops/docker-prune.sh: новая секция снимает зависшие (running, но брошенные) job-контейнеры Forgejo Actions раннера — три штуки Up 4-8 недель на проде, docker container prune их не видит (фильтрует только status=exited). Фильтр по имени — якорь ^FORGEJO-ACTIONS-TASK- (regex, не substring), сервисные контейнеры (forgejo/forgejo-runner*/gendesign-*/tradein-*/couchdb) под него не подпадают + explicit-skip как страховка. Возраст — из docker inspect .State.StartedAt, порог JOB_CONTAINER_MAX_AGE_HOURS (default 24 — CI job столько никогда не идёт). DRY_RUN уже существующий флаг, переиспользован. Идемпотентно на пустом списке (mapfile + `|| true`). 2. ops/journald-gendesign.conf.example: SystemMaxUse=500M для journald. Замер: journalctl --disk-usage без прав группы systemd-journal/adm недосчитывает (показал 174M) — реальный du -sh /var/log/journal = 2.5G, ~80% всех 3.1G /var/log. journald.conf на проде сейчас без лимита вообще. Установка — руками на сервере (systemd-конфиг вне /opt/gendesign, deploy.yml его не синкает): инструкция в шапке файла. 3. Caddyfile: убран мёртвый блок status.gendsgn.ru (указывал на несуществующий uptime-kuma, дёргал ACME раз в 6 часов на staging-эндпоинте). Заодно убрана dangling forward-ссылка "описан для status.gendsgn.ru ниже" в комментарии у meraocenka.ru. grep подтвердил: других ссылок на этот хост в Caddyfile/compose/скриптах не осталось (docker-compose.uptime.yml и README упоминают — вне scope, стек сам по себе не трогается). caddy validate через prod-контейнер (stdin, без записи файлов на диск) — конфиг валиден, как и baseline до правки.	2026-08-15 22:27:48 +03:00
bot-backend	8fcec9f12e	fix(tradein/observability): stop basic_auth 401 and RetryError GlitchTip noise ... 83% of tracker issues (7460 total) were pure noise drowning real signal: - basic_auth 401 (3738 issues, 2019 distinct titles) — ops/glitchtip-auth- forwarder sent EVERY 401 from bots scanning gendsgn.ru (GET /wp-admin/ install.php etc.) as an individual GlitchTip event, remote_ip baked into message/tags inflated cardinality. Not an application error — expected bot-scan traffic against a basic_auth-protected site. - RetryError (2462 issues) — geocoder.py's three tenacity @retry-wrapped Nominatim helpers (lookup/suggest/reverse) raised tenacity.RetryError on exhaustion without reraise=True; RetryError.__str__() embeds a Future repr() with a memory address that differs every call, so GlitchTip grouped each exhausted retry as a distinct issue instead of one. Fix at the source, not post-hoc issue cleanup: - forwarder.py: before_send drops events tagged event_type in {basic_auth_failed, basic_auth_storm}; forwarder's own capture_exception (real script bugs) carries no such tag and passes through untouched. - geocoder.py: reraise=True on all three @retry decorators — propagates the real underlying exception (stable type + stacktrace) instead of the unstable RetryError wrapper. - sentry_scrub.stabilize_retry_error_fingerprint: belt-and-suspenders before_send hook, composed into both app/main.py and scheduler_main.py (geocoder runs in both processes — FastAPI request path and the overnight geocode_missing_listings batch). Collapses any RetryError that still slips through into one persistent issue per cause-exception type name only — never IP/address/listing-id. Content-ful categories (OperationalError, city-sweep, harvest_quarter, cian/avito/yandex sweep failures, scrape_freshness_check — ~700 issues) are untouched: filters key off event_type tag / exception type name only.	2026-08-15 18:08:04 +03:00
bot-backend	31c8ac4c5f	chore(ops): выставить +x на docker-prune.sh и restore.sh ... Оба скрипта закоммичены как 100644, хотя соседние по каталогу backup.sh и uptime-healthcheck.sh — 100755. На прод-VM файлы лежат с +x, поэтому `git status` в /opt/gendesign постоянно показывает их как modified: M ops/docker-prune.sh M ops/restore.sh (old mode 100644 / new mode 100755, контент идентичен) Функционально это ничего не ломает: cron зовёт docker-prune.sh через `bash <путь>`, restore.sh запускают руками так же. Проблема в другом — постоянный M в прод-репозитории обесценивает единственный дешёвый сигнал, по которому видно ручную правку файла на проде. Шум надо убирать, а не привыкать к нему. Приводим режим к тому, что реально на диске и что уже стоит у соседей.	2026-08-15 17:17:58 +03:00
bot-backend	ddb76a137b	chore(ops): чинить корень утечки docker-томов + еженедельная уборка ... Диск был занят на 76% (110 из 145 ГБ). Разбор: 201 том-сирота на 12.6 ГБ — 125 анонимных (каталоги данных PostgreSQL от тестовых прогонов CI) и 76 окружений задач Forgejo Actions. Прод-данных среди них нет ни одного. Корневая причина: ci.yml и ci-tradein.yml поднимают свой postgres и снимают его через `docker rm -f` БЕЗ `-v`. Контейнер уходит, анонимный том с данными остаётся сиротой — по одному на каждый прогон CI. - ci.yml / ci-tradein.yml: `docker rm -f "$CI_PG"` → `docker rm -fv` (4 места). В deploy-*.yml тот же вызов применяется к БОЕВЫМ контейнерам — туда -v добавлять нельзя, снесло бы тома с данными прода. Не тронуто. - ops/docker-prune.sh — страховка на то, что runner не убрал за собой. Удаляет: остановленные контейнеры старше 24ч, висячие образы старше 7 суток и тома-сироты ТОЛЬКО двух известных форм (64-символьный hex и FORGEJO-ACTIONS-TASK-*). Именованные тома не трогаются никогда — голый `docker volume prune` такой разницы не делает, поэтому здесь не используется. Порядок важен: контейнеры → образы → тома, иначе освободившиеся после контейнеров тома останутся до следующего запуска (на этом я и споткнулся при ручной чистке — после prune осталось ещё 78 сирот). Проверено на проде: DRY_RUN, затем боевой прогон, затем повторный — no-op. Тома 220 → 15, все используются, освобождать нечего. Диск 76% → 67%. Cron поставлен: вс 04:00 UTC (свободный слот рядом с бэкапами).	2026-08-15 16:53:25 +03:00
bot-backend	bea61f6cd9	feat(auth): отдельная БД auth — фундамент единого входа «Меры» и «Птицы» ... PR-1 эпика: вся авторизация переезжает на одну нейтральную форму входа, браузерный popup (Caddy basic_auth) убирается. Этот PR — ТОЛЬКО фундамент, прод работает как сейчас: в БД gendesign ничего не меняется, новая БД создаётся и наполняется логинами без паролей, читать её пока некому. Почему отдельная БД, а не таблица в существующей: хранилище доступов не должно принадлежать продукту, из которого аккаунты выносятся. Сервер — существующий gendesign-postgres (новый контейнер не заводим); проверено, что оба бэкенда сидят в сети gendesign_shared и TCP-достают до него. Состав: - data/sql/auth/001-003 — схема (users, sessions), роль приложения, сид 13 логинов. password_hash = NULL у ВСЕХ: plaintext и bcrypt-хеши в git запрещены, пароли проставляются отдельно на проде (конвенция репы, прецедент tradein м.193). - ops/db-bootstrap/create_auth_db.sql — CREATE DATABASE через \gexec. Не миграцией: CREATE DATABASE запрещён в транзакции, а миграции обязаны быть транзакционными. - ops/db-bootstrap/set_auth_app_password.sql — пароль роли из env, зеркало set_tradein_fdw_password.sql (GUC + \o /dev/null + %L, строго через stdin — :'pw' не интерполируется внутри $$...$$, на этом падал деплой 2026-05-24). Схема лежит в ПОДКАТАЛОГЕ data/sql/auth/ намеренно: основной цикл деплоя использует `ls -1 data/sql/*.sql`, который в подкаталоги не рекурсирует → эти файлы физически не могут примениться в БД gendesign. Защита не на дисциплине, а на глобе. Триггер `data/sql/**` подкаталог при этом покрывает. Права: владелец БД — суперюзер, а не auth_app (иначе гранты были бы декорацией). users — только SELECT+UPDATE (INSERT не выдан: создания аккаунтов в этом PR нет, а снять грант, на который уже опирается прод-код, сложнее чем выдать). REVOKE ALL ON DATABASE FROM PUBLIC продублирован в bootstrap и в миграции намеренно: bootstrap гоняется каждый деплой (переприменяемость), миграция — однократно (самодостаточность). Проверено ИСПОЛНЕНИЕМ на postgis/postgis:16-3.4 (тот же образ, что на проде): двойной прогон всех файлов идемпотентен; COALESCE-защита сида не затирает вручную проставленные пароль/имя (проверено живьём); ASCII-CHECK отклоняет кириллицу; auth_app коннектится, посторонняя роль → permission denied; битая миграция даёт exit 1 и НЕ пишется в _schema_migrations, т.е. деплой прервётся до подъёма кода; пароль с кавычками и бэкслешем не ломает %L и не печатается в stdout. Тест backend/tests/sql/test_auth_sql_migrations.py: имена, транзакционность, наличие wiring в deploy.yml и детектор паролей/хешей, покрывающий И data/sql/auth, И ops/db-bootstrap — единственное место в репе с ALTER ROLE ... PASSWORD. Детектор проверен на живучесть: подложенный bcrypt-хеш роняет тест. Открытые развилки зафиксированы комментариями в коде, решаются в PR-2/3: судьба tradein_users/tradein_sessions (два одинаковых по схеме хранилища) и expired != disabled (trial-экран не выражается булевым is_active). NB: переменную AUTH_DB_PASSWORD нужно завести вручную в runtime-env бэкенда на VPS. Пока пусто — шаг ALTER ROLE пропускается с warning'ом, деплой не падает.	2026-07-31 21:47:33 +03:00
Light1YT	eb251ba7e7	ci(infra): coverage-gate (#68) + OpenAPI codegen-assert (#69) + uptime monitoring (#75) ... #68: pytest-cov + [tool.coverage] fail_under=65 (baseline 71%), backend-tests --cov + xml. #69: openapi-codegen-check job (dump app.openapi() → openapi-typescript → git diff). Job использует node_modules-pinned openapi-typescript/prettier (НЕ npx --yes latest — иначе version-mismatch ложный diff). + regenerated api-types.ts из СВЕЖЕГО main openapi (8288 строк, включая #73 /freshness — синхронен). #75: Uptime Kuma isolated stack + status.gendsgn.ru Caddy + external Telegram watchdog. #77: no change — build cache достаточен. Closes #68 Closes #69 Closes #75 Closes #77	2026-06-13 23:28:06 +05:00
Light1YT	6883d14177	fix(ops): repair broken main-DB backup + harden auth scripts/docs (#71 #427 #429 #428) ... #71 (CRITICAL): backup.sh committed 100644 → git reset --hard on deploy re-asserts non-exec mode → raw-path cron fails Permission denied (last good dump 2026-05-27, no S3). Commit 100755 + chmod ops/*.sh in deploy.yml + size sanity-check (never prune good dumps for a truncated one) + keep-N retention + optional S3 (redacted /etc/default template). Modeled on the working backup-tradein-db.sh. #427: widen basic_auth username regex ^[a-z][a-z0-9_.-]{1,62}$ + literal-escape dotted names in grep probes. #429: replace list_users.sh false-positive grep with anchored awk over basic_auth block. #428: PILOT_ACCESS.md support email → pilot@gendsgn.ru. Closes #71 Closes #427 Closes #429 Closes #428	2026-06-13 20:13:04 +05:00
lekss361	08a8cf51b3	fix(deploy): mute psql set_config stdout — prevent password leak in CI logs ... Review-bot PR #510 нашёл P0: `set_config(name,value,is_local)` возвращает установленное значение, psql печатает rows на stdout без `-q`/`-A`/`-t`, итог — фактический pw появляется в Forgejo Actions deploy logs (retained, visible всем с repo read access). Fix: оборачиваем оба `SELECT set_config(...)` в `\o /dev/null` / `\o` brackets. Output mutes только для этих строк — NOTICE-сообщения из DO block (idempotency signal 'tradein_fdw_reader password set') остаются видимыми. Также добавлен rollback hint в комментарии: НЕ revert файл (вернёт сломанный :'pw' внутри $$), а unset GENDESIGN_FDW_PASSWORD в .env.runtime на VPS.	2026-05-24 14:21:36 +03:00
lekss361	da7814810c	fix(deploy): tradein_fdw_reader password — psql var interpolation in DO block ... psql :'pw' substitution НЕ работает внутри dollar-quoted блока $$..$$ — это правило psql, не bug. Symptom: deploy 2026-05-24 после merge PR #503 упал с 'syntax error at or near :' on LINE 4 of set_tradein_fdw_password.sql, :'pw' дошёл до сервера как literal вместо интерполяции. Fix: передаём password в DO через session GUC (set_config) — psql интерполирует :'pw' ВНЕ dollar quote, внутри читаем через current_setting(). Очищаем GUC после выполнения (defense-in-depth).	2026-05-24 14:03:15 +03:00