Problemi operativi e ciclo di vita

L'Operational Issue come unità di lavoro — modello di base, differenza tra Issue e Task, tipi singolo e massivo, workflow degli stati con la matrice delle transizioni e il registro di audit immutabile.

Operational Issue

Operational Issue è l’entità centrale di OHM.

È un oggetto stateful che rappresenta un problema di esercizio lungo tutto il suo ciclo di vita.

Modello di base

yaml

id: OHM-2026-001842
kind: single
canon: no_hourly_archive
title: 'Hourly archive is missing'
priority: P1
severity: critical
confidence: 0.94

scope:
  organization: 'Demo Gas Utility'
  region: 'North'
  asset_id: 'station-5690'

ownership:
  zone: backend_integration
  assignee: 'Integration-2'

timestamps:
  first_detected_at: '2026-07-21T04:00:00Z'
  created_at: '2026-07-21T04:03:12Z'
  acknowledged_at: '2026-07-21T05:10:00Z'
  due_at: '2026-07-22T04:00:00Z'
  resolved_at: null

status:
  workflow: in_progress
  snapshot: persistent
  overdue: false
  unattended: false
  chronic: false

root_cause:
  class: communication
  hypothesis: 'device does not establish a communication session'
  confidence: 0.82
  confirmed: false

evidence: []
tasks: []
history: []
related_issues: []
knowledge_articles: []

Scheda Operational Issue con lo stepper del workflow, le Evidence prodotte dai Detector, un'ipotesi AI sulla Root Cause con la relativa probabilità, il riepilogo dell'impatto sul business (Business Impact) e gli articoli della Knowledge Base ordinati per rilevanza — Scheda Issue: stepper del workflow, Evidence dei Detector, AI Root Cause con probabilità, Business Impact, articoli di soluzioni note (KB) ordinati per rilevanza

Issue e Task sono entità distinte

L’Issue risponde alla domanda:

Quale problema di esercizio deve essere risolto?

Il Task risponde alla domanda:

Quale azione concreta deve essere eseguita?

Un singolo Issue può contenere più Task. Per l’Issue archivio mancante su 38 dispositivi:

Task 1 — verificare la raggiungibilità del gateway;
Task 2 — verificare la coda sul server;
Task 3 — confrontare le versioni del firmware;
Task 4 — contattare l’operatore di rete mobile;
Task 5 — eseguire un’ispezione a campione sul campo.

La chiusura di un singolo Task non chiude automaticamente l’Issue.

Issues singoli e massivi

OHM adotta un unico modello per entrambe le scale:

Tipo	Descrizione
`single`	problema che riguarda un singolo Asset o una singola entità logica
`massive`	incidente sistemico che coinvolge un gruppo di Asset
`manual`	problema registrato da una persona
`external`	problema importato da un sistema esterno

Ciclo di vita dell’Operational Issue

Workflow principale

flowchart TD
  S1["Rilevato"] --> S2["Sottoposto a triage"]
  S2 --> S3["Assegnato"]
  S3 --> S4["Accettato"]
  S4 --> S5["In corso"]
  S5 --> S6["In attesa di verifica"]
  S6 --> S7["Verificato"]
  S7 --> S8["Risolto"]
  S8 --> S9["Archiviato"]

Esiti finali aggiuntivi:

annullato;
duplicato;
non riprodotto;
risoluzione non prevista;
rischio accettato.

Stati del workflow

Stato	Significato
`detected`	l’Issue è stato creato automaticamente o manualmente
`triaged`	sono stati esaminati Severity, zona di responsabilità e contesto iniziale
`assigned`	è stato individuato il responsabile
`accepted`	il responsabile ha confermato la presa in carico
`in_progress`	i lavori sono in corso
`awaiting_verification`	il lavoro è dichiarato completato ed è in attesa di verifica
`verified`	il risultato è stato confermato
`resolved`	l’Issue è chiuso con un esito definito
`archived`	l’oggetto completato è stato spostato nella cronologia di lungo periodo
`cancelled`	l’Issue è stato annullato per una motivazione documentata
`duplicate`	l’Issue è un duplicato di un altro oggetto
`not_reproduced`	il problema non è stato confermato durante la verifica
`wont_fix`	è stata presa la decisione gestionale di non intervenire
`accepted_risk`	il rischio è stato formalmente accettato da una persona autorizzata

Stato dello Snapshot

Oltre al workflow, OHM tiene traccia dello stato del problema sulla base dello Snapshot giornaliero dei Detector:

Stato dello Snapshot	Significato
`new`	il problema si è manifestato per la prima volta
`persistent`	il problema persiste
`worsened`	la situazione è peggiorata
`improved`	la situazione è migliorata, ma il problema non è scomparso
`cleared`	il Detector non conferma più il problema
`reopened`	il problema si è ripresentato dopo la chiusura

Lo stato del workflow e quello dello Snapshot non vengono mai confusi.

Esempio: workflow_status = in_progress insieme a snapshot_status = improved.

Ciò significa che i lavori sono ancora in corso, mentre i dati oggettivi mostrano già un miglioramento.

Matrice delle transizioni

Stato attuale	Transizioni ammesse
detected	triaged, assigned, duplicate, cancelled
triaged	assigned, cancelled, accepted_risk
assigned	accepted, in_progress, reassigned
accepted	in_progress, reassigned
in_progress	awaiting_verification, escalated, accepted_risk
awaiting_verification	verified, in_progress
verified	resolved
resolved	reopened, archived
reopened	triaged, assigned, in_progress
qualsiasi stato attivo	duplicate, cancelled

Ogni transizione viene annotata in un registro eventi immutabile.

Schermata di riferimento con gli stati del ciclo di vita dell'Issue e le relative transizioni ammesse, gli stati dello Snapshot e le fasi dell'incidente — Stati e workflow: il ciclo di vita dell'Issue con le transizioni ammesse, gli stati dello Snapshot e le fasi dell'incidente

Registro di audit (Audit Trail)

Tutte le azioni significative vengono registrate in una cronologia immutabile.

Un evento contiene:

yaml

event_id: EVT-9038172
issue_id: OHM-2026-001842
event_type: status_changed
timestamp: '2026-07-23T10:14:00Z'
actor:
  type: user
  id: 'usr-231'
  role: 'zone_manager'
before:
  status: assigned
after:
  status: in_progress
reason: 'Diagnostics started'
source:
  ip: 'masked'
  client: 'web'
correlation_id: 'req-982310'

Vengono sempre registrati:

la creazione;
l’assegnazione;
la riassegnazione;
la modifica della priorità;
la modifica della scadenza;
la modifica dello stato;
il commento;
l’aggiunta di Evidence;
la conferma della Root Cause;
la verifica manuale;
l’accettazione del rischio;
l’applicazione di un articolo KB;
l’unione e la suddivisione degli Issues;
la modifica della configurazione di un Detector;
le azioni di esportazione e di integrazione.

Continuazione della scheda Issue con la checklist dei Task e la Timeline degli eventi in ordine cronologico, che registra ogni azione compiuta sull'Issue — Scheda Issue (continua): checklist dei Task e Timeline completa degli eventi — la fonte unica di tutti i KPI

Argomenti correlati

Ultimo aggiornamento il 4 agosto 2026

Questa pagina è stata utile?