Detektori i kanonski problemi

Arhitektura detektora

Detektor (Detector)

Detector je algoritam koji analizira zadati skup podataka i daje formalizovan nalaz.

Detektor ne upravlja izvršenjem i ne generiše proizvoljan tekst. Izlaz detektora ima strukturisan format.

detector_id: archive.tail_gap.v3
detector_version: '3.2.1'
run_id: 'run-20260723-0400'
asset_id: 'station-5690'
observed_at: '2026-07-23T04:00:00Z'

finding:
  canon: no_hourly_archive
  detected: true
  severity: critical
  confidence: 0.98
  value: 73
  unit: 'hours'
  threshold: 24
  baseline: 0

evidence:
  last_valid_hour: '2026-07-20T03:00:00Z'
  expected_end: '2026-07-23T04:00:00Z'
  missing_hours: 73

Lanac Detector → Canon → Issue

flowchart TD
  D["Detector"] -->|"klasifikacija"| C["Canon"]
  C -->|"upravljanje"| I["Operational Issue"]

• Detector – konkretan algoritam;
• Canon – stabilan tip operativnog problema;
• Operational Issue – pojava problema u konkretnom kontekstu.

Isti kanonski problem može da potvrdi nekoliko različitih detektora.

Primer:

flowchart TD
  D1["archive.tail_gap.v3"] --> CANON["no_hourly_archive"]
  D2["archive.coverage.v2"] --> CANON
  D3["archive.delivery_queue.v1"] --> CANON
  D4["session.freshness.v4"] --> CANON
  CANON --> ISSUE["OHM-2026-001842"]

Klase detektora

Zahtevi za svaki detektor

Svaki detektor u produkcionom okruženju ima:

• jedinstven identifikator detector_id;
• semantičku verziju;
• definisanu namenu;
• vlasnika;
• opis ulaznih podataka;
• kontrolisane pragove;
• pravila izuzimanja;
• zahteve za minimalnu veličinu uzorka;
• kontrolne tačke kvaliteta podataka (DQ gates);
• formulu za izračunavanje ozbiljnosti;
• formulu za izračunavanje nivoa pouzdanosti;
• odgovarajući kanonski problem;
• skup dokaza (Evidence);
• testove;
• kontrolni uzorak;
• procenu lažno pozitivnih rezultata;
• datum puštanja u rad;
• dnevnik izmena;
• režim isključivanja i vraćanje na prethodnu verziju.

Kontrolne tačke kvaliteta podataka

Detektor ne sme da daje visok nivo pouzdanosti ako su izvorni podaci nepotpuni ili protivrečni.

Primeri kontrolnih tačaka:

Stanje detektora

OHM prati kvalitet samih detektora.

Ključni pokazatelji:

• broj aktiviranja;
• udeo potvrđenih aktiviranja;
• stopa lažno pozitivnih rezultata;
• udeo ručnih otkazivanja;
• udeo ponovnih otvaranja;
• raspodela nivoa pouzdanosti;
• drift ulaznih podataka;
• promena strukture uzorka;
• prosečno vreme do potvrde;
• verzija algoritma;
• broj aktivnih problema po verziji.

Kanonski problemi (Canon)

Canon je stabilna poslovna klasifikacija problema koja ne zavisi od konkretne implementacije detektora.

Zašto su potrebni kanonski problemi

Bez kanonskih problema analitički sistem se brzo izrodi u skup neusaglašenih poruka:

• archive_missing
• no_archive
• archive_gap
• hourly_data_absent
• delivery_error

Kanonski problem objedinjuje sve ove ekvivalentne signale pod jednim identifikatorom: canon: no_hourly_archive.

To obezbeđuje:

• jedinstven tok rada;
• jedinstven sporazum o nivou usluge (SLA);
• preglednu analitiku;
• stabilne ključne pokazatelje učinka (KPI);
• zajedničku bazu znanja;
• uporedivost između verzija;
• prevod interfejsa bez izmena u logici;
• integraciju sa spoljnim sistemima.

Struktura kanonskog problema

canon_id: no_hourly_archive
name: 'Hourly archive is missing'
domain: archive
default_owner_zone: backend_integration
default_priority: P1
actionable: true
verification_mode: data
sla_policy: archive_p1
suppression_group: communication_archive
knowledge_tags:
  - archive
  - delivery
  - communication

Osnovni skup kanonskih problema

Verzionisanje kanonskih problema

Izmena teksta ili prevoda ne zahteva promenu identifikatora.

Nova verzija kanonskog problema potrebna je kada se promeni bilo šta od sledećeg:

• poslovno značenje;
• pravilo dodele;
• kriterijum potrebe za postupanjem;
• način verifikacije;
• SLA princip;
• logika spajanja sa drugim problemima.

Analitika kvaliteta detektora

Operational Health Matrix ne ocenjuje samo opremu, već i kvalitet sopstvenih analitičkih algoritama.

Za svaki detektor sistem izračunava:

• tačnost;
• preciznost;
• odziv;
• stopu lažno pozitivnih rezultata;
• stopu lažno negativnih rezultata;
• prosečan nivo pouzdanosti;
• drift;
• stabilnost;
• prosečno vreme verifikacije;
• stopu prihvatanja.

Ovakav pristup omogućava stalno unapređivanje analitičkog modela podsistema Data Platform bez narušavanja ponovljivosti rezultata.

Sam portfolio detektora razvija se prema planu po fazama: novi detektori se uvode u talasima, a svaki talas je uslovljen spremnošću interfejsa API platforme na koje se oslanja.