Files
orchestrator/docs/work-items/ORCH-062/10-tech-risks.md

5.4 KiB
Raw Blame History

work_item, stage, author_agent, status, created_at, model_used
work_item stage author_agent status created_at model_used
ORCH-062 architecture architect proposed 2026-06-09 claude-opus-4-8

10 — Технические риски: ORCH-062 — авто-prune docker build cache на mva154

Work Item: ORCH-062 · Repo: orchestrator · Стадия: architecture

Информационный (гейтом не парсится). Детализация R-1…R-4 из BRD + риски, выявленные при архитектурном решении (Вариант A, ssh-на-хост). Решение — 06-adr/ADR-001-build-cache-pruner.md.

Реестр рисков

ID Риск Вер. Влия. Митигейшн
TR-1 Слишком агрессивная политика (-a без возрастного фильтра / малый until) убивает тёплый кэш → каждая сборка «холодная», медленная (BRD R-1) Низ. Сред. Дефолт docker builder prune -f --filter until=24h без -a; -a — только опционально и всегда в паре с until (D2/AC-2). Параметр удержания конфигурируем
TR-2 Гонка уборки с активной сборкой staging/прод-образа (check_staging_image_fresh, build-once retag) — теоретическое удаление кэша во время сборки (BRD R-2) Низ. Низ. docker builder prune --filter until=24h по контракту BuildKit не трогает кэш, занятый/использованный активной сборкой (свежий < 24ч); период тика — порядка часов (6ч), не конкурирует за ресурсы (NFR-4)
TR-3 Контейнер не имеет docker CLI (Dockerfile:11) → наивный subprocess.run(["docker",…]) упал бы FileNotFoundError — (закрыт решением) Решено архитектурно: уборка идёт через ssh на хост (image_freshness-канал), не CLI-в-контейнере. Не риск реализации, а зафиксированный инвариант D3
TR-4 ssh-канал недоступен (нет deploy_ssh_host / закрыт ssh) → уборка не выполняется Низ. Сред. Тик no-op + причина в status().last_error (наблюдаемо в GET /queue); never-raise — конвейер не страдает; документированный host-cron fallback (07 I-3); disk-watchdog продолжает сигналить о росте диска
TR-5 Расширение скоупа на docker image prune / system prune → удаление образов запущенных контейнеров (BRD R-4) Низ. Выс. Жёстко исключено D2/FR-3/AC-3: команда строго docker builder prune; reviewer проверяет отсутствие image prune/system prune/рестарта в коде и процедуре
TR-6 Рестарт прода/докера ради уборки (групповой self-hosting риск) — (исключён) Выс. Вариант B (рестарт docker daemon) отвергнут именно по этой причине; Вариант A не рестартит ни прод, ни docker daemon (D3/I-3)
TR-7 Сбой docker-команды/таймаут на хосте всплывает в фоновый поток → останавливает цикл/конвейер Низ. Сред. never-raise per-команда и per-tick (D6/FR-6/AC-4), как disk_watchdog._run/tick; ненулевой rc/таймаут/OSError логируются и проглатываются
TR-8 Telegram-шум при каждом тике Низ. Низ. Нотификация только при освобождении ≥ notify_min_gb; дефолт 0 → тихо (D4/D5)

Сводный вывод

Доминирующий класс — операционная безопасность self-hosting (уборка на проде, обслуживающем все проекты). Все высоко-влиятельные риски (TR-5/TR-6) структурно исключены выбором узкой команды docker builder prune и отказом от рестарта docker daemon/прода (отклонён Вариант B). Остаточные риски — низкой вероятности и нейтрализуются never-raise + наблюдаемостью в GET /queue

  • обратимостью kill-switch.

Эскалация: вводится новый фоновый компонент (leaf-демон) — формально подпадает под arch:major-change. Однако это калька уже принятого паттерна disk_watchdog/reconciler/ job_reaper без изменения STAGE_TRANSITIONS/QG_CHECKS/схемы БД и без рестарта прода, поэтому остаточный риск для прод-конвейера — низкий; возврат в анализ не требуется (ТЗ реализуемо без нарушения принципов архитектуры).