Modelul domeniului operațional

Modelul domeniului operațional

Operational Health Matrix se bazează pe un model unificat al domeniului operațional, care definește entitățile de bază, relațiile dintre ele și responsabilitățile în întregul subsistem Data Platform.

Fiecare proces, detector, endpoint API și componentă analitică lucrează cu același model al domeniului, ceea ce asigură coerența în tot sistemul.

Modelul domeniului elimină ambiguitățile, reduce la minimum duplicarea datelor și oferă un limbaj operațional comun tuturor componentelor platformei.

Entități de bază

Domeniul subsistemului Operational Health Matrix cuprinde următoarele entități principale:

• Asset
• Detector
• Evidence
• Operational Issue
• Task
• Root Cause
• Health
• Knowledge Article
• Massive Incident
• SLA Policy
• Team
• User
• Notification
• Attachment
• Comment
• Audit Record

Fiecare entitate are propriul ciclu de viață și participă la unul sau mai multe fluxuri de lucru operaționale.

Activ (Asset)

Activul este entitatea centrală a platformei.

Orice element fizic sau logic monitorizat este reprezentat ca activ.

Exemple tipice:

• Gas Meter
• Pressure Sensor
• Corrector
• RTU
• Gateway
• Valve Controller
• Telemetry Unit
• Communication Device
• Software Component

Fiecare activ conține:

• identificatorul unic;
• tipul;
• modelul;
• producătorul;
• numărul de serie;
• proprietarul;
• regiunea operațională;
• configurația;
• versiunea de firmware;
• profilul de comunicație;
• starea în ciclul de viață.

Detector

Detectorul este o componentă analitică al cărei rol este să transforme telemetria în observații operaționale.

Detectorul nu creează logică de afaceri.

Rolul său se limitează la identificarea tiparelor observabile și la generarea dovezilor.

Atributele detectorului includ:

• Identificator
• Versiune
• Problemă canonică (Canon)
• Nivel de încredere
• Status
• Indicatori de exactitate
• Stare

Dovadă (Evidence)

Dovada reprezintă o confirmare imuabilă care susține o concluzie operațională.

Dovezile pot proveni din:

• telemetrie;
• jurnalele de comunicație;
• înregistrările de audit;
• confirmarea utilizatorului;
• fotografiile încărcate;
• diagnosticarea sistemului;
• sistemele externe.

Dovezile nu pot fi modificate după creare.

Dacă este necesară o corecție, se creează o nouă dovadă, iar versiunea anterioară se păstrează.

Problemă operațională (Operational Issue)

Problema operațională reprezintă o problemă de exploatare confirmată, care necesită investigare sau rezolvare.

Fiecare problemă operațională conține:

• problema canonică;
• gravitatea;
• prioritatea;
• statusul;
• responsabilul;
• cauza fundamentală;
• politica SLA;
• statusul verificării;
• istoricul operațional.

Problema operațională este entitatea operațională principală a platformei.

Sarcină (Task)

Sarcina reprezintă o acțiune executabilă, necesară pentru rezolvarea unei probleme operaționale.

Sarcinile nu pot exista independent.

Fiecare sarcină aparține unei singure probleme operaționale.

O problemă operațională poate conține mai multe sarcini.

Cauză fundamentală (Root Cause)

Cauza fundamentală reprezintă motivul de fond confirmat al uneia sau al mai multor probleme operaționale.

Mai multe probleme operaționale pot face trimitere la aceeași cauză fundamentală.

Această relație permite analiza operațională în întreaga organizație și identificarea problemelor recurente.

Stare (Health)

Starea este un indicator operațional calculat.

Starea se definește pentru:

• activ;
• amplasament;
• regiune;
• organizație;
• întregul ecosistem.

Valorile stării se calculează întotdeauna automat.

Articol din baza de cunoștințe (Knowledge Article)

Articolul din baza de cunoștințe păstrează experiența operațională validată.

Fiecare articol poate face trimitere la:

• probleme canonice;
• cauze fundamentale;
• tipuri de active;
• versiuni de firmware;
• proceduri operaționale;
• documentația producătorului.

Incident masiv (Massive Incident)

Incidentul masiv grupează mai multe probleme operaționale care provin dintr-un eveniment operațional comun.

Oferă o singură entitate prin care se gestionează incidentele de infrastructură de mare amploare.

Principii operaționale

Operational Health Matrix respectă mai multe principii arhitecturale, care definesc comportamentul fiecărei componente.

Mai întâi activul (Asset First)

Fiecare eveniment operațional este asociat unui activ.

Activele rămân entitățile principale pe tot parcursul ciclului de viață.

Exploatare centrată pe probleme

Exploatarea se gestionează prin probleme operaționale, nu prin alarme individuale sau evenimente de telemetrie.

Decizii bazate pe dovezi

Fiecare concluzie operațională trebuie să se sprijine pe una sau mai multe dovezi.

Presupunerile nesusținute nu sunt tratate niciodată drept fapte confirmate.

Cauza fundamentală înaintea rezolvării

Ori de câte ori este posibil, acțiunile corective vizează cauzele confirmate, nu simptomele observabile.

Omul în procesul decizional (Human-in-the-Loop)

Platforma sprijină luarea deciziilor operaționale, dar nu înlocuiește niciodată responsabilitatea inginerească.

Acțiunile critice necesită confirmarea explicită a unei persoane.

Analiză explicabilă

Concluziile analitice rămân transparente.

Fiecare recomandare include dovezile care o susțin și informații despre nivelul de încredere.

Pistă de audit imuabilă

Istoricul operațional nu poate fi rescris.

Fiecare modificare generează o nouă înregistrare de audit.

Mai întâi interfața API (API First)

Fiecare funcție a platformei este accesibilă prin interfețe API documentate.

Interfețele de utilizator și integrările externe se bazează pe aceleași servicii operaționale.

Arhitectură bazată pe evenimente

Modificările operaționale se propagă sub formă de evenimente.

Astfel sunt posibile integrările asincrone și fluxurile de prelucrare scalabile.

Modelul de date operațional

Platforma respectă un model de date operațional unificat.

flowchart TD
    A["Asset"] --> DET["Detector"]
    A --> EV["Evidence"]
    A --> ISSUE["Operational Issue"]
    ISSUE --> TASK["Task"]
    ISSUE --> RC["Root Cause"]
    ISSUE --> SLA["SLA Policy"]
    ISSUE --> CMT["Comment"]
    ISSUE --> ATT["Attachment"]
    A --> HLT["Health"]
    A --> KB["Knowledge Articles"]

Responsabilitate

Fiecare entitate are un singur responsabil al ciclului de viață.

Regulile ciclului de viață

Modelul domeniului respectă mai mulți invarianți:

• Activele nu se șterg niciodată cât timp există probleme operaționale în istoricul lor.
• Dovezile sunt imuabile.
• Sarcinile nu pot exista fără o problemă operațională.
• Cauzele fundamentale pot fi comune mai multor probleme.
• Valorile stării se calculează și nu pot fi editate manual.
• Înregistrările de audit pot fi doar adăugate (append-only).
• Articolele din baza de cunoștințe sunt versionate pe tot parcursul ciclului lor de viață.

Aceste constrângeri asigură coerența, trasabilitatea și reproductibilitatea în întregul subsistem Operational Health Matrix.