--- _last_updated_: 2026-05-28T16:30:00+03:00 session_id: 2026-05-28-prod-epz-search-outage-admin-handoff --- # Next session handoff _Сессия: новая admin task `restore-elasticsearch-indices-books-vds` заведена по итогам диагностики prod outage в репозитории `books`._ ## Recent commits - (pending — этот сеанс ничего не commit'ил; .tasks/STATUS.md + .tasks/restore-elasticsearch-indices-books-vds.md + .tasks/NEXT_SESSION.md готовы к одному commit'у) ## Контекст инцидента В репо `books` сегодня диагностировали prod outage поиска slovo (товары + EPZ): `/api/{epz,products}/search` возвращают 500 `index_not_found_exception`. Эндпоинты лезут на canonical ES `https://elasticsearch.kzntsv.site/` (books VDS Portainer stack 33) — и не находят там ни `epz`, ни `products`. **curl `_cat/indices`** на двух сторонах: - `elasticold.kzntsv.site` (Windows rollback, live) — **полный набор**: epz 820604 / products 105922 / artmone 2621. - `elasticsearch.kzntsv.site` (books VDS stack 33) — **0 индексов**, cluster green, 0 active primary shards. Даже `read_me` плейсхолдер из миграции 25.05 пропал. **Окно поломки:** 27.05 10:24 MSK (последний рестарт `books-api`/`books-web`, ошибок в их stderr ещё не было) → 28.05 13:59 UTC (первая фиксация `index_not_found_exception` в логах). В этом окне на books VDS шла работа `bookva-tenant-cutover-prep` (Step 2 — 9 Portainer stacks создавались, в т.ч. **bookva-es=37**). Возможный конфликт volume/audit на stack 33 — выяснить forensics'ом. Snapshot repo `kreknin` на target ES зарегистрирован (location=/snapshots). `pre-migration-2026-05-25` снапшот был только с `read_me` placeholder, для restore не годится. Но **в kreknin могут быть post-25.05 daily snapshots** (`books-vds-backup-daily-kreknin` пайплайн closed 25.05) — проверить `_snapshot/kreknin/_all?verbose=true`, искать снимок с непустыми epz/products/artmone. ## LIVE сейчас - **books-app prod**: поиск slovo (товары + EPZ) лежит, пользователи видят 500 на `/epz/search`. Заведена `epz-search-seller-pin-tenant` ⚪ в `books` репо как side-issue (хардкод `findByPk(1)`), но **не блокер этого outage'а**. - **Source ES** на Windows host жив (`elasticold.kzntsv.site` через traefik basicAuth) — не disabled per migration policy, годится для повторного reindex. - **Target ES** на books VDS жив (cluster green, отвечает 200 на `_cluster/health`), но индексов нет. ## Что делать на следующей сессии (по приоритету) ### 1. **Forensics + restore** — `restore-elasticsearch-indices-books-vds` ⚪ Полный playbook + acceptance в task-файле. Старт: ```bash # на books VDS — Portainer audit stack 33 curl -fsS -H "X-API-Key: $PORTAINER_TOKEN" \ https://portainer.kzntsv.site/api/stacks/33 | jq '.UpdateDate, .Status' sudo docker volume inspect /usr/docker/elasticsearch/data sudo ls -lah /usr/docker/elasticsearch/data/nodes/0/indices/ 2>/dev/null ``` Затем — `curl _snapshot/kreknin/_all?verbose=true` на target → если post-25.05 snapshot с непустыми индексами есть → restore. Иначе — reindex повторно по `migrate-elasticsearch-to-books-vds.md` Steps 4–6 (730MB, ~5–10 мин). После — `docker restart books-api books-web books-task-runner books-job-scheduler` (на случай stale connection pool у consumer'ов). ### 2. **(carried) Registry GC** — ~20G storage reclaim Из прошлого handoff'а, всё ещё pending. Read-only=true ~5–15 мин: ```bash sudo docker exec registry registry garbage-collect --delete-untagged=true /etc/docker/registry/config.yml sudo du -sh /opt/stacks/registry ``` ### 3. **(carried) Cleanup netplan artifacts** — low priority, оставить `/etc/netplan/01-eth0.yaml`, `/etc/netplan/50-cloud-init.yaml`, `/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg` — не влияют (netplan masked), оставить пока кто-нибудь не решит снять mask. ### 4. **(carried) board-viewer-build unhealthy** — пред-инцидент Не связан с outage'ом. Опционально разобрать через `sudo docker logs board-viewer-build | tail -50`. ## Спроси user'а - **ES restore сейчас или подождать low-traffic окно?** Reindex 730MB / 5–10 мин, slovo поиск всё это время уже лежит — задержка не критична для бэка, только для пользователей. Snapshot restore (если есть свежий) — быстрее. - **Push** wiki + memory + tasks — push'нуть commit'нутые изменения в origin? (Per project-discipline нужен per-session grant, пока не давал.) - **Cleanup netplan artifacts** — оставить или зачистить? (carried) ## Не делать (preemptive guards) - **НЕ stop / recreate Portainer stack 33** до forensics. Если volume накосячил из-за recreate — повторный recreate может затереть оставшиеся следы (logs, audit). - **НЕ удалять `kreknin` repo / старые snapshot'ы** до confirm'а что restore не нужен. `pre-migration-2026-05-25` сам по себе не годится, но **в repo могут лежать другие snapshots** от daily пайплайна. - **НЕ менять consumer config'и в `books`** на elasticold обратно. На VPS bind-mount уже sed'нут на canonical с 25.05 — пусть остаётся. Восстановим данные на canonical endpoint'е, не двигаем endpoint. - **НЕ unmask netplan/systemd-networkd** на vds-kzntsv (carried — anti-pattern для Rusonyx). - **НЕ reboot VDS без необходимости** (carried). - **НЕ делать registry GC без `read-only=true`** (carried). ## Memory updates за сессию - (нет новых memory-файлов — incident self-contained в task file с pointers на migration playbook) ## Wiki ингест - (нет на этом раунде — после restore, если forensics выявит конкретный trigger «X recreate стирает Y volume», стоит ингестнуть в `.wiki/concepts/portainer-stack-volume-pitfalls.md` или подобное; пока гипотеза только)