release: v1.9.0 — IRM-алерты отдельно от инцидентов

- Alembic 005: таблицы irm_alerts и incident_alert_links
- Модуль alerts: API/UI, Ack/Resolve, привязка к инциденту через alert_ids
- Вебхук Grafana: одна транзакция ingress + irm_alerts; разбор payload в grafana_payload
- По умолчанию инцидент из вебхука не создаётся (AUTO_INCIDENT_FROM_ALERT)
- Документация IRM_GRAFANA_PARITY.md, обновления IRM.md и CHANGELOG

Made-with: Cursor

docs/IRM.md

@@ -6,7 +6,8 @@
 
 | Область | Назначение | onGuard24 | Grafana / внешнее |
 |---------|------------|-----------|-------------------|
-| **Инциденты** | Учёт сбоев, статусы (open → resolved), связь с алертом | Модуль `incidents`: таблица `incidents`, API, UI, авто-создание из `alert.received` | Contact point **Webhook** → `POST /api/v1/ingress/grafana`; правила алертинга в Grafana |
+| **Инциденты** | Учёт сбоев, статусы (open → resolved), связь с алертами | Модуль `incidents`: `incidents`, `incident_alert_links`, API, UI; создание вручную или с `alert_ids` | См. **Алерты**; [IRM_GRAFANA_PARITY.md](IRM_GRAFANA_PARITY.md) |
+| **Алерты (IRM)** | Приём, Ack/Resolve, не смешивать с инцидентом | Модуль `alerts`: `irm_alerts`, UI/API, вебхук пишет в одной транзакции с `ingress_events` | Grafana IRM Alert Groups; у нас без группировки/эскалации на уровне алерта |
 | **Задачи** | Подзадачи по инциденту (разбор, фикс) | Модуль `tasks`: таблица `tasks`, привязка к `incident_id` | Опционально: ссылки из алерта; основная работа в onGuard24 |
 | **Цепочки эскалаций** | Кого звать и в каком порядке при таймаутах | Модуль `escalations`: таблица `escalation_policies` (JSON `steps`), API/UI заготовка | Маршрутизация уведомлений может дублироваться в Grafana contact points; целевая логика — в onGuard24 |
 | **Календарь дежурств** | Кто в смене, расписание | Модуль `schedules` (развитие) | Календари/команды — данные в onGuard24; уведомления — через интеграции |
@@ -17,11 +18,12 @@
 | **Пользователи / права** | RBAC | *Пока нет* | SSO Grafana, сеть за reverse proxy |
 | **SLO** | Цели по доступности | *Вне скоупа v1* | Grafana SLO / Mimir |
 
-## Поток данных (алерт → инцидент)
+## Поток данных (как в Grafana IRM)
 
-1. Grafana срабатывает правило → шлёт JSON на **webhook** onGuard24.
-2. Сервис пишет строку в `ingress_events`, публикует **`alert.received`**.
-3. Модуль **incidents** подписан на событие и создаёт запись в **`incidents`** с ссылкой на `ingress_event_id`.
+1. Grafana срабатывает правило → JSON на **webhook** onGuard24.
+2. В одной транзакции: **`ingress_events`** + **`irm_alerts`** (статус `firing`), публикуется **`alert.received`**.
+3. Дежурный в модуле **Алерты** читает заголовок, лейблы, **Acknowledge** / **Resolve** — это не создание инцидента.
+4. **Инцидент** создаётся отдельно (вручную или из карточки алерта), опционально с привязкой **`alert_ids`**. Авто-инцидент из вебхука только при **`AUTO_INCIDENT_FROM_ALERT=1`** (legacy).
 
 ## Что настроить в Grafana (обязательно для приёма алертов)
 

docs/IRM_GRAFANA_PARITY.md

@@ -0,0 +1,39 @@
+# Сравнение onGuard24 с Grafana IRM (Alerting / Incident)
+
+Grafana Cloud / IRM даёт **группы алертов**, **Acknowledge / Resolve**, **инциденты**, **команды (teams)**, **эскалационные цепочки**, **расписания дежурств**. Ниже — что уже есть в onGuard24 и что планировать отдельно.
+
+## Уже есть (после разделения алерт / инцидент)
+
+| Grafana IRM (идея) | onGuard24 |
+|--------------------|-----------|
+| Входящие уведомления от интеграции | Webhook `POST /api/v1/ingress/grafana` → `ingress_events` + **`irm_alerts`** |
+| Статусы firing / acknowledged / resolved | Поле **`irm_alerts.status`**, UI **Алерты**, API `PATCH …/acknowledge`, `…/resolve` |
+| Просмотр labels / сырого payload | Карточка алерта в UI, JSON вебхука |
+| Инцидент как отдельная сущность | **`incidents`**, создание вручную или кнопка «Создать инцидент» на алерте; связь **`incident_alert_links`** |
+| Эскалации (JSON-шаги) | Модуль **Эскалации** (`escalation_policies`) — без автодвижка по таймерам |
+| Контакты / каналы | Модуль **Контакты** |
+| Расписания (заглушка) | **Календарь дежурств** — UI-задел |
+
+## Пока нет (зрелые следующие этапы)
+
+| Функция Grafana IRM | Заметка |
+|---------------------|---------|
+| **Teams** с фильтрами и привязкой маршрутов | Нет сущности `team`; алерты не маршрутизируются по команде |
+| **Alert groups** (несколько алертов в одной группе с общим ID) | Сейчас **одна строка `irm_alerts` на один webhook**; группировка fingerprint / rule_uid — отдельная задача |
+| **Silence / Restart** из UI | Статус `silenced` в БД зарезервирован, логика не подключена |
+| **Эскалация по таймеру** (wait 15m → notify next) | Политики есть, **фонового исполнителя** нет |
+| **On-call из расписания** в цепочке | Нет связи schedules → escalation executor |
+| **Пользователи / «Mine» / назначение** | Нет учётных записей onGuard24 для дежурного; `acknowledged_by` — свободный текст (можно расширить) |
+| **Интеграция обратно в Grafana** (resolve в Grafana из IRM) | Не делалось |
+
+## Переменные окружения
+
+- **`AUTO_INCIDENT_FROM_ALERT`** — если `1` / `true`, сохраняется старое поведение: **каждый** вебхук ещё и создаёт строку в **`incidents`**. По умолчанию **выключено**: только **`irm_alerts`**.
+
+## Рекомендуемый поток
+
+1. Grafana → webhook → **алерт** (`firing`).
+2. Дежурный в **Алертах**: прочитал → **Ack** → разобрался → **Resolve** (или сразу Resolve).
+3. При необходимости **Создать инцидент** (документирование, задачи, эскалация вручную).
+
+Так модель ближе к IRM, где **алерт** и **инцидент** разведены.