docs(proof): add operational evidence profile
This commit is contained in:
igor04091968
@@ -53,6 +53,7 @@ runtime, OCR/content-analysis, 1C/AI/ETL integration и MCP/dev helpers. Эти
|
|||||||
- [Установка для эксперта](INSTALL_FOR_EXPERT_RU.md)
|
- [Установка для эксперта](INSTALL_FOR_EXPERT_RU.md)
|
||||||
- [Сценарий экспертной проверки](docs/EXPERT_TEST_SCENARIO_RU.md)
|
- [Сценарий экспертной проверки](docs/EXPERT_TEST_SCENARIO_RU.md)
|
||||||
- [Release manifest 2026-06](docs/RELEASE_MANIFEST_2026-06.md)
|
- [Release manifest 2026-06](docs/RELEASE_MANIFEST_2026-06.md)
|
||||||
|
- [Эксплуатационный профиль](docs/OPERATIONAL_PROOF_PROFILE_RU.md)
|
||||||
- [Сторонние компоненты](THIRD_PARTY_COMPONENTS.md)
|
- [Сторонние компоненты](THIRD_PARTY_COMPONENTS.md)
|
||||||
- [Сторонние лицензии](THIRD_PARTY_LICENSES_RU.md)
|
- [Сторонние лицензии](THIRD_PARTY_LICENSES_RU.md)
|
||||||
- [Архитектура](docs/ARCHITECTURE_RU.md)
|
- [Архитектура](docs/ARCHITECTURE_RU.md)
|
||||||
|
|||||||
@@ -0,0 +1,98 @@
|
|||||||
|
-- Operational proof snapshot for DetMir/AWatch-rus.
|
||||||
|
-- Output is aggregate-only: no users, company names, hosts, domains, paths,
|
||||||
|
-- evidence content, tokens, passwords or raw incident payloads.
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
database,
|
||||||
|
count() AS tables_total,
|
||||||
|
sum(total_rows) AS rows_total,
|
||||||
|
formatReadableSize(sum(total_bytes)) AS compressed_size,
|
||||||
|
formatReadableSize(sum(total_bytes_uncompressed)) AS uncompressed_size
|
||||||
|
FROM system.tables
|
||||||
|
WHERE database = 'analytics_1c'
|
||||||
|
AND engine NOT IN ('View')
|
||||||
|
GROUP BY database;
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
version() AS clickhouse_version,
|
||||||
|
uptime() AS uptime_seconds,
|
||||||
|
(SELECT count() FROM system.tables WHERE database = 'analytics_1c') AS analytics_objects,
|
||||||
|
formatReadableSize((
|
||||||
|
SELECT sum(total_bytes)
|
||||||
|
FROM system.tables
|
||||||
|
WHERE database = 'analytics_1c'
|
||||||
|
AND engine NOT IN ('View')
|
||||||
|
)) AS analytics_compressed_size;
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
count() AS queries_logged,
|
||||||
|
min(event_time) AS first_query,
|
||||||
|
max(event_time) AS last_query,
|
||||||
|
quantile(0.5)(query_duration_ms) AS p50_ms,
|
||||||
|
quantile(0.95)(query_duration_ms) AS p95_ms,
|
||||||
|
max(query_duration_ms) AS max_ms
|
||||||
|
FROM system.query_log
|
||||||
|
WHERE event_time >= now() - INTERVAL 7 DAY
|
||||||
|
AND type = 'QueryFinish'
|
||||||
|
AND current_database = 'analytics_1c';
|
||||||
|
|
||||||
|
SELECT 'business_events' AS table_name, count() AS rows, min(ts) AS min_ts, max(ts) AS max_ts
|
||||||
|
FROM analytics_1c.business_events
|
||||||
|
UNION ALL
|
||||||
|
SELECT 'document_change_events', count(), min(ts), max(ts)
|
||||||
|
FROM analytics_1c.document_change_events
|
||||||
|
UNION ALL
|
||||||
|
SELECT 'detections', count(), min(ts), max(ts)
|
||||||
|
FROM analytics_1c.detections
|
||||||
|
UNION ALL
|
||||||
|
SELECT 'cases', count(), min(opened_at), max(opened_at)
|
||||||
|
FROM analytics_1c.cases
|
||||||
|
UNION ALL
|
||||||
|
SELECT 'company_health_signals', count(), min(generated_at), max(generated_at)
|
||||||
|
FROM analytics_1c.company_health_signals
|
||||||
|
UNION ALL
|
||||||
|
SELECT 'company_forecasts', count(), min(generated_at), max(generated_at)
|
||||||
|
FROM analytics_1c.company_forecasts
|
||||||
|
ORDER BY table_name;
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
countDistinct(infobase) AS infobases,
|
||||||
|
countDistinct(user) AS users_in_reglog,
|
||||||
|
countDistinct(host) AS hosts_in_reglog,
|
||||||
|
count() AS reglog_events,
|
||||||
|
min(ts) AS min_ts,
|
||||||
|
max(ts) AS max_ts
|
||||||
|
FROM analytics_1c.reglog_events;
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
countDistinct(infobase) AS infobases,
|
||||||
|
countDistinct(company_entity_key) AS company_entities,
|
||||||
|
countDistinct(document_id) AS documents,
|
||||||
|
countDistinct(user) AS users,
|
||||||
|
count() AS business_events,
|
||||||
|
min(ts) AS min_ts,
|
||||||
|
max(ts) AS max_ts
|
||||||
|
FROM analytics_1c.business_events;
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
severity,
|
||||||
|
status,
|
||||||
|
count() AS detections
|
||||||
|
FROM analytics_1c.detections
|
||||||
|
GROUP BY severity, status
|
||||||
|
ORDER BY detections DESC;
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
severity,
|
||||||
|
status,
|
||||||
|
count() AS cases
|
||||||
|
FROM analytics_1c.cases
|
||||||
|
GROUP BY severity, status
|
||||||
|
ORDER BY cases DESC;
|
||||||
|
|
||||||
|
SELECT
|
||||||
|
countDistinct(company_key) AS registry_companies,
|
||||||
|
countIf(key_contour = 1) AS key_contour_rows,
|
||||||
|
countDistinct(assignee_name) AS assignees,
|
||||||
|
max(ts) AS last_snapshot
|
||||||
|
FROM analytics_1c.company_registry;
|
||||||
@@ -0,0 +1,148 @@
|
|||||||
|
# Эксплуатационный профиль 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.
|
||||||
Reference in New Issue
Block a user