Operational Issues a životní cyklus

Operational Issue jako jednotka práce — základní model, rozdíl mezi Issue a Task, jednotlivé a hromadné druhy, workflow statusů s maticí přechodů a neměnná auditní stopa.

Operational Issue

Operational Issue je ústřední entitou OHM.

Jde o stavový objekt, který reprezentuje provozní problém po celou dobu jeho životního cyklu.

Základní model

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: []

Karta Operational Issue se stepperem workflow, důkazy detektorů, AI-hypotézou kořenové příčiny s její pravděpodobností, souhrnem obchodního dopadu a seřazenými články znalostní báze — Karta Issue: stepper workflow, důkazy detektorů, AI Root Cause s pravděpodobností, obchodní dopad, seřazené články známých řešení (KB)

Issue a Task jsou odlišné entity

Issue odpovídá na otázku:

Jaký provozní problém je třeba odstranit?

Task odpovídá na otázku:

Jakou konkrétní akci je třeba provést?

Jeden Issue může obsahovat několik úkolů. Pro Issue chybí archiv u 38 zařízení:

Task 1 — zkontrolovat dostupnost brány;
Task 2 — zkontrolovat serverovou frontu;
Task 3 — porovnat verze firmwaru;
Task 4 — kontaktovat mobilního operátora;
Task 5 — provést výběrovou kontrolu v terénu.

Uzavřením jednoho úkolu se Issue automaticky neuzavírá.

Jednotlivé a hromadné Issues

OHM používá jeden model pro obě měřítka:

Druh	Popis
`single`	problém jednoho aktiva nebo jedné logické entity
`massive`	systémový incident, který zasáhl skupinu aktiv
`manual`	problém zaregistrovaný člověkem
`external`	problém importovaný z externího systému

Životní cyklus Operational Issue

Hlavní workflow

flowchart TD
  S1["Zjištěn"] --> S2["Provedena triáž"]
  S2 --> S3["Přidělen"]
  S3 --> S4["Převzat"]
  S4 --> S5["V řešení"]
  S5 --> S6["Čeká na ověření"]
  S6 --> S7["Ověřen"]
  S7 --> S8["Vyřešen"]
  S8 --> S9["Archivován"]

Další koncové výsledky:

zrušen;
duplicita;
nereprodukován;
odstranění se neplánuje;
riziko přijato.

Statusy workflow

Status	Význam
`detected`	Issue byl vytvořen automaticky nebo ručně
`triaged`	byly posouzeny severity, zóna odpovědnosti a prvotní kontext
`assigned`	byl určen odpovědný řešitel
`accepted`	řešitel potvrdil převzetí
`in_progress`	probíhají práce
`awaiting_verification`	práce je ohlášena jako dokončená a čeká na ověření
`verified`	výsledek byl potvrzen
`resolved`	Issue je uzavřen se stanoveným výsledkem
`archived`	dokončený objekt byl přesunut do dlouhodobé historie
`cancelled`	Issue byl zrušen z doloženého důvodu
`duplicate`	Issue je duplicitou jiného objektu
`not_reproduced`	problém nebyl při ověření potvrzen
`wont_fix`	bylo přijato manažerské rozhodnutí problém neodstraňovat
`accepted_risk`	riziko bylo formálně přijato oprávněnou osobou

Stav snapshotu

Kromě workflow sleduje OHM stav problému podle denního snapshotu detektorů:

Stav snapshotu	Význam
`new`	problém se objevil poprvé
`persistent`	problém přetrvává
`worsened`	stav se zhoršil
`improved`	stav se zlepšil, ale problém nezmizel
`cleared`	detektor problém již nepotvrzuje
`reopened`	problém se po uzavření objevil znovu

Status workflow a stav snapshotu se nikdy nezaměňují.

Příklad: workflow_status = in_progress současně se snapshot_status = improved.

To znamená, že práce stále probíhají, zatímco objektivní data už ukazují zlepšení.

Matice přechodů

Aktuální status	Povolené přechody
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
libovolný aktivní	duplicate, cancelled

Každý přechod se zaznamenává do neměnného protokolu událostí.

Referenční obrazovka se statusy životního cyklu Issue a jejich povolenými přechody, se stavy snapshotu a s fázemi incidentu — Statusy a workflow: životní cyklus Issue s povolenými přechody, stavy snapshotu a fáze incidentu

Auditní stopa (Audit Trail)

Všechny významné akce se zaznamenávají do neměnné historie.

Událost obsahuje:

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'

Vždy se zaznamenává:

vytvoření;
přidělení;
přeřazení;
změna priority;
změna termínu;
změna statusu;
komentář;
přidání Evidence;
potvrzení Root Cause;
ruční ověření;
přijetí rizika;
použití článku KB;
sloučení a rozdělení Issues;
změna konfigurace detektoru;
exportní a integrační akce.

Pokračování karty Issue s kontrolním seznamem úkolů a chronologickou časovou osou událostí, která zaznamenává každou akci provedenou nad Issue — Karta Issue (pokračování): kontrolní seznam úkolů a úplná časová osa událostí — jediný zdroj pro všechny KPI

Související témata

Naposledy aktualizováno 3. srpna 2026

Byla tato stránka užitečná?