مسائل عملیاتی و چرخهٔ عمر

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 می‌تواند شامل چند Task باشد. برای Issue آرشیو برای 38 دستگاه موجود نیست:

• Task 1 — بررسی در دسترس بودن گیت‌وی؛
• Task 2 — بررسی صف سمت سرور؛
• Task 3 — مقایسهٔ نسخه‌های Firmware؛
• Task 4 — تماس با اپراتور تلفن همراه؛
• Task 5 — انجام بازرسی میدانی نمونه‌ای.

بستن یک Task، Issue را به‌صورت خودکار نمی‌بندد.

‏Issueهای تکی و انبوه

‏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 روزانهٔ Detectorها رصد می‌کند:

وضعیت 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'

موارد زیر همواره ثبت می‌شوند:

• ایجاد؛
• واگذاری؛
• واگذاری مجدد؛
• تغییر اولویت (Priority)؛
• تغییر مهلت؛
• تغییر وضعیت؛
• کامنت؛
• افزودن Evidence؛
• تأیید Root Cause؛
• راستی‌آزمایی دستی؛
• پذیرش ریسک؛
• به‌کارگیری مقالهٔ KB؛
• ادغام و تفکیک Issues؛
• تغییر پیکربندی Detector؛
• خروجی‌گیری و اقدامات یکپارچه‌سازی.