زمن الاستجابة، حركة المرور، الأخطاء، الإشباع

أربعة أرقام تغطي معظم عمليات التشغيل

من كتاب Google SRE. أربع إشارات تقيسها على كل مستوى خدمة. إذا قمت بمراقبة هذه الأربعة بشكل جيد، فستلتقط معظم مشاكل الإنتاج قبل أن يلاحظها المستخدمون.

زمن الاستجابة (Latency): كم يستغرق تنفيذ الطلب؟ قسِّ التوزيعات الإحصائية، وليس المتوسطات فقط. يُعدّ زمن الاستجابة عند النسبة المئوية 99 (p99) أهم من المتوسط، لأن تأخير الذيل (Tail Latency) هو ما يشعر به المستخدمون بأنه "بطء". الخدمة التي يبلغ متوسط زمن استجابتها 50 مللي ثانية بينما يصل p99 إلى 5,000 مللي ثانية لديها مشكلة حقيقية لا يلاحظها معظم المستخدمين، لكن الـ 1% الأكثر تضرراً يلاحظونها بالتأكيد.

الحركة (Traffic): كم عدد الطلبات في الثانية؟ إجمالي الطلبات، لكل نقطة نهاية (Endpoint)، لكل رمز حالة (Status Code)، ولكل منطقة جغرافية. حدد الخط الأساس (Baseline) المعروف؛ وأطلق التنبيهات عند حدوث شذوذات (انخفاض مفاجئ = مشكلة في نقطة الدخول؛ ارتفاع مفاجئ = ذروة في الطلبات أو هجوم).

الأخطاء (Errors): معدل الطلبات الفاشلة. ميّز بين أخطاء 4xx (أخطاء العميل، وليست من مسؤوليتك) وأخطاء 5xx (أخطاء الخادم، وهي من مسؤوليتك). تتبّع معدل الأخطاء كنسبة مئوية من إجمالي الحركة، وليس كأرقام مطلقة، حتى تعمل التنبيهات بشكل صحيح عبر مستويات الأحمال المختلفة.

التشبع (Saturation): ما مدى امتلاء النظام؟ استخدام المعالج (CPU)، الذاكرة، عمق حوض الاتصالات (Connection Pool)، وطول الطابور (Queue). هذا هو المؤشر المسبق (Leading Indicator). يرتفع التشبع قبل تدهور زمن الاستجابة أو زيادة الأخطاء. الطبقة التي تصل إلى 90% تشبع هي على بُعد دقيقة سيئة واحدة من انهيار الطابور.

على مستوى طبقة الوكيل (Proxy Tier) تحديداً

يُضاء كل إشارة على مستوى طبقة الحافة (Edge Layer):

- زمن الاستجابة على الوكيل: مدة مصافحة TLS، وقت الاتصال بالخادم الخلفي (Upstream)، والإجمالي من الطلب إلى الاستجابة. يتم قياسها بشكل منفصل لأنها تقع في أجزاء مختلفة من مسار الطلب.

- الحركة على الوكيل: إجمالي الطلبات/ثانية، التوزيع لكل خادم خلفي (خادم خلفي "ساخن" يشير إلى انحراف في موازن الأحمال)، وتفصيل حسب رمز الحالة.

- الأخطاء عند الوسيط (Proxy): أخطاء 4xx من العملاء (مستخدموك الذين يحاولون الوصول إلى نقاط نهاية خاطئة)، وأخطاء 5xx من الخوادم الخلفية (خدماتك التي تفشل)، وأخطاء داخلية في الوسيط (502 = الخادم الخلفي غير قابل للوصول، 504 = انتهاء مهلة الخادم الخلفي).

- التشبع عند الوسيط (Proxy): عدد جلسات TLS، عمق مجموعة اتصالات الخادم الخلفي (Upstream Connection Pool)، ومعالج الوسيط نفسه (إيقاف TLS يستهلك قدرًا كبيرًا من المعالج).

نصيحة احترافية: ارتفاع مفاجئ في أخطاء 502 مع انخفاض زمن استجابة الخادم الخلفي يعني أن الخادم الخلفي يقطع الاتصال قبل الرد (إعادة تعيين الاتصال، انهيار، نفاد الذاكرة). أما ارتفاع أخطاء 504 فيعني أن الخادم الخلفي بطيء لكنه ما زال يرد. اقرأ رمز الخطأ؛ فهو يخبرك أين يقع الفشل.

اقرأ الإشارات

تعرض لوحة التحكم لديك ما يلي خلال آخر 10 دقائق:

- الحركة (Traffic): مستقرة تقريبًا عند 800 طلب/ثانية (لا يوجد ارتفاع مفاجئ)

- زمن الاستجابة (Latency): p50 مستقر عند 40 مللي ثانية، بينما ارتفع p99 من 200 مللي ثانية إلى 2,500 مللي ثانية خلال 5 دقائق ولا يزال في ارتفاع

- الأخطاء: معدل الأخطاء 4xx مستقر عند 0.3% (خلفية طبيعية)؛ ارتفع معدل الأخطاء 5xx من 0.1% إلى 1.2% (معظمها 504 انتهاء مهلة البوابة)

- التشبع: ارتفع معالج الخلفية (CPU) من 45% إلى 78% خلال نفس الدقائق الخمس؛ معالج الوكيل (proxy) مستقر عند 30%

متى يتم التوسع، ومتى يتم تصريف الحمل، ومتى يتم استدعاء المسؤول

قرارات السعة تتطلب محفّزات

مراقبة المقاييس أمر سهل. أما معرفة متى يجب اتخاذ إجراء بناءً عليها فهي الانضباط الحقيقي.

قم بالتوسع عندما: يتجاوز الإشباع عتبة مستدامة (على سبيل المثال، معالج الخلفية > 70% لمدة 5 دقائق)، أو عندما يتجاوز عمق الطابور الهدف المحدد، أو عندما يتجاوز زمن الاستجابة p99 حد الخدمة (SLO). يجب أن يُطلق المحفّز قبل حدوث الأعطال، وليس عند حدوثها.

قم بتصريف نسخة (Replica) عندما: تكون بطيئة باستمرار أو مليئة بالأخطاء بينما النسخ الأخرى سليمة (غالباً ما يكون تشغيل نسخة واحدة بسرعة عالية مشكلة على مستوى المضيف، وليس مشكلة في التطبيق)، أو عند نشر إصدار جديد، أو عند تقاعد نسخة بشكل سلس.

استدعِ مسؤولاً بشرياً عندما: يتم استهلاك حد الخدمة (SLO) بسرعة أكبر مما يمكن لميزانية الأخطاء أن تتحمله، أو عندما يُطلق محفّز الإشباع دون أن تمتصه آلية التوسع التلقائي، أو عندما يظهر نمط متسلسل (ارتفاع معدل الخطأ ومعدل إعادة المحاولة معاً).

لا تستدعِ مسؤولاً عندما: تحلّ دقيقة سيئة واحدة من تلقاء نفسها، أو عندما تسبب مهام الدفعة الخلفية (Batch Jobs) تقلبات دورية متوقعة، أو عندما يعبر الضوضاء العتبة (العتبة هي الخاطئة، وليس النظام).

أهداف التعلم (SLOs) واستهلاك ميزانية الأخطاء

يحدد هدف مستوى الخدمة (SLO) الأداء المقبول: 'معدل النجاح >= 99.9% خلال نافذة زمنية مدتها 28 يومًا'. والمكمّل (0.1%) هو ميزانية الأخطاء.

معدل الاستهلاك (Burn rate): السرعة التي تستهلك بها ميزانية الأخطاء. إذا استهلكت 10% من الميزانية في ساعة واحدة، فإن المعدل يكون أسرع بمقدار 240 مرة من المعدل المستدام (ساعة واحدة هي 1/672 من نافذة 28 يومًا؛ استهلاك 10% في تلك النافذة = 10% × 672 = 6720% متوقعة للنافذة الكاملة، بينما المسموح به هو 100% فقط).

تنبيهات معدل الاستهلاك متعددة النوافذ: يتم إرسال تنبيه (Page) عندما تستهلك نافذة قصيرة (5 دقائق بمعدل 14.4x) ونافذة طويلة (ساعة واحدة بمعدل 6x) الميزانية بشكل أسرع من المعدل المستدام. يلتقط هذا النوع من التنبيهات كلًا من الأعطال السريعة والتدهورات البطيئة.

لماذا هذا مهم للسعة (Capacity): خدمة تعمل بنسبة SLO تبلغ 99.9% مع هامش مرونة 1% يمكنها امتصاص التقلبات الطفيفة. أما خدمة تعمل بنسبة 99.93% (تلتزم بالكاد بـ SLO) فهي على بعد يوم سيء واحد فقط من انتهاك الهدف. يجب أن تستهدف قرارات السعة هامشًا مريحًا لـ SLO، وليس الحد الأدنى الذي يحققه فقط.

قرار سعة تحت المراقبة

لدى خدمتك هدف مستوى خدمة (SLO) بنسبة 99.9% من الطلبات الناجحة على مدار 28 يومًا. الحالة الحالية من المراقبة خلال الساعة الماضية:

- معدل النجاح: 99.5% (مستمر لمدة 30 دقيقة)

- وحدة المعالجة المركزية (CPU) للجهة الخلفية: متوسط 82% عبر الأسطول (الهدف 70%)

- زمن الاستجابة p99: 800 مللي ثانية (هدف SLO: <500 مللي ثانية)

- حركة المرور: 1,400 طلب/ثانية، مرتفعة من الأساس 1,000 طلب/ثانية (أعلى من الطبيعي بنسبة 40%؛ والاتجاه لا يزال في تصاعد)

- التوسع التلقائي: مُعدّ لإضافة نسخ (replicas) عندما يتجاوز CPU 80% لمدة 5 دقائق متواصلة؛ حالياً في منتصف عملية توسع ستضيف 3 نسخ خلال ~90 ثانية

صمّم خطة لمراقبة الإطلاق

التوليف

يمكنك الآن تصميم /health يلتقط الأعطال الحقيقية، و/version يتيح لك التحقق من عمليات النشر، ولوحات بيانات للإشارات الذهبية الأربع على مستوى الوكيل، ومحفزات سعة مرتبطة بمعدل استهلاك SLO.

طبّق جميع العناصر الأربعة.

تقوم فريقك بإطلاق search.example.com (خدمة البحث من درس أنماط الفشل). يريد الفريق نشر مراقبة تكتشف المشكلات قبل المستخدمين، مع مصفوفة قرار واضحة للتنبيه أو عدمه. SLO: 99.9% من الطلبات ناجحة، زمن الاستجابة p99 < 300 مللي ثانية، على مدى نافذة زمنية مدتها 28 يومًا.

إغلاق الدورة

إغلاق الدورة

لقد أكملت جميع الدروس الخمسة:

- الوكلاء والمصادر: الشكل الذي تتخذه طبقة الحافة والذي تستخدمه تقريبًا جميع خدمات الويب العامة

- التوسع الأفقي غير الحافظ للحالة: لماذا تضاعف الطبقة غير الحافظة للحالة بشكل رخيص وكيفية تحديد حجمها

- فصل الدخول والخروج: لماذا يتحول صندوق واحد إلى صندوقين، ووضع العطل الذي يفرض ذلك

- أوضاع العطل ونطاق التأثير: نقاط الفشل المفردة (SPOFs)، والتداعيات، والتدقيق اللاحق، وعناصر العمل الخالية من اللوم

- قابلية المراقبة والسعة (هذا الدرس): ما الذي يجب قياسه حتى تظهر المشكلات قبل أن يلاحظها المستخدمون

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

الدروس المصاحبة: خمسة دروس حول هندسة-* تعيد صياغة نفس المادة كنظرية الرسوم البيانية والهندسة. وهي مناسبة للتقديم بأي ترتيب.

أحسنت.