المراقبة مقابل قابلية الملاحظة
المراقبة مقابل قابلية الملاحظة
أمضيت دروساً سابقة في بناء أنظمة تعمل: خدمات في حاويات على Kubernetes، وبنية تحتية تُجهّزها Terraform، وخطوط أنابيب ترقّي الكود من الـ commit إلى الإنتاج. الآن يأتي السؤال الذي يواجهه كل مهندس متمرس في نهاية المطاف: كيف تعرف فعلاً ما تفعله تلك الأنظمة — ليس الآن فحسب، بل حين يسوء أمر في الساعة الثانية صباحاً بطريقة لم ترَها من قبل؟
هذا التمييز يقود كل شيء في هذا الدرس. المراقبة وقابلية الملاحظة فكرتان مترابطتان لكنهما مختلفتان جوهرياً، والخلط بينهما أحد أكثر الأخطاء تكلفة في الأنظمة الكبيرة النطاق.
المراقبة: المجاهيل المعروفة
المراقبة هي ممارسة جمع مجموعة محددة سلفاً من الإشارات التي تؤمن بأهميتها والتنبيه عليها. تقرر مسبقاً: "أهتم باستخدام CPU، ومعدل أخطاء HTTP 5xx، وعمق قائمة الانتظار، وزمن الاستجابة عند الـ p99." تضع حدوداً عليا. حين يُتجاوز حد، تُنبَّه.
المراقبة تجيب على أسئلة تعرف بالفعل أنك ستطرحها. النموذج الذهني هو قائمة تحقق: هل الـ CPU بخير؟ هل معدل الأخطاء بخير؟ هل القرص بخير؟ إن اجتازت كل العناصر، تُعلن النظام صحيحاً. إن فشل عنصر، تعرف أي لوحة قيادة تفتح.
المراقبة ممتازة في اكتشاف أوضاع الفشل المعروفة — الأعطال التي رأيتها من قبل، التي توقعتها حين صممت النظام. مجموعة اتصالات قاعدة البيانات استُنفدت، أو تسرب ذاكرة يظهر كارتفاع مطّرد في RSS، أو خدمة خارجية تنتهي مهلتها وتسبب ارتفاعاً في زمن الاستجابة. هذه هي مجاهيلك المعروفة: لا تعرف متى ستحدث، لكنك تعرف أنها يمكن أن تحدث، لذا أضفت قياساً عليها.
فجوة قابلية الملاحظة: المجاهيل المجهولة
إليك الحقيقة الصعبة: في نظام موزع بالغ التعقيد، الأعطال التي تؤذيك فعلاً هي التي لم تتوقعها. مجموعة نادرة من معاملات الإدخال تكشف مساراً في الكود لم يُختبر قط في اختبارات الحمل. تقسيم شبكي بين منطقتَي توافر محددتين لا يحدث إلا تحت نمط مرور بعينه. واجهة برمجية خارجية تبدأ في إعادة بيانات قديمة بصمت، مما يُدهور محرك التوصيات دون أي ارتفاع في معدل الأخطاء. هذه هي المجاهيل المجهولة — لم تعرف بوجود وضع الفشل، لذا لم تضع له قياساً، ومراقبتك لا تخبرك بشيء مفيد.
قابلية الملاحظة هي خاصية النظام التي تتيح لك فهم حالته الداخلية بفحص مخرجاته الخارجية — دون الحاجة إلى معرفة الأسئلة التي ستطرحها مسبقاً. يأتي المصطلح من نظرية التحكم: النظام "قابل للملاحظة" إذا استطعت تحديد حالته الداخلية من مخرجاته وحدها. مطبقاً على هندسة البرمجيات، يعني أن نظامك يُصدر بيانات كافية — مقاييس وسجلات وتتبعات — حتى تتمكن من الاستدلال العكسي من عرض غير متوقع إلى سببه الجذري، حتى لأوضاع فشل لم ترها من قبل.
الفرق الحاسم: مع المراقبة تتلقى تنبيهاً ثم تنظر إلى لوحات القيادة المحددة مسبقاً. مع قابلية الملاحظة تتلقى تنبيهاً ثم تطرح أسئلة جديدة على بيانات القياس لتستكشف ما يحدث فعلاً. تقطّع البيانات بمعرف المستخدم، بالمنطقة، بالإصدار، بمسار الطلب — أياً كان ما يقودك إليه البيانات — حتى تضيّق سلسلة السببية.
مثال إنتاجي ملموس
تخيل خدمة الدفع في شركة تجارة إلكترونية. مراقبتك تقول: معدل الأخطاء 0.05%، زمن p99 هو 340ms، الـ CPU عند 42%. كل شيء أخضر. لكن الإيرادات انخفضت 18% خلال الساعات الست الماضية. هذه فجوة قابلية ملاحظة كلاسيكية — لم يتجاوز أي مقياس مُراقَب حداً، ومع ذلك النظام معطوب بشدة.
مع نظام ذي قابلية ملاحظة كاملة يمكنك أن تسأل: أي شريحة من المستخدمين تفشل؟ قطّع البيانات بالدولة — البرازيل تُظهر معدل إتمام الدفع 11% مقابل المعتاد 89%. انغمس في التتبعات للطلبات البرازيلية — استدعاء بوابة الدفع لديه مهلة 28 ثانية يُبتلع بصمت بـ try/catch يُعيد نجاحاً مزيفاً. الاستثناء مُسجَّل لكن لم يبنِ أحد مُراقَبةً على عدد الأخطاء لذلك المزود المحدد.
وجدت هذا في دقائق لأن البيانات كانت موجودة ويمكنك استعلامها بحرية. بدون تلك البيانات، كنت ستقضي ساعات تتطلع إلى لوحات القيادة الخضراء متساءلاً عن سبب انخفاض الإيرادات.
لماذا يهم هذا التمييز الآن
في تطبيق أحادي مع عشرة خوادم، كانت المراقبة كافية. كان عدد المكونات محدوداً، وأوضاع الفشل مفهومة جيداً، والمهندسون يعرفون كل مسار في الكود. في نظام خدمات مصغرة على Kubernetes مع 200 خدمة وآلاف الـ pods ومئات النشرات يومياً، عدد حالات الفشل الممكنة هائل فلكياً. المراقبة وحدها لا تستطيع مواكبة ذلك.
اتجاهان جعلا هذا غير اختياري على نطاق الإنتاج:
- انفجار القيم الكاردينالية: الأنظمة الحديثة تُصدر بيانات كاردينالية عالية — معرفات الطلبات، معرفات المستخدمين، معرفات التتبع، أعلام الميزات، متغيرات التجارب. أدوات مراقبة السلاسل الزمنية التقليدية (Nagios، Prometheus المبكر) لم تُصمَّم للاستعلام عبر هذه الأبعاد بحرية. الـ backends المصممة لقابلية الملاحظة صُممت لذلك.
- تحول ملكية الإنتاج إلى اليسار: مع انتشار "أنت تبنيه، أنت تُشغّله"، يمتلك مهندسو المنتج مناوبتهم الخاصة. هم ليسوا خبراء في كل وضع فشل — يحتاجون أدوات تتيح لهم الاستكشاف الحر، لا مجرد التحقق من لوحات بناها شخص آخر منذ أشهر.
الركائز الثلاث (لمحة مسبقة)
تُنفَّذ قابلية الملاحظة عادةً من خلال ثلاثة أنواع متكاملة من الإشارات، يغطيها الدرس التالي بعمق:
- المقاييس — قياسات رقمية مجمّعة عبر الزمن (معدل الطلبات، عدد الأخطاء، مئينيات زمن الاستجابة). فعّالة التخزين، ممتازة للتنبيه، كاردينالية محدودة.
- السجلات — سجلات أحداث منظَّمة تُصدَر أثناء التشغيل. تفاصيل عالية، حقول اعتباطية، مكلفة على نطاق واسع دون إدارة دقيقة.
- التتبعات — سجلات رحلة طلب واحد عبر خدمات متعددة. ضرورية لإسناد زمن الاستجابة ورسم خرائط الاعتماديات في الأنظمة الموزعة.
لا يكفي أي منها وحده. الممارسة الناضجة لقابلية الملاحظة تستخدم الثلاثة وتُوفّق بينها — تتلقى تنبيهاً من مقياس، تقفز إلى التتبعات ذات الصلة، وتفحص سطور السجل من الامتدادات التي تبدو شاذة. الأدوات التي تجعل هذا الترابط سلساً (Honeycomb، Grafana + Tempo + Loki، Datadog APM) هي ما يُفرّق بين بنية قابلية ملاحظة إنتاجية ومجموعة لوحات قيادة.
تحويل النموذج الذهني
الخلاصة العملية هي تحول في طريقة تفكيرك في أنظمتك وعلاقتك بأوضاع فشلها. المراقبة تسأل: هل هذا المكون ضمن المعاملات المتوقعة؟ قابلية الملاحظة تسأل: ما الذي يفعله هذا النظام فعلاً، ولماذا؟ المراقبة مجموعة تأكيدات. قابلية الملاحظة قدرة للاستفسار.
البناء نحو الأخيرة يتطلب اتخاذ قرارات متعمدة في كل طبقة من بنيتك — كيف تُصدر تطبيقاتك البيانات، وكيف تُزوَّد بنيتك التحتية بالقياسات، وما الأدوات التي تستخدمها لتخزين بيانات القياس والاستعلام عنها، وكيف يُطور فريقك ممارسة التصحيح الاستكشافي على البيانات الحية. تبني الدروس التسعة الأخرى في هذا الدرس التعليمي كل تلك الطبقات بشكل منهجي.