4.8 KiB
4.8 KiB
10 — Технические риски: ORCH-059
Work Item: ORCH-059 · Repo: orchestrator · ведёт: архитектор
Связано: 06-adr/ADR-001-confirm-deploy-status.md.
| ID | Риск | Вероятн. | Влияние | Митигация | Проверка |
|---|---|---|---|---|---|
| R-1 | Ключ confirm_deploy отсутствует в _DEFAULT_STATES / у проектов без статуса → KeyError в webhook-пути |
Сред | Выс (краш обработчика) | Доступ ТОЛЬКО через .get("confirm_deploy"); _DEFAULT_STATES не содержит ключ намеренно; отсутствие → ветка не активируется (fail-closed) |
TC-03, AC-7 |
| R-2 | Approved на deploy после правки вызывает check_deploy_status (вердикта нет) → ложный откат БАГ-8 / ложный advance |
Выс | Выс (петля dev↔deploy, ложный rollback прода) | Блок Фазы B возвращается рано для deploy + finished_agent is None self-hosting в ОБОИХ случаях; Approved → note=approved-on-deploy-noop, QG не запускается |
TC-05, TC-07, TC-11, AC-3 |
| R-3 | Самоправка прода требует внепланового рестарта прод-контейнера | Низ | Выс (встаёт конвейер всех проектов) | Изменение — чистая маршрутизация в коде; выкат через штатный deploy-staging (8501) → deploy; sentinel-состояние ORCH-036 не трогаем |
AC-9, RG-01 |
| R-4 | Confirm Deploy прислан на не-deploy стадии (оператор ошибся) → срабатывает как обычный approve и продвигает чужой гейт |
Низ | Сред | handle_confirm_deploy гардит stage == "deploy"; иначе no-op с логом |
TC-04 (+ ручная верификация) |
| R-5 | Кэш get_project_states закэширован до создания статуса «Confirm Deploy» → ключ не виден после конфигурации Plane |
Сред | Сред (деплой не запускается) | После создания статуса в Plane — reload_project_states(orch) или штатный рестарт по стадии deploy; зафиксировано в 07-infra-requirements.md |
ручная верификация |
| R-6 | Новый kwarg confirm_deploy ломает существующие вызовы advance_stage (launcher/reconciler/finalizer) |
Низ | Выс | keyword-only с дефолтом False; все вызовы передают finished_agent; не-deploy/finished_agent≠None пути не затронуты |
RG-01, AC-9 |
| R-7 | Регрессия идемпотентности Фазы B (двойной Confirm Deploy) |
Низ | Сред | Внутренности _handle_self_deploy_phase_b (маркер initiated) не меняются; меняется только триггер |
TC-08, AC-5 |
| R-8 | Реконсилятор F-1 на deploy (finished_agent=None) меняет поведение |
Низ | Низ (улучшение) | Намеренно: раньше неявно мог войти в Фазу B, теперь → no-op. Прод-деплой инициируется только явным Confirm Deploy. Документировано в ADR/README |
RG-01 |
| R-9 | Несовпадение имени статуса в Plane и _PLANE_NAME_TO_KEY (регистр/пробел) → ключ не резолвится |
Сред | Сред (деплой не запускается, fail-closed) | Точное имя «Confirm Deploy» (case-sensitive) — требование среды в 07-infra-requirements.md; маппинг ровно этой строкой |
TC-01, TC-02 |
Сводный вывод
Все риски — низкого/среднего остаточного уровня после митигаций. Доминирующий
класс — fail-closed: любая неполнота конфигурации (нет статуса, протухший кэш,
недоступный API) приводит к «деплой не запускается», а не к «деплой запускается
вслепую» или к крашу. Контракты конвейера (STAGE_TRANSITIONS, QG_CHECKS,
check_deploy_status, Фазы A/C, merge-gate, схема БД) не затрагиваются, поэтому
поверхность регрессии ограничена тремя модулями (plane_sync.py,
webhooks/plane.py, stage_engine.py).