---
doc_id: REF-CK8S-0014
type: governance
title: "kodex — управление рисками и релизами в четвёртой волне"
status: active
owner_role: EM
created_at: 2026-04-21
updated_at: 2026-04-23
related_issues: [470]
related_prs: []
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-04-21-refactoring-wave4"
  approved_by: "ai-da-stas"
  approved_at: 2026-04-21
---

# Управление рисками и релизами в четвёртой волне

## TL;DR
- Контур управления рисками и релизами проектируется как обязательная способность платформы, а не как внешний процесс поверх agent-manager.
- Каждый рабочий переход, `PR/MR`, кандидат в релиз и опасная `job` должны иметь класс риска и понятный набор обязательных контрольных точек.
- Владелец продукта утверждает документы, high-risk переходы и итоговое go/no-go решение по релизу, но не рассматривается как обязательный построчный reviewer каждого изменения кода.
- Машина приёмки и агентные роли могут закрывать часть проверки, но не имеют права подменять человеческую контрольную точку там, где policy требует решения человека.
- При переходе между этапами действует правило сильнейший риск побеждает: итоговый класс риска равен максимальному классу среди артефактов, действий и целевого контура.
- Release branches, release lines, разрешения плагинов и unattended automation тоже входят в governance-модель и не считаются внешними деталями.

## 1. Зачем нужна отдельная governance-модель
Новая платформа не может строиться на наивном допущении, что достаточно:
- запустить агента;
- получить `PR`;
- прогнать набор автоматических checks;
- без отдельной policy-логики перейти к merge или release.

Такой путь ломается в трёх местах:
1. не все изменения одинаково опасны;
2. не каждый этап требует одного и того же человеческого участия;
3. release не заканчивается в момент, когда закончилась build/deploy `job`.

Поэтому платформа обязана уметь:
- классифицировать риск;
- понимать, какой переход разрешён автоматически, а какой нет;
- собирать пакет подтверждений;
- останавливать процесс до нужного Human gate;
- фиксировать решение человека как часть канонического процесса.

## 2. Базовые принципы

### 2.1. Риск — свойство перехода, а не только артефакта
Класс риска может относиться к:
- задаче;
- `PR/MR`;
- запуску агента;
- платформенной `job`;
- release-кандидату;
- пострелизному действию;
- регламентной cleanup или recovery-операции.

Один и тот же `Issue` может пройти несколько разных переходов с разным уровнем риска.

### 2.2. Сильнейший риск побеждает
Если в одном переходе участвуют несколько источников риска, итоговый класс равен максимальному.

Примеры:
- безопасный `PR` + выкладка в production = не ниже класса production-перехода;
- обычная release-задача + `job` с destructive cleanup = не ниже класса destructive операции;
- `R1`-код + `R3`-миграция = итоговый переход `R3`.

### 2.3. Нельзя молча пересекать границу риска
Если переход требует Human gate, платформа обязана:
- перевести процесс в ожидающее состояние;
- показать, какой gate требуется;
- собрать минимальный evidence package;
- запросить конкретное решение, а не абстрактное посмотрите пожалуйста.

### 2.4. Owner не является обязательным reviewer всего кода
Owner обязан участвовать там, где его решение действительно меняет product/risk outcome:
- продуктовые документы;
- high-risk переходы;
- архитектурно опасные решения;
- финальное go/no-go по релизу, если это требует policy.

Owner не должен становиться ручным bottleneck для каждого изменения кода.

### 2.5. Агентный review не отменяет человеческую контрольную точку
Встроенные и пользовательские роли проверки полезны как:
- reviewer;
- `qa`;
- документационный контролёр;
- policy/gatekeeper;
- release-check;
- postdeploy-наблюдатель.

Но если transition policy требует человеческого решения, даже идеальный комментарий агента не заменяет это решение.

## 3. Источники риска

### 3.1. Источники классификации
Класс риска может быть задан или повышен через:
- тип задачи и flow;
- профиль риска проекта или репозитория;
- профиль риска сервиса, модуля, API или БД;
- тип целевого действия: merge, deploy, cleanup, rollback, hotfix;
- выбранный runtime-контур: `code-only`, `full-env`, production только для чтения, production с записью;
- разрешения пакета, статус верификации plugin или guidance package и их коммерческий/внешний источник;
- release branch, release line и rollout policy;
- trigger-driven или cron-driven запуск без ручного старта человека;
- внешние ограничения: auth, токены, доступ к секретам, rate limits, destructive operations;
- результаты acceptance machine, reviewer/qa/sre и других контрольных ролей.

### 3.2. Профиль риска
Платформа должна поддерживать профиль риска как policy-срез, который задаёт минимальный required class и mandatory gates для:
- проекта;
- репозитория;
- сервиса;
- API-контракта;
- класса данных;
- инфраструктурного действия.

Примеры:
- сервис аутентификации всегда не ниже `R3`;
- миграции production-БД всегда не ниже `R3`;
- изменение внешнего provider-контракта не ниже `R2`;
- docs-only изменение может остаться `R0`.

Профиль риска должен уметь задаваться не только на уровне сервис целиком, но и на более точных срезах:
- для всего проекта;
- для репозитория;
- для сервиса целиком;
- для каталогов, подкаталогов и файлов по glob-паттернам;
- для отдельных путей внутри `services.yaml` по path-паттернам и `json-path`-подобным селекторам;
- для всего файла `services.yaml` целиком.

Для `services.yaml` базовое правило этой волны такое:
- любое изменение файла по умолчанию считается рискованным;
- policy может дополнительно повышать риск для отдельных полей и путей;
- понижение риска для отдельных элементов `services.yaml` допускается только через явное policy-решение и не должно происходить по умолчанию.

### 3.3. Автоматическое определение риска
Платформа должна уметь автоматически определять initial classification на основе простой и прозрачной логики:
- changed files;
- changed paths;
- принадлежность пути к сервису, проекту или инфраструктурному контуру;
- risk profile проекта и репозитория;
- risk profile сервиса и его path-паттернов;
- специальных правил для `services.yaml`, миграций, auth, secret-bearing и destructive зон.

Автоматическое определение риска должно быть:
- детерминированным;
- объяснимым для человека;
- достаточным для initial classification без ручного чтения всего diff;
- пригодным для дальнейшего повышения риска агентом, acceptance machine или человеком.

### 3.4. Кто назначает и кто может менять класс риска
Базовая модель:
- initial classification формирует `agent-manager` по flow policy и профилю риска;
- профильный агент по рискам или иная разрешённая контрольная роль может повышать класс риска, если находит дополнительные факторы, не покрытые базовой классификацией;
- acceptance machine может только повысить класс или заблокировать переход;
- человек с соответствующим gate может повысить или понизить класс, но обязан оставить объяснение;
- понижение класса без явного человеческого решения запрещено.

Платформа должна поддерживать специальную встроенную роль управления рисками:
- её базовый профиль и место в каталоге ролей задаются в общей продуктовой модели;
- в governance-контуре она может рекомендовать повышение класса, запуск дополнительных control/review ролей и усиление gate-контуров;
- в governance-контуре она не может единолично понижать риск без human approval.

### 3.5. История изменения класса риска
Изменение класса риска не должно быть скрытым внутренним флагом.

Платформа обязана хранить и показывать:
- исходный автоматически назначенный класс;
- каждое последующее изменение класса;
- кто или что изменило класс: policy, агент-менеджер, контрольная роль, acceptance machine, человек;
- обоснование изменения;
- время изменения;
- какие дополнительные roles/gates были активированы этим изменением.

История класса риска должна быть видна в операторском и review-контуре так, чтобы человек понимал:
- почему процесс оказался в текущем risk state;
- кто усилил или понизил требования;
- какие решения уже были приняты на предыдущих шагах.

## 4. Каноническая шкала риска

| Класс | Характер изменения или действия | Типичный пример | Минимальный governance-контур |
|---|---|---|---|
| `R0` | Неисполняемые и безопасные изменения | docs-only, naming, процессные документы | документный review и policy-проверка |
| `R1` | Локальное исполняемое изменение без влияния на контракты, данные и production-policy | ограниченный кодовый фикс, локальная вёрстка, изолированная логика | стандартный технический review и машинные проверки |
| `R2` | Изменение бизнес-логики, provider semantics, модели данных, runtime-поведения или release-ready поставки | новый use-case, изменение API/DTO, `full-env` сценарий, стандартный релиз | усиленный technical review, профильный gate и release gate |
| `R3` | Аутентификация, секреты, destructive operations, production write-path, cluster-impact, критичные recovery/rollback сценарии | миграция production-БД, изменение auth-flow, destructive cleanup, срочный hotfix в критичный сервис | обязательный human approval перед применением и усиленный postdeploy-контур |

## 5. Роли в governance-контуре

| Роль | Что обязана делать | Что не обязана делать |
|---|---|---|
| `agent-manager` | определить initial risk class, собрать нужные роли и gates, остановить недопустимый переход | самостоятельно выдавать human approval |
| роль управления рисками | анализировать diff, policy и контекст артефактов с точки зрения риска, рекомендовать усиление контроля и запуск дополнительных ролей | самостоятельно понижать класс риска без human approval |
| acceptance machine | проверить контракт артефактов, policy, обязательные поля и наличие нужных gates | подменять reviewer или owner |
| технический reviewer | оценить корректность реализации и качество изменения | принимать product/go-no-go решение за owner |
| `qa` / контрольная роль | подтвердить проверяемое поведение, зафиксировать evidence и дефекты | обходить release gate |
| оператор / `sre` | подтвердить безопасное выполнение runtime/release действий и наблюдение за средой | утверждать продуктовую ценность изменения |
| Owner | утвердить документы, high-risk переходы и релизные решения, если этого требует policy | построчно проверять каждый кодовый diff |

Если один человек совмещает несколько ролей, это фиксируется как временная организационная мера, но не меняет саму модель обязанностей.

## 6. Правила переходов между этапами

### 6.1. До merge
- `R0` допускает документный review без отдельного release-контура.
- `R1` требует стандартного технического review и успешного acceptance/check-контура.
- `R2` требует минимум одного профильного Human gate сверх базовой машинной приёмки.
- `R3` не может пройти к merge-ready состоянию без явного high-risk gate.

Повышение класса риска должно уметь запускать дополнительные контуры проверки.

Канонические примеры:
- переход в `R2` может добавлять дополнительный review более сильной моделью или специализированной ролью поверх базового review-контура;
- такой дополнительный review может быть итеративным и повторяться после каждого цикла исправлений, если это требует policy;
- переход в `R3` может добавлять специализированную роль поиска уязвимостей, проверки опасных операций, секретов или production-impact ещё до выхода на owner review;
- конкретный набор дополнительных ролей и число повторов не зашиваются жёстко в код, а определяются flow policy, risk profile и профилем роли.

### 6.2. Перед релизом
- Любой переход в `release` обязан иметь release-кандидат, связанный с исходными `Issue/PR`.
- Если проект использует release branch или release line, platform policy обязана явно связывать их с release-кандидатом, rollout policy и нужными gates.
- `R1`-релиз может использовать облегчённую человеческую контрольную точку по policy проекта.
- `R2`-релиз требует явной релизной контрольной точки и пакета подтверждений.
- `R3`-релиз требует high-risk approval и готового postdeploy-плана до запуска deploy `job`.

### 6.4. Автоматические запуски и триггеры
Flow, который стартует:
- по cron;
- по alert-trigger;
- по package-driven callback;
- по другому внешнему событию без ручного старта пользователя,

обязан подчиняться отдельной automation policy.

Минимальные правила:
- automation rule имеет собственный risk profile;
- unattended start не отменяет Human gate там, где он требуется;
- trigger source должен быть трассируем;
- если automation rule создаёт `Issue` или запускает release-related процесс, это должно быть видно в governance-контуре как отдельный источник перехода.

### 6.3. После релиза
Релиз не считается завершённым в момент успешного deploy `job`.

Обязательная каноника:
1. deploy;
2. postdeploy-наблюдение;
3. оценка блокирующих сигналов;
4. решение `continue / hold / rollback / follow-up`;
5. перевод результата в стабильное состояние или в recovery-контур.

## 7. Решения, которые может выдать governance-контур

### 7.1. Канонические исходы gate
- `approve`
- `approve_with_conditions`
- `revise`
- `reject`
- `hold`
- `rollback`
- `escalate`

### 7.2. Что означают эти исходы
- `approve` — переход разрешён без дополнительных условий.
- `approve_with_conditions` — переход разрешён, но платформа обязана создать follow-up действия и явно их показать.
- `revise` — нужно исправление в том же артефакте или в новом follow-up.
- `reject` — текущий вариант не может идти дальше в этой форме.
- `hold` — процесс останавливается до внешнего решения, окна, ресурса или сигнала.
- `rollback` — нужно инициировать откат или recovery-сценарий.
- `escalate` — решение должно принять другой человек или другой уровень ответственности.

## 8. Что должно быть видно пользователю и оператору
Governance не должна жить только во внутренней БД.

Минимально должны быть видимы:
- текущий risk class;
- объяснение, почему он именно такой;
- какая контрольная точка требуется сейчас;
- кто должен принять решение;
- какой evidence уже собран;
- что именно блокирует переход;
- какой следующий допустимый action.

## 9. Что intentionally не фиксируется в этой волне
В этой волне не фиксируются:
- точные UI-компоненты risk inspector;
- финальный набор всех встроенных reviewer-ролей;
- точные организационные должности и их маппинг на Human gate;
- точные SLA по каждому типу gate.

Но любая следующая волна уже обязана считать класс риска, Human gate и управление релизами не факультативным процессом, а канонической частью платформы.
