---
doc_id: REF-CK8S-0016
type: governance
title: "kodex — безопасность релиза, наблюдаемость и уведомления в четвёртой волне"
status: active
owner_role: SRE
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
- Успешный deploy `job` ещё не означает, что релиз завершён безопасно.
- Канонический цикл релиза: `release -> deploy -> postdeploy -> ops -> stable or rollback`.
- Build/deploy `job`, housekeeping `job` и сигналы среды должны быть наблюдаемы в одном governance-контуре.
- В PostgreSQL храним только статус, метаданные, ссылки и короткий хвост лога; полные логи остаются в Kubernetes-контуре или внешней системе логирования.
- Платформа обязана иметь настраиваемый контур уведомлений о блокирующих событиях, завершении этапов и необходимости человеческого действия.
- Автоматизация по триггерам и релизные линии должны быть наблюдаемы тем же контуром, а не скрываться в отдельном scheduler-слое.

## 1. Что такое контур безопасного релиза
Release safety-loop — это обязательный связанный контур:
1. подготовка release-кандидата;
2. запуск deploy `job`;
3. пострелизное наблюдение;
4. оценка блокирующих сигналов;
5. решение `continue / hold / rollback / follow-up`;
6. перевод релиза в стабильное состояние или в recovery-процесс.

Это значит:
- релиз не закрывается сразу после зелёной deploy `job`;
- состояние среды после выкладки является частью канонического результата;
- follow-up после релиза — нормальная часть процесса, а не признак что-то пошло не так.

## 2. Канонические состояния release safety-loop

| Состояние | Смысл |
|---|---|
| `release_candidate` | артефакты и evidence готовы к release gate |
| `awaiting_release_gate` | платформа ждёт человеческое решение перед deploy |
| `deploying` | выполняются release `job` и связанные технические шаги |
| `postdeploy_observation` | релиз выложен, но среда ещё наблюдается |
| `stable` | блокирующих сигналов нет, релиз признан состоявшимся |
| `hold` | переход остановлен до разбирательства или внешнего решения |
| `rollback` | запущен или требуется откат |
| `follow_up_required` | релиз состоялся, но нужны дополнительные действия |

Если проект использует release line или release branch, этот же safety-loop применяется ко всему координационному контуру:
- release candidate;
- release branch или release line state;
- rollout stage;
- postdeploy signals;
- решение `continue / hold / rollback / follow-up`.

## 3. Источники блокирующих сигналов
Блокирующий сигнал может прийти из разных контуров. Платформа обязана сводить их в единый governance-слой.

Основные источники:
- acceptance machine;
- reviewer, `qa`, мониторинговые и postdeploy-роли;
- `runtime-manager` и platform `job`;
- `provider-hub`, если внешний провайдер не даёт безопасно продолжить действие;
- `interaction-hub`, если человек сообщил о проблеме или не дал обязательное решение;
- housekeeping и retention `job`, если сбой влияет на жизнеспособность среды.

Примеры блокирующих сигналов:
- failed deploy `job`;
- failed smoke или postdeploy-check;
- истощение диска, квоты или критического ресурса;
- застрявшая cleanup `job`, из-за которой среда теряет управляемость;
- расхождение между ожидаемым и фактическим состоянием в production;
- high-risk предупреждение от человека или контрольной роли.

## 4. Platform jobs как часть safety-контура

### 4.1. Что входит в наблюдаемые `job`
К safety-контурy относятся не только build/deploy операции, но и:
- подготовка slot;
- зеркалирование зависимостей;
- публикация образов;
- deploy в slot или production;
- cleanup старых slot и временных данных;
- retention и housekeeping `job`;
- периодические health-check `job`.

### 4.2. Почему housekeeping обязана быть видимой
Если cleanup `job` или retention `job` перестала работать:
- у платформы может закончиться диск;
- среда перестанет быть предсказуемой;
- следующий релиз упрётся в накопленный мусор;
- оператор узнает о проблеме слишком поздно, если это останется только в логах Kubernetes.

Поэтому failure таких `job` должен:
- попадать в `runtime-manager`;
- становиться видимым в `operations-hub`;
- поднимать уведомление через `interaction-hub`, если policy считает событие значимым.

## 5. Наблюдаемость без мусора в БД

### 5.1. Что платформа хранит по `job` и `run`
Минимально должны быть доступны:
- тип операции;
- связанный проект, репозиторий, slot, release или production-контекст;
- текущий статус;
- timeline;
- причина ошибки;
- короткий хвост лога;
- ссылка на полный источник логов;
- следующий ожидаемый action.

### 5.2. Что платформа не хранит как канонику
Не нужно тащить в PostgreSQL:
- полный stdout/stderr build и deploy;
- полные логи контейнеров;
- повторную копию реестра образов;
- дубликаты метрик и событий, которыми уже владеет Kubernetes или внешний observability-стек.

### 5.3. Что должно быть видно оператору
Оператору достаточно видеть:
- какой `run` или `job` упал;
- почему он упал;
- насколько это блокирует процесс;
- что можно сделать дальше;
- где открыть полный лог или первоисточник.

## 6. Production-контур только для чтения
Wave 4 закрепляет обязательное ограничение:
- роли `qa`, мониторинга, release-check и postdeploy-наблюдения могут работать в production-контуре только для чтения, если policy не говорит иначе;
- результат их работы оформляется через комментарии, follow-up `Issue`, отчётные `PR/MR` и decision records;
- прямое изменение production-состояния из такой роли запрещено.

Это позволяет:
- иметь реальный postdeploy-контур;
- не превращать наблюдение в скрытую ручную админку;
- сохранять трассируемость решений через provider-native артефакты.

## 7. Контур уведомлений

### 7.1. Базовые требования
Платформа обязана поддерживать настраиваемые уведомления по минимуму для:
- ошибки agent `run`;
- ошибки platform `job`;
- блокирующего сигнала;
- завершения важного этапа;
- запроса human gate;
- исчерпания лимита или отказа внешнего провайдера;
- проблем housekeeping и retention.

### 7.2. Каналы на текущем уровне не фиксируются жёстко
Wave 4 не закрепляет один конкретный механизм расширения.

На этом уровне фиксируется только задел:
- фронтенд-уведомления обязательны;
- внешний канал должен подключаться через расширяемый контракт;
- конкретный механизм может быть реализован как адаптеры, плагины, OpenAPI-контракт или гибрид.

Для wave 5.1 это означает:
- уведомления и approval-каналы для `Telegram` и других систем должны проектироваться как плагины или пакеты поверх общего платформенного контракта;
- scheduler, alert receiver и другие точки входа автоматизации не должны теряться вне операторской видимости.

### 7.3. Что должно настраиваться
Минимально должны настраиваться:
- тип события;
- серьёзность;
- канал доставки;
- адресат или группа адресатов;
- повторная отправка и эскалация;
- требование подтверждения.

## 8. Решения после блокирующего сигнала
Если обнаружен блокирующий сигнал, платформа не должна просто зафиксировать ошибку в журнале.

Канонические дальнейшие варианты:
- `continue`, если сигнал снят и policy это допускает;
- `hold`, если нужен человек, окно или дополнительная проверка;
- `rollback`, если продолжение опасно;
- `follow_up_required`, если релиз остаётся в силе, но нужно последующее действие;
- `incident_flow`, если проблема выходит за рамки обычного postdeploy-контурa.

## 9. Что intentionally не фиксируется в этой волне
В этой волне не фиксируются:
- конкретный стек метрик, логов и трейсинга;
- конкретные Kubernetes CronJob-манифесты;
- точная схема UI-центра уведомлений;
- окончательная маршрутизация по внешним каналам.

Но любая последующая реализация обязана считать housekeeping, blocking signals, уведомления и postdeploy-наблюдение частью канонического release-контура, а не опциональным когда-нибудь потом.
