في معظم المشاريع، تُضاف المراقبة بعد أول حادثة مؤلمة: ساعات من التخمين في الظلام، ثم قرار متأخر بأن «نحتاج مراقبة أفضل». المقاربة الأصح — والأرخص بكثير — أن تُبنى قابلية الملاحظة (Observability) من اليوم الأول، كجزء من تعريف «مكتمل» لأي ميزة جديدة. في هذا المقال نشرح الأركان الثلاثة التي نؤسسها في «الشبكة» مع كل نظام نبنيه، ولماذا صارت أنظمة الذكاء الاصطناعي تجعل هذا التأسيس أكثر إلحاحًا من أي وقت.
مراقبة الرسوم ليست قابلية ملاحظة
الفرق جوهري: المراقبة التقليدية تجيب عن أسئلة قررتها مسبقًا — «كم استهلاك المعالج؟». قابلية الملاحظة تمكّنك من طرح أسئلة لم تخطر ببالك وقت البناء: «لماذا تفشل طلبات هذا العميل تحديدًا بعد الساعة الثامنة؟». الحوادث الحقيقية دائمًا من النوع الثاني — أسئلة جديدة لم يتوقعها أحد.
النظام القابل للملاحظة يجيب عن أسئلة لم تُطرح بعد — دون نشر كود جديد لجمع البيانات.
الركن الأول: سجلات منظمة لا نصوص حرة
السجل النصي «حدث خطأ في الدفع» يقرؤه إنسان واحد؛ السجل المنظم (JSON بحقول ثابتة) تستعلمه الآلة عبر ملايين الأسطر. من اليوم الأول نلتزم: كل سجل يحمل معرّف ارتباط (Correlation ID) يتبع الطلب عبر كل الخدمات، ومستوى خطورة صحيحًا، وحقولًا موحدة الأسماء عبر النظام كله.
القيمة تظهر في أول تحقيق: بدل البحث في ملفات متفرقة، استعلام واحد يعيد رحلة الطلب كاملة من البوابة إلى قاعدة البيانات.
الركن الثاني: مقاييس تهم المستخدم
استهلاك المعالج والذاكرة مفيد، لكنه لا يخبرك إن كان المستخدم يعاني. الإشارات الأربع الذهبية هي الأساس:
- زمن الاستجابة — وبالذات الشريحة المئوية 95 و99، لا المتوسط الذي يجمّل الصورة.
- معدل الحركة — طلبات في الثانية، لفهم السياق والذروات.
- معدل الأخطاء — نسبة الطلبات الفاشلة، مقسمة حسب النوع والمسار.
- التشبع — كم اقتربت الموارد من حدودها قبل أن تنهار.
هذه الأربعة لكل خدمة، مع لوحة واحدة تجمعها، تكشف 90% من المشاكل قبل أن يبلّغ عنها العملاء.
الركن الثالث: تتبع موزع يربط القصة
في نظام من خدمات متعددة، السجلات والمقاييس تخبرك أن شيئًا بطيء — التتبع الموزع (Tracing) يخبرك أين. كل طلب يحمل سياق تتبع ينتقل عبر الخدمات، فترى الرحلة شلالًا زمنيًا: أي خدمة استهلكت الوقت، وأي استدعاء تكرر بلا داعٍ. معيار OpenTelemetry جعل هذا متاحًا بجهد معقول ودون ارتباط بمزوّد واحد.
أنظمة الذكاء الاصطناعي ترفع الرهان
مع الوكلاء والنماذج اللغوية، لم يعد السؤال «أي خدمة بطيئة؟» بل «لماذا قرر الوكيل هذا القرار؟». لذلك نمدّ التتبع ليشمل كل تشغيل: التوجيهات المستخدمة وإصدارها، وكل استدعاء نموذج بمدخلاته ومخرجاته، وكل استدعاء أداة بنتيجته — مربوطة بمعرّف تشغيل واحد. بدون هذا الأثر، تصحيح سلوك وكيل في الإنتاج تخمين محض؛ ومعه، كل قرار قابل للتفسير والمراجعة.
نبّه على الأعراض، وحقق في الأسباب
التنبيهات الكثيرة أخطر من قلتها — الفريق يتعلم تجاهلها. القاعدة: نبّه فقط على ما يلمس المستخدم (معدل أخطاء يتجاوز الحد، بطء ملموس، توقف كامل)، واجعل كل تنبيه قابلًا للتصرف برابط مباشر إلى لوحة التحقيق أو دليل التشغيل. أعطال الأسباب الداخلية — امتلاء قرص، تراجع نسخة — تذهب للوحات المراجعة اليومية، لا لإيقاظ أحد فجرًا.
قائمة تحقق لليوم الأول
- هل سجلاتك منظمة بحقول موحدة ومعرّف ارتباط في كل طلب؟
- هل تقيس الإشارات الأربع الذهبية لكل خدمة، بالشرائح المئوية لا المتوسطات؟
- هل يمر التتبع الموزع عبر كل خدماتك بمعيار OpenTelemetry؟
- هل تسجل أنظمة الذكاء الاصطناعي عندك كل قرار باستدعاءاته ومخرجاته؟
- هل كل تنبيه يوقظ إنسانًا مرتبط بأثر ملموس على المستخدم وإجراء واضح؟
الخلاصة
قابلية الملاحظة استثمار يتضاعف عائده مع كل حادثة: ما كان سيستغرق ليلة من التخمين يصبح استعلامًا من دقائق. ابدأها من اليوم الأول — سجلات منظمة، ومقاييس ذهبية، وتتبع موزع، وأثر كامل لقرارات الذكاء الاصطناعي — وستكتشف أن أغلب الحوادث الكبيرة كانت إشارات صغيرة ظهرت مبكرًا ولم يرها أحد.
في «الشبكة» نبني قابلية الملاحظة في كل نظام نسلمه، من اليوم الأول لا بعد أول حادثة. إذا كان نظامك يعمل «صندوقًا أسود» وتريد أن ترى ما بداخله، تواصل معنا.