--- title: 'Modelul domeniului operațional' description: 'Entitățile, relațiile, responsabilitatea și regulile ciclului de viață din modelul domeniului operațional, pe care se bazează fiecare problemă, sarcină și scor de stare.' section: 'Operations Center' weight: 3 related: - operational-issues - detectors-and-canons --- ## 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. ```mermaid 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ță. | Entitate | Responsabilul ciclului de viață | | ----------------- | ------------------------------- | | Asset | Registrul activelor | | Detector | Analiza datelor | | Evidence | Achiziția datelor | | Operational Issue | Exploatare | | Task | Exploatare | | Health | Analiza datelor | | Knowledge Article | Excelență operațională | | Massive Incident | Exploatare | ### 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.