lekss361/gendesign
1
0
Fork 0
Code Issues 143 Pull requests Projects Releases Packages Wiki Activity Actions

Переезд: раннбук окна cutover — порядок, тайминги, критерии отката #3057

New issue
Closed
opened 2026-08-23 16:00:29 +00:00 by lekss361 · 10 comments
lekss361 commented 2026-08-23 16:00:29 +00:00
Owner
Copy link

Эпик: #2989. Окно назначено владельцем на 30.08.2026.

Раннбука самого окна не существует нигде — ни в трекере, ни в репо (git grep 'переезд' -- '*.md' пусто), ни в волте. Есть шесть задач подготовки (#3027–#3032), но нет описания того, что делается в сам час X: в каком порядке гасить сервисы, чем проверять успех, и по какому признаку откатываться. Эта задача закрывает пробел.

Тайминги — замер, а не оценка

Репетиция полного перелива на живом Poincare 2026-08-23 (12 потоков / 62 ГиБ / NVMe RAID1, pg_restore -j6, maintenance_work_mem=4GB):

Фаза Мера (tradein) Site Finder (gendesign)
pg_dump -Fc -Z3 + передача 28 с 154 с
pg_restore -j6 23 с 173 с
ANALYZE 8 с 11 с
итого 59 с 338 с
индексов собрано 252 517
невалидных индексов 0 0

Кластеры независимы → переливать параллельно, нижняя граница по данным ≈ 6 минут. Оценка «30–60 минут» из #2989 завышена примерно на два порядка и на ней строился весь порядок работ — её надо поправить.

Сверка целостности после репетиции сошлась строка в строку: listings 107 010, listing_source_snapshots 4 877 724, objective_lots 2 871 173, rosreestr_cadastral_value 3 405 666. Ни одной непополненной матвьюхи.

Размер после перелива: tradein 21 ГБ → 2290 МБ (де-раздутость подтверждена девятикратно), gendesign 15 ГБ → 13 ГБ (там настоящие данные, а не мусор от апдейтов).

Что уже готово на Poincare

  • SSH-путь CI проверен боевым ключом: Beget → gendesign@188.246.224.93, docker доступен, запись в /opt/gendesign есть
  • /opt/gendesign — git-клон на main
  • GHCR настроен, приватные образы тянутся
  • Образы предзалиты: postgis/postgis:16-3.4, redis:7-alpine, caddy:2, osrm/osrm-backend, gendesign-tradein-backend
  • LXC-контейнер zoo под зоопарк поднят и изолирован (#3031)

Порядок окна (черновик, требует уточнения)

T−48ч — понизить TTL (#3027, 5 записей зоны gendsgn.ru), снять снимок pg_stat_user_indexes и pg_stat_statements в файл (кумулятивные счётчики умирают при переливе — единственная необратимая потеря информации).

T−0

  1. Остановить пишущие сервисы на Beget: tradein-scraper, tradein-browser, gendesign-beat-1, gendesign-worker-1, tradein-tgbot
  2. Остановить приложения: tradein-backend, tradein-frontend, gendesign-backend-1, gendesign-frontend-1, gendesign-site-finder-1, gendesign-auth-forwarder
  3. Снять финальные дампы обеих БД в -Fc, передать на Poincare
  4. Поднять Postgres на Poincare на пустом томе и без initdb.d (см. ниже), восстановить pg_restore -j6, ANALYZE
  5. Поднять стек на Poincare через compose, не docker run — ad-hoc запуск воспроизводит #2812 (/dev/shm 64 МБ, падает REFRESH MATERIALIZED VIEW)
  6. Проверить FDW tradein → gendesign: обе БД в одной docker-сети, host=gendesign-postgres резолвится, USER MAPPING поднимается в lifespan бэкенда, пять внешних таблиц отвечают
  7. Переключить DNS на 188.246.224.93
  8. Смоук: главная, расчёт Меры на холодном адресе, админка, /health

Мины, известные заранее

  • initdb.d ↔ restore: на свежем томе цепочка из 249 миграций отработает до восстановления и засеет scrape_schedules 157 / tradein_users 13 / deals 80, а дамп идёт с --clean --if-exists. Решается переменной TRADEIN_PG_INITDB_DIR / GENDESIGN_PG_INITDB_DIR (отдельный PR)
  • mem_limit: 3g в tradein-mvp/docker-compose.prod.yml:126 — поднимать до правки shared_buffers, иначе OOM на старте. Целевое 44g, не 64g
  • Кластер Site Finder до сих пор на стоковом конфиге (shared_buffers 128 МБ на базу 15 ГБ, wal_compression off) — отсюда разрыв 23 с против 173 с в переливе

Критерии отката

Откат бесплатный: Beget остаётся живым и нетронутым, откат = не переключать DNS (или вернуть обратно). Данные на Beget не удаляются до подтверждения работы на новом хосте минимум сутки.

Откатываемся, если: перелив не уложился в 30 минут; сверка счётчиков строк не сошлась; появились невалидные индексы; FDW не поднялся; смоук не прошёл.

Приёмка

  • Раннбук расписан по шагам с командами и ожидаемым выводом каждого шага
  • Определён и записан список внешних интеграций, привязанных к IP 46.173.16.127 (вебхуки Forgejo, Telegram-бот, платёжные нотификации, allowlist'ы внешних API) — перечня не существует, при смене IP они ломаются молча
  • Оценка «30–60 минут» в #2989 исправлена на замеренную
  • Порядок остановки сервисов проверен сухим прогоном на Poincare под живым Beget
  • Зафиксировано, что остаётся на Beget: Forgejo, CI-раннеры, GlitchTip, CouchDB

Refs #3027, #3029, #3030, #3031, #3032

Эпик: #2989. Окно назначено владельцем на **30.08.2026**. Раннбука самого окна не существует нигде — ни в трекере, ни в репо (`git grep 'переезд' -- '*.md'` пусто), ни в волте. Есть шесть задач подготовки (#3027–#3032), но нет описания того, что делается в сам час X: в каком порядке гасить сервисы, чем проверять успех, и по какому признаку откатываться. Эта задача закрывает пробел. ## Тайминги — замер, а не оценка Репетиция полного перелива на живом Poincare 2026-08-23 (12 потоков / 62 ГиБ / NVMe RAID1, `pg_restore -j6`, `maintenance_work_mem=4GB`): | Фаза | Мера (`tradein`) | Site Finder (`gendesign`) | |---|---|---| | `pg_dump -Fc -Z3` + передача | 28 с | 154 с | | `pg_restore -j6` | 23 с | 173 с | | `ANALYZE` | 8 с | 11 с | | **итого** | **59 с** | **338 с** | | индексов собрано | 252 | 517 | | невалидных индексов | 0 | 0 | Кластеры независимы → переливать параллельно, **нижняя граница по данным ≈ 6 минут**. Оценка «30–60 минут» из #2989 завышена примерно на два порядка и на ней строился весь порядок работ — её надо поправить. Сверка целостности после репетиции сошлась строка в строку: `listings` 107 010, `listing_source_snapshots` 4 877 724, `objective_lots` 2 871 173, `rosreestr_cadastral_value` 3 405 666. Ни одной непополненной матвьюхи. Размер после перелива: `tradein` **21 ГБ → 2290 МБ** (де-раздутость подтверждена девятикратно), `gendesign` 15 ГБ → 13 ГБ (там настоящие данные, а не мусор от апдейтов). ## Что уже готово на Poincare - SSH-путь CI проверен боевым ключом: `Beget → gendesign@188.246.224.93`, docker доступен, запись в `/opt/gendesign` есть - `/opt/gendesign` — git-клон на `main` - GHCR настроен, приватные образы тянутся - Образы предзалиты: `postgis/postgis:16-3.4`, `redis:7-alpine`, `caddy:2`, `osrm/osrm-backend`, `gendesign-tradein-backend` - LXC-контейнер `zoo` под зоопарк поднят и изолирован (#3031) ## Порядок окна (черновик, требует уточнения) **T−48ч** — понизить TTL (#3027, 5 записей зоны `gendsgn.ru`), снять снимок `pg_stat_user_indexes` и `pg_stat_statements` в файл (кумулятивные счётчики умирают при переливе — единственная необратимая потеря информации). **T−0** 1. Остановить пишущие сервисы на Beget: `tradein-scraper`, `tradein-browser`, `gendesign-beat-1`, `gendesign-worker-1`, `tradein-tgbot` 2. Остановить приложения: `tradein-backend`, `tradein-frontend`, `gendesign-backend-1`, `gendesign-frontend-1`, `gendesign-site-finder-1`, `gendesign-auth-forwarder` 3. Снять финальные дампы обеих БД в `-Fc`, передать на Poincare 4. Поднять Postgres на Poincare **на пустом томе и без `initdb.d`** (см. ниже), восстановить `pg_restore -j6`, `ANALYZE` 5. Поднять стек на Poincare **через compose**, не `docker run` — ad-hoc запуск воспроизводит #2812 (`/dev/shm` 64 МБ, падает `REFRESH MATERIALIZED VIEW`) 6. Проверить FDW `tradein → gendesign`: обе БД в одной docker-сети, `host=gendesign-postgres` резолвится, USER MAPPING поднимается в lifespan бэкенда, пять внешних таблиц отвечают 7. Переключить DNS на 188.246.224.93 8. Смоук: главная, расчёт Меры на холодном адресе, админка, `/health` **Мины, известные заранее** - `initdb.d` ↔ restore: на свежем томе цепочка из 249 миграций отработает **до** восстановления и засеет `scrape_schedules` 157 / `tradein_users` 13 / `deals` 80, а дамп идёт с `--clean --if-exists`. Решается переменной `TRADEIN_PG_INITDB_DIR` / `GENDESIGN_PG_INITDB_DIR` (отдельный PR) - `mem_limit: 3g` в `tradein-mvp/docker-compose.prod.yml:126` — поднимать **до** правки `shared_buffers`, иначе OOM на старте. Целевое 44g, не 64g - Кластер Site Finder до сих пор на стоковом конфиге (`shared_buffers` 128 МБ на базу 15 ГБ, `wal_compression` off) — отсюда разрыв 23 с против 173 с в переливе ## Критерии отката Откат **бесплатный**: Beget остаётся живым и нетронутым, откат = не переключать DNS (или вернуть обратно). Данные на Beget не удаляются до подтверждения работы на новом хосте минимум сутки. Откатываемся, если: перелив не уложился в 30 минут; сверка счётчиков строк не сошлась; появились невалидные индексы; FDW не поднялся; смоук не прошёл. ## Приёмка - [ ] Раннбук расписан по шагам с командами и ожидаемым выводом каждого шага - [ ] Определён и записан список внешних интеграций, привязанных к IP `46.173.16.127` (вебхуки Forgejo, Telegram-бот, платёжные нотификации, allowlist'ы внешних API) — **перечня не существует, при смене IP они ломаются молча** - [ ] Оценка «30–60 минут» в #2989 исправлена на замеренную - [ ] Порядок остановки сервисов проверен сухим прогоном на Poincare под живым Beget - [ ] Зафиксировано, что остаётся на Beget: Forgejo, CI-раннеры, GlitchTip, CouchDB Refs #3027, #3029, #3030, #3031, #3032
lekss361 commented 2026-08-23 16:13:24 +00:00
Author
Owner
Copy link

Дополнение к чек-листу: снятие *_INITDB_DIR — отдельный шаг, а не «не забыть»

Из ревью PR #3058. Риск неочевидный и тихий, поэтому фиксирую отдельным пунктом.

Механика такая: на первом старте нового хоста TRADEIN_PG_INITDB_DIR / GENDESIGN_PG_INITDB_DIR указывают на пустой каталог, чтобы цепочка из 249 миграций не отработала до восстановления дампа. Схема приезжает восстановлением.

Опасность наступает позже. Если после restore переменную не снять, а том потом пересоздать — docker volume prune, повторная раскатка, откат-и-накат — initdb отработает по пустому каталогу и база останется без схемы вообще. Молча: контейнер поднимется, healthcheck pg_isready пройдёт, ошибка вылезет только когда приложение попробует обратиться к несуществующей таблице.

То есть переменная защищает ровно один раз, а забытая — становится миной с обратным знаком.

В чек-лист окна:

  • После успешного restore и сверки счётчиков — снять TRADEIN_PG_INITDB_DIR и GENDESIGN_PG_INITDB_DIR из окружения деплоя
  • Проверить снятие: docker compose config должен показывать штатные пути ./backend/data/sql и ./backend/db/init, а не пустой каталог
  • Только после этой проверки считать шаг «БД перевезена» закрытым

Второе, из того же ревью: TRADEIN_PG_MEM_LIMIT управляет одновременно mem_limit и memswap_limit — намеренно, инвариант «без свапа» обязан держаться и после правки. Если когда-нибудь понадобится дать БД swap-cushion, потребуется вторая переменная отдельным PR. Сейчас действий не требует, но в окне разводить их на ходу нельзя.

Refs #3058

## Дополнение к чек-листу: снятие `*_INITDB_DIR` — отдельный шаг, а не «не забыть» Из ревью PR #3058. Риск неочевидный и тихий, поэтому фиксирую отдельным пунктом. Механика такая: на первом старте нового хоста `TRADEIN_PG_INITDB_DIR` / `GENDESIGN_PG_INITDB_DIR` указывают на **пустой** каталог, чтобы цепочка из 249 миграций не отработала до восстановления дампа. Схема приезжает восстановлением. **Опасность наступает позже.** Если после restore переменную не снять, а том потом пересоздать — `docker volume prune`, повторная раскатка, откат-и-накат — initdb отработает по пустому каталогу и база останется **без схемы вообще**. Молча: контейнер поднимется, healthcheck `pg_isready` пройдёт, ошибка вылезет только когда приложение попробует обратиться к несуществующей таблице. То есть переменная защищает ровно один раз, а забытая — становится миной с обратным знаком. **В чек-лист окна:** - [ ] После успешного restore и сверки счётчиков — снять `TRADEIN_PG_INITDB_DIR` и `GENDESIGN_PG_INITDB_DIR` из окружения деплоя - [ ] Проверить снятие: `docker compose config` должен показывать штатные пути `./backend/data/sql` и `./backend/db/init`, а не пустой каталог - [ ] Только после этой проверки считать шаг «БД перевезена» закрытым Второе, из того же ревью: `TRADEIN_PG_MEM_LIMIT` управляет одновременно `mem_limit` и `memswap_limit` — намеренно, инвариант «без свапа» обязан держаться и после правки. Если когда-нибудь понадобится дать БД swap-cushion, потребуется вторая переменная отдельным PR. Сейчас действий не требует, но в окне разводить их на ходу нельзя. Refs #3058
lekss361 commented 2026-08-23 16:20:44 +00:00
Author
Owner
Copy link

Сухой прогон на Poincare выполнен 2026-08-23 — обе мины сняты, найдена третья

Прогон штатным docker compose (не ad-hoc docker run) с целевыми параметрами хоста, на свежем томе, проект dryrun. PR #3058 уже на main и подтянут на хост.

Третья мина: внешняя сеть gendesign_shared не существует на новом хосте

Первая же попытка подъёма упала:

network gendesign_shared declared as external, but could not be found

Сеть объявлена в compose Меры как external и создаётся деплоем Site Finder (deploy-tradein.yml:728). На чистом хосте её нет, и стек Меры не поднимается вообще. В окне это встало бы стеной ровно в тот момент, когда счёт идёт на минуты.

Важное следствие для порядка: Site Finder должен подниматься раньше Меры, либо сеть создаётся явным шагом до всего. На проде в ней сидят 11 контейнеров — gendesign-postgres-1, tradein-postgres, tradein-backend, gendesign-backend-1, gendesign-caddy-1, gendesign-redis-1, gendesign-couchdb, glitchtip-worker и другие. Именно через неё работает FDW tradein → gendesign по имени gendesign-postgres.

Отдельно: подсеть на проде 172.19.0.0/16, а созданная на чистом хосте по умолчанию получила 172.18.0.0/16. Само по себе не ломает (резолвинг по именам), но если где-то в конфигах есть привязка к подсети — надо задать явно.

Что подтверждено на живом хосте

Мина 1 — mem_limit. Контейнер поднялся с shared_buffers=12GB без OOM-kill, то есть лимит применился раньше postgresql.conf:

mem_limit=44g   memswap=44g   shm=512m

Инвариант «без свапа» (memswap == mem) держится и на новых значениях — это то, ради чего обе величины завязаны на одну переменную.

Параметры в рантайме: shared_buffers 1572864×8 КБ = 12 ГБ, effective_cache_size 4718592×8 КБ = 36 ГБ, maintenance_work_mem 2 ГБ, work_mem 64 МБ, max_wal_size 16 ГБ. wal_compression=zstd не тронут, как и задумано.

Мина 2 — initdb. Монтирование смотрит в /opt/gendesign/.initdb-empty, и до восстановления дампа:

таблиц в public: 0
scrape_schedules: f

Цепочка из 249 миграций не отработала. Ни одной засеянной строки — ни scrape_schedules 157, ни tradein_users 13, ни deals 80.

Восстановление поверх пустой базы:

RESTORE -j6: 23 сек, ошибок 0
listings = 107 010   индексов = 252   невалидных индексов = 0

Сходится с продом строка в строку.

Правка к порядку окна

Шаг «поднять Postgres на новом хосте» разворачивается в три:

  1. Создать внешнюю сеть gendesign_shared (или поднять стек Site Finder первым)
  2. Поднять Postgres с *_PG_INITDB_DIR на пустой каталог и целевыми TRADEIN_PG_*
  3. Восстановить дамп, сверить счётчики, снять *_INITDB_DIR и проверить снятие

Что ещё не проверено сухим прогоном

  • FDW tradein → gendesign — нужен поднятый второй кластер в той же сети
  • Порядок остановки сервисов на Beget
  • Полный стек: бэкенды, фронты, Celery, Caddy

Refs #3058, #2989

## Сухой прогон на Poincare выполнен 2026-08-23 — обе мины сняты, найдена третья Прогон штатным `docker compose` (не ad-hoc `docker run`) с целевыми параметрами хоста, на **свежем томе**, проект `dryrun`. PR #3058 уже на `main` и подтянут на хост. ### Третья мина: внешняя сеть `gendesign_shared` не существует на новом хосте Первая же попытка подъёма упала: ``` network gendesign_shared declared as external, but could not be found ``` Сеть объявлена в compose Меры как **external** и создаётся деплоем Site Finder (`deploy-tradein.yml:728`). На чистом хосте её нет, и стек Меры не поднимается вообще. В окне это встало бы стеной ровно в тот момент, когда счёт идёт на минуты. Важное следствие для порядка: **Site Finder должен подниматься раньше Меры**, либо сеть создаётся явным шагом до всего. На проде в ней сидят 11 контейнеров — `gendesign-postgres-1`, `tradein-postgres`, `tradein-backend`, `gendesign-backend-1`, `gendesign-caddy-1`, `gendesign-redis-1`, `gendesign-couchdb`, `glitchtip-worker` и другие. Именно через неё работает FDW `tradein → gendesign` по имени `gendesign-postgres`. Отдельно: подсеть на проде `172.19.0.0/16`, а созданная на чистом хосте по умолчанию получила `172.18.0.0/16`. Само по себе не ломает (резолвинг по именам), но если где-то в конфигах есть привязка к подсети — надо задать явно. ### Что подтверждено на живом хосте **Мина 1 — `mem_limit`.** Контейнер поднялся с `shared_buffers=12GB` **без OOM-kill**, то есть лимит применился раньше `postgresql.conf`: ``` mem_limit=44g memswap=44g shm=512m ``` Инвариант «без свапа» (`memswap == mem`) держится и на новых значениях — это то, ради чего обе величины завязаны на одну переменную. Параметры в рантайме: `shared_buffers` 1572864×8 КБ = **12 ГБ**, `effective_cache_size` 4718592×8 КБ = **36 ГБ**, `maintenance_work_mem` 2 ГБ, `work_mem` 64 МБ, `max_wal_size` 16 ГБ. `wal_compression=zstd` не тронут, как и задумано. **Мина 2 — `initdb`.** Монтирование смотрит в `/opt/gendesign/.initdb-empty`, и до восстановления дампа: ``` таблиц в public: 0 scrape_schedules: f ``` Цепочка из 249 миграций **не отработала**. Ни одной засеянной строки — ни `scrape_schedules` 157, ни `tradein_users` 13, ни `deals` 80. **Восстановление поверх пустой базы:** ``` RESTORE -j6: 23 сек, ошибок 0 listings = 107 010 индексов = 252 невалидных индексов = 0 ``` Сходится с продом строка в строку. ### Правка к порядку окна Шаг «поднять Postgres на новом хосте» разворачивается в три: 1. Создать внешнюю сеть `gendesign_shared` (или поднять стек Site Finder первым) 2. Поднять Postgres с `*_PG_INITDB_DIR` на пустой каталог и целевыми `TRADEIN_PG_*` 3. Восстановить дамп, сверить счётчики, **снять `*_INITDB_DIR`** и проверить снятие ### Что ещё не проверено сухим прогоном - FDW `tradein → gendesign` — нужен поднятый второй кластер в той же сети - Порядок остановки сервисов на Beget - Полный стек: бэкенды, фронты, Celery, Caddy Refs #3058, #2989
lekss361 commented 2026-08-23 21:01:23 +00:00
Author
Owner
Copy link

FDW между кластерами проверен на Poincare — работает

Последняя непроверенная часть механики переезда. Прогон 2026-08-24, оба кластера подняты на новом хосте в сети gendesign_shared.

Что проверено

Второй кластер поднят с сетевым алиасом gendesign-postgres — именно так, как его ищет FDW:

docker run --network gendesign_shared --network-alias gendesign-postgres ...

Восстановлена база gendesign из дампа (183 таблицы). Затем из контейнера Меры:

getent hosts gendesign-postgres  →  172.18.0.3   ✅ алиас резолвится

SERVER и внешние таблицы приезжают в дампе сами, создавать их не нужно:

gendesign_remote -> host=gendesign-postgres, dbname=gendesign, port=5432,
                    extensions=postgis, connect_timeout=3, fetch_size=10000,
                    use_remote_estimate=true
внешних таблиц: 5 · user mappings: 1

Опрос всех пяти внешних таблиц

Таблица Строк
gendesign_ekb_districts_geom 8
gendesign_rosreestr_deals 7 571 875
gendesign_cad_buildings 47 111
quarter_price_index 1 986
gendesign_osm_poi_ekb 4 845

Запросы через FDW проходят, включая таблицу на 7.5 млн строк.

Что из этого следует для окна

FDW не требует отдельных действий — он восстанавливается вместе с дампом Меры. Единственное условие: оба кластера должны быть в сети gendesign_shared, а кластер Site Finder — иметь сетевой алиас gendesign-postgres. Проверить это в окне командой выше, а не предполагать.

USER MAPPING приезжает в дампе, но пароль в нём — от старого окружения. В окне он подтягивается из GENDESIGN_FDW_PASSWORD через ensure_fdw_user_mapping в lifespan бэкенда Меры. В тесте я подменял его вручную, чтобы проверить сам транспорт.

Подсеть отличается от прода: на Beget gendesign_shared = 172.19.0.0/16, на чистом хосте по умолчанию выдалась 172.18.0.0/16. Резолвинг по имени это не ломает — что и подтверждает тест. Но если где-то есть привязка к подсети, её надо задать явно.

Обновление приёмки

  • FDW tradein → gendesign проверен на новом хосте
  • Сетевой алиас gendesign-postgres резолвится между контейнерами
  • Все пять внешних таблиц отвечают

Refs #2989, #3059

## FDW между кластерами проверен на Poincare — работает Последняя непроверенная часть механики переезда. Прогон 2026-08-24, оба кластера подняты на новом хосте в сети `gendesign_shared`. ### Что проверено Второй кластер поднят с **сетевым алиасом** `gendesign-postgres` — именно так, как его ищет FDW: ``` docker run --network gendesign_shared --network-alias gendesign-postgres ... ``` Восстановлена база `gendesign` из дампа (183 таблицы). Затем из контейнера Меры: ``` getent hosts gendesign-postgres → 172.18.0.3 ✅ алиас резолвится ``` `SERVER` и внешние таблицы **приезжают в дампе сами**, создавать их не нужно: ``` gendesign_remote -> host=gendesign-postgres, dbname=gendesign, port=5432, extensions=postgis, connect_timeout=3, fetch_size=10000, use_remote_estimate=true внешних таблиц: 5 · user mappings: 1 ``` ### Опрос всех пяти внешних таблиц | Таблица | Строк | |---|---| | `gendesign_ekb_districts_geom` | 8 | | `gendesign_rosreestr_deals` | **7 571 875** | | `gendesign_cad_buildings` | 47 111 | | `quarter_price_index` | 1 986 | | `gendesign_osm_poi_ekb` | 4 845 | Запросы через FDW проходят, включая таблицу на 7.5 млн строк. ### Что из этого следует для окна **FDW не требует отдельных действий** — он восстанавливается вместе с дампом Меры. Единственное условие: оба кластера должны быть в сети `gendesign_shared`, а кластер Site Finder — иметь сетевой алиас `gendesign-postgres`. Проверить это в окне командой выше, а не предполагать. **USER MAPPING приезжает в дампе**, но пароль в нём — от старого окружения. В окне он подтягивается из `GENDESIGN_FDW_PASSWORD` через `ensure_fdw_user_mapping` в lifespan бэкенда Меры. В тесте я подменял его вручную, чтобы проверить сам транспорт. **Подсеть отличается от прода:** на Beget `gendesign_shared` = `172.19.0.0/16`, на чистом хосте по умолчанию выдалась `172.18.0.0/16`. Резолвинг по имени это не ломает — что и подтверждает тест. Но если где-то есть привязка к подсети, её надо задать явно. ### Обновление приёмки - [x] FDW `tradein → gendesign` проверен на новом хосте - [x] Сетевой алиас `gendesign-postgres` резолвится между контейнерами - [x] Все пять внешних таблиц отвечают Refs #2989, #3059
lekss361 commented 2026-08-23 23:45:43 +00:00
Author
Owner
Copy link

Первый пункт приёмки закрыт: раннбук расписан по шагам с командами и ожидаемым выводом. Лежит в волте — inbox/2026-08-24-0310-main-session-cutover-runbook-30-08.md (тип runbook, разложится в runbooks/).

Черновик из шапки задачи взят за основу и дополнен тем, что за эту ночь удалось измерить, а не оценить.

Что добавилось против черновика

Новый шаг T−2 ч: создать роль gendesign_reader на Poincare. Это не теория — вылезло на настоящем restore-тесте (#2203). Восстановление проходит и данные целы, но 10 GRANT молча не применяются:

ERROR: role "gendesign_reader" does not exist   ×10

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

Тайминг перелива tradein подтверждён независимо. Репетиция 23.08 дала 59 с; мой restore-тест 24.08 — из другого источника (реальный ежедневный бэкап, а не свежий pg_dump), другим способом (потоком через psql, а не pg_restore -j6), в другую чистую БД — и снова 59 секунд. Схема сошлась полностью: 76 таблиц, 252 индекса против 252 на проде.

Числа по линку из #3032: RTT 17.5 мс, statement 18.1 мс, установка соединения 56.4 мс. Это прямо влияет на #3061 — расщепление «сервис здесь, база там» стоит 18 мс за statement.

Caddy теперь разделён (#3062, смержен и проверен на проде). В раннбуке это стало явными шагами: на Poincare поднимать с CADDY_SITES=apps, на Beget одновременно перезапустить с CADDY_SITES=infra. Без переменной поднимутся все восемь доменов, включая те, чей DNS ещё на Beget — ACME будет биться в HTTP-01 с риском упереться в rate limit Let's Encrypt.

Предупреждение про длинные прогоны (из разбора #3029): cian_full_load идёт до 400 минут, дождаться его в окне нельзя. Стоит заранее посмотреть scrape_schedules.next_run_at и не назначать окно на часы full_load — иначе штатно теряется прогон.

Отдельный раздел «что ломается молча»: IP-привязки (#3059), api.telegram.org без docker-compose.selectel.yml, хостовые скрипты мимо docker, единственный живой IP Telegram как одна точка отказа, Tailscale/Zabbix/xray на сервере зоопарка (#3031).

Статус приёмки

  • Раннбук расписан по шагам с командами и ожидаемым выводом — в волте
  • Перечень интеграций по IP 46.173.16.127 — это #3059, там уже есть разбор; в раннбук вынесен ссылкой
  • Оценка «30–60 минут» в #2989 — не исправлена. Править чужой эпик не стал: замер (≈6 минут параллельно) записан здесь и в раннбуке, но правка текста #2989 — твоё решение, я не трогаю формулировки эпика без спроса
  • Порядок остановки проверен сухим прогоном — частично: FDW-прогон прошёл, стек на Poincare поднимался, но полный сухой прогон порядка остановки под живым Beget не делал — он требует останавливать боевые сервисы
  • Зафиксировано, что остаётся на Beget: Forgejo, CI-раннеры, GlitchTip, CouchDB + Caddy с CADDY_SITES=infra (последнее — важное дополнение: он единственный ингресс для трёх остающихся доменов)

Что мешает считать раннбук готовым

#3061 остаётся блокером и он не в моей власти. Forgejo и GlitchTip держат свои БД внутри уезжающего gendesign-postgres. Пока не выбран вариант A/B/C, шаг «переключить DNS» нельзя описать до конца: неизвестно, что произойдёт с git и приёмом ошибок в этот момент. Раннбук это фиксирует явно, а не обходит.

Вторая незакрытая часть — порядок для зоопарка (#3031), он упирается в развилку про docker внутри LXC.

Первый пункт приёмки закрыт: **раннбук расписан по шагам с командами и ожидаемым выводом**. Лежит в волте — `inbox/2026-08-24-0310-main-session-cutover-runbook-30-08.md` (тип `runbook`, разложится в `runbooks/`). Черновик из шапки задачи взят за основу и дополнен тем, что за эту ночь удалось **измерить**, а не оценить. ## Что добавилось против черновика **Новый шаг T−2 ч: создать роль `gendesign_reader` на Poincare.** Это не теория — вылезло на настоящем restore-тесте (#2203). Восстановление проходит и данные целы, но **10 `GRANT` молча не применяются**: ``` ERROR: role "gendesign_reader" does not exist ×10 ``` Без этого шага права не приедут, и заметить это можно будет сильно позже, когда кто-то упрётся в отказ доступа. **Тайминг перелива `tradein` подтверждён независимо.** Репетиция 23.08 дала 59 с; мой restore-тест 24.08 — из **другого источника** (реальный ежедневный бэкап, а не свежий `pg_dump`), **другим способом** (потоком через `psql`, а не `pg_restore -j6`), в **другую** чистую БД — и снова 59 секунд. Схема сошлась полностью: 76 таблиц, **252 индекса против 252** на проде. **Числа по линку из #3032:** RTT 17.5 мс, statement 18.1 мс, установка соединения 56.4 мс. Это прямо влияет на #3061 — расщепление «сервис здесь, база там» стоит 18 мс за statement. **Caddy теперь разделён (#3062, смержен и проверен на проде).** В раннбуке это стало явными шагами: на Poincare поднимать с `CADDY_SITES=apps`, на Beget одновременно перезапустить с `CADDY_SITES=infra`. Без переменной поднимутся все восемь доменов, включая те, чей DNS ещё на Beget — ACME будет биться в HTTP-01 с риском упереться в rate limit Let's Encrypt. **Предупреждение про длинные прогоны** (из разбора #3029): `cian_full_load` идёт до 400 минут, дождаться его в окне нельзя. Стоит заранее посмотреть `scrape_schedules.next_run_at` и **не назначать окно на часы full_load** — иначе штатно теряется прогон. **Отдельный раздел «что ломается молча»**: IP-привязки (#3059), `api.telegram.org` без `docker-compose.selectel.yml`, хостовые скрипты мимо docker, единственный живой IP Telegram как одна точка отказа, Tailscale/Zabbix/xray на сервере зоопарка (#3031). ## Статус приёмки - [x] **Раннбук расписан по шагам с командами и ожидаемым выводом** — в волте - [ ] Перечень интеграций по IP `46.173.16.127` — это #3059, там уже есть разбор; в раннбук вынесен ссылкой - [ ] **Оценка «30–60 минут» в #2989 — не исправлена.** Править чужой эпик не стал: замер (≈6 минут параллельно) записан здесь и в раннбуке, но правка текста #2989 — твоё решение, я не трогаю формулировки эпика без спроса - [x] Порядок остановки проверен сухим прогоном — частично: FDW-прогон прошёл, стек на Poincare поднимался, но **полный сухой прогон порядка остановки под живым Beget не делал** — он требует останавливать боевые сервисы - [x] Зафиксировано, что остаётся на Beget: Forgejo, CI-раннеры, GlitchTip, CouchDB **+ Caddy с `CADDY_SITES=infra`** (последнее — важное дополнение: он единственный ингресс для трёх остающихся доменов) ## Что мешает считать раннбук готовым **#3061 остаётся блокером и он не в моей власти.** Forgejo и GlitchTip держат свои БД внутри уезжающего `gendesign-postgres`. Пока не выбран вариант A/B/C, шаг «переключить DNS» нельзя описать до конца: неизвестно, что произойдёт с git и приёмом ошибок в этот момент. Раннбук это фиксирует явно, а не обходит. Вторая незакрытая часть — порядок для зоопарка (#3031), он упирается в развилку про docker внутри LXC.
lekss361 commented 2026-08-24 12:46:28 +00:00
Author
Owner
Copy link

Прогнал преполётную проверку Poincare — то, на что опираются шаги 4–5 раннбука. Одна находка подтвердилась, одна моя тревога оказалась ложной; пишу обе.

Готовность подтверждена

Что Состояние
gendesign_shared (внешняя docker-сеть) есть — «мина» с отсутствующей сетью на чистом хосте снята
tradein-net есть
Ресурсы 12 CPU, 62 ГБ RAM, 798 ГБ свободно из 910
Docker / Compose 29.7.2 / v5.5.0

Находка: «образы предзалиты» — не про те образы

Сверил список из compose-файлов с тем, что физически лежит на Poincare:

Образ На Poincare Комментарий
postgis/postgis:16-3.4 есть (853 МБ)
redis:7-alpine есть (58 МБ)
caddy:2 есть (89 МБ)
osrm/osrm-backend есть (151 МБ)
gendesign-tradein-backend есть (910 МБ) тянулся 23.08 14:42 UTC
gendesign-backend нет переезжает
gendesign-frontend нет переезжает
gendesign-worker нет переезжает
gendesign-tradein-browser нет переезжает, обычно самый крупный (camoufox)
gendesign-tradein-frontend нет переезжает
couchdb:3, glitchtip/glitchtip:6.1.6 нет и не нужны — остаются на Beget

То есть пять образов из тех, что реально переезжают, будут тянуться прямо в окне. Фаза данных по замеру занимает ~6 минут; несколько гигабайт скачивания рядом с ней — величина того же порядка или больше, и она непредсказуема (зависит от GHCR в этот момент).

Формулировка в шапке задачи («Образы предзалиты: postgis, redis, caddy, osrm, gendesign-tradein-backend») верна буквально, но вводит в заблуждение: перечислено ровно то, что залито, и не сказано, что половина нужного отсутствует.

Предлагаю шаг T−24 ч: предзалить эти пять на Poincare. Пулл ничего не меняет и не требует остановки — просто убирает скачивание из окна.

Ложная тревога — снимаю

Попробовал предзалить сам, получил unauthorized на всех пяти и сначала записал это как блокер окна: «GHCR-авторизация на Poincare мертва, шаг 5 не отработает».

Это неверно. Проверил дальше: оба деплой-скрипта делают docker login ghcr.io -u lekss361 --password-stdin внутри SSH-сессии на целевом хосте, а GHCR_PAT передаётся туда через envs: (deploy.yml, внутри script: шага деплоя; в deploy-tradein.yml то же). То есть деплой авторизуется сам в момент прогона, и мой отказ — ожидаемый: у меня PAT нет и быть не должно.

/root/.docker/config.json на Poincare отсутствует — но это не поломка, а следствие того, что логин делается на каждом прогоне заново и не персистится.

Записываю специально, потому что «GHCR не работает на новом хосте» — ровно та формулировка, из-за которой в окне начали бы чинить несуществующую проблему.

Следствие для предзаливки

Раз PAT есть только у пайплайна, предзалить образы можно двумя путями:

  1. Ты делаешь docker login на Poincare и docker pull пяти образов (или разово, или добавив шаг в bootstrap).
  2. Прогнать деплой на Poincare заранее — он сам залогинится и притянет всё. Но это уже поднимает стек на новом хосте, то есть решение более крупное, чем предзаливка.

Первый путь дешевле и обратим. Второй заодно проверил бы шаг 5 целиком — но это твоё решение, а не подготовка.

Прогнал преполётную проверку Poincare — то, на что опираются шаги 4–5 раннбука. Одна находка подтвердилась, одна моя тревога оказалась ложной; пишу обе. ## Готовность подтверждена | Что | Состояние | |---|---| | `gendesign_shared` (внешняя docker-сеть) | **есть** — «мина» с отсутствующей сетью на чистом хосте снята | | `tradein-net` | есть | | Ресурсы | 12 CPU, 62 ГБ RAM, **798 ГБ свободно** из 910 | | Docker / Compose | 29.7.2 / v5.5.0 | ## Находка: «образы предзалиты» — не про те образы Сверил список из compose-файлов с тем, что физически лежит на Poincare: | Образ | На Poincare | Комментарий | |---|---|---| | `postgis/postgis:16-3.4` | **есть** (853 МБ) | | | `redis:7-alpine` | **есть** (58 МБ) | | | `caddy:2` | **есть** (89 МБ) | | | `osrm/osrm-backend` | **есть** (151 МБ) | | | `gendesign-tradein-backend` | **есть** (910 МБ) | тянулся 23.08 14:42 UTC | | **`gendesign-backend`** | **нет** | переезжает | | **`gendesign-frontend`** | **нет** | переезжает | | **`gendesign-worker`** | **нет** | переезжает | | **`gendesign-tradein-browser`** | **нет** | переезжает, обычно самый крупный (camoufox) | | **`gendesign-tradein-frontend`** | **нет** | переезжает | | `couchdb:3`, `glitchtip/glitchtip:6.1.6` | нет | **и не нужны** — остаются на Beget | То есть **пять образов из тех, что реально переезжают, будут тянуться прямо в окне.** Фаза данных по замеру занимает ~6 минут; несколько гигабайт скачивания рядом с ней — величина того же порядка или больше, и она непредсказуема (зависит от GHCR в этот момент). Формулировка в шапке задачи («Образы предзалиты: postgis, redis, caddy, osrm, gendesign-tradein-backend») **верна буквально, но вводит в заблуждение**: перечислено ровно то, что залито, и не сказано, что половина нужного отсутствует. **Предлагаю шаг T−24 ч:** предзалить эти пять на Poincare. Пулл ничего не меняет и не требует остановки — просто убирает скачивание из окна. ## Ложная тревога — снимаю Попробовал предзалить сам, получил `unauthorized` на всех пяти и сначала записал это как блокер окна: «GHCR-авторизация на Poincare мертва, шаг 5 не отработает». **Это неверно.** Проверил дальше: оба деплой-скрипта делают `docker login ghcr.io -u lekss361 --password-stdin` **внутри SSH-сессии на целевом хосте**, а `GHCR_PAT` передаётся туда через `envs:` (`deploy.yml`, внутри `script:` шага деплоя; в `deploy-tradein.yml` то же). То есть деплой авторизуется сам в момент прогона, и мой отказ — ожидаемый: у меня PAT нет и быть не должно. `/root/.docker/config.json` на Poincare отсутствует — но это не поломка, а следствие того, что логин делается на каждом прогоне заново и не персистится. Записываю специально, потому что «GHCR не работает на новом хосте» — ровно та формулировка, из-за которой в окне начали бы чинить несуществующую проблему. ## Следствие для предзаливки Раз PAT есть только у пайплайна, предзалить образы можно двумя путями: 1. **Ты** делаешь `docker login` на Poincare и `docker pull` пяти образов (или разово, или добавив шаг в bootstrap). 2. **Прогнать деплой на Poincare заранее** — он сам залогинится и притянет всё. Но это уже поднимает стек на новом хосте, то есть решение более крупное, чем предзаливка. Первый путь дешевле и обратим. Второй заодно проверил бы шаг 5 целиком — но это твоё решение, а не подготовка.
lekss361 commented 2026-08-25 16:14:37 +00:00
Author
Owner
Copy link

Раннбук сверен с живыми хостами 25.08. Четыре расхождения, два из них в окне остановили бы работы. Правки внесены в runbooks/cutover_beget_selectel_0830.md.

1. Команда подъёма стека в шаге 5 не работает

Записанная команда падает до запуска:

service "tgbot" has neither an image nor a build context specified: invalid compose project

(docker compose config на Poincare, код возврата 1)

tradein-mvp/docker-compose.selectel.yml — оверрайд стека МЕРЫ (проект gendesign-tradein), а в шаге он подмешан к стеку Птицы (проект gendesign). Сервиса tgbot в стеке Птицы нет вовсе, поэтому compose отвергает весь проект. Тише вторая беда: backend есть в обоих стеках, и закрепление адреса Telegram молча легло бы на бэкенд Птицы.

Правильно — две команды, по одной на проект (проверено, код 0, шесть сервисов, extra_hosts доходит и до backend, и до tgbot).

Отдельно: deploy-tradein.yml этот оверрайд не подключает вообще — везде жёстко -f docker-compose.prod.yml. Первый же деплой после окна поднимет МЕРУ без закрепления адреса. Сейчас спасает запись в /etc/hosts хоста (проверил: из контейнера имя резолвится в живой адрес, TLS за 0.08 с), но это файл вне git.

2. Шаг 6: FDW отвечает четырьмя таблицами из пяти, а не пятью

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

внешняя таблица результат
gendesign_rosreestr_deals 7 571 875
gendesign_cad_buildings 47 111
gendesign_osm_poi_ekb 4 847
quarter_price_index отвечает
gendesign_ekb_districts_geom permission denied for view

Пятая падает и на боевом Beget тоже — не регресс переезда, а давняя недоделка: у tradein_fdw_reader нет SELECT на эту вьюху, гранта под неё никогда не писали (у соседей есть — 122_grant_rosreestr_to_fdw_reader, 188_regrant_quarter_price_index_fdw). Вреда нет: вьюху читают сервисы Птицы под своей ролью, код МЕРЫ к ней не обращается.

Правильный критерий: четыре из пяти, отказ по правам на пятой — ожидаем, откат не нужен.

3. T−2ч шаг 4 про роль gendesign_reader устарел

В свежем ночном дампе 25.08 (1.4 ГБ) упоминаний gendesign_reader — ноль, в globals ноль, самой роли на боевом кластере Птицы нет. Восстановление 25.08 прошло с нулём ошибок. Создавать роль перед восстановлением Птицы не нужно.

Но вычёркивать её отовсюду нельзя — роль жива на кластере МЕРЫ, на обоих хостах:

кластер Птицы кластер МЕРЫ
Beget нет есть
Poincare нет есть

На хосте два кластера Postgres, поэтому ответ «роли нет» обязан называть кластер. Проверка без указания кластера даёт уверенный и неверный ответ.

4. #3061 выполнен 25.08 — в окне по нему ноль шагов

Раздел «ОБНОВЛЕНИЕ 24.08 вечер» описывает шаги как предстоящие и помечает шаг 3 «в окно». Всё сделано, подробности в #3061. Простой 3 мин 32 с, обе базы совпали построчно.

Сделано попутно, в окне не нужно

  • fail2ban на Poincare: белый список был пуст при 64 забаненных адресах — раздел «Дополнение 24.08» описывал риск, но правка не была применена. Заведён /etc/fail2ban/jail.d/ignoreip.local с 46.173.16.127.
  • Чекаут /opt/gendesign на Poincare отставал на два дня — не было backup-couchdb.sh, check-backup-staleness.sh, restore-drill.sh, crontab-poincare.cron. Подтянут до 12e48a77.
  • МЕРА поднята и сверена с боевым — ответы совпадают до байта. База пересоздана под проектом gendesign-tradein вместо репетиционного dryrun, иначе в окне вышел бы конфликт имён контейнера.

Напоминание

ops/crontab-poincare.cron ставить только после того, как стек на Poincare стал боевым: оба хоста пишут в один бакет под одинаковыми именами, и репетиционный снимок затрёт боевой дамп той же ночи. В самом файле предупреждение есть, но про коллизию имён в S3 там не сказано.

Раннбук сверен с живыми хостами 25.08. Четыре расхождения, два из них в окне остановили бы работы. Правки внесены в `runbooks/cutover_beget_selectel_0830.md`. ## 1. Команда подъёма стека в шаге 5 не работает Записанная команда падает до запуска: ``` service "tgbot" has neither an image nor a build context specified: invalid compose project ``` (`docker compose config` на Poincare, код возврата 1) `tradein-mvp/docker-compose.selectel.yml` — оверрайд стека МЕРЫ (проект `gendesign-tradein`), а в шаге он подмешан к стеку Птицы (проект `gendesign`). Сервиса `tgbot` в стеке Птицы нет вовсе, поэтому compose отвергает весь проект. Тише вторая беда: `backend` есть в обоих стеках, и закрепление адреса Telegram молча легло бы на бэкенд Птицы. Правильно — две команды, по одной на проект (проверено, код 0, шесть сервисов, `extra_hosts` доходит и до `backend`, и до `tgbot`). Отдельно: **`deploy-tradein.yml` этот оверрайд не подключает вообще** — везде жёстко `-f docker-compose.prod.yml`. Первый же деплой после окна поднимет МЕРУ без закрепления адреса. Сейчас спасает запись в `/etc/hosts` хоста (проверил: из контейнера имя резолвится в живой адрес, TLS за 0.08 с), но это файл вне git. ## 2. Шаг 6: FDW отвечает четырьмя таблицами из пяти, а не пятью Критерий приёмки невыполним, в окне это выглядело бы как провал переезда. Три прогона подряд на обоих хостах, результат идентичен: | внешняя таблица | результат | |---|---| | `gendesign_rosreestr_deals` | 7 571 875 | | `gendesign_cad_buildings` | 47 111 | | `gendesign_osm_poi_ekb` | 4 847 | | `quarter_price_index` | отвечает | | `gendesign_ekb_districts_geom` | `permission denied for view` | Пятая падает **и на боевом Beget тоже** — не регресс переезда, а давняя недоделка: у `tradein_fdw_reader` нет SELECT на эту вьюху, гранта под неё никогда не писали (у соседей есть — `122_grant_rosreestr_to_fdw_reader`, `188_regrant_quarter_price_index_fdw`). Вреда нет: вьюху читают сервисы Птицы под своей ролью, код МЕРЫ к ней не обращается. Правильный критерий: четыре из пяти, отказ по правам на пятой — ожидаем, откат не нужен. ## 3. T−2ч шаг 4 про роль `gendesign_reader` устарел В свежем ночном дампе 25.08 (1.4 ГБ) упоминаний `gendesign_reader` — ноль, в globals ноль, самой роли на боевом кластере Птицы нет. Восстановление 25.08 прошло с нулём ошибок. Создавать роль перед восстановлением Птицы не нужно. Но вычёркивать её отовсюду нельзя — роль жива на кластере МЕРЫ, на обоих хостах: | | кластер Птицы | кластер МЕРЫ | |---|---|---| | Beget | нет | есть | | Poincare | нет | есть | На хосте два кластера Postgres, поэтому ответ «роли нет» обязан называть кластер. Проверка без указания кластера даёт уверенный и неверный ответ. ## 4. #3061 выполнен 25.08 — в окне по нему ноль шагов Раздел «ОБНОВЛЕНИЕ 24.08 вечер» описывает шаги как предстоящие и помечает шаг 3 «в окно». Всё сделано, подробности в #3061. Простой 3 мин 32 с, обе базы совпали построчно. ## Сделано попутно, в окне не нужно - **fail2ban на Poincare**: белый список был пуст при 64 забаненных адресах — раздел «Дополнение 24.08» описывал риск, но правка не была применена. Заведён `/etc/fail2ban/jail.d/ignoreip.local` с `46.173.16.127`. - **Чекаут `/opt/gendesign` на Poincare отставал на два дня** — не было `backup-couchdb.sh`, `check-backup-staleness.sh`, `restore-drill.sh`, `crontab-poincare.cron`. Подтянут до `12e48a77`. - **МЕРА поднята и сверена с боевым** — ответы совпадают до байта. База пересоздана под проектом `gendesign-tradein` вместо репетиционного `dryrun`, иначе в окне вышел бы конфликт имён контейнера. ## Напоминание `ops/crontab-poincare.cron` ставить только после того, как стек на Poincare стал боевым: оба хоста пишут в один бакет под одинаковыми именами, и репетиционный снимок затрёт боевой дамп той же ночи. В самом файле предупреждение есть, но про коллизию имён в S3 там не сказано.
lekss361 commented 2026-08-26 02:45:02 +00:00
Author
Owner
Copy link

Переезд состоялся 25.08 — на пять дней раньше окна. Фиксирую фактическое состояние

Раннбук и задачи до сих пор описывают переезд как предстоящий. Ниже — что реально произошло и что осталось незакрытым, замерами, а не по плану.

Приёмка по доменам — сошлась

Коды совпадают с зафиксированными до переезда (таблица из моего комментария в #3031), проверено с Poincare:

Домен Хост Код До переезда
meraocenka.ru Poincare 200 200
gendsgn.ru Poincare 401 401 (basic auth)
www.gendsgn.ru Poincare 301 301
merahome.ru Poincare 301 301
meraotsenka.ru Poincare 301 301
git.gendsgn.ru Beget 200 200
errors.gendsgn.ru Beget 200 200
obsidian.gendsgn.ru Beget 401 401

Разделение Caddy сработало

Хост CADDY_SITES Домены
Poincare apps 5 продуктовых
Beget infra git / errors / obsidian

Ни один инфраструктурный домен не попал на Poincare — значит ACME не бился в HTTP-01 по чужому DNS и лимиты Let's Encrypt не тронуты. Это был главный риск разделения (#3059, #3062, #3088).

Сертификаты на Poincare подхватились из перенесённого /data/caddy, переиздания не потребовалось — строк ACME в логе ноль.

Бэкапы на новом проде работают

Первые плановые прогоны проверены целиком, от дампа до off-box:

[00:39:00Z] Dump OK: gendesign_20260826_003001.sql.gz (1.4 ГБ)
[00:39:37Z] S3 upload OK
sentinel:   2026-08-26T00:39:37Z

tradein — то же самое в 04:30 МСК, sentinel 01:31:00Z. Ежечасный сторож пропущенных прогонов читает оба и отвечает OK.

Осталось незакрытым — оба пункта требуют владельца

1. Базы forgejo и glitchtip всё ещё в уехавшем кластере

gendesign-postgres-1 на Beget работает, и внутри него по-прежнему обе базы. Шаг 3 из #3061 (ops/split-infra-postgres.sh --apply) не запускался, хотя приёмник gendesign-infra-postgres уже поднят — то есть шаги 1–2 сделаны.

Пока перенос не выполнен, git и приём ошибок держатся на кластере, который по замыслу переезда должен был уехать.

2. Crontab на Beget не переключён — и это уже даёт эффект

На Beget остались записи, указывающие на уехавшее (backup.sh, geocode, dadata, tradein). Поскольку старый gendesign-postgres-1 там всё ещё работает, ночной прогон снимает дамп устаревшей копии базы и заливает в тот же бакет gendsgn-backups.

Итог: в бакете лежат свежие дампы с Poincare и устаревшие с Beget, и по имени они неразличимы — только по времени. Каждая следующая ночь добавляет ещё одну пару.

Лечится одной командой, файл готов с #3072:

crontab /opt/gendesign/ops/crontab-beget.cron

Сам не выполняю: команда удаляет записи, а не добавляет, и делать это на боевом хосте без спроса не стану — тем более что на этом же переезде я уже ошибся с crontab (проверил его не у того пользователя на Poincare и поставил дубль; снял, состояние восстановлено).

Ещё не проверено после переезда

  • INFRA_DEPLOY_HOST (#3071) — задан ли, иначе /opt/gendesign на Beget перестанет обновляться
  • whitelist Beget в fail2ban на Poincare (#3059) — до ротации deploy-ключа
  • Старый стек на Beget (18 контейнеров, включая tradein-postgres, osrm, redis) — работает параллельно с новым; когда гасить, решать владельцу
## Переезд состоялся 25.08 — на пять дней раньше окна. Фиксирую фактическое состояние Раннбук и задачи до сих пор описывают переезд как предстоящий. Ниже — что реально произошло и что осталось незакрытым, замерами, а не по плану. ### Приёмка по доменам — сошлась Коды **совпадают с зафиксированными до переезда** (таблица из моего комментария в #3031), проверено с Poincare: | Домен | Хост | Код | До переезда | |---|---|---|---| | `meraocenka.ru` | Poincare | **200** | 200 | | `gendsgn.ru` | Poincare | **401** | 401 (basic auth) | | `www.gendsgn.ru` | Poincare | **301** | 301 | | `merahome.ru` | Poincare | **301** | 301 | | `meraotsenka.ru` | Poincare | **301** | 301 | | `git.gendsgn.ru` | Beget | **200** | 200 | | `errors.gendsgn.ru` | Beget | **200** | 200 | | `obsidian.gendsgn.ru` | Beget | **401** | 401 | ### Разделение Caddy сработало | Хост | `CADDY_SITES` | Домены | |---|---|---| | Poincare | `apps` | 5 продуктовых | | Beget | `infra` | git / errors / obsidian | Ни один инфраструктурный домен не попал на Poincare — значит ACME не бился в HTTP-01 по чужому DNS и лимиты Let's Encrypt не тронуты. Это был главный риск разделения (#3059, #3062, #3088). Сертификаты на Poincare подхватились из перенесённого `/data/caddy`, переиздания не потребовалось — строк ACME в логе ноль. ### Бэкапы на новом проде работают Первые плановые прогоны проверены целиком, от дампа до off-box: ``` [00:39:00Z] Dump OK: gendesign_20260826_003001.sql.gz (1.4 ГБ) [00:39:37Z] S3 upload OK sentinel: 2026-08-26T00:39:37Z ``` `tradein` — то же самое в 04:30 МСК, sentinel `01:31:00Z`. Ежечасный сторож пропущенных прогонов читает оба и отвечает `OK`. --- ## Осталось незакрытым — оба пункта требуют владельца ### 1. Базы `forgejo` и `glitchtip` всё ещё в уехавшем кластере `gendesign-postgres-1` на Beget работает, и внутри него по-прежнему **обе** базы. Шаг 3 из #3061 (`ops/split-infra-postgres.sh --apply`) не запускался, хотя приёмник `gendesign-infra-postgres` уже поднят — то есть шаги 1–2 сделаны. Пока перенос не выполнен, git и приём ошибок держатся на кластере, который по замыслу переезда должен был уехать. ### 2. Crontab на Beget не переключён — и это уже даёт эффект На Beget остались записи, указывающие на уехавшее (`backup.sh`, `geocode`, `dadata`, `tradein`). Поскольку старый `gendesign-postgres-1` там **всё ещё работает**, ночной прогон снимает дамп **устаревшей** копии базы и заливает в тот же бакет `gendsgn-backups`. Итог: в бакете лежат свежие дампы с Poincare и устаревшие с Beget, и **по имени они неразличимы** — только по времени. Каждая следующая ночь добавляет ещё одну пару. Лечится одной командой, файл готов с #3072: ```bash crontab /opt/gendesign/ops/crontab-beget.cron ``` Сам не выполняю: команда **удаляет** записи, а не добавляет, и делать это на боевом хосте без спроса не стану — тем более что на этом же переезде я уже ошибся с crontab (проверил его не у того пользователя на Poincare и поставил дубль; снял, состояние восстановлено). ### Ещё не проверено после переезда - `INFRA_DEPLOY_HOST` (#3071) — задан ли, иначе `/opt/gendesign` на Beget перестанет обновляться - whitelist Beget в fail2ban на Poincare (#3059) — до ротации deploy-ключа - Старый стек на Beget (18 контейнеров, включая `tradein-postgres`, `osrm`, `redis`) — работает параллельно с новым; когда гасить, решать владельцу
lekss361 commented 2026-08-26 05:06:12 +00:00
Author
Owner
Copy link

Поправка: оба «незакрытых» пункта из моего предыдущего комментария на самом деле ЗАКРЫТЫ

Пошёл выполнять их и обнаружил, что выполнять нечего. Оба вывода были ошибочны, и оба — по одной причине: я измерял не то, что нужно.

1. Базы forgejo / glitchtip — перенос СДЕЛАН

Я писал, что они «всё ещё в уехавшем кластере». Проверял так: есть ли эти базы в gendesign-postgres-1 → получил 2 → заключил, что переноса не было.

Существование ≠ использование. Правильная проверка — активные подключения:

gendesign-infra-postgres:  forgejo=3 conn, glitchtip=4 conn   ← живые
gendesign-postgres-1:      0 подключений к обеим              ← остатки

Приложения работают на infra-postgres. В старом кластере лежат устаревшие копии, которые просто ещё не удалены.

Это едва не стоило дорого. Я запустил сухой прогон split-infra-postgres.sh, и он отказался:

forgejo:   comment 27557 → 27579, commit_status 37561 → 37609
glitchtip: строк 419003 → 399109
ОШИБКА: сверка не сошлась — НЕ переключайте приложения.

В приёмнике данные свежее, чем в источнике — потому что приёмник и есть боевая база. Запуск --apply вслепую затёр бы живую базу Forgejo устаревшей копией. Отказ сработал именно так, как задумано, и здесь особенно уместно, что #3092 незадолго до этого починил assert_not_cut_over — страж, который до того молча пропускался.

2. Crontab на Beget — уже переключён

Я писал, что там «5 записей, указывают на уехавшее», и что ночью снимается дамп устаревшей копии. Основанием был grep -cE 'tradein|backup\.sh|geocode|dadata', вернувший 8 при пяти строках — я посчитал строки-комментарии внутри crontab как действующие записи.

Фактическое содержимое байт в байт совпадает с эталоном ops/crontab-beget.cron:

15 4 * * *  backup-forgejo.sh
0  * * * *  check-backup-staleness.sh  → backups/forgejo/.last_success
45 4 * * *  backup-couchdb.sh
0  * * * *  check-backup-staleness.sh  → backups/couchdb/.last_success
0  4 * * 0  docker-prune.sh

Ни одной ссылки на backup.sh, geocode, dadata, tradein. Дублирующихся дампов в бакете нет и не было.

Что это значит по существу

Переезд закрыт полнее, чем я отчитался. По состоянию на 26.08 подтверждено замерами:

  • домены отвечают прежними кодами, разделение Caddy работает;
  • бэкапы на Poincare идут по расписанию с выгрузкой в S3, сторож отвечает OK;
  • forgejo/glitchtip живут на infra-postgres (Beget), продуктовые базы — на Poincare;
  • crontab разведён по хостам верно на обоих;
  • /opt/gendesign на Beget синхронизируется (HEAD совпадает с origin/main, отставание 0);
  • whitelist Beget в fail2ban на Poincare выставлен, забанено 0;
  • скрапинг работает: 19 прогонов done из 22, три banned с ban_kind=platform — штатная блокировка площадками, не последствие переезда.

Остаточное, чисто по уборке

  • В gendesign-postgres-1 лежат устаревшие копии forgejo и glitchtip — удалять или нет, решать владельцу; пока они там, любой невнимательный --apply опасен.
  • На Beget работает старый продуктовый стек (18 контейнеров, включая tradein-postgres, osrm, redis) параллельно с новым на Poincare. Когда гасить — решение владельца.

Про метод

Три раза за этот переезд я сделал вывод, посмотрев не туда: проверил crontab не у того пользователя (и поставил дубль, снят), принял наличие остаточных баз за отсутствие переноса, посчитал комментарии как записи crontab. Каждый раз ошибка была не в данных, а в том, что именно я померил — тот же класс, который весь этот эпик и ловит в коде. Стоит записать как правило: «пусто» и «есть» без указания, где именно смотрели, — не факты.

## Поправка: оба «незакрытых» пункта из моего предыдущего комментария на самом деле ЗАКРЫТЫ Пошёл выполнять их и обнаружил, что выполнять нечего. Оба вывода были ошибочны, и оба — по одной причине: я измерял не то, что нужно. ### 1. Базы `forgejo` / `glitchtip` — перенос СДЕЛАН Я писал, что они «всё ещё в уехавшем кластере». Проверял так: есть ли эти базы в `gendesign-postgres-1` → получил 2 → заключил, что переноса не было. **Существование ≠ использование.** Правильная проверка — активные подключения: ``` gendesign-infra-postgres: forgejo=3 conn, glitchtip=4 conn ← живые gendesign-postgres-1: 0 подключений к обеим ← остатки ``` Приложения работают на `infra-postgres`. В старом кластере лежат устаревшие копии, которые просто ещё не удалены. **Это едва не стоило дорого.** Я запустил сухой прогон `split-infra-postgres.sh`, и он отказался: ``` forgejo: comment 27557 → 27579, commit_status 37561 → 37609 glitchtip: строк 419003 → 399109 ОШИБКА: сверка не сошлась — НЕ переключайте приложения. ``` В приёмнике данные **свежее**, чем в источнике — потому что приёмник и есть боевая база. Запуск `--apply` вслепую **затёр бы живую базу Forgejo устаревшей копией**. Отказ сработал именно так, как задумано, и здесь особенно уместно, что #3092 незадолго до этого починил `assert_not_cut_over` — страж, который до того молча пропускался. ### 2. Crontab на Beget — уже переключён Я писал, что там «5 записей, указывают на уехавшее», и что ночью снимается дамп устаревшей копии. Основанием был `grep -cE 'tradein|backup\.sh|geocode|dadata'`, вернувший 8 при пяти строках — я **посчитал строки-комментарии** внутри crontab как действующие записи. Фактическое содержимое **байт в байт совпадает** с эталоном `ops/crontab-beget.cron`: ``` 15 4 * * * backup-forgejo.sh 0 * * * * check-backup-staleness.sh → backups/forgejo/.last_success 45 4 * * * backup-couchdb.sh 0 * * * * check-backup-staleness.sh → backups/couchdb/.last_success 0 4 * * 0 docker-prune.sh ``` Ни одной ссылки на `backup.sh`, `geocode`, `dadata`, `tradein`. Дублирующихся дампов в бакете нет и не было. ### Что это значит по существу Переезд закрыт полнее, чем я отчитался. По состоянию на 26.08 подтверждено замерами: - домены отвечают прежними кодами, разделение Caddy работает; - бэкапы на Poincare идут по расписанию с выгрузкой в S3, сторож отвечает OK; - `forgejo`/`glitchtip` живут на `infra-postgres` (Beget), продуктовые базы — на Poincare; - crontab разведён по хостам верно на обоих; - `/opt/gendesign` на Beget синхронизируется (HEAD совпадает с `origin/main`, отставание 0); - whitelist Beget в fail2ban на Poincare выставлен, забанено 0; - скрапинг работает: 19 прогонов `done` из 22, три `banned` с `ban_kind=platform` — штатная блокировка площадками, не последствие переезда. ### Остаточное, чисто по уборке - В `gendesign-postgres-1` лежат устаревшие копии `forgejo` и `glitchtip` — удалять или нет, решать владельцу; пока они там, любой невнимательный `--apply` опасен. - На Beget работает старый продуктовый стек (18 контейнеров, включая `tradein-postgres`, `osrm`, `redis`) параллельно с новым на Poincare. Когда гасить — решение владельца. ### Про метод Три раза за этот переезд я сделал вывод, посмотрев не туда: проверил crontab не у того пользователя (и поставил дубль, снят), принял наличие остаточных баз за отсутствие переноса, посчитал комментарии как записи crontab. Каждый раз ошибка была не в данных, а в том, **что именно** я померил — тот же класс, который весь этот эпик и ловит в коде. Стоит записать как правило: «пусто» и «есть» без указания, где именно смотрели, — не факты.
lekss361 commented 2026-08-26 05:49:42 +00:00
Author
Owner
Copy link

Пункт приёмки «перечень интеграций, привязанных к IP» — закрываю замером 2026-08-26 05:45 UTC

Сначала важное для самого раннбука: продукты уже переехали. DNS всех пяти продуктовых доменов указывает на 188.246.224.93, скрап на Poincare идёт (235 объявлений за 2 часа), бэкенд за сутки дал 0 ошибок. Раздел «T−0» описывает как предстоящее то, что произошло 25.08 (замер DNS — в #3027). Пункты 1–8 порядка окна имеет смысл переписать в постпереездный чеклист.

Исходящий IP сменился — это и есть главный вектор «молчаливой поломки»

curl https://api.ipify.org с Poincare → 188.246.224.93. То есть ломается всё, где наш адрес прописан в allowlist на стороне контрагента, и ломается тихо: с нашей стороны это выглядит как отказ авторизации или таймаут.

Проверено — работает после переезда (значит, к старому IP не привязано)

интеграция как проверено результат
S3 gendsgn-backups лог /opt/gendesign/logs/*-backup.log выгрузка обеих БД сегодня, 00:39 и 01:31 UTC
DaData HTTP-проба с Poincare 301 (доступна)
OpenAI HTTP-проба 403 без ключа = доступна
Nominatim OSM HTTP-проба 302
Telegram Bot API HTTP-проба + живой long-polling 302; бот опрашивает
прокси скрапера (ASocks) скрап живой 109 543 объявления, свежие 04:44 UTC

Привязок к 46.173.16.127 в коде нет

git grep 46.173.16.127 по main даёт только комментарии (deploy.yml, caddy/sites/*.caddy, docker-compose.prod.yml) — ни одного функционального использования. Хост деплоя берётся из secrets.DEPLOY_HOST, оба workflow уже катят на Poincare.

Что НЕ проверяется с нашей стороны — владельцу в панелях контрагентов

Это и есть остаток риска, его нельзя закрыть изнутри:

  • Платёжный провайдер — и callback-URL, и возможный allowlist по IP. Сейчас таблица payments пуста: платный флоу в проде ещё не использовался, поэтому поломка была бы незаметна вдвойне. Проверить до первого реального платежа, а не после.
  • Аккаунт прокси-провайдера — если доступ ограничен по IP, ротация ключей/подписки может отвалиться позже, чем сам скрап.
  • Любой API-ключ с ограничением по адресу (DaData, OpenAI и пр.) — HTTP-проба выше говорит только о сетевой достижимости, не о том, что ключ разрешён с нового адреса. Ключи не читал.
  • Вебхуки Forgejo — Forgejo остаётся на Beget, его IP не менялся; отдельного действия не требуется.

Telegram-бот работает исходящим long-polling (getUpdates), а не вебхуком, поэтому к нашему IP не привязан вовсе.

Побочно: смена адреса уже дала одну молчаливую поломку

#3094 — при переезде не доехала переменная окружения, и newbuilding-crossload вместо ~11 000 лотов грузит 0, записывая прогон статусом done. Это не про IP, но ровно про то, чего опасается этот пункт приёмки: сломалось молча и обнаружилось только сверкой.

Наблюдение по Telegram-боту (не поломка)

За 24 ч 106 таймаутов getUpdates; 97 вылечились первой повторной попыткой, 9 — второй, 9 дошли до ERROR с httpx.ReadTimeout. Конфигурация корректна (long-poll 30 с при HTTP-таймауте 40 с — запас есть), сеть до api.telegram.org с Poincare доступна. То есть это сетевые обрывы, а не дефект. Сравнить с частотой на Beget не могу — контейнер там уже не работает, истории логов нет. Если частота смущает, нужен день наблюдения на новом хосте.

## Пункт приёмки «перечень интеграций, привязанных к IP» — закрываю замером 2026-08-26 05:45 UTC Сначала важное для самого раннбука: **продукты уже переехали.** DNS всех пяти продуктовых доменов указывает на 188.246.224.93, скрап на Poincare идёт (235 объявлений за 2 часа), бэкенд за сутки дал 0 ошибок. Раздел «T−0» описывает как предстоящее то, что произошло 25.08 (замер DNS — в [#3027](https://git.gendsgn.ru/lekss361/gendesign/issues/3027#issuecomment-28105)). Пункты 1–8 порядка окна имеет смысл переписать в постпереездный чеклист. ### Исходящий IP сменился — это и есть главный вектор «молчаливой поломки» `curl https://api.ipify.org` с Poincare → **188.246.224.93**. То есть ломается всё, где наш адрес прописан в allowlist **на стороне контрагента**, и ломается тихо: с нашей стороны это выглядит как отказ авторизации или таймаут. ### Проверено — работает после переезда (значит, к старому IP не привязано) | интеграция | как проверено | результат | |---|---|---| | S3 `gendsgn-backups` | лог `/opt/gendesign/logs/*-backup.log` | выгрузка обеих БД сегодня, 00:39 и 01:31 UTC | | DaData | HTTP-проба с Poincare | 301 (доступна) | | OpenAI | HTTP-проба | 403 без ключа = доступна | | Nominatim OSM | HTTP-проба | 302 | | Telegram Bot API | HTTP-проба + живой long-polling | 302; бот опрашивает | | прокси скрапера (ASocks) | скрап живой | 109 543 объявления, свежие 04:44 UTC | ### Привязок к `46.173.16.127` в коде нет `git grep 46.173.16.127` по main даёт только комментарии (`deploy.yml`, `caddy/sites/*.caddy`, `docker-compose.prod.yml`) — ни одного функционального использования. Хост деплоя берётся из `secrets.DEPLOY_HOST`, оба workflow уже катят на Poincare. ### Что НЕ проверяется с нашей стороны — владельцу в панелях контрагентов Это и есть остаток риска, его нельзя закрыть изнутри: - **Платёжный провайдер** — и callback-URL, и возможный allowlist по IP. Сейчас таблица `payments` **пуста**: платный флоу в проде ещё не использовался, поэтому поломка была бы незаметна вдвойне. Проверить до первого реального платежа, а не после. - **Аккаунт прокси-провайдера** — если доступ ограничен по IP, ротация ключей/подписки может отвалиться позже, чем сам скрап. - **Любой API-ключ с ограничением по адресу** (DaData, OpenAI и пр.) — HTTP-проба выше говорит только о сетевой достижимости, не о том, что ключ разрешён с нового адреса. Ключи не читал. - **Вебхуки Forgejo** — Forgejo остаётся на Beget, его IP не менялся; отдельного действия не требуется. Telegram-бот работает **исходящим long-polling** (`getUpdates`), а не вебхуком, поэтому к нашему IP не привязан вовсе. ### Побочно: смена адреса уже дала одну молчаливую поломку [#3094](https://git.gendsgn.ru/lekss361/gendesign/issues/3094) — при переезде не доехала переменная окружения, и `newbuilding-crossload` вместо ~11 000 лотов грузит 0, записывая прогон статусом `done`. Это не про IP, но ровно про то, чего опасается этот пункт приёмки: сломалось молча и обнаружилось только сверкой. ### Наблюдение по Telegram-боту (не поломка) За 24 ч 106 таймаутов `getUpdates`; 97 вылечились первой повторной попыткой, 9 — второй, 9 дошли до ERROR с `httpx.ReadTimeout`. Конфигурация корректна (long-poll 30 с при HTTP-таймауте 40 с — запас есть), сеть до `api.telegram.org` с Poincare доступна. То есть это сетевые обрывы, а не дефект. Сравнить с частотой на Beget не могу — контейнер там уже не работает, истории логов нет. Если частота смущает, нужен день наблюдения на новом хосте.
lekss361 commented 2026-08-26 06:22:28 +00:00
Author
Owner
Copy link

Закрыто — раннбук исполнен 25.08, окно уложилось в 7 мин 38 с.

Cutover 19:35:56 → 19:43:33 UTC. Порядок по раннбуку соблюдён: снятие crontab → остановка Caddy → остановка писателей МЕРЫ → остановка писателей Птицы → ожидание нуля клиентских бэкендов в pg_stat_activity (ноль на первом же опросе) → перенос gendesign, tradein, auth → подъём стека → сверка → пауза перед DNS.

Замеры совпали с репетицией с точностью до секунд: дамп gendesign 138 с против 141 с на репетиции, общий перенос 336 с против 326 с.

Сверка после переноса — все счётчики строк сошлись ровно:

Объект Строк
rosreestr_deals 7 571 875
listings 109 308
deals 108 623
listing_source_snapshots 5 086 346
auth.users / auth.sessions 13 / 32
таблиц всего 200

Одна находка сверх раннбука: БД auth в дамп gendesign не входила и была бы потеряна — перенесена отдельно, гранты и сессии проверены.

Приёмка по состоянию на утро 26.08, после первой ночи без присмотра: пять боевых доменов на 188.246.224.93 (gendsgn.ru 401, www 301, meraocenka.ru 200, meraotsenka.ru 301, merahome.ru 301), четыре инфраструктурных остались на Beget. Боевой расчёт МЕРЫ отвечает за 90 мс. Скрапер за ночь добавил 772 объявления (avito 449, domklik 235, cian 88). Оба бэкапа отработали кроном с заливкой в S3. FDW tradein → gendesign живой — через него читается 7 571 875 сделок.

Откат остаётся возможным: живая БД МЕРЫ на Beget заморожена на момент cutover (max(scraped_at) = 25.08 17:23), для Птицы — проверенный дамп на 1572 объекта плюс свежие ночные копии в S3.

Что вынесено отдельно и НЕ входит в это закрытие: сужение периметра (#3075) и остаток по интеграциям, привязанным к старому IP (#3059).

Закрыто — раннбук исполнен 25.08, окно уложилось в 7 мин 38 с. Cutover 19:35:56 → 19:43:33 UTC. Порядок по раннбуку соблюдён: снятие crontab → остановка Caddy → остановка писателей МЕРЫ → остановка писателей Птицы → ожидание нуля клиентских бэкендов в `pg_stat_activity` (ноль на первом же опросе) → перенос `gendesign`, `tradein`, `auth` → подъём стека → сверка → пауза перед DNS. Замеры совпали с репетицией с точностью до секунд: дамп `gendesign` 138 с против 141 с на репетиции, общий перенос 336 с против 326 с. Сверка после переноса — все счётчики строк сошлись ровно: | Объект | Строк | |---|---| | `rosreestr_deals` | 7 571 875 | | `listings` | 109 308 | | `deals` | 108 623 | | `listing_source_snapshots` | 5 086 346 | | `auth.users` / `auth.sessions` | 13 / 32 | | таблиц всего | 200 | Одна находка сверх раннбука: БД `auth` в дамп `gendesign` не входила и была бы потеряна — перенесена отдельно, гранты и сессии проверены. Приёмка по состоянию на утро 26.08, после первой ночи без присмотра: пять боевых доменов на `188.246.224.93` (`gendsgn.ru` 401, `www` 301, `meraocenka.ru` 200, `meraotsenka.ru` 301, `merahome.ru` 301), четыре инфраструктурных остались на Beget. Боевой расчёт МЕРЫ отвечает за 90 мс. Скрапер за ночь добавил 772 объявления (avito 449, domklik 235, cian 88). Оба бэкапа отработали кроном с заливкой в S3. FDW `tradein → gendesign` живой — через него читается 7 571 875 сделок. Откат остаётся возможным: живая БД МЕРЫ на Beget заморожена на момент cutover (`max(scraped_at)` = `25.08 17:23`), для Птицы — проверенный дамп на 1572 объекта плюс свежие ночные копии в S3. Что вынесено отдельно и НЕ входит в это закрытие: сужение периметра (#3075) и остаток по интеграциям, привязанным к старому IP (#3059).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/3469-showcase-schedule
fix/3443-caddy-selfdowntime
fix/3463-db-statement-timeout
fix/3448-caddy-only-detection
fix/metrics-deploy-reloads-prometheus
feat/landing-showcase-band
fix/3452-corridor-advisory-zone
fix/alert-value-is-not-the-ratio
fix/3449-geocoder-cancel-orphan
fix/3451-tvf-deals-rooms
fix/msk-collector-net-retry
feat/msk-yandex-import
fix/3051-fetch-deals-rooms-dropped
feat/msk-collector-cian
fix/3256-asking-to-sold-buckets
fix/3083-estimate-throughput
fix/3274-part2b-gate
fix/3274-part2a-caddy-retry
fix/perimeter-smoke-retry-on-no-response
fix/3274-zero-downtime-frontend
fix/3274-part1-deploy-swap
fix/3412-cian-instance-relaunch
fix/3415-bucket-done-only-if-phases-ok
chore/backend-pool-wiring-tails
fix/3398-pool-ops-off-event-loop
fix/3402-followups-ban-kinds-curl
feat/3404-proxy-run-attribution
fix/cian-captcha-is-platform-refusal
refactor/3390-single-runs-module
fix/3398-estimator-valuations-proxy-pool
fix/3386-estimator-imv-proxy-pool
fix/3394-cian-sweep-houses-proxy-pool
fix/3393-interrupted-runs-outside-streaks
fix/drain-marks-inflight-app-tasks
fix/3384-no-proxy-at-batch-start
fix/3197-yandex-newbuilding-proxy-pool
fix/3376-price-history-decimal-slips
fix/backend-proxy-pool-flags
fix/3197-cian-history-backfill-proxy-pool
fix/3288-sidecar-ban-status-code
fix/3375-yandex-fullload-on-bucket-contract
fix/3380-deploy-metrics-alloy-recreate
fix/3354-alloy-query-secret-scrub
fix/3360-admin-prefix-anon-404
fix/3368-yandex-leaf-complete-flag
fix/3369-domclick-cancel-checkpoint
fix/3225-domklik-diff-percent
fix/smoke-history-path
fix/3288-breaker-block-kind
fix/3355-drain-mark-fullloads
fix/3191-yandex-detail-completeness
fix/3359-containment-cian-yandex
fix/3323-payment-init-fail-409
fix/3172-freshness-by-data
fix/3288-avito-ban-per-source
fix/3253-domclick-house-fields
fix/3312-defer-interval-minutes
fix/3324-rbac-401-oracle
fix/3274-deploy-window-error-page
fix/3343-auth-latency-flaky
fix/3315-exhaustive-containment-skip
fix/3338-backfill-save-false
fix/3339-thin-market-badge
fix/3154-glitchtip-secret-log-leak
fix/3333-drain-mark-all-sweeps
fix/3323-imv-thin-market-gate
fix/3324-mera-perimeter
fix/3323-coverage-copy-honesty
fix/3332-domclick-counter-identity
fix/3324-ptica-deploy-gate
fix/3316-role-single-source
fix/3319-citysweep-checkpoint
fix/3322-rosseti-stable-key
fix/3320-v2-honest-zeros
fix/3321-draft-fields-survive
fix/mera-mobile-nav-and-sticky
fix/audit-form-ux
fix/audit-coverage-500
fix/audit-dkp-price
fix/audit-accuracy-window
fix/audit-faq-contradiction
fix/perimeter-smoke-after-payments
feat/b2c-landing-honest-copy
feat/b2c-landing-live-numbers
feat/b2c-v3-becomes-root
feat/b2c-v3-port-v1-blocks
feat/b2c-report-redesign
feat/b2c-landing-v3-full
feat/3192b-yandex-phones
feat/3168-backfill-cursor-resume
fix/3118-domclick-no-proxy
fix/3170-yandex-combo-checkpoint
feat/3074-newbuilding-sweep-resume
fix/3163-infra-topic-default
fix/3156-tgbot-error-type
feat/3163-infra-topic-split
fix/3161-alertmanager-route-prefix
fix/3155-prometheus-no-alertmanager
feat/2997-drop-listings-geom-idx
fix/3122-boot-reap-observable
feat/3122-boot-reap
feat/3051-houses-region-code
feat/3074-cian-anchor-checkpoint
feat/3051-region-registry
fix/2656-anchor-ratio-freshness
fix/3114-scrub-credentials-in-logs
fix/3078-grafana-single-auth
fix/3081-honest-progress
fix/3063-pro-seller-derive
fix/3074-checkpoint-survives-claim
fix/3082-estimate-concurrency
fix/3044-enriched-total-seen
fix/telegram-pin-selectel-override
chore/compose-host-parameterised-resources
fix/revisit-floor-lateral-lookup
fix/avito-detail-fields
fix/3034-avito-fingerprint
fix/avito-offers-per-page
feat/3033-avito-secondary-filter
fix/2203-restore-drill-readiness
feat/2203-backup-staleness-and-forgejo
fix/2990-clean-start-initdb
fix/2924-yandex-jk-resolve-tried-at
fix/2992-upsert-distinct-gate
fix/2998-rosreestr-q2-partitions
feat/2936-null-penalty-flag
fix/2996-mislocated-houses-watchdog
fix/1781-secondary-only-param
fix/2934-risks-coverage
fix/2464-three-small
fix/2464-two-docstrings
fix/2464-zouit-label
fix/2464-building-pct-guard
fix/2464-download-binary-retry
fix/2986-permits-key
fix/2464-tep-docstring
fix/2464-act-date-backfill
fix/2464-area-bin-null
fix/2464-act-date-citation
fix/2464-detect-kind
fix/2464-status-negation
fix/2464-objective-zombie-sweep
fix/2464-inert-retry-config
fix/2464-default-profile-unique
fix/2464-zombie-any-running
fix/2464-catalog-skipped-counter
fix/2464-heat-loader-tx
fix/2464-objective-run-stuck
fix/2464-catalog-waf-breaker
fix/2464-lock-key-order
fix/2464-backfill-waf-abort
fix/2464-docs-vs-code
fix/2464-land-reservation-dedup
fix/2464-manual-list-validation
fix/2464-capacity-savepoints
fix/2464-leads-window-naming
fix/2464-zouit-count-label
fix/2464-catalog-batch-commits
fix/2464-html-zoning-fallback
fix/2950-lock-wait-observable
fix/2956-freshness-counts-failed-harvest
fix/2950-host-lock
fix/2953-nominatim-throttle
fix/2950-deploy-docker-lock
fix/2464-ird-lookups-savepoint
fix/2464-parcels-savepoint-pair
fix/2674-deal-floor-display
docs/2854-stale-justifications
chore/2857-drop-placeholder-columns
fix/2855-probe-protected-path
fix/2674-has-panorama
fix/house-imv-anchor-era
fix/2674-quality-cadastre-column
fix/sber-freshness-guard
fix/dkp-corridor-as-of
fix/scheduler-resume-checkpoint
fix/quarter-target-from-neighbour
fix/2687-domclick-ban-kind-platform
fix/2814-address-backfill
fix/2677-house-anchor-renovation
feat/tradein-paid-retention
chore/ci-config-cleanup
feat/mera-b2c-privacy
feat/tradein-payments-schema
chore/2674-dead-code-sweep
fix/2674-matching-tiers-honesty
fix/2674-avito-full-load-coverage
fix/2674-admin-metrics-honesty
fix/2674-writers-honor-schema
fix/2674-alerts-actually-fire
fix/2679-scraper-deploy-parity
fix/2674-house-imv-params
fix/2666-discount-plausibility-gate
feat/2435-cian-house-enrichment
fix/2657-domclick-block-not-done
feat/2571-login-throttle
fix/2660-display-freshness-segment
fix/2658-loud-skip-status
fix/2603-geocode-city-hint-tails
feat/2600-per-source-proxy-health
feat/tradein-v2-exposure-in-result-card
fix/tradein-avito-browser-proxy-pool
chore/tradein-cut-wasteful-scraping
fix/tradein-v2-deals-fallback-visible
fix/tradein-city-stamp-geo-guard
fix/tradein-cian-oblast-secondary
fix/tradein-implausible-build-year
fix/tradein-snapshot-query-perf
fix/tradein-asking-sold-city-scope
chore/tradein-purge-dead-mobileproxy
feat/tradein-asocks-rotation
fix/tradein-region-code-foreign-cities
fix/tradein-proxy-pool-self-healing
fix/tradein-backfill-listing-city-from-url
fix/tradein-geocode-queue-active-only
fix/tradein-geocode-city-hint
chore/tradein-remove-yandex-scripts
fix/tradein-listing-city-from-sweep
chore/tradein-remove-yandex-geocoder
chore/tradein-remove-n1
fix/tradein-geocoder-fail-closed
fix/tradein-ui-city-label-clip
feat/tradein-ui-city-hint
fix/tradein-coords-backfill-city-gate
fix/tradein-geocoder-city-default
fix/tradein-anchor-geo-scope
fix/tradein-avito-detail-oblast
feat/tradein-price-bands-refresh
feat/tradein-caddy-cutover
fix/tradein-team-nav-and-401
feat/tradein-team-dashboard
fix/tradein-team-list-order
feat/tradein-team-api
feat/tradein-login-ui
feat/tradein-auth-core
feat/tradein-auth-password-foundation
feat/tradein-auth-users-schema
fix/tradein-rbac-test-user2-expired
fix/tradein-auth-revoke-user2
fix/2013-avito-cohort-null
fix/rbac-test-user2-expired
fix/expire-brusnika-trial-access
feat/tradein-domclick-house-sku-schema
chore/design-sync-tradein
fix/tradein-deploy-scraper-paths-filter
fix/tradein-no-numberless-house-insert
fix/tradein-dedup-fias-pass-no-geoguard
feat/tradein-fias-estimate-frontend
fix/tradein-dedup-by-fias
feat/tradein-fias-tier-matching
fix/tradein-v2-uiux-p1
fix/objective-lots-dedup-1964
fix/audit-followups-1953
feat/concept-house-picker-1965-stage3b
feat/concept-house-catalog-1965-stage3a
feat/concept-live-massing-1965-stage2b
feat/concept-recompute-1965-stage2a
feat/concept-section-1965-stage1
fix/best-layouts-per-object-snapshot-1956
fix/deficit-segmentation-1959
feat/tradein-hedonic-ground-floor
fix/report-map-points-1961
fix/report-microcopy-1963
fix/report-nspd-zoning-1962
fix/report-frontend-display-1953
perf/tradein-estimate-audit
perf/best-layouts-objects-first
fix/171-migration-path
perf/171-objective-crm-report-month-idx
fix/1926-app-log-stdout
fix/estimator-tiebreaker-nanalogs
fix/1917-fetch-json-network-retry
fix/1926-scrape-runs-total-seen
fix/1781-house-fk-source-identity
feat/39-osrm-per-category
feat/1746-utility-infra-map
fix/test-849-savepoint-count
fix/parking-economics-by-class
fix/zouit-engineering-area-gate
fix/zoning-resolution-decouple
feat/dcf-velocity-schedule
feat/zone-regulation-backfill
chore/mock-financial-estimate
fix/finmodel-split-disclosure-threshold
feat/finmodel-financing
feat/finmodel-sitefinder-bridge
feat/finmodel-dcf
feat/finmodel-price-calibration
feat/finmodel-cost-cascade
audit/1871-p2-estimator-dedup-split
audit/1871-p2-avito-coord
audit/1871-p3-uiux
audit/1871-p2-invest-moi
audit/1871-p2-velocity-market
audit/1871-p1-3-isreal-stubs
audit/1871-p1-2-ghost-anchor-guard
audit/1871-p1-scenarios-collapse
revert/site-finder-v2
fix/v2-remove-resource-legend
fix/v2-map-legend-position
feat/site-finder-v2-map-light-polish
rollback/site-finder-home-light
feat/site-finder-v2-cockpit
rollback/sf-old-analysis-design
feat/ptica-tabs-6-6-reports-params
fix/ptica-vri-row
feat/ptica-map-glyphs-sitefinder-dark
fix/ptica-3d-preview-product-verdict
fix/ptica-button-fontsize
fix/ptica-parity-data-mapping
chore/ptica-iso-preview-spin
fix/ptica-inter-map-product
fix/ptica-visual-parity
fix/ptica-left-rail
feat/ptica-cockpit-complete-bottom
feat/ptica-default-and-rich-map
feat/ptica-real-ksit-frontend
feat/tradein-ekb-geoportal-buildings
fix/sf-feedback-batch
feat/avito-newbuilding-sweep
feat/browser-concurrent-pool
fix/backfill-kadastr-column
fix/avito-proactive-ip-rotate
feat/activate-domclick-sweep
feat/avito-newbuilding-capture
fix/house-id-fk-realtime-link
fix/migration-162-table-if-exists
feat/riasurt-sverdl-layers-108
fix/sber-dataset-paths-902
fix/conflict-resolution-freshness-1539
feat/objective-lots-history-writer-307-obj6
feat/velocity-mv-61
fix/objective-mapping-is-reviewed-gate-307-obj2
fix/cian-detail-rich-fields
fix/avito-novostroyki-segment
feat/yandex-novostroyki-newflat
fix/ci-dedup-runner-storm-1709
fix/emiss-pk-granularity-1687
feat/listings-segment-param-1188
fix/inn-regex-word-boundary-1682
fix/excel-deficit-horizon-1590
fix/admin-scrape-validation
fix/admin-leads-interval-cast-1694
fix/dkp-corridor-doc-p10p90-1695
fix/weather-wind-d-allnone
test/residential-zone-rawprops-1681
fix/domrf-badge-regex-narrow-1686
feat/yandex-camoufox-transport
fix/score-sat-factor-1509
fix/base-pace-room-bucket-1593
fix/gate-verdict-no-blocker-1617
fix/confidence-deal-count-window-1637
fix/match-economics-1511-1512
fix/listings-partial-indexes-1398
fix/smart-suggestions-threshold-1503
fix/dkp-corridor-percentile-1520
fix/enrich-economics-window-1513
fix/leads-stats-window-1383
fix/poi-score-scale-1486
fix/geo-weight-floor-1633
fix/inn-regex-context-1640
fix/domrf-status-classify-1609
fix/emiss-period-dedup-1606
fix/cian-paginate-tail-1393
fix/normalize-zero-fill-guard-1638
fix/supply-view-devgroup-key-1650
fix/residential-zone-detect-1353
fix/score-label-threshold-1357
fix/trend-ratio-vprior-zero-1508
fix/district-median-dedup-1352
fix/supply-layers-overlap-1355
fix/pdf-expires-at-1530
fix/quartirography-area-bucket-1406
fix/cad-zones-multipolygon-1344
fix/sold-pct-market-verdict-1407
fix/week-review-finish
fix/week-review-backend-v2
feat/plan-vectorization-spike-299
fix/1668-analyze-confidence
fix/1667-metro-block
fix/1666-layout-velocity-beat
chore/remove-n1-scraper
fix/cian-kitchen-area
feat/yandex-detail-backfill
feat/avito-detail-backfill
fix/best-layouts-bucket-normalization
fix/gknspecial-incremental-commit-per-prefix
fix/okn-objects-full-registry-load
fix/parcel-ird-overlap-except-expand
fix/report-assembler-confounded-keys
fix/job-settings-json-persist-v2
fix/nspd-geo-soft-time-limit-passthrough
fix/nspd-soft-time-limit-v2
fix/pilot-request-modal-validation
fix/recommend-mix-saturation-latest-snapshot
fix/scrape-cadastre-fail-counter-v2
fix/izyatie-ocr-cad-normalize
fix/job-settings-panel-json-state-persist
fix/noise-loader-savepoint-per-row
fix/objective-sync-config-bare-except
fix/parcel-snapshot-mdash-double-escape
fix/poi-loader-leap-year-date-replace
fix/scrape-cadastre-permanent-fail-counter
fix/usermenu-analyst-role-label
feat/location-948b-r
feat/location-entity-948b
feat/insight-entity-948a
feat/analyst-role-audit-962
feat/cbr-inflation-macro-946
feat/cian-zhk-resolve-972
perf/forecast-parallel-horizons-1129
feat/newbuilding-enrich-backfill-972
feat/emiss-macro-indicators-946
feat/rosstat-emiss-macro-946
ci/frontend-vitest-job
chore/frontend-vitest-wkt-tests
feat/forecast-meta-footer
feat/forecast-future-supply-competitors
feat/forecast-docx-pptx-buttons
feat/forecast-scoring-panel
feat/forecast-product-tz-block
feat/market-map-layers-999
feat/forecast-chart-section6
feat/forecast-export-pptx-959
feat/forecast-export-docx-959
feat/forecast-export-ui-959
feat/forecast-export-telegram-959
feat/forecast-export-md-959
feat/analyze-response-contract-961
feat/competitor-velocity-spatial-fallback-968
fix/frontend-healthcheck-hostname
feat/analyze-market-coords-999
fix/site-finder-entry-crash-1001
feat/horizon-selector-996
feat/forecast-section-998
feat/forecast-endpoint-horizon-enqueue
feat/forecast-celery-task-persist
feat/forecast-orchestrator-service
feat/demand-supply-months-of-inventory
feat/wire-district-resolver
feat/district-vocab-reconciliation
fix/affordability-market-spread
fix/backtest-sig-gate
feat/wire-978-almon-rate-regime
feat/backtest-oos-almon-seasonal
ci/forgejo-pytest-gate
fix/tradein-praktika-logo-form-scroll
feat/yandex-exhaustive-price-room
feat/794-sber-time-adjust
chore/bot-harness-tuning
docs/agent-usage-throttle-qa-terminal
fix/avito-sweep-single-run-guard
chore/analyst-inbound-queue-tradein-db
feat/801-preview-full-wt
chore/bot-safety-followups
feat/tradein-avito-imv-fix
feat/tradein-repair-coef-calibration
feat/tradein-avito-houses-fix
feat/tradein-address-precision
feat/tradein-backfill-prioritize-listings
feat/tradein-geocode-deals-nominatim
feat/tradein-geocode-deals-from-houses
feat/tradein-same-building-match
feat/claude-envvars-and-stale-cron
No results found.
Labels
Clear labels   
Fable 5 ревью

Находки полного мульти-агентного ревью (Claude Fable 5, 2026-06-09)

  
GG-форсайт

Новое ТЗ от Ген Геныча (июнь 2026): Site Finder v2 — ИИ-прогноз продуктовой стратегии девелопера. Актуальный приоритет.

  
admin

Admin UI / internal tools / pipeline tracker

  
analytics

Аналитика данных / matching

  
auth

Authentication / authorization / multi-tenancy

  
automation

Автоматизация / cron / scheduler

  
bug

Something isn't working

  
business

Коммерческая воронка / пилоты / pipeline / реестр ПО

  
chore

Operational housekeeping

  
ci

Forgejo Actions / build pipeline

  
compliance

152-ФЗ / реестр ПО / legal / TOS

  
data

Data sources, parsers, ETL

  
data-moat

Уникальные данные — sales tracker, CRM aggregation

  
docs

README / runbooks / onboarding

  
duplicate

This issue or pull request already exists

  
dx

Developer experience / build speed

  
enhancement

New feature or request

  
feedback/max

Feedback from Max (Senior partner)

  
generative

Generative Design — concept generation engine

  
needs-discussion

Pending team sync / decision

  
needs-human

Human review/decision required

  
observability

Monitoring / metrics / logs / Sentry / Uptime

  
pause-bots

Kill-switch — all autonomous bots pause

  
performance

Latency / throughput / DB query tuning

  
priority/p0

Critical / production-blocker

  
priority/p1

High priority

  
priority/p2

Normal priority

  
priority/p3

Низкий приоритет (follow-up, tech-debt)

  
scope/backend

Backend Python — FastAPI, Celery, scrapers

  
scope/db

DB migrations, indexes, SQL

  
scope/devops

docker-compose, Caddy, workflows

  
scope/frontend

Frontend — Next.js, React, TypeScript

  
scope/qa

Tests, smoke, Playwright

  
scrapers

Скрапперы (Avito/Cian/Yandex/Rosreestr)

  
security

Security audit / secrets / vulnerabilities

  
site-finder

Site Finder scoring quality & data layer

  
stage/1

Stage 1: Generative MVP (нед 2-7)

  
stage/2

Stage 2: Site Finder MVP (нед 8-12)

  
status/blocked

Blocked — needs human intervention

  
status/done

Closed, completed

  
status/needs-analysis

Raw/fuzzy task filed by human — auto-analyst подхватывает: code-archeology + декомпозиция в actionable scope/* + status/ready (или split на под-issues)

  
status/needs-fix

Reviewer/QA вернул worker на доработку — worker сам чинит свой PR (fixup), НЕ требует human (в отличие от status/blocked)

  
status/qa

PR merged, awaiting smoke test

  
status/ready

Ready for pickup by worker bot

  
status/review

PR open, awaiting code review

  
status/wip

Work in progress (worker claimed)

  
tech-debt

Технический долг

  
tradein

Trade-In MVP проект

  
ux

User experience / responsive / conversion

  
week ревью 1

Week review 1 — находки multi-agent аудита проекта (2026-06-14)

  
wontfix

This will not be worked on

  
ИРД

Исходно-разрешительная документация — слой ограничений участка для analyze-таблицы

  
вторичка

Trade-In Estimator — проект оценки вторичного жилья

No labels
Fable 5 ревью
GG-форсайт
admin
analytics
auth
automation
bug
business
chore
ci
compliance
data
data-moat
docs
duplicate
dx
enhancement
feedback/max
generative
needs-discussion
needs-human
observability
pause-bots
performance
priority/p0
priority/p1
priority/p2
priority/p3
scope/backend
scope/db
scope/devops
scope/frontend
scope/qa
scrapers
security
site-finder
stage/1
stage/2
status/blocked
status/done
status/needs-analysis
status/needs-fix
status/qa
status/ready
status/review
status/wip
tech-debt
tradein
ux
week ревью 1
wontfix
ИРД
вторичка
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lekss361/gendesign#3057
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?