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