السجلّات
سجلّات منفصلة ومختومة بالوقت لأحداث فردية، وهي أدق الإشارات وأكثرها فائدة في إعادة بناء ما حدث بالضبط.
المراقبة والتحسين · الخطوة 06 · المرحلة الأخيرة · منهجية عملنا
البرمجيات الحية ليست برمجيات مكتملة.
لا يُفهَم النظام لكونه يعمل، بل يُفهَم لأنه يُلاحَظ ويُقاس ويُحسَّن باستمرار استنادًا إلى الأدلة. تُغلِق هذه المرحلة الأخيرة حلقة منهجية OpenQCore، إذ تتحول الأدلة التي تنتجها إلى نقطة انطلاق للسؤال التالي الجدير بالبحث.
ليس هذا السؤال
«هل النظام لا يزال يعمل؟»
بل هذا السؤال
«هل نفهم فعليًا كيف يتصرف هذا النظام تحت ظروف حقيقية عبر الزمن، وهل هذا الفهم يقود تحسينًا مستمرًا، أم يكتفي بتأكيد أن شيئًا لم يتعطل؟»
قابلية المراقبة · الاستجابة للحوادث · التحسين المستمر · الأدلة · التغذية الراجعة
لماذا تأتي المراقبة بعد النشر
الاستعداد التشغيلي نقطة بداية، لا حالة نهائية.
تؤكد مرحلة النشر والتمكين أن النظام يعمل بأمان، وأن المسؤولين عنه على استعداد. غير أنها لا تُنتج بعدُ فهمًا مستمرًا ومبنيًا على الأدلة لكيفية تصرف هذا النظام مع تراكم الاستخدام الفعلي والبيانات الحقيقية والظروف الواقعية عبر الزمن. وهذا الفهم هو غاية هذه المرحلة.
الاستعداد التشغيلي ← قابلية المراقبة المستمرة
لماذا انضباط المراقبة مهم
أربع إشارات تحدد ما إذا كان النظام سليمًا فعليًا.
يحدد كتاب Google، Site Reliability Engineering (2016) — وهو المرجع البحثي ذاته المُشار إليه في المرحلة السابقة — أربع إشارات تُعدّ كافية، إن روقبت جيدًا، لفهم صحة معظم الأنظمة، وتُعرَف بالإشارات الذهبية.
زمن الاستجابة
المدة اللازمة لخدمة طلب معين، مع التمييز بين الاستجابات الناجحة والفاشلة.
حركة المرور
حجم الطلب المفروض على النظام، مقيسًا بمقاييس ذات صلة بوظيفته.
الأخطاء
معدل الطلبات التي تفشل، سواء بشكل صريح أو من خلال نتائج غير صحيحة.
التشبّع
مدى قرب النظام من حدود موارده، والهامش المتبقي منها.
Beyer وJones وPetoff وMurphy (محررون)، Site Reliability Engineering (2016).
الركائز الثلاث لقابلية المراقبة
البيانات ليست مرادفة للفهم.
تبني OpenQCore قابلية المراقبة حول ثلاثة أنواع متكاملة من البيانات، وهو إطار واسع الاستخدام في المجال، تكوّن رسميًا في مشروع OpenTelemetry (معيار مفتوح تستضيفه مؤسسة CNCF) وفي كتاب Cindy Sridharan، Distributed Systems Observability (2018).
المقاييس
قياسات رقمية مجمَّعة عبر الزمن، فعّالة في اكتشاف الاتجاهات وإطلاق التنبيهات.
التتبعات
المسار الذي يسلكه طلب واحد عبر مكوّنات موزَّعة، وهي أساسية لفهم أين يستغرق الوقت وأين تحدث الأعطال في الأنظمة المعقدة.
من الإشارات إلى الفهم
البيانات الخام لا قيمة لها ما لم تُفسَّر.
السجلّات والمقاييس والتتبعات ليست في ذاتها بصيرة (insight)، بل تصبح مفيدة حين تُنظَّم في لوحات بيانات تكشف الأنماط، وتنبيهات تُبرز ما يستوجب الانتباه، وفهمًا في نهاية المطاف يمكن أن يوجّه قرارًا فعليًا.
التنبيه من غير إرهاق
التنبيه الذي لا يثق به أحد لا يقرؤه أحد.
نمط فشل موثَّق جيدًا لدى فرق التشغيل، يُعرَف غالبًا بـ«إرهاق التنبيهات»، يحدث حين يُبنى التنبيه على أي انحراف في رقم بدلًا من التأثير الفعلي على المستخدمين أو النظام. والنتيجة كمّ كبير من التنبيهات يُتجاهَل في النهاية، بما في ذلك المهم منها.
التنبيه المبني على الأعراض
تُطلَق التنبيهات استنادًا إلى تأثير ملحوظ يواجه المستخدم، لا لمجرد خروج مقياس داخلي عن نطاقه.
عتبات قابلة للتنفيذ
لا يوجد تنبيه إلا إذا كان هناك إجراء محدَّد وواضح ينبغي على أحد اتخاذه استجابةً له.
دورية مراجعة التنبيهات
تُراجَع قواعد التنبيه بانتظام، وتُلغى حين لا تعود تشير إلى حالة حقيقية قابلة للتنفيذ.
الاستجابة للحوادث والتحليل اللاحق غير التجريمي
فهم النظام، لا تحديد المسؤول.
عند وقوع حادثة، تتبع OpenQCore ممارسة موثَّقة للتحليل اللاحق غير التجريمي، وهو مفهوم تكوّن رسميًا في كتاب Google، Site Reliability Engineering (2016)، يركّز فيه التحليل على الظروف المنظومية التي سمحت بوقوع الفشل، لا على الفرد الذي صادف تورّطه فيه.
لهذه التفرقة أثر عملي: فالفرق التي تخشى التجريم تميل إلى التقصير في الإبلاغ وإخفاء الظروف التي تسببت في الفشل، ما يزيد احتمال تكرار الفشل نفسه. وتُصمَّم العملية غير التجريمية لإظهار تلك الظروف بصدق، لأن ذلك تحديدًا هو السبيل إلى إصلاحها.
حلقة التغذية الراجعة المستمرة
المراقبة لا تُنهي المنهجية، بل تُعيد تشغيلها.
الإشارات المُجمَّعة أثناء المراقبة — اتجاهات الأداء، والحوادث المتكررة، وانحراف أداء النماذج، وأنماط الاستخدام غير المتوقعة — لا تُقدَّم وتُؤرشَف فحسب، بل تتحول إلى أدلة قد تبرر إعادة النظر في تعريف مشكلة ما، أو التشكيك في افتراض معماري، أو تحديد مشكلة جديدة تمامًا جديرة بالبحث.
وهذا ما يُغلِق منهجية OpenQCore ذات المراحل الست في دورة مستمرة لا في خط مستقيم: فالأدلة المُنتَجة في مرحلة المراقبة والتحسين تعود إلى مرحلة البحث والاكتشاف، حيث تبدأ العملية من جديد على أساس أقوى مما كان عليه في السابق.
تحسين الأداء مقابل خط الأساس
يُقاس التحسّن مقابل خط الأساس ذاته الذي حدد النجاح.
يُقيَّم عمل التحسين مقابل خط الأساس ومعايير النجاح التي أُرسيت أثناء مرحلة البحث والاكتشاف، لا مقابل انطباع عام بأن النظام أصبح أفضل.
المقارنة مع خط الأساس
يُقاس الأداء الحالي مباشرة مقابل خط الأساس المُسجَّل قبل وجود النظام بشكله الحالي.
كشف الانتكاسات
تُحدَّد التغييرات التي تُضعف مقياسًا كان مستقرًا سابقًا ويُحقَّق فيها، لا أن تُستوعَب باعتبارها وضعًا طبيعيًا جديدًا.
تحليل اتجاهات السعة
تُتابَع اتجاهات استهلاك الموارد لاستباق احتياجات التوسع قبل أن تتحول إلى حادثة.
المراقبة الخاصة بالنماذج والذكاء الاصطناعي
أنظمة الذكاء الاصطناعي تتطلب أدلة لا تلتقطها المراقبة التقليدية.
اتساقًا مع تحليل المخاطر السياقي المُقدَّم أثناء البحث والاكتشاف، تُراقَب المكونات الخاصة بالذكاء الاصطناعي بحثًا عن إشارات لا تُظهرها مراقبة التطبيقات التقليدية من تلقاء نفسها.
كشف انحراف النموذج
قياس مستمر لما إذا كان أداء النموذج يتراجع مع ابتعاد بيانات الواقع عمّا بُني النموذج وقُيِّم عليه.
معدل التجاوز البشري
عدد المرات التي يتجاوز فيها مراجع بشري توصية أو قرارًا صادرًا عن الذكاء الاصطناعي، وهو مؤشر مباشر على أين تكون الثقة في النظام مبررة وأين لا تكون.
إعادة معايرة التقييم
إعادة تقييم دورية استنادًا إلى أدلة محدَّثة، بدلًا من الاعتماد إلى أجل غير مسمى على التقييم المُنجَز قبل النشر.
بوابة مراجعة التحسين
المراقبة تنتهي بقرار، لا بلوحة بيانات فحسب.
تُراجَع الأدلة المُجمَّعة أثناء المراقبة دوريًا مقابل بوابة قرار محدَّدة.
متابعة المراقبة
يعمل النظام ضمن المعايير المتوقعة، وتستمر الملاحظة من غير تغيير في المسار.
التحسين
تحسين محدَّد ومحدود تبرره الأدلة، ويمكن السعي إليه من غير الحاجة إلى مراجعة تعريف المشكلة الأساسي.
العودة إلى الاكتشاف
تشير الأدلة إلى مشكلة أوسع من مجرد تحسين، والاستجابة الصحيحة هي العودة إلى البحث والاكتشاف بما تم تعلّمه.
الإيقاف التدريجي
تشير الأدلة إلى أن النظام لم يعد يبرر تكلفة تشغيله مقارنةً بالقيمة التي يقدمها.
مخرجات هذه المرحلة
أدلة مستمرة، لا تقرير لمرة واحدة.
بحسب نطاق المشروع، تُنتج هذه المرحلة:
لوحة قابلية المراقبة
تمثيل بصري حي للسجلّات والمقاييس والتتبعات ذات الصلة بصحة النظام والإشارات الذهبية.
دليل الاستجابة للحوادث
إجراءات موثَّقة للاستجابة للحوادث التشغيلية وحلّها.
سجلّات التحليل اللاحق
تحليل غير تجريمي للحوادث وأسبابها المنظومية والتغييرات التي أُجريت استجابةً لها.
تقرير اتجاهات الأداء
الأداء مقيسًا عبر الزمن مقابل خط الأساس ومعايير النجاح الأصلية.
تقرير انحراف النموذج
تتبع أداء النموذج مقابل بيانات الواقع وأنماط الاستخدام المتطورة.
قائمة فرص التحسين
فرص تحسين تبررها الأدلة، مرتَّبة حسب الأولوية للعمل المستقبلي.
المنهجية تُغلِق الحلقة
الأدلة تتحول إلى السؤال التالي.
مراحل OpenQCore الست — البحث والاكتشاف، والاستراتيجية والبنية، وتصميم الحل، والتطوير والتكامل، والنشر والتمكين، والمراقبة والتحسين — لا تشكّل خطًا مستقيمًا ينتهي هنا. فالأدلة التي تنتجها هذه المرحلة تصبح نقطة انطلاق للمشكلة التالية الجديرة بالبحث، سواء أكان ذلك بتحسين النظام القائم أو بتحديد نظام جديد تمامًا.
المراقبة والتحسين ← الأدلة ← البحث والاكتشاف
الخطوة 01
البحث والاكتشاف
حيث تبدأ المنهجية، وحيث تعود أدلتها في نهاية المطاف.
مراجع البحث والمنهجية
Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (محررون) — Site Reliability Engineering: How Google Runs Production Systems (2016)
مصدر مفهومَي الإشارات الذهبية والتحليل اللاحق غير التجريمي المُشار إليهما أعلاه.
Sridharan, C. — Distributed Systems Observability (2018)؛ مشروع OpenTelemetry (CNCF)
مصدر إطار الركائز الثلاث لقابلية المراقبة المُشار إليه أعلاه.
NIST — إطار إدارة مخاطر الذكاء الاصطناعي (AI RMF 1.0)
مصدر منهج المخاطر السياقي المُشار إليه في قسم المراقبة الخاصة بالذكاء الاصطناعي أعلاه.