Операційні проблеми та життєвий цикл

Operational Issue

Operational Issue — центральна сутність OHM.

Це stateful-об’єкт, який представляє експлуатаційну проблему протягом усього її життєвого циклу.

Базова модель

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

Issue і Task — різні сутності

Issue відповідає на запитання:

Яку експлуатаційну проблему потрібно усунути?

Task відповідає на запитання:

Яку конкретну дію необхідно виконати?

Один Issue може містити кілька задач. Для Issue відсутній архів на 38 пристроях:

• Task 1 — перевірити доступність шлюзу;
• Task 2 — перевірити серверну чергу;
• Task 3 — порівняти версії прошивки;
• Task 4 — звернутися до оператора мобільного зв’язку;
• Task 5 — виконати вибіркову польову перевірку.

Закриття однієї задачі не закриває Issue автоматично.

Одиничні та масові Issues

OHM використовує одну модель для обох масштабів:

Життєвий цикл Operational Issue

Основний workflow

flowchart TD
  S1["Виявлено"] --> S2["Проведено тріаж"]
  S2 --> S3["Призначено"]
  S3 --> S4["Прийнято"]
  S4 --> S5["У роботі"]
  S5 --> S6["Очікує перевірки"]
  S6 --> S7["Перевірено"]
  S7 --> S8["Усунено"]
  S8 --> S9["В архіві"]

Додаткові кінцеві результати:

• скасовано;
• дублікат;
• не відтворено;
• усунення не планується;
• ризик прийнято.

Статуси workflow

Snapshot-статус

Крім workflow, OHM відстежує стан проблеми на основі щоденного знімка детекторів (snapshot):

Статус workflow і snapshot-статус ніколи не змішуються.

Приклад: workflow_status = in_progress разом із snapshot_status = improved.

Це означає, що роботи ще тривають, тоді як об’єктивні дані вже показують покращення.

Матриця переходів

Кожен перехід записується до незмінного журналу подій.

Журнал аудиту (Audit Trail)

Усі значущі дії записуються до незмінної історії.

Подія містить:

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'

Завжди журналюються:

• створення;
• призначення;
• перепризначення;
• зміна пріоритету;
• зміна терміну;
• зміна статусу;
• коментар;
• додавання Evidence;
• підтвердження root cause;
• ручна верифікація;
• прийняття ризику;
• застосування статті KB;
• об’єднання та розділення Issues;
• зміна конфігурації детектора;
• експорт та інтеграційні дії.