أساسيات تصميم الأنظمة

المقاييس الأساسية: زمن الاستجابة والإنتاجية والتوافر

18 دقيقة الدرس 5 من 10

المقاييس الأساسية: زمن الاستجابة والإنتاجية والتوافر

قبل أن تبدأ في تصميم أي نظام، تحتاج إلى مفردات مشتركة لقياس مدى جودة أدائه. ثلاثة أرقام تهيمن على كل نقاش في تصميم الأنظمة: زمن الاستجابة (Latency)، والإنتاجية (Throughput)، والتوافر (Availability). إن فهم معناها والمقايضات الصعبة بينها هو أساس كل قرار معماري ستتخذه.

زمن الاستجابة: كم يستغرق الطلب الواحد؟

زمن الاستجابة (Latency) هو الوقت المنقضي من لحظة إرسال العميل للطلب حتى استلامه الاستجابة الكاملة. يُقاس بالميلي ثانية (ms) أو الميكروثانية (µs). كلما قلّ كان أفضل.

إليك أرقاماً مرجعية يجب أن يحفظها كل مهندس:

  • قراءة ذاكرة التخزين المؤقت L1: ~1 نانوثانية
  • قراءة ذاكرة التخزين المؤقت L2: ~4 نانوثانية
  • قراءة من الذاكرة العشوائية RAM: ~100 نانوثانية
  • قراءة عشوائية من SSD: ~100 ميكروثانية (0.1 ms)
  • وقت بحث HDD: ~10 ms
  • رحلة ذهاباً وإياباً داخل مركز البيانات: ~0.5 ms
  • رحلة عبر مناطق مختلفة (مثلاً US ← EU): ~150 ms
  • رحلة عبر شبكة 4G: ~50–100 ms
الفكرة الجوهرية: القرص والشبكة أبطأ بمراحل من الذاكرة. حين ترى نظاماً بطيئاً، فالاختناق في الغالب أحد هذين السببين: عمليات قرص مفرطة، أو جولات شبكية غير ضرورية.

النسب المئوية: لماذا يكذب المتوسط؟

الإبلاغ عن متوسط زمن الاستجابة هو من أخطر العادات في الهندسة. تخيّل 99 طلباً تكتمل في 10 ms وطلباً واحداً يستغرق 10,000 ms. المتوسط ~109 ms — لكن 99% من المستخدمين بخير وأحدهم غاضب. المتوسط يخفي الحالة الشاذة تماماً.

يستخدم المجال بدلاً من ذلك النسب المئوية (Percentiles):

  • p50 — الوسيط؛ 50% من الطلبات أسرع من هذه القيمة.
  • p95 — 95% من الطلبات أسرع. 5% أبطأ.
  • p99 — 99% من الطلبات أسرع. طلب واحد فقط من كل مئة أبطأ.
  • p999 — 99.9% من الطلبات أسرع. الأسوأ من بين كل 1,000.

في بيئة الإنتاج ستسمع فرق العمل تقول مثلاً: "p99 لدينا هو 200 ms." هذا يعني أن 1% من المستخدمين ينتظرون أكثر من 200 ms. عند معدل 10,000 طلب في الثانية، هذا يعني 100 مستخدم يعانون استجابة بطيئة كل ثانية.

أفضل الممارسات: تتبّع دائماً p99 (وأحياناً p999) في لوحات المراقبة. حسّن p99 أولاً وليس المتوسط. أدوات مثل Prometheus وDatadog وNew Relic تدعم رسوم بيانية للنسب المئوية مباشرة.
Latency Percentile Distribution Latency (ms) % of Requests 10 50 100 200 500 50% 95% 99% 99.9% p50 ≈ 10 ms p95 ≈ 50 ms p99 ≈ 100 ms p999 ≈ 200 ms
توزيع تراكمي لزمن استجابة الطلبات. الذيلان p99 وp999 يكشفان الطلبات البطيئة التي يخفيها المتوسط.

الإنتاجية: كم من العمل يتحمّله النظام؟

الإنتاجية (Throughput) هي عدد الطلبات (أو العمليات، أو البايتات) التي يستطيع النظام معالجتها في وحدة الزمن. الوحدات الشائعة هي طلب في الثانية (RPS) أو استعلام في الثانية (QPS) أو بايت في الثانية (Bps). كلما ارتفعت كان أفضل.

تُخبرك الإنتاجية عن السعة. نظام يعالج 500 RPS عند p99 = 50 ms يختلف جذرياً عن نظام يعالج 50,000 RPS بنفس زمن الاستجابة. أنت تحتاج الرقمين معاً.

المقايضة بين زمن الاستجابة والإنتاجية

زمن الاستجابة والإنتاجية مرتبطان لكنهما رافعتان متعاكستان. التجميع (Batching) مثال كلاسيكي: إذا أرسلت عمليات الكتابة في قاعدة البيانات واحدة تلو الأخرى، فكل عملية سريعة (زمن استجابة منخفض) لكن الإنتاجية الكلية تكون محدودة بسبب تكلفة الرحلة الشبكية. لكن إذا جمعت 1,000 عملية كتابة في معاملة واحدة، ترتفع الإنتاجية بشكل كبير، في حين تنتظر كل عملية كتابة حتى اكتمال نافذة التجميع — ويزيد زمن الاستجابة.

خطأ شائع: لا تحسّن بُعداً واحداً فقط. نظام بزمن استجابة 1 ms لا يتحمل سوى 10 RPS لا قيمة له في الإنتاج. ونظام يصل إلى الحد الأقصى عند 100,000 RPS لكن p99 لديه 30 ثانية سيدمر تجربة المستخدم. صمّم للاثنين معاً.

التوافر: درجات التسعة

التوافر (Availability) هو النسبة المئوية للوقت الذي يخدم فيه النظام الطلبات بشكل صحيح. يُعبَّر عنه كنسبة مئوية — وعادةً ما يُكتب بالأرقام الشهيرة "التسعات (Nines)":

Availability Nines Reference Table Availability Downtime / year Downtime / month Tier 90% (one nine) 36.5 days 73 hours Unacceptable 99% (two nines) 3.65 days 7.3 hours Basic 99.9% (three nines) 8.76 hours 43.8 minutes Standard 99.99% (four nines) 52.6 minutes 4.38 minutes High 99.999% (five nines) 5.26 minutes 26 seconds Carrier-grade Each additional nine is 10× harder and more expensive to achieve.
جدول مرجعي لدرجات التسعة وميزانياتها من وقت التوقف. معظم اتفاقيات الخدمة تستهدف 99.9% إلى 99.99%.

لاحظ كيف تكلّف كل تسعة إضافية جهداً هندسياً أكبر بمرتبة من حجمه. الانتقال من 99% إلى 99.9% يعني التخلص من ساعات من وقت التوقف سنوياً. والانتقال من 99.99% إلى 99.999% يعني تحمّل 5 دقائق فقط من التوقف غير المخطط سنوياً — يُحقق ذلك من خلال بنى متعددة المناطق ذات توافر عالٍ، وتحويل تلقائي للفشل في غضون ثوانٍ، وهندسة الفوضى المستمرة.

SLI وSLO وSLA

ثلاثة مصطلحات ستصادفها باستمرار:

  • SLI (مؤشر مستوى الخدمة): القياس الفعلي — مثلاً "كان p99 لزمن الاستجابة 180 ms في الساعة الأخيرة."
  • SLO (هدف مستوى الخدمة): الهدف الداخلي — مثلاً "يجب أن يكون p99 لزمن الاستجابة أقل من 200 ms، محسوباً على نافذة دوارة مدتها 30 يوماً."
  • SLA (اتفاقية مستوى الخدمة): عقد قانوني مع العميل — مثلاً "نضمن توافراً بنسبة 99.9%؛ وفي حال عدم التحقق تحصل على اعتمادات خدمة."
الفكرة الجوهرية: يجب أن تكون SLOs أكثر صرامة من SLAs. إذا كانت اتفاقية الخدمة تعد بتوافر 99.9%، فهدفك الداخلي SLO يجب أن يستهدف 99.95% — الفجوة بينهما هي ميزانية الأخطاء. أنفق هذه الميزانية على الصيانة المخططة والنشر الجريء؛ وحافظ عليها بشدة حين تقترب من نفادها.

كيف تتفاعل هذه المقاييس في الواقع؟

لنأخذ مثال كتلة قواعد بيانات: إضافة نسخ للقراءة (Read Replicas) تزيد الإنتاجية (استعلامات موازية أكثر) لكنها قد تُعلي قليلاً زمن الاستجابة للقراءات التي تصل إلى نسخة متأخرة عن الأصل. إضافة ذاكرة تخزين مؤقت في الذاكرة (مثل Redis) تقلل زمن الاستجابة بشكل كبير — لكنها تجلب خطر البيانات القديمة وطفرة فقدان التخزين المؤقت التي تُدهور مؤقتاً كلا المقياسين. وتحقيق التوافر العالي يتطلب تكراراً وتحويلاً للفشل، مما يضيف تنسيقاً موزعاً يؤثر بدوره على زمن الاستجابة والإنتاجية.

تصميم الأنظمة هو فن ضبط هذه الأرقام الثلاثة وفق متطلباتك المحددة. لا توجد نقطة مثلى عالمية — هناك فقط المقايضة الصحيحة لحجم عملك وميزانيتك وتوقعات مستخدميك.

نصيحة المقابلات: في مقابلة تصميم الأنظمة، بمجرد سماعك متطلباً مثل "يجب ألا يشعر المستخدمون بالبطء"، حوّله فوراً إلى أرقام ملموسة: "إذن نحتاج p99 لزمن الاستجابة أقل من 100 ms وتوافراً بنسبة 99.9%." تحديد المتطلبات الغامضة بأرقام يدل على تفكير المهندس الأول.