# زمن العودة إلى الخدمة (Mean Time to Restore)

> متوسط الوقت من اكتشاف العطل حتى عودة الخدمة للمستخدم، لا حتى إصلاح السبب الجذري.

- **المجال:** تقنية المعلومات (IT Operations)
- **الوحدة:** ساعة
- **تكرار القياس:** شهري
- **الاتجاه المرغوب:** أقل أفضل
- **النوع:** تابع (Lagging)
- **الرابط:** https://kpihub.co/k/it-mttr

## الهدف

قياس سرعة التعافي لا ندرة الأعطال، فالعطل سيقع، والفارق بين فريق ناضج وغيره هو كم يبقى الأثر.

## لماذا هو مهم

- الأنظمة الحديثة تفشل بطبيعتها، والسعي إلى صفر أعطال أغلى وأقلّ جدوى من سرعة العودة
- ساعة أقلّ في العودة تعادل ساعة إنتاج مستعادة في كل قسم يعتمد على النظام
- يقيس جاهزية الفريق والأدوات معًا: الاكتشاف والتشخيص والاستعادة

## المعادلة

```
MTTR = Σ (Service restored at − Fault detected at) ÷ Incidents
```

فكّكه إلى ثلاث مراحل: الاكتشاف والتشخيص والاستعادة. الإجمالي لا يقول أين يضيع الوقت، وأغلبه في أغلب الفرق يقع في الاكتشاف لا في الإصلاح.

## مثال محسوب

‏34 حادثة في الشهر بمجموع 71.4 ساعة حتى عودة الخدمة. الحساب: 71.4 ÷ 34 = 2.1 ساعة، منها 0.9 حتى الاكتشاف وحده.

## النطاق الاسترشادي

تحت ساعة للأنظمة الحرجة، وتحت أربع ساعات للمساندة. والمقارنة تصحّ بدرجة خطورة الحادثة لا بمتوسط واحد يخلط عطلًا كبيرًا بشكوى صغيرة.

## تحليل الاتجاه

- طول مرحلة الاكتشاف يعالَج بالمراقبة والتنبيه لا بمزيد من المهندسين
- ارتفاعه خارج ساعات العمل يعني ترتيب مناوبة يحتاج مراجعة
- انخفاضه مع ارتفاع تكرار الحوادث ليس تحسّنًا كاملًا: تتعافى أسرع وتسقط أكثر

## أسئلة تشخيصية

- كم من الزمن قبل أن نعرف أصلًا؟ الاكتشاف هو المرحلة الأكبر عادةً
- من اكتشف العطل: المراقبة أم المستخدم؟ الثاني إخفاق في ذاته
- هل الترتيب خارج الدوام يعادل ترتيب الدوام؟

## نصائح عملية

- قِس مرحلة الاكتشاف منفصلةً، فهي أرخص مرحلة لتقصيرها وأكبرها أثرًا
- تابع نسبة الحوادث التي اكتشفها المستخدم قبل المراقبة، فهي مقياس تغطية المراقبة
- افصل بدرجة الخطورة، فمتوسط واحد يخفي الحوادث الكبرى

## العرض المناسب

- شلال المراحل: اكتشاف وتشخيص واستعادة
- توزيع أزمنة العودة بدرجة الخطورة
- خط زمني للزمن مع أعمدة عدد الحوادث

## تحذيرات وفخاخ

- قياس الإجمالي وحده يوجّه الاستثمار إلى الإصلاح بينما المشكلة في الاكتشاف
- متوسط عبر درجات الخطورة يخفي الحوادث التي أوقفت العمل
- خفضه بحلول مؤقّتة متكرّرة يبني دينًا تقنيًّا ينفجر لاحقًا

## أثر التغيير

- خفض زمن الاكتشاف من 0.9 ساعة إلى 0.2 يخفض الزمن الكلّي ثلثًا بلا زيادة كادر
- ساعة أقلّ على 34 حادثة تعادل 34 ساعة إنتاج مستعادة شهريًّا
- مراقبة تغطّي ما يكتشفه المستخدمون اليوم تنقل الفريق من ردّ الفعل إلى الاستباق

## احسبه في أداتك

### Excel

```excel
=AVERAGE((Inc[Restored] - Inc[Detected]) * 24)
```

### Power BI (DAX)

```dax
Mean Time To Restore =
AVERAGEX (
    'Incident',
    DATEDIFF ( 'Incident'[DetectedAt], 'Incident'[RestoredAt], MINUTE ) / 60.0
)
```

### Tableau

```
AVG( DATEDIFF('minute', [Detected At], [Restored At]) ) / 60
```

### SQL

```sql
SELECT severity,
       AVG(EXTRACT(EPOCH FROM (restored_at - detected_at)) / 3600) AS mttr_hours,
       AVG(EXTRACT(EPOCH FROM (detected_at - started_at)) / 3600)  AS detection_hours,
       COUNT(*) FILTER (WHERE found_by = 'User')                    AS user_found
FROM   incident
WHERE  started_at BETWEEN :from_date AND :to_date
GROUP  BY severity
ORDER  BY mttr_hours DESC;
```

---

المصدر: [KPIHub](https://kpihub.co/k/it-mttr) · مرجع عربي مجاني لمؤشرات الأداء.