Evidence و همبسته‌سازی

مدل تغییرناپذیر Evidence همراه با نمره‌دهی کیفیت، و سازوکار همبسته‌سازی که نشانه‌های مرتبط را با سطح اطمینان صریح به یک علت ریشه‌ای محتمل پیوند می‌دهد.

مدل Evidence

‏Evidence چیست

Evidence مدرکی ساختارمند است که سامانه بر پایهٔ آن یک Issue را می‌سازد، به‌روزرسانی می‌کند یا راستی‌آزمایی می‌کند.

‏Evidence می‌تواند:

به‌صورت خودکار محاسبه شده باشد؛
از یک دستگاه دریافت شده باشد؛
از یک سامانهٔ بیرونی وارد شده باشد؛
به‌دست کاربر افزوده شده باشد؛
توسط یک گزارش تخصصی تولید شده باشد؛
در قالب سند، عکس یا نظر پیوست شده باشد.

ساختار Evidence

yaml

evidence_id: EVD-830129
issue_id: OHM-2026-001842
type: detector_finding
source:
  provider: analyze_station
  detector_id: archive.tail_gap.v3
  detector_version: '3.2.1'
observed_at: '2026-07-23T04:00:00Z'
created_at: '2026-07-23T04:03:12Z'

payload:
  missing_hours: 73
  coverage_valid: 0.91
  last_valid_hour: '2026-07-20T03:00:00Z'

quality:
  completeness: 1.0
  freshness: 0.98
  consistency: 0.96
  confidence: 0.98

links:
  report: '/reports/analyze-station/5690'

انواع Evidence

نوع	نمونه
`detector_finding`	نتیجهٔ Detector
`telemetry_sample`	قطعه‌ای از تله‌متری
`archive_window`	خلاصهٔ یک بازهٔ آرشیو
`event_log`	لاگ رویدادهای دستگاه
`configuration_snapshot`	‏Snapshot پیکربندی
`operator_comment`	نظر دیسپچر
`field_report`	گزارش یا صورت‌جلسهٔ گروه میدانی
`photo`	عکس تجهیزات
`external_ticket`	پیوند به یک تیکت بیرونی
`verification_result`	تأیید رفع مشکل
`root_cause_confirmation`	تأیید علت ریشه‌ای
`knowledge_application`	به‌کارگیری مقالهٔ Knowledge Base

کیفیت Evidence

برای هر Evidence کیفیت آن محاسبه می‌شود:

Q_{evidence} = w_c C + w_f F + w_s S + w_t T

که در آن:

$C$ — کامل‌بودن؛
$F$ — تازگی؛
$S$ — سازگاری؛
$T$ — اعتماد به منبع؛
$w_c + w_f + w_s + w_t = 1$ .

وزن‌های پایهٔ پیشنهادی:

مؤلفه	وزن
$w_c$ — کامل‌بودن	0.30
$w_f$ — تازگی	0.25
$w_s$ — سازگاری	0.25
$w_t$ — اعتماد به منبع	0.20

نتیجه به بازهٔ 0 تا 1 نرمال می‌شود.

تغییرناپذیری Evidence

‏Evidence اصلی هرگز پس از ثبت ویرایش نمی‌شود. اصلاح، نسخه‌ای تازه یا یک Evidence اصلاحی جداگانه ایجاد می‌کند.

این کار این موارد را تضمین می‌کند:

ممیزی‌پذیری؛
تکرارپذیری؛
حفاظت از تاریخچه؛
بررسی درست موارد اختلافی؛
امکان محاسبهٔ دوباره.

همبسته‌سازی رویدادها و Root Cause

وظیفهٔ همبسته‌سازی

همبسته‌سازی مانع از ساخته‌شدن چندین Issue مستقل برای یک علت فنی واحد می‌شود.

سامانه این موارد را تحلیل می‌کند:

هم‌خوانی Asset؛
نزدیکی زمانی؛
وابستگی توپولوژیک؛
‏Firmware مشترک؛
گیت‌وی مشترک؛
اپراتور ارتباطی مشترک؛
منطقهٔ مشترک؛
صف سرور مشترک؛
توالی نشانه‌ها؛
پیوندهای تاریخی؛
علت‌های ریشه‌ای تأییدشدهٔ موارد پیشین.

سطوح همبسته‌سازی

درون یک Asset واحد

چند نشانه پیرامون یک Canon اصلی گرد می‌آیند.

flowchart TD
  A["stale_communication"] --> C{"همبسته‌سازی درون Asset"}
  B["no_hourly_archive"] --> C
  D["battery_unknown"] --> C
  C --> R["Issue اصلی: stale_communication"]
  C --> S1["سیگنال ثانویه: no_hourly_archive"]
  C --> S2["سیگنال ثانویه: battery_unknown"]

میان Assetها

مشکلات مشابه در قالب یک Massive Incident گروه‌بندی می‌شوند.

flowchart TD
  A["38 دستگاه"] --> G{"گروه‌بندی"}
  B["یک نسخهٔ Firmware"] --> G
  C["یک بازهٔ زمانی"] --> G
  D["یک نوع خرابی"] --> G
  G --> M["Massive Incident: firmware_regression"]

بر پایهٔ وابستگی

مشکلات دستگاه‌های فرزند به خرابی یک مؤلفهٔ مشترک پیوند می‌خورند.

flowchart TD
  A["Gateway-17 در دسترس نیست"] --> B["12 تصحیح‌کننده بدون ارتباط"]
  B --> C["12 آرشیو تحویل نشده"]
  C --> D["یک رخداد وابستگی"]

امتیاز همبستگی (Correlation Score)

برای سنجش قدرت پیوند از یک مدل قابل توضیح استفاده می‌شود:

S_{corr} = w_a A + w_t T + w_p P + w_c C + w_h H

که در آن:

$A$ — هم‌خوانی Asset یا وابستگی؛
$T$ — نزدیکی زمانی؛
$P$ — هم‌خوانی الگو؛
$C$ — زمینهٔ مشترک؛
$H$ — تأیید تاریخی پیوند.

نمونهٔ وزن‌ها:

عامل	وزن
$A$ — هم‌خوانی Asset یا وابستگی	0.30
$T$ — نزدیکی زمانی	0.20
$P$ — شباهت الگو	0.20
$C$ — زمینهٔ مشترک	0.15
$H$ — تأیید تاریخی	0.15

آستانهٔ ادغام برای هر کلاس مشکل جداگانه تعیین می‌شود. برای سیگنال‌های حیاتی Security، آستانه‌ای محافظه‌کارانه‌تر مجاز است.

کلاس‌های Root Cause

‏OHM از یک فهرست مدیریت‌شدهٔ علت‌های ریشه‌ای استفاده می‌کند:

کلاس	نمونه‌ها
Power	باتری، منبع تغذیه، مبدل
Communication	شبکه، SIM، سیگنال، اپراتور
Firmware	رگرسیون، ناسازگاری
Configuration	پارامتر نادرست
Registry	رکورد تکراری، رکورد شبح، انتساب نادرست
Sensor	خرابی، رانش، قرائت ثابت‌مانده
Metering	مشکل اندازه‌شناختی
Infrastructure	سرور، صف، گیت‌وی
Integration	‏API، قالب، نگاشت
Human	خطا در اقدام یا فرایند
Environment	دما، رطوبت، اثر بیرونی
Security	نقض یکپارچگی یا دسترسی
External	سامانه یا تأمین‌کنندهٔ ثالث
Unknown	دادهٔ ناکافی

وضعیت‌های Root Cause

وضعیت	معنا
`hypothesis`	فرضیه‌ای که به‌صورت خودکار پیشنهاد شده است
`under_investigation`	فرضیه در حال بررسی است
`probable`	با چند نشانهٔ مستقل تأیید شده است
`confirmed`	به‌دست کاربر مجاز و بر پایهٔ Evidence تأیید شده است
`rejected`	فرضیه رد شده است
`unknown`	علت ریشه‌ای مشخص نشده است

اطمینان به Root Cause

اطمینان به یک فرضیه از مجموع شواهد محاسبه می‌شود:

C_{root} = \frac{ \sum_{i=1}^{n} r_i q_i a_i }{ \sum_{i=1}^{n} r_i } \cdot K_{independence}

که در آن:

$r_i$ — اعتمادپذیری Detector یا منبع؛
$q_i$ — کیفیت Evidence؛
$a_i$ — سازگاری Evidence با فرضیه؛
$K_{independence}$ — ضریب استقلال منابع.

اگر چند Evidence از یک مجموعه‌دادهٔ مبدأ واحد سرچشمه بگیرند، کاملاً مستقل به شمار نمی‌آیند.

اطمینان عملیاتی (Operational Confidence)

Operational Confidence نشان می‌دهد سامانه تا چه اندازه مطمئن است که یک Issue، مشکلی واقعی و به‌درستی طبقه‌بندی‌شده است.

C_{issue} = w_d D + w_e E + w_r R + w_h H - w_x X

که در آن:

$D$ — اعتمادپذیری Detectorها؛
$E$ — کیفیت Evidence؛
$R$ — سازگاری همبسته‌سازی؛
$H$ — نرخ تأیید تاریخی؛
$X$ — جریمهٔ تناقض‌ها و کمبود داده.

تفسیر:

Confidence	سطح	اقدام
≥ 0.85	بالا	ساخت خودکار یک Issue قابل اقدام
0.65–0.85	کافی	ساخت Issue با تریاژ معمول
0.40–0.65	محدود	نیازمند بررسی
< 0.40	پایین	سیگنال تحلیلی، اقدام‌های خودکار ممنوع

موضوعات مرتبط

آخرین به‌روزرسانی در ۱۳ مرداد ۱۴۰۵

آیا این صفحه مفید بود؟