# زمن استجابة الخدمات الداخلية (Internal Service Latency)

> الزمن الذي تستغرقه الخدمة أو قاعدة البيانات للردّ على طلب، مقيسًا عند المئين الخامس والتسعين.

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

## الهدف

كشف البطء قبل أن يصير توقّفًا، فالخدمة البطيئة تُحسب متاحة في كل تقارير الإتاحة وهي معطّلة عمليًّا.

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

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

## المعادلة

```
Latency = 95th percentile of service response time
```

المتوسط عديم الفائدة هنا: خدمة متوسطها 40 ملّي ثانية ومئينها الخامس والتسعون 8 ثوانٍ تُسقط تجربة المستخدم، والمتوسط يقول إنها ممتازة.

## مثال محسوب

خدمة بمتوسط 0.04 ثانية ومئين خامس وتسعين 8.2 ثانية. المتوسط يقول ممتاز، والمئين يقول إن واحدًا من كل عشرين طلبًا يفشل عمليًّا.

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

تحت 300 ملّي ثانية للخدمات التفاعلية وتحت ثانيتين للتقارير الثقيلة. والمعيار يُكتب في اتفاقية مستوى الخدمة الداخلية لا يُترك للتقدير.

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

- تدهوره التدريجي مع نموّ البيانات يعني استعلامًا لا يتوسّع، وهو أشيع سبب
- قفزته بعد نشر يعني تراجعًا أدخله تغيير بعينه
- ارتفاعه في ساعات الذروة وحدها يعني سعة لا بطء تصميم

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

- ما المئين الخامس والتسعون؟ المتوسط لا يمثّل تجربة أحد
- هل الاستعلام يتوسّع مع نموّ البيانات؟ أشيع سبب للتدهور التدريجي
- أي خدمة في السلسلة هي الأبطأ؟ الأبطأ يحكم الجميع

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

- أدر المئين الخامس والتسعين لا المتوسط، وضعه في اتفاقية الخدمة الداخلية
- اقرأه مع هامش السعة، فالبطء غالبًا إنذار سعة مبكّر
- تتبّع الطلب عبر الخدمات، فالبطء غالبًا في خدمة واحدة داخل السلسلة

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

- توزيع أزمنة الاستجابة مع تعليم المئين الخامس والتسعين
- خط زمني للزمن مع تعليم تواريخ النشر
- شلال الزمن عبر سلسلة الخدمات

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

- قياس المتوسط يجعل خدمة تفشل في 5% من الطلبات تبدو ممتازة
- قياس زمن الخادم وحده يخفي بطء الشبكة الذي يعيشه المستخدم
- علاج البطء بترقية العتاد بينما السبب استعلام لا يتوسّع

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

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

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

### Excel

```excel
=PERCENTILE.INC(Call[DurationSeconds],0.95)
```

### Power BI (DAX)

```dax
P95 Service Latency =
PERCENTILEX.INC (
    'ServiceCall',
    'ServiceCall'[DurationSeconds],
    0.95
)
```

### Tableau

```
PERCENTILE([Duration Seconds], 0.95)
```

### SQL

```sql
SELECT service_name,
       AVG(duration_ms)                                          AS mean_ms,
       PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY duration_ms) AS p95_ms,
       COUNT(*)                                                  AS calls
FROM   service_call
WHERE  called_at BETWEEN :from_date AND :to_date
GROUP  BY service_name
ORDER  BY p95_ms DESC;
```

---

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