Модель Evidence і кореляція

Модель Evidence

Що таке Evidence

Evidence — структурований доказ, на підставі якого система створює, оновлює або верифікує Issue.

Evidence може бути:

• автоматично розрахованим;
• отриманим від пристрою;
• імпортованим із зовнішньої системи;
• доданим користувачем;
• сформованим профільним звітом;
• долученим у вигляді документа, фото або коментаря.

Структура Evidence

evidence_id: EVD-830129
issue_id: OHM-2026-001842
type: detector_finding
source:
  provider: analyze_station
  detector_id: archive.tail_gap.v3
  detector_version: '3.2.1'
observed_at: '2026-07-23T04:00:00Z'
created_at: '2026-07-23T04:03:12Z'

payload:
  missing_hours: 73
  coverage_valid: 0.91
  last_valid_hour: '2026-07-20T03:00:00Z'

quality:
  completeness: 1.0
  freshness: 0.98
  consistency: 0.96
  confidence: 0.98

links:
  report: '/reports/analyze-station/5690'

Типи Evidence

Якість Evidence

Для кожного Evidence розраховується якість:

де:

• $C$ — повнота;
• $F$ — актуальність;
• $S$ — узгодженість;
• $T$ — довіра до джерела;
• $w_c + w_f + w_s + w_t = 1$.

Рекомендовані базові ваги:

Результат нормується в діапазон від 0 до 1.

Незмінність Evidence

Первинне Evidence ніколи не редагується заднім числом. Виправлення створює нову версію або окреме коригувальне Evidence.

Це забезпечує:

• можливість аудиту;
• відтворюваність;
• захист історії;
• коректний розгляд спірних випадків;
• можливість повторного розрахунку.

Кореляція подій і Root Cause

Завдання кореляції

Кореляція запобігає створенню безлічі незалежних Issues на одну й ту саму технічну причину.

Система аналізує:

• збіг активу;
• часову близькість;
• топологічну залежність;
• спільну прошивку;
• спільний шлюз;
• спільного оператора зв’язку;
• спільний регіон;
• спільну серверну чергу;
• послідовність симптомів;
• історичні зв’язки;
• підтверджені root causes минулих випадків.

Рівні кореляції

У межах одного активу

Кілька симптомів об’єднуються навколо основного Canon.

flowchart TD
  A["stale_communication"] --> C{"Кореляція в межах активу"}
  B["no_hourly_archive"] --> C
  D["battery_unknown"] --> C
  C --> R["Головний Issue stale_communication"]
  C --> S1["Вторинний сигнал no_hourly_archive"]
  C --> S2["Вторинний сигнал battery_unknown"]

Між активами

Подібні проблеми групуються в масовий інцидент.

flowchart TD
  A["38 пристроїв"] --> G{"Групування"}
  B["Одна версія прошивки"] --> G
  C["Одне часове вікно"] --> G
  D["Один тип збою"] --> G
  G --> M["Massive Incident firmware_regression"]

За залежністю

Проблеми дочірніх пристроїв пов’язуються з відмовою спільного компонента.

flowchart TD
  A["Gateway-17 недоступний"] --> B["12 коректорів без зв’язку"]
  B --> C["12 архівів не доставлено"]
  C --> D["Один інцидент залежності"]

Оцінка зв’язку (Correlation Score)

Для оцінювання сили зв’язку використовується пояснювана модель:

де:

• $A$ — збіг активу або залежності;
• $T$ — часова близькість;
• $P$ — збіг патерну;
• $C$ — спільний контекст;
• $H$ — історична підтвердженість зв’язку.

Приклад ваг:

Поріг об’єднання задається окремо для кожного класу проблем. Для критичних security-сигналів допускається консервативніший поріг.

Класи Root Cause

OHM використовує керований довідник першопричин:

Статуси Root Cause

Упевненість у Root Cause

Упевненість у гіпотезі розраховується за сукупністю доказів:

де:

• $r_i$ — надійність детектора або джерела;
• $q_i$ — якість Evidence;
• $a_i$ — узгодженість Evidence з гіпотезою;
• $K_{independence}$ — коефіцієнт незалежності джерел.

Якщо кілька Evidence походять з одного й того самого вихідного набору даних, вони не вважаються повністю незалежними.

Операційна впевненість (Operational Confidence)

Operational Confidence показує, наскільки система впевнена, що Issue є реальною та правильно класифікованою проблемою.

де:

• $D$ — надійність детекторів;
• $E$ — якість Evidence;
• $R$ — узгодженість кореляції;
• $H$ — історична підтверджуваність;
• $X$ — штраф за суперечності та брак даних.

Інтерпретація: