AWatch-rus/docs/OPERATIONAL_PROOF_PROFILE_RU.md

Эксплуатационный профиль DetMir

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

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

Снимок 2026-06-03

Источник: агрегированные запросы ClickHouse analytics_1c, системный query_log, runbook DetMir/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

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

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

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

Из runbook DetMir/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.