من مدوّنة الهندسة.
كيف نفكّر في الأنظمة الذكية والموثوقية وشحن برمجيات تدوم.
تصميم وكلاء يفشلون بأمان
العرض التوضيحي سهل، والثقة صعبة. وكيل الذكاء الاصطناعي الذي يستطيع استدعاء أدواتك يستطيع استدعاءها بشكل خاطئ أيضًا. السؤال الحقيقي عند بناء وكلاء الذكاء الاصطناعي ليس «هل سيرتكب الوكيل خطأً؟» — فالإجابة دائمًا نعم — بل: هل هذا الخطأ محتوى، ومرئي، وقابل للتراجع؟ هذا بالضبط ما يعنيه «الفشل بأمان»، وهو مشكلة تصميم معماري قبل أن يكون مشكلة نموذج لغوي. في هذا المقال نشارك المبادئ التي نطبّقها في «الشبكة» عند تصميم وكلاء ذكاء اصطناعي جاهزين للإنتاج، لا للعروض التوضيحية فقط.لماذا ينجح العرض التوضيحي ويفشل الإنتاج؟في العرض التوضيحي، يتحكم الفريق في كل شيء: المدخلات نظيفة، والسيناريو محفوظ، والجمهور متسامح. في الإنتاج، يقابل الوكيل مدخلات لم يرها أحد من قبل، وأنظمة تتغير دون إشعار، ومستخدمين يجرّبون حدود النظام — أحيانًا بنيّة حسنة وأحيانًا لا. الفجوة بين البيئتين هي المكان الذي تولد فيه الحوادث.الفرق الناجحة لا تحاول بناء وكيل «لا يخطئ أبدًا»، لأن هذا هدف مستحيل مع النماذج الاحتمالية. بدلًا من ذلك، تبني بنية تحتية تجعل كلفة الخطأ الواحد صغيرة ومحصورة. هذا التحوّل في طريقة التفكير — من منع الفشل إلى احتوائه — هو أساس كل ما يلي.ابدأ من الصلاحيات، لا من التوجيهاتمعظم إخفاقات الوكلاء التي نراها في المشاريع الحقيقية تعود إلى سبب واحد: وصول أوسع من اللازم. من السهل أن تمنح الوكيل مفتاح API كاملًا وتكتب في التوجيهات «لا تحذف أي بيانات» — لكن التوجيه ليس ضمانة، بل رجاء. النموذج قد يُساء توجيهه عبر حقن الأوامر، أو يخطئ في فهم السياق، أو ببساطة يهلوس.القاعدة التي نلتزم بها: قيّد كل وكيل بأصغر مجموعة أدوات وبيانات يحتاجها لأداء مهمته، معبَّرًا عنها بصلاحيات صريحة على مستوى النظام — نطاقات OAuth محدودة، ومفاتيح مقيدة، وأدوار قاعدة بيانات للقراءة فقط حيث يكفي ذلك.يجب ألّا يقدر الوكيل على فعل شيء لم يسمح به نموذج صلاحياتك أصلًا — بغضّ النظر عمّا يقوله التوجيه.ميزة هذا النهج أنه قابل للتدقيق: يمكنك أن تعرف بدقة ماذا يستطيع الوكيل أن يفعل في أسوأ الحالات، بقراءة الصلاحيات لا بتخمين سلوك النموذج.صمّم لنطاق الأثر: ضع البشر عند الحواف الخطرةلا تحتاج كل خطوة إلى موافقة بشرية — فوكيل يطلب إذنًا لكل قراءة يفقد جدواه، ويتعلم المستخدمون الضغط على «موافق» دون تفكير، وهو أخطر من غياب الموافقة أصلًا. الحل هو تصنيف الإجراءات حسب نطاق الأثر:إجراءات منخفضة الأثر — قراءة بيانات، صياغة مسودة، اقتراح خطة: تعمل ذاتيًا دون توقف.إجراءات متوسطة الأثر — إرسال بريد داخلي، تعديل سجل واحد: تُنفَّذ مع إشعار فوري وإمكانية تراجع.إجراءات عالية الأثر — حذف بيانات، تحويل أموال، مراسلة عملاء: تتوقف إلزاميًا لموافقة بشرية صريحة.بهذا التصنيف تحصل على وكيل سريع في 90% من عمله، وحذر في الـ10% التي تستحق الحذر. والأهم: حين يخطئ النموذج في تقدير خطورة إجراء، تكون الشبكة الأمنية في طبقة التصنيف نفسها، لا في حسن نية النموذج.اجعل كل قرار قابلًا للتتبّعحين يحدث خطأ في الإنتاج، «النموذج قرّر ذلك» ليست إجابة تُقنع عميلًا أو مدققًا. كل تشغيل وكيل يجب أن يُصدر أثرًا كاملًا قابلًا للمراجعة: المدخلات الأصلية، والخطة التي وضعها الوكيل، وكل استدعاء أداة بمعامِلاته ونتيجته، والمخرج النهائي — مربوطة جميعًا بمعرّف تشغيل واحد.هذا السجل ليس رفاهية تشغيلية؛ إنه ما يحوّل الحادثة من لغز إلى درس. بدونه تعرف أن شيئًا خاطئًا حدث، لكنك لا تعرف لماذا، ولا تستطيع منع تكراره. ومع الجهات التنظيمية في القطاعات الحساسة، يصبح سجل التدقيق شرط دخول لا ميزة إضافية.اجعل التراجع خطة أولى، لا خطة طوارئالإجراء القابل للتراجع يمكن تفويضه للوكيل بثقة أكبر بكثير من الإجراء النهائي. لذلك نعيد تصميم الأدوات نفسها قبل أن نمنحها للوكيل: الحذف يصبح أرشفة قابلة للاستعادة، والإرسال يصبح جدولة مع مهلة إلغاء، والتعديل يحتفظ بنسخة سابقة. كلما اتسعت مساحة «القابل للتراجع» في نظامك، اتسعت مساحة ما يمكن أتمتته بأمان — دون رفع سقف المخاطرة.قيّم قبل الإطلاق، وراقب بعدهالاختبار اليدوي لا يكفي مع نظام غير حتمي. قبل الإطلاق، نبني لكل وكيل مجموعة تقييم (Evals) من حالات حقيقية مأخوذة من طبيعة العمل، وحالات عدائية مصممة لكسره: مدخلات ملتبسة، ومحاولات حقن أوامر، وحالات حافّة نادرة. أي تعديل على التوجيهات أو النموذج يمرّ على هذه المجموعة قبل النشر.وبعد الإطلاق، تستمر المراقبة على عيّنات من الحركة الحقيقية: نسب نجاح المهام، ومعدلات التوقف للموافقة، والأنماط الشاذة في استدعاء الأدوات. النموذج الذي عمل جيدًا الشهر الماضي قد يتغير سلوكه مع تحديث جديد — والمراقبة المستمرة هي ما يكشف ذلك قبل عملائك.قائمة تحقق قبل إطلاق أي وكيلهل يملك الوكيل أضيق صلاحيات ممكنة لأداء مهمته؟هل الإجراءات مصنّفة حسب نطاق الأثر، مع موافقة بشرية إلزامية للحساس منها؟هل كل تشغيل يُنتج سجل تدقيق كاملًا يمكن الرجوع إليه؟هل الإجراءات الخطرة قابلة للتراجع، أو مؤجلة بمهلة إلغاء؟هل توجد مجموعة تقييم تُشغَّل قبل كل تغيير، ومراقبة مستمرة بعد النشر؟الخلاصةالوكيل الجدير بالثقة ليس الوكيل الذي لا يخطئ، بل الوكيل الذي حين يخطئ يكون خطؤه محصورًا بالصلاحيات، مرئيًا في السجلات، وقابلًا للتراجع بالتصميم. هذه ليست قيودًا على قدرة الوكيل — بل هي بالضبط ما يسمح لك بتوسيع صلاحياته لاحقًا بثقة، خطوة بعد خطوة.في «الشبكة» نبني وكلاء الذكاء الاصطناعي بهذه المبادئ منذ اليوم الأول: صلاحيات دنيا، وموافقات عند الحواف الخطرة، وسجلات تدقيق كاملة، وتقييم مستمر. إذا كنت تخطط لإدخال الوكلاء إلى أنظمة عملك، تواصل معنا — نساعدك على البدء بأمان دون التضحية بالسرعة.
كيف نحافظ على 99.98% عبر المناطق
99.98% ليست شعارًا تسويقيًا — إنها أقل من ساعتي توقف في السنة كاملة. الوصول إلى هذا الرقم في توافرية الأنظمة لا يتحقق بشراء خوادم أكبر، بل بقرارات معمارية تفترض أن كل مكوّن سيفشل يومًا ما: الخادم، وقاعدة البيانات، والشبكة، وحتى المنطقة السحابية بأكملها. في هذا المقال نشرح المنهجية العملية التي نتبعها في «الشبكة» للحفاظ على توافرية عالية عبر مناطق متعددة، من اتفاقيات مستوى الخدمة الصادقة إلى اختبار الفشل المتعمد.ابدأ بميزانية الخطأ، لا بالوعدأول خطوة نحو توافرية حقيقية هي رقم صادق. اتفاقية مستوى الخدمة (SLA) التي تعد بـ100% كذبة مؤدبة؛ والفرق الناضجة تحدد هدف مستوى خدمة (SLO) قابلًا للقياس، وتشتق منه ميزانية خطأ: عدد الدقائق المسموح فيها بالتدهور قبل أن يتوقف إطلاق الميزات الجديدة لصالح تحسين الاستقرار.ميزانية الخطأ تحوّل الموثوقية من نقاش عاطفي إلى قرار هندسي: إذا استهلكنا الميزانية مبكرًا، تتجمد المخاطرة تلقائيًا. وإذا بقيت الميزانية سليمة، نملك مساحة آمنة للتجريب والنشر السريع.المنطقة الواحدة نقطة فشل — مهما كبرتيمكن لأفضل بنية داخل منطقة سحابية واحدة أن تختفي كاملة بسبب عطل في مزوّد الخدمة، أو خطأ في التوجيه، أو حادثة على مستوى مركز البيانات. لهذا نصمم من اليوم الأول على أساس منطقتين على الأقل: منطقة أساسية تخدم الحركة، ومنطقة ثانوية جاهزة للاستلام.السؤال ليس «هل ستفشل المنطقة؟» بل «كم دقيقة نحتاج لنقل الحركة عنها عندما تفشل؟»التبديل الفعّال يحتاج ثلاثة عناصر تعمل معًا: توجيه DNS بمهلة قصيرة (TTL منخفض) أو موازن حمل عالمي، ونسخة حديثة من البيانات في المنطقة الثانوية، وأتمتة تنقل الحركة دون انتظار قرار بشري في الثالثة فجرًا.البيانات هي الجزء الصعبنقل حركة الويب بين المناطق سهل نسبيًا؛ الصعب هو البيانات. لكل نظام نحدد رقمين بوضوح: RPO (كم ثانية من البيانات نقبل خسارتها في أسوأ الحالات) وRTO (كم دقيقة نحتاج للعودة للعمل). هذان الرقمان يحددان نمط النسخ المناسب:نسخ متزامن — صفر فقدان بيانات، لكنه يضيف زمن استجابة ويحدّ المسافة بين المناطق.نسخ شبه متزامن — توازن عملي: تأخير ثوانٍ قليلة مقابل أداء طبيعي.نسخ غير متزامن + نسخ احتياطية مستمرة — للأنظمة التي تتحمل فقدان دقائق قليلة.المهم أن يكون الاختيار قرارًا واعيًا لكل نظام على حدة، لا افتراضًا واحدًا يفرض نفسه على كل شيء.فحوصات صحية تقول الحقيقةكثير من الأنظمة «الخضراء» في لوحة المراقبة تكون معطلة فعليًا، لأن الفحص الصحي يختبر أن العملية حية فقط، لا أنها تخدم المستخدمين. الفحص الصادق يمر عبر المسار الحقيقي: يستعلم قاعدة البيانات، ويلمس التخزين المؤقت، ويتحقق من التبعيات الخارجية الحرجة — ثم يقرر. وعلى أساسه يقرر موازن الحمل إخراج الخادم أو المنطقة من الخدمة تلقائيًا.اختبر الفشل قبل أن يختبركخطة التبديل التي لم تُختبر ليست خطة — إنها أمنية. نجدول تمارين دورية نطفئ فيها المنطقة الأساسية عمدًا في بيئة الإنتاج أو ما يطابقها، ونقيس بالدقائق: متى اكتشف النظام الفشل؟ متى انتقلت الحركة؟ هل فُقدت بيانات؟ كل تمرين يكشف افتراضًا خاطئًا كان سيظهر في حادثة حقيقية أمام العملاء.النتيجة الجانبية الأهم: الفريق يتدرب على الإجراء حتى يصبح روتينًا مملًا — وهذا بالضبط ما تريده في الطوارئ الحقيقية.الحوادث ستقع — جهّز السيناريو لا البطولةحتى مع كل ما سبق، ستقع حوادث. الفارق بين توقف 5 دقائق وتوقف 5 ساعات هو الجاهزية التشغيلية: دليل تشغيل (Runbook) واضح لكل سيناريو، وتنبيهات تصل للشخص الصحيح من أول مرة، وقناة تواصل معلنة للعملاء، ومراجعة ما بعد الحادثة بلا لوم تنتج إصلاحات جذرية لا ترقيعات.قائمة تحقق للتوافرية العاليةهل لديك SLO مكتوب وميزانية خطأ تُراجع شهريًا؟هل تعمل خدمتك من منطقتين على الأقل، وتم اختبار التبديل خلال آخر ربع سنة؟هل حددت RPO وRTO لكل نظام بيانات — والنسخ الفعلي يحققهما؟هل فحوصاتك الصحية تختبر المسار الحقيقي لا مجرد حياة العملية؟هل لديك Runbook محدث لكل سيناريو فشل رئيسي؟الخلاصةالتوافرية العالية ليست منتجًا يُشترى بل عادات تُبنى: أهداف صادقة تقود القرارات، ومنطقة ثانية جاهزة دائمًا، وبيانات منسوخة بوعي، وفحوصات تقول الحقيقة، وفشل يُختبر بالجدول قبل أن يفرض نفسه بلا موعد. بهذه العادات يصبح رقم مثل 99.98% نتيجة طبيعية لا معجزة.في «الشبكة» نصمم البنى السحابية عالية التوافرية ونشغّلها لعملائنا عبر مناطق متعددة. إذا كان نظامك لا يحتمل التوقف، تواصل معنا — نساعدك تبني موثوقية تُقاس بالأرقام لا بالوعود.
الرموز كعقد بين الفرق
في كل مشروع رقمي يتكرر المشهد نفسه: المصمم يختار درجة لون في أداة التصميم، والمطور يكتب قيمة قريبة منها في الكود، وبعد ستة أشهر يصبح في المنتج أحد عشر «أزرق» مختلفًا ولا أحد يعرف أيها الصحيح. رموز التصميم (Design Tokens) هي الحل الجذري لهذه الفوضى — وهي أرخص وسيلة نعرفها للبقاء متّسقًا مع نمو المنتج والفريق. في هذا المقال نشرح كيف نتعامل معها في «الشبكة» بوصفها عقدًا ملزمًا بين التصميم والتطوير، لا مجرد ملف ألوان.ما هي رموز التصميم؟الرمز هو قيمة تصميمية مسماة: بدل أن تكتب #237F8C في عشرين مكانًا، تعرّف color-brand-primary مرة واحدة وتشير إليه في كل مكان. ينطبق الأمر نفسه على المسافات، وأحجام الخطوط، وأنصاف الأقطار، والظلال، ومدد الحركة. القيمة تسكن في مكان واحد، والاسم يحمل المعنى.القوة الحقيقية ليست في التسمية بل في النتيجة: حين يتغير اللون الأساسي للعلامة، يتغير في مصدر واحد وينعكس تلقائيًا على الويب والتطبيق والبريد التسويقي — بدل أسابيع من المطاردة اليدوية.الرمز عقد، والعقد له طرفانالخطأ الشائع هو معاملة الرموز كملف إعدادات يخص المطورين. الرموز الناجحة عقد بين التصميم والهندسة: المصمم يلتزم بأن كل قرار بصري يمر عبر رمز مسمى، والمطور يلتزم بألا تدخل قيمة خام واحدة إلى الكود.أي قيمة بصرية لا تملك اسمًا متفقًا عليه هي دين تقني بصري — ستدفع ثمنه عند أول إعادة تصميم.بهذا العقد يصبح نقاش «هل هذا هو الرمادي الصحيح؟» نقاشًا في مكان واحد، ويتحول مراجع الكود من مقارنة أرقام سداسية إلى قراءة نوايا واضحة.ثلاث طبقات تمنع الفوضىالرموز المسطحة تنهار مع أول وضع ليلي أو علامة فرعية. البنية التي نعتمدها ثلاث طبقات:رموز أساسية — لوحة القيم الخام: teal-600، space-4، font-size-16. لا تُستخدم في الواجهات مباشرة.رموز دلالية — المعنى الوظيفي: color-text-primary، surface-raised، border-focus. تشير إلى الطبقة الأساسية.رموز المكوّنات — عند الحاجة فقط: button-bg يشير إلى رمز دلالي.الوضع الليلي بهذه البنية ليس ملف CSS جديدًا، بل إعادة ربط الطبقة الدلالية بقيم أساسية أخرى. والعلامة الفرعية الجديدة لوحة أساسية جديدة تحت الأسماء الدلالية نفسها.مصدر واحد للحقيقة — والباقي توليدالعقد ينهار إذا كان له نسختان. نخزن الرموز في مصدر واحد (ملفات JSON في المستودع عادة، أو أداة مثل Tokens Studio متصلة به)، ونولّد منه كل الصيغ آليًا: متغيرات CSS للويب، وقيم أدوات التصميم، وثوابت المنصات الأصلية. أدوات مثل Style Dictionary تجعل هذا التوليد خطوة بناء عادية.القاعدة الذهبية: التعديل يحدث في المصدر فقط. تعديل يدوي في أي صيغة مولّدة هو كسر للعقد وسيُمحى مع أول توليد قادم.حوكمة التغيير: الرموز لها إصداراتتغيير قيمة رمز يلمس كل شاشة في المنتج، لذا يستحق انضباط الإصدارات: تغيير قيمة فقط هو تحديث بسيط؛ إعادة تسمية أو حذف رمز تغيير كاسر يحتاج فترة انتقال ومسارًا واضحًا للترحيل. مراجعة تغييرات الرموز تكون مشتركة — مصمم ومطور معًا — لأن العقد لا يعدّله طرف واحد.قائمة تحقق لبدء العمل بالرموزهل لديك جرد للقيم البصرية المكررة في منتجك الحالي (الألوان أولًا)؟هل الرموز مقسمة إلى طبقات أساسية ودلالية — والواجهات تستهلك الدلالية فقط؟هل يوجد مصدر واحد تُولَّد منه كل الصيغ آليًا في خطوة البناء؟هل يمنع فحص آلي في CI دخول قيم خام جديدة إلى الكود؟هل تغييرات الرموز تمر بمراجعة مشتركة بين التصميم والهندسة؟الخلاصةرموز التصميم ليست ترفًا لفرق التصميم الكبيرة؛ إنها أرخص تأمين ضد تآكل الاتساق الذي يصيب كل منتج ينمو. عقد واضح، وثلاث طبقات، ومصدر واحد للحقيقة، وحوكمة بسيطة — هذا كل ما تحتاجه لتظل هوية منتجك متماسكة عبر كل منصة وكل فريق وكل إعادة تصميم قادمة.في «الشبكة» نبني أنظمة التصميم ونؤسس بنية الرموز للمنتجات العربية والإنجليزية على حد سواء — بما فيها تحديات الاتجاهين RTL وLTR. إذا كان منتجك يعاني من فوضى بصرية متراكمة، تواصل معنا ونساعدك تبني نظامًا يوقفها من الجذر.
اختيار معمارية محايدة للنماذج
كل بضعة أشهر يظهر نموذج ذكاء اصطناعي جديد يتفوق على سابقه في القدرة أو السعر أو كليهما. المنتج الذي كتب استدعاءات مزوّد واحد في كل أنحاء الكود يجد نفسه أمام خيارين مؤلمين: إعادة كتابة واسعة، أو البقاء على نموذج متقادم يدفع ثمنه أداءً وتكلفة. المعمارية المحايدة للنماذج (Model-Agnostic) تحل هذه المعضلة من الأساس: تبني منتجك مرة واحدة، وتبدّل النماذج تحته بحرّية. في هذا المقال نشرح كيف نصمم هذه الطبقة في «الشبكة» وما الذي تعلمناه من تشغيلها في منتجات حقيقية.لماذا الحياد قرار استراتيجي لا ترف تقني؟ثلاثة أسباب تجعل الارتباط الصلب بمزوّد واحد مخاطرة: أولًا، السباق محتدم — النموذج الأفضل اليوم قد يصبح الثالث خلال أشهر. ثانيًا، الأسعار تتحرك باستمرار، وفارق التكلفة بين نموذجين قادرين على المهمة نفسها قد يصل إلى عشرة أضعاف. ثالثًا، متطلبات الامتثال وإقامة البيانات قد تفرض غدًا نموذجًا يعمل داخل حدودك الجغرافية أو بنيتك الخاصة.اربط منتجك بالمهمة التي يحلها، لا بالنموذج الذي يشغّلها اليوم.طبقة تجريد واحدة تفصل المنتج عن المزوّدالقاعدة الأولى: لا يستدعي كود المنتج مزوّدًا مباشرة أبدًا. كل الاستدعاءات تمر عبر واجهة داخلية موحدة تتولى ترجمة الطلب لصيغة كل مزوّد، وتوحيد صيغ الردود واستدعاءات الأدوات، ومعالجة الأخطاء وإعادة المحاولة والتبديل الاحتياطي عند تعطل مزوّد.الواجهة تعرّف بمصطلحات منتجك — «لخّص»، «صنّف»، «استخرج» — وتحتها يعيش ملف إعدادات يحدد أي نموذج يخدم أي مهمة. تغيير النموذج يصبح تعديل سطر إعدادات، لا مشروع إعادة كتابة.وجّه كل مهمة إلى النموذج الذي تستحقهليس كل استدعاء يحتاج أقوى نموذج وأغلاه. التوجيه الذكي يصنّف المهام:المهام المعقدة — تحليل عميق، توليد كود، استدلال متعدد الخطوات: النموذج الأقوى.المهام الحجمية — تصنيف، استخراج حقول، صياغة قصيرة: نموذج صغير سريع بجزء يسير من التكلفة.المهام الحساسة — بيانات لا تغادر بنيتك: نموذج مستضاف ذاتيًا أو داخل المنطقة الجغرافية المطلوبة.في منتجات كثيرة، 80% من الاستدعاءات مهام حجمية يمكن أن يخدمها نموذج أرخص بجودة مماثلة — والتوجيه وحده يخفض الفاتورة أضعافًا.البرومبتات أصول تُدار — لا نصوص مبعثرةالتبديل الحر يفترض أن التوجيهات نفسها قابلة للنقل. نخزّن البرومبتات خارج الكود، بإصدارات وتاريخ تغييرات، ونسمح بنسخ مخصصة لكل نموذج عند الحاجة — لأن الصياغة المثلى تختلف بين النماذج. النتيجة: تجربة نموذج جديد لا تلمس كود المنتج إطلاقًا.التقييم هو صمام الأمانلا معنى لحرية التبديل بدون وسيلة تخبرك هل التبديل آمن. لكل مهمة نبني مجموعة تقييم من حالات حقيقية بمعايير نجاح واضحة، وأي نموذج مرشح يمر عليها قبل أن يلمس الإنتاج. الأرقام تحسم النقاش: جودة مكافئة أو أفضل، بتكلفة أقل، بزمن استجابة مقبول — أو لا تبديل.وبعد التبديل، تستمر المراقبة في الإنتاج على عيّنات حقيقية، لأن سلوك النموذج مع بياناتك الفعلية قد يختلف عن نتائج مجموعة التقييم.تحذير: لا تفرط في الهندسةالحياد لا يعني بناء منصة ضخمة من اليوم الأول. إن كان منتجك يستدعي نموذجًا واحدًا في موضعين، تكفيك دالة مغلّفة واحدة وملف برومبتات منظم. ابنِ الطبقة الكاملة حين تتعدد المهام والنماذج فعلًا — الحياد عادة معمارية تبدأ صغيرة، لا مشروعًا مسبقًا ضخمًا.قائمة تحقق للمعمارية المحايدةهل يمر كل استدعاء نموذج عبر طبقة تجريد داخلية واحدة؟هل يحدد ملف إعدادات — لا الكود — أي نموذج يخدم أي مهمة؟هل برومبتاتك مخزنة بإصدارات وقابلة للتخصيص لكل نموذج؟هل لديك مجموعة تقييم لكل مهمة تحسم قرارات التبديل بالأرقام؟هل تتبع التكلفة وزمن الاستجابة لكل مهمة ونموذج في الإنتاج؟الخلاصةسوق النماذج سيبقى متحركًا لسنوات، والرابح ليس من يراهن على الحصان الصحيح، بل من يبني عربة تُبدّل أحصنتها بسهولة. طبقة تجريد نظيفة، وتوجيه حسب المهمة، وبرومبتات مُدارة، وتقييم يحسم القرارات — بهذه العناصر يصبح كل نموذج جديد فرصة تلتقطها في أيام، لا تهديدًا يستدعي إعادة بناء.في «الشبكة» نصمم معماريات الذكاء الاصطناعي للمنتجات التي تريد الاستفادة من السباق لا الاحتراق به. إذا كان منتجك مرتبطًا بمزوّد واحد وتريد فك الارتباط بأمان، تواصل معنا.
المراقبة من اليوم الأول
في معظم المشاريع، تُضاف المراقبة بعد أول حادثة مؤلمة: ساعات من التخمين في الظلام، ثم قرار متأخر بأن «نحتاج مراقبة أفضل». المقاربة الأصح — والأرخص بكثير — أن تُبنى قابلية الملاحظة (Observability) من اليوم الأول، كجزء من تعريف «مكتمل» لأي ميزة جديدة. في هذا المقال نشرح الأركان الثلاثة التي نؤسسها في «الشبكة» مع كل نظام نبنيه، ولماذا صارت أنظمة الذكاء الاصطناعي تجعل هذا التأسيس أكثر إلحاحًا من أي وقت.مراقبة الرسوم ليست قابلية ملاحظةالفرق جوهري: المراقبة التقليدية تجيب عن أسئلة قررتها مسبقًا — «كم استهلاك المعالج؟». قابلية الملاحظة تمكّنك من طرح أسئلة لم تخطر ببالك وقت البناء: «لماذا تفشل طلبات هذا العميل تحديدًا بعد الساعة الثامنة؟». الحوادث الحقيقية دائمًا من النوع الثاني — أسئلة جديدة لم يتوقعها أحد.النظام القابل للملاحظة يجيب عن أسئلة لم تُطرح بعد — دون نشر كود جديد لجمع البيانات.الركن الأول: سجلات منظمة لا نصوص حرةالسجل النصي «حدث خطأ في الدفع» يقرؤه إنسان واحد؛ السجل المنظم (JSON بحقول ثابتة) تستعلمه الآلة عبر ملايين الأسطر. من اليوم الأول نلتزم: كل سجل يحمل معرّف ارتباط (Correlation ID) يتبع الطلب عبر كل الخدمات، ومستوى خطورة صحيحًا، وحقولًا موحدة الأسماء عبر النظام كله.القيمة تظهر في أول تحقيق: بدل البحث في ملفات متفرقة، استعلام واحد يعيد رحلة الطلب كاملة من البوابة إلى قاعدة البيانات.الركن الثاني: مقاييس تهم المستخدماستهلاك المعالج والذاكرة مفيد، لكنه لا يخبرك إن كان المستخدم يعاني. الإشارات الأربع الذهبية هي الأساس:زمن الاستجابة — وبالذات الشريحة المئوية 95 و99، لا المتوسط الذي يجمّل الصورة.معدل الحركة — طلبات في الثانية، لفهم السياق والذروات.معدل الأخطاء — نسبة الطلبات الفاشلة، مقسمة حسب النوع والمسار.التشبع — كم اقتربت الموارد من حدودها قبل أن تنهار.هذه الأربعة لكل خدمة، مع لوحة واحدة تجمعها، تكشف 90% من المشاكل قبل أن يبلّغ عنها العملاء.الركن الثالث: تتبع موزع يربط القصةفي نظام من خدمات متعددة، السجلات والمقاييس تخبرك أن شيئًا بطيء — التتبع الموزع (Tracing) يخبرك أين. كل طلب يحمل سياق تتبع ينتقل عبر الخدمات، فترى الرحلة شلالًا زمنيًا: أي خدمة استهلكت الوقت، وأي استدعاء تكرر بلا داعٍ. معيار OpenTelemetry جعل هذا متاحًا بجهد معقول ودون ارتباط بمزوّد واحد.أنظمة الذكاء الاصطناعي ترفع الرهانمع الوكلاء والنماذج اللغوية، لم يعد السؤال «أي خدمة بطيئة؟» بل «لماذا قرر الوكيل هذا القرار؟». لذلك نمدّ التتبع ليشمل كل تشغيل: التوجيهات المستخدمة وإصدارها، وكل استدعاء نموذج بمدخلاته ومخرجاته، وكل استدعاء أداة بنتيجته — مربوطة بمعرّف تشغيل واحد. بدون هذا الأثر، تصحيح سلوك وكيل في الإنتاج تخمين محض؛ ومعه، كل قرار قابل للتفسير والمراجعة.نبّه على الأعراض، وحقق في الأسبابالتنبيهات الكثيرة أخطر من قلتها — الفريق يتعلم تجاهلها. القاعدة: نبّه فقط على ما يلمس المستخدم (معدل أخطاء يتجاوز الحد، بطء ملموس، توقف كامل)، واجعل كل تنبيه قابلًا للتصرف برابط مباشر إلى لوحة التحقيق أو دليل التشغيل. أعطال الأسباب الداخلية — امتلاء قرص، تراجع نسخة — تذهب للوحات المراجعة اليومية، لا لإيقاظ أحد فجرًا.قائمة تحقق لليوم الأولهل سجلاتك منظمة بحقول موحدة ومعرّف ارتباط في كل طلب؟هل تقيس الإشارات الأربع الذهبية لكل خدمة، بالشرائح المئوية لا المتوسطات؟هل يمر التتبع الموزع عبر كل خدماتك بمعيار OpenTelemetry؟هل تسجل أنظمة الذكاء الاصطناعي عندك كل قرار باستدعاءاته ومخرجاته؟هل كل تنبيه يوقظ إنسانًا مرتبط بأثر ملموس على المستخدم وإجراء واضح؟الخلاصةقابلية الملاحظة استثمار يتضاعف عائده مع كل حادثة: ما كان سيستغرق ليلة من التخمين يصبح استعلامًا من دقائق. ابدأها من اليوم الأول — سجلات منظمة، ومقاييس ذهبية، وتتبع موزع، وأثر كامل لقرارات الذكاء الاصطناعي — وستكتشف أن أغلب الحوادث الكبيرة كانت إشارات صغيرة ظهرت مبكرًا ولم يرها أحد.في «الشبكة» نبني قابلية الملاحظة في كل نظام نسلمه، من اليوم الأول لا بعد أول حادثة. إذا كان نظامك يعمل «صندوقًا أسود» وتريد أن ترى ما بداخله، تواصل معنا.
SaaS متعدد المستأجرين بلا ألم
كل منصة SaaS ناجحة تصل إلى اللحظة نفسها: عشرات ثم مئات المستأجرين على البنية ذاتها، وسؤال واحد يحدد مستقبل المنتج — هل صُمم التعدد من الأساس أم رُقّع لاحقًا؟ الفارق بين الحالتين هو الفارق بين نمو هادئ وليالٍ من حوادث تسرب البيانات بين العملاء. في هذا المقال نلخص أنماط العزل والمصادقة والفوترة التي نطبقها في «الشبكة» عند بناء منصات متعددة المستأجرين تنمو بلا ألم.اختر نموذج العزل بوعي — لا بالمصادفةقرار العزل هو أهم قرار معماري في المنصة، وله ثلاثة أنماط رئيسية:قاعدة بيانات لكل مستأجر — أقوى عزل وأسهل امتثال، لكن كلفة تشغيلية تتضاعف مع كل عميل. مناسب للعملاء الكبار وقطاعات التنظيم الصارم.مخطط مشترك بمعرّف مستأجر — الأكفأ تشغيليًا والأسرع نموًا، لكنه يضع كل عبء العزل على انضباط الكود.هجين — مخطط مشترك للشريحة العامة، وقواعد مستقلة لمن يدفع مقابل العزل. النمط الذي تنتهي إليه أغلب المنصات الناضجة.لا يوجد نموذج «صحيح» — يوجد نموذج يطابق عملاءك اليوم ويترك الباب مفتوحًا لعملاء الغد.معرّف المستأجر يمر في كل طبقة — والدفاع متعدد الخطوطفي النموذج المشترك، أخطر حادثة ممكنة استعلام نسي شرط المستأجر فأظهر بيانات عميل لعميل آخر. الحماية لا تُترك للانتباه البشري بل تُبنى طبقات: سياق مستأجر إلزامي في كل طلب، وطبقة وصول للبيانات تضيف الشرط تلقائيًا ولا تسمح بتجاوزه، وأمان مستوى الصف (RLS) في قاعدة البيانات كخط دفاع أخير يعمل حتى لو أخطأ الكود.ثم اختبارات آلية تحاول عمدًا الوصول عبر الحدود بين مستأجرين — تفشل الإطلاقة في CI قبل أن تصل الثغرة للإنتاج.المصادقة: هوية المستخدم شيء وعضويته شيء آخرالنمط الذي يصمد: هوية واحدة للمستخدم، وعضويات متعددة في مستأجرين، وأدوار لكل عضوية. هذا يفتح الحالات الحقيقية بسلاسة — مستشار يعمل مع ثلاث شركات، وموظف ينتقل بين فريقين — دون حسابات مكررة. ومع أول عميل كبير سيأتي طلب SSO (تسجيل الدخول الموحد عبر SAML أو OIDC)؛ ابنِ نقطة التوصيل مبكرًا، فهي شرط صفقات لا ميزة رفاهية.الفوترة تبدأ من القياسلا يمكن فوترة ما لا تقيسه. من اليوم الأول، سجّل الاستخدام لكل مستأجر — المستخدمين النشطين، حجم التخزين، استدعاءات الواجهات، أو أي وحدة تعكس القيمة عندك — في مسار أحداث مستقل عن منطق الفوترة نفسه. بعدها تستطيع تركيب أي نموذج تسعير فوق البيانات: باقات، أو دفع بالاستخدام، أو مزيج، وتغييره لاحقًا دون إعادة بناء.واربط حدود الباقات بالإنفاذ الفعلي: الباقة التي تعد بعشرة مستخدمين يجب أن يفرضها النظام آليًا، مع رسالة ترقية مهذبة لا خطأ غامض.الجار المزعج: عدالة المواردفي البنية المشتركة، مستأجر واحد ثقيل — استيراد مليون سجل، أو تكامل مجنون — يمكن أن يبطئ المنصة على الجميع. الوقاية: حدود معدل لكل مستأجر لا للنظام كله، وطوابير معالجة تفصل الأحمال الثقيلة عن المسار التفاعلي، ومراقبة مقسمة بالمستأجر تكشف من يستهلك ماذا قبل أن يشتكي الآخرون.الترحيلات على أسطول قواعدإن اخترت قاعدة لكل مستأجر، فكل ترحيل مخطط يصبح عملية على أسطول: أتمتة تنفذ الترحيل تدريجيًا، وتتحقق من نجاحه لكل قاعدة، وتوقف الانتشار عند أول فشل. بدون هذه الأتمتة، سيتباعد المستأجرون في إصدارات المخطط — وهي فوضى يصعب العودة منها.قائمة تحقق للتعدد بلا ألمهل اخترت نموذج العزل قرارًا واعيًا موثقًا — لا افتراضًا ورثته؟هل يمر معرّف المستأجر إلزاميًا في كل طبقة، مع RLS كخط دفاع أخير؟هل الهوية منفصلة عن العضوية، ونقطة SSO جاهزة للعملاء الكبار؟هل تقيس الاستخدام لكل مستأجر من اليوم الأول، والحدود مُنفذة آليًا؟هل لديك حدود معدل لكل مستأجر ومراقبة مقسمة تكشف الجار المزعج؟الخلاصةتعدد المستأجرين ليس ميزة تضيفها لاحقًا، بل عدسة تصمم من خلالها كل طبقة: العزل، والهوية، والقياس، والعدالة التشغيلية. المنصات التي تبنيه من الأساس تنمو من عشرة عملاء إلى ألف بهدوء؛ والتي ترقّعه تدفع الثمن حوادث وثقة عملاء. الاستثمار المبكر هنا هو أرخص تأمين لمستقبل منتجك.في «الشبكة» نصمم منصات SaaS متعددة المستأجرين من الصفر ونعالج مشاكل التعدد في المنصات القائمة. إذا كنت تبني منصتك أو تستعد لعميلك الكبير الأول، تواصل معنا.
لوحة معلومات يقرأها الناس فعلًا
أغلب لوحات المعلومات تموت ميتة صامتة: تُبنى بحماس، وتُعرض في اجتماع الإطلاق، ثم لا يفتحها أحد بعد أسبوعين. المشكلة نادرًا ما تكون في البيانات — إنها في التصميم الذي يعرض كل شيء ولا يقول شيئًا. لوحة المعلومات الناجحة ليست معرضًا للرسوم البيانية، بل أداة قرار يومية. في هذا المقال نلخص المبادئ التي نصمم بها في «الشبكة» لوحات يفتحها الناس كل صباح لأنها تجيب عن أسئلتهم فعلًا.ابدأ من القرار، لا من البياناتالسؤال الخاطئ عند بناء اللوحة: «ما البيانات المتوفرة لدينا؟». السؤال الصحيح: «ما القرارات التي يتخذها مستخدم هذه اللوحة كل أسبوع؟». كل عنصر في اللوحة يجب أن يجيب عن سؤال محدد يقود لتصرف — «هل نحتاج تدخلًا اليوم؟»، «أين يتسرب العملاء؟». الرسم الذي لا يغيّر قرارًا هو ضجيج مهما كان جميلًا.لكل رسم في اللوحة سؤال يجيب عنه — وإن لم تستطع صياغة السؤال، احذف الرسم.حبر البيانات: كل بكسل يبرر وجودهمبدأ إدوارد توفتي الشهير: انسب أكبر قدر من «الحبر» للبيانات نفسها، وأقل قدر للزينة. عمليًا هذا يعني حذف الخلفيات المظللة، والحدود الثقيلة، والتدرجات، والظلال، وخطوط الشبكة الكثيفة، وتأثيرات الأبعاد الثلاثية — كلها تنافس البيانات على انتباه العين ولا تضيف معلومة. اللوحة النظيفة ليست ذوقًا جماليًا؛ إنها سرعة قراءة.لون واحد يكفي للتمييزاللوحة التي تستخدم عشرة ألوان لا تميّز شيئًا — فحين يصرخ كل شيء، لا يُسمع شيء. النظام الذي يعمل: درجات رمادية هادئة للأساس، ولون تمييز واحد للأهم — الخط الذي يهم الآن، أو الشريحة التي تحتاج انتباهًا — والأحمر محجوز حصريًا للتحذير الحقيقي. بهذا الانضباط، تقود اللون عين القارئ إلى ما يستحق خلال ثانية.التسلسل الهرمي يقود العينالقارئ يمسح اللوحة، لا يقرؤها سطرًا سطرًا. صمم لهذا السلوك: الأرقام المصيرية في الأعلى كبيرة وواضحة، والتفاصيل الداعمة تحتها، والاستكشاف العميق في المستوى الأخير أو خلف نقرة. وقاعدة الشاشة الواحدة: ما يحتاج تمريرًا طويلًا لن يُرى — إن كثرت الأقسام فوزّعها على لوحات لجمهور مختلف بدل شاشة واحدة لا نهائية.اختر الرسم الذي يطابق السؤالالاتجاه عبر الزمن — خط. لا شيء يضاهيه.المقارنة بين فئات — أعمدة مرتبة من الأكبر للأصغر.رقم واحد مصيري — رقم كبير مع مؤشر التغير عن الفترة السابقة، لا عدّاد سرعة.الدائرة (Pie) — نادرًا: فئتان أو ثلاث كحد أقصى، وإلا فالأعمدة أوضح.وانتبه لمحاور تبدأ من غير الصفر في الأعمدة — إنها تضخّم الفروق وتخدع القارئ، وثقة اللوحة أغلى ما فيها.رقم بلا سياق ليس معلومة«الإيراد 48,000» — هل هذا جيد؟ لا أحد يعلم بدون مقارنة. كل رقم في اللوحة يحتاج مرجعًا: الفترة السابقة، أو الهدف، أو متوسط السوق. أضف خط الهدف على الرسم، ونسبة التغير بجانب الرقم، ولوّن الانحراف — عندها يتحول الرقم من إحصائية إلى حكم: نحن بخير، أو نحتاج تدخلًا.للجمهور العربي: اللوحة تقرأ من اليميناللوحات ثنائية اللغة تحدٍّ نتعامل معه يوميًا: في الواجهة العربية ينعكس التخطيط كاملًا (RTL) فيبدأ التسلسل البصري من أعلى اليمين، بينما تبقى محاور الزمن في الرسوم تجري من اليسار لليمين كما يتوقع القارئ للأرقام. والأرقام الطويلة والتواريخ تحتاج تنسيقًا محليًا صحيحًا. اختبر النسختين — فاللوحة التي تُقرأ طبيعيًا بالعربية لا تأتي مجانًا من مكتبة رسوم أجنبية.قائمة تحقق قبل إطلاق أي لوحةهل كل رسم يجيب عن سؤال قرار واضح يمكنك كتابته بجملة؟هل حذفت كل زينة لا تحمل معلومة — خلفيات وظلال وأبعاد ثلاثية؟هل تستخدم لونًا واحدًا للتمييز والأحمر للتحذير فقط؟هل الأهم في أعلى الشاشة، وكل شيء مرئي بلا تمرير طويل؟هل كل رقم مصحوب بمقارنة تعطيه معنى — هدف أو فترة سابقة؟الخلاصةلوحة المعلومات الجيدة ليست الأكثر رسومًا بل الأسرع إجابة: يفتحها صاحب القرار فيعرف خلال ثوانٍ هل الأمور بخير وأين يجب أن ينظر. ابدأ من الأسئلة، وقتّر في الحبر واللون، ورتّب بالتسلسل، وأعطِ كل رقم سياقه — وستحصل على اللوحة النادرة: التي يفتحها الناس كل يوم طوعًا.في «الشبكة» نصمم لوحات المعلومات والتقارير التفاعلية ثنائية اللغة للشركات والجهات — من نمذجة البيانات إلى واجهة تُقرأ فعلًا. إذا كانت لوحاتك تُبنى ولا تُفتح، تواصل معنا.
احصل على المقالات الجديدة بالبريد.
من حين لآخر، تقنية، بلا حشو. ألغِ الاشتراك متى شئت.
رسالة واحدة عند النشر. هذا كل شيء.