# Эксплуатационный профиль AWatch-rus

Документ фиксирует не функциональные обещания, а проверяемые эксплуатационные
показатели. Это материал для коммерческих презентаций, пилотов и экспертных
обсуждений: сколько данных система уже обрабатывает, как быстро отвечает
аналитический слой, какие классы инцидентов/сигналов фиксируются и где лежат
проверочные артефакты.

Снимок ниже обезличен: не раскрываются имена пользователей, компаний, хостов,
пути, домены, токены, evidence-файлы и содержимое инцидентов.

## Снимок 2026-06-03

Источник: агрегированные запросы ClickHouse `analytics_1c`, системный
`query_log`, runbook AWatch-rus.

### Масштаб данных

| Метрика | Значение |
|---|---:|
| ClickHouse objects в `analytics_1c` | 46 |
| MergeTree tables | 24 |
| Всего строк в MergeTree tables | 764 098 |
| Compressed size | 12.04 MiB |
| Uncompressed size | 252.31 MiB |
| ClickHouse uptime на момент снимка | 782 640 секунд |

### Нагрузка ClickHouse за 7 дней

| Метрика | Значение |
|---|---:|
| Завершенных query в `analytics_1c` | 60 588 |
| P50 query duration | 12 ms |
| P95 query duration | 208.45 ms |
| Max query duration | 2 039 ms |
| Окно query log | 2026-05-27 07:12:59 -> 2026-06-03 07:12:42 |

Практический вывод: аналитический слой уже выдерживает десятки тысяч запросов
за неделю с медианной задержкой около десятков миллисекунд.

### Объем бизнес/аудит-событий

| Поток | Строк | Диапазон данных |
|---|---:|---|
| `reglog_events` | 8 070 | 2026-05-04 -> 2026-06-03 |
| `business_events` | 4 265 | 2026-05-22 -> 2026-06-03 |
| `document_change_events` | 8 280 | 2026-05-22 -> 2026-06-03 |
| `company_health_signals` | 156 189 | 2026-05-22 -> 2026-06-03 |
| `company_forecasts` | 194 228 | 2026-05-22 -> 2026-06-03 |
| `detections` | 162 966 | 2026-05-15 -> 2026-06-03 |
| `cases` | 162 966 | 2026-05-15 -> 2026-06-03 |

Важно для продаж: `detections` и `cases` в этом срезе являются
автоматически сформированным detection/case-oriented потоком. Для внешней
демонстрации их нужно называть именно так: `derived detections/cases`, а не
ручные подтвержденные инциденты.

### Покрытие источников

| Метрика | Значение |
|---|---:|
| Учетных информационных баз в `reglog_events` | 43 |
| Уникальных пользователей в `reglog_events` | 7 |
| Уникальных hosts в `reglog_events` | 1 |
| Учетных информационных баз в `business_events` | 43 |
| Company/entity keys в `business_events` | 44 |
| Уникальных документов в `business_events` | 1 838 |
| Пользователей в `business_events` | 7 |
| Registry companies | 47 |
| Registry assignees | 7 |

### Severity distribution

`detections`:

| Severity | Status | Count |
|---|---|---:|
| critical | open | 107 359 |
| high | open | 45 784 |
| medium | open | 9 823 |

`cases`:

| Severity | Status | Count |
|---|---|---:|
| critical | open | 107 359 |
| high | open | 45 784 |
| medium | open | 9 823 |

Коммерчески корректная формулировка:

> AWatch-rus уже формирует case-oriented поток технических сигналов и
> расследовательских карточек по правилам, severity и статусам. Для пилота с
> заказчиком отдельно настраивается политика дедупликации, подтверждения и
> закрытия cases под регламент заказчика.

## ActivityWatch/AW-RUS эксплуатационные факты

Из runbook AWatch-rus:

- зафиксирован и устранен uncontrolled growth в `aw-session-events`;
- основной источник роста давал около `6.9M` process-level rows;
- controlled trim удалил `6 906 190` шумных `process_start/process_stop`
  событий;
- logon/session evidence сохранены: после trim осталось `174` logon-события;
- AW SQLite DB был уменьшен примерно с `6.8G` до `350M`;
- integrity check до и после maintenance: `ok`;
- DB health guard после стабилизации: DB около `352MiB`, WAL около `4MiB`,
  recent process events `0`, latest event type `logon`, health OK.

Коммерческий вывод:

> Система не только собирает телеметрию, но и уже прошла реальную эксплуатационную
> стабилизацию: обнаружен источник взрывного роста событий, введены безопасный
> trim, SQLite integrity gate, DB health guard и weekly maintenance.

## Что показывать заказчику

Лучше работают не абстрактные описания, а 5 чисел:

1. Объем обработанных строк в ClickHouse.
2. Число источников/пользователей/информационных баз.
3. P50/P95 задержки аналитических запросов.
4. Число сформированных detections/cases по severity.
5. Uptime и история устраненных эксплуатационных проблем.

## Что не говорить без уточнения

- Не называть auto-generated `cases` подтвержденными ИБ-инцидентами без ручной
  валидации.
- Не раскрывать реальные имена пользователей, компаний, hosts, paths, domains
  и evidence.
- Не обещать сертифицированную DLP/SIEM/EDR/СЗИ.
- Не использовать абсолютные цифры без даты снимка и источника.

## Как обновлять снимок

Использовать SQL pack:

- `clickhouse-1c/ops/operational_proof_snapshot.sql`

Порядок:

1. Выполнить SQL pack на актуальном ClickHouse.
2. Сохранить агрегированный вывод в приватный customer/proof report.
3. Для публичного repo переносить только обезличенные агрегаты.
4. Если цифры используются в коммерческой презентации, рядом указывать дату
   снимка и scope.