مَن يشتري العُطل قبل وقوعه؟

في الثامن عشر من نوفمبر 2025، بدأت شبكة «كلاودفلير» (Cloudflare) تتصرف على نحوٍ يذكّر بمريض ترتفع حرارته وتهبط كل خمس دقائق. تنقطع خدمات، ثم تعود، ثم تنقطع. ظن الفريق في البداية أن الشبكة تتعرض لهجوم إلكتروني ضخم. وكان السبب، وفق تقرير الشركة اللاحق، أكثر غرابة وأقل بطولية: تغيير في صلاحيات قاعدة بيانات ضاعف محتويات ملف تستخدمه منظومة اكتشاف الروبوتات (Bot Management). انتشر الملف إلى أجهزة الشبكة، فتجاوز الحد الذي تستطيع البرمجيات استيعابه. وصار تحديثٌ مشروع طريقًا إلى تعطّل واسع S01.

لم يكن الملف منشورًا كل صباح بصحبة بيان رسمي. كان يتجدد آليًا كل خمس دقائق، عبر استعلام من قاعدة بيانات «كليك هاوس» (ClickHouse). كانت بعض العقد قد تلقت تحديث الصلاحيات وبعضها لم يتلقه، ولذلك وصل ملف صالح أحيانًا وملف مضاعف أحيانًا أخرى. كان تعافي الخدمة مؤقتًا، فتوهّم الراصدون أن السبب قد يكون حركة عدائية تتقلب. وحين صار معظم المخدمين ينتجون النسخة السيئة استقرت حالة الفشل. بحلول 14:30 بالتوقيت العالمي المنسق (Coordinated Universal Time; UTC) عادت الحركة الأساسية غالبًا، ولم تُعلن عودة كل الأنظمة إلى حالتها الطبيعية حتى 17:06، حسب التقرير نفسه S01.

وقبل ذلك بخمسة أشهر، في 12 يونيو 2025، تعرضت خدمات «غوغل كلاود» (Google Cloud) لاضطراب عالمي. هنا أيضًا لم تبدأ المشكلة بقذيفة أو اختراق. أدخل تحديث لسياسة الحصص بيانات تحتوي حقولًا فارغة، وانتشرت عالميًا، ثم استدعت مسارًا برمجيًا يعجز عن التعامل مع قيمة معدومة (Null Pointer). وحتى بعد تحديد السبب، أبطأت موجة إعادة التشغيل التعافي في بعض المناطق، لأن محاولات الرجوع إلى الخدمة ضغطت على قاعدة بيانات تعتمد عليها S02.

تختلف الشركتان، وتختلف البرمجيات، لكن بين الحادثتين قرابة هندسية تستحق الدراسة: المنظومة لم تعجز عن معالجة كارثة استثنائية؛ لقد تعاملت مع مدخل غير متوقع كما لو كان مستحيلًا، ثم نشرت نتيجة هذا الافتراض بثقة الآلة وسرعتها.

تترك الحوادث وراءها تقارير طويلة. يقرأها المهندسون، وتُناقش في الاجتماعات، ثم تنضم إلى أرشيف الخبرة البشرية. وبعد أشهر قد تظهر العائلة نفسها من الأخطاء في مؤسسة أخرى، وقد يكون المهندسون قرأوا التقرير الأول أصلًا. ومن هنا تبدأ الفكرة الاستراتيجية: ماذا لو استطعنا تحويل الحادثة الموثقة إلى وحدة معرفة تنفيذية (Executable Failure Contract)، تحدد الشرط الذي أثار العطل، والسلوك الذي يجب ألا يحدث، والتجربة التي تكشفه، والدليل الذي يثبت نتيجة الاختبار؟

عندها لن تكون السلعة المصدَّرة مجرد أداة ترصد الأعطال أو استشارة تُكتب لمرة واحدة. ستكون اختبارًا يمكن لمهندس في الرياض تطويره، ولمشغّل في سنغافورة تشغيله، ولمشترٍ في فرانكفورت أن يتحقق من نتيجته دون أن يضطر إلى تصديق البائع على كلمته. والسؤال الذي يستحق بحثًا علميًا وتجاريًا ليس ما إذا كانت الفكرة جميلة. بل هل يمكن نقل منطق العطل بين أنظمة مختلفة من غير أن نفقد معناه، وهل سيدفع عميل أجنبي ثمن هذا النقل مرتين؟

تبدو الفكرة غريبة إن تخيلنا أن صناعة البرمجيات تقوم على بيع ما يحدث حين تسير الأمور جيدًا. التطبيق الناجح يقدّم خدمة، والرقاقة تعالج حسابًا، والشبكة تنقل رسالة. لكن هناك اقتصادًا صامتًا حول هذه المنتجات: اقتصاد ما كان ينبغي أن يحدث. يمكن لمؤسسة أن تسدد عقدًا شهريًا لقاء اختبارٍ لم يكتشف شيئًا، بشرط أن تملك سببًا هندسيًا مقنعًا للثقة بأن التجربة كُتبت بطريقة تفصل الأداء السليم عن عطل يمكن كشفه.

ليست تلك السوق خيالًا. توفر «أمازون ويب سيرفيسز» (Amazon Web Services; AWS) خدمة إدخال الأعطال المقيّدة (AWS Fault Injection Service; FIS). ومنذ 2023 لديها مكتبة سيناريوهات جاهزة، كما أوضحت في دليل منشور سنة 2024. ويمكن لتلك التجارب محاكاة تعطل نطاق إتاحة (Availability Zone)، أو آثار اضطراب اتصال، مع آليات توقف عند تجاوز حدود محددة S06S08. وفي مايو 2025 نشرت مثالًا يولّد قوالب تجارب من أوصاف باللغة الطبيعية باستخدام «أمازون بدروك» (Amazon Bedrock) والنماذج اللغوية الكبيرة (Large Language Models; LLMs) S07.

إذن لا يجوز لمشروع سعودي أن يعلن أنه اخترع هندسة الفوضى (Chaos Engineering)، أو اكتشف أول مرة إمكان كتابة وصف حادثة لتحويله إلى تجربة. المنافسون موجودون، وبعضهم يملك المنصة التي يختبرها العميل. تكمن نافذة المنتج المقترح في مكان أضيق وأصعب: ترجمة آلية الفشل الدلالية إلى اختبار قابل للنقل بين البيئات، وإرفاقه بدليل مُراجع على السلوك المرصود، بدل ربط الاختبار بمحرّك سحابي واحد أو الاكتفاء بإيقاف مخدم عشوائي.

قد لا ينجح هذا التمييز في السوق. وربما يضيف مقدمو السحابة ما يجعله مجانيًا مع اشتراكاتهم، أو يقرر المشترون أن حلًا متخصصًا لكل منصة أكثر فاعلية. لذلك لا نخلط بين فجوة تبدو هندسيًا مثيرة وبين فرصة استثمارية مثبتة. المشروع الحقيقي يبدأ عند اكتشاف من سيدفع لقاء تجسير هذه الفجوة، لا عند اختراع اسمٍ إنجليزي رنان لها.

تقارير الأعطال تُكتب باللغة التي تصلح لشرح ما حدث للبشر: خط زمني، قرارات، افتراضات، تفاصيل انتشار، سبب جذري (Root Cause) ومقترحات علاج. أما الحاسوب فلا يستطيع إجراء تجربة آمنة بمجرد أن نخبره بأن فريقًا «سيحسّن التعامل مع الخطأ». يحتاج إلى شرط محدد، وحالة أولية، وفعل مسموح، وناتج يمكن رصده، وطريقة توقف وإرجاع.

أقترح اعتبار التقرير مادة خام لا برنامجًا جاهزًا. يمر بخمس ترجمات:

1. الفصل بين المشاهدة والتفسير. أي الوقائع أعلنتها الجهة صاحبة النظام؟ ما الذي بقي استنتاجًا؟ وما الجزء الذي لا نملك مواصفاتٍ لنقله؟
2. استخراج النمط السببي. مثل: تغير صلاحية القراءة في مخزن بيانات يولّد صفوفًا مكررة، تكبر بها بنية تكوين مشتركة، ثم يعجز القارئ عن تجاوز حجمها. هذا وصف لعائلة سلوك، لا نسخة من تصميم شركة بعينها.
3. كتابة ثابتٍ وظيفي (Invariant). مثال: «لا يجوز لوجود سجلات خصائص مكررة دلاليًا أن يؤدي إلى تعطل مسار الخدمة الأساسي». لكن هذا الثابت نفسه يحتاج قيدًا: هل إزالة التكرار آمنة في المنتج المعني؟ ربما يكون ترتيب السجلات أو تكرارها جزءًا مقصودًا من المعنى.
4. تجميع تجربة مقيّدة. يولّد المترجم (Compiler) مدخلات اختبار اصطناعية في بيئة معزولة، ويطلب نتيجة محددة، ويضع حدودًا للتوقف (Stop Conditions) وطريقة تراجع (Rollback).
5. إخراج سجل شاهد. ما نسخة البرنامج؟ ما البذرة العشوائية إن وجدت؟ ما حالات الاختبار؟ وما مشاهدات القياس عن طريق آثار التنفيذ الموزعة (Distributed Traces) والسجلات والمقاييس؟

يمكن تمثيل الوحدة الناتجة بملف ذي بنية واضحة: IncidentSpec، فيه evidence, preconditions, stimulus, oracle, stop, rollback, environment وlimitations. هذه حقول مقترحة للبحث والتطوير، وليست معيارًا معتمدًا أو اسمًا لمنتج سعودي موجود. ويرمز oracle إلى قاعدة الحكم التي تفصل النجاح من الفشل. إن أسوأ ما في الاختبار الذكي ليس عجزه عن إثارة العطل؛ بل أن يثيره ثم يحتفل بنجاح التجربة لأنه لا يعرف النتيجة الصحيحة.

الأعطال السحابية الشائعة تُحقن بقطع الشبكة أو زيادة زمن الاستجابة (Latency)، أو إيقاف حاوية، أو إنهاك المعالج. هذه نافعة فعلًا. لكنها لا تطابق وحدها الحدث الذي قتل مسار عمل في القصتين السابقتين. كان السبب ملفًا زائد الحجم، وحقلًا مفقودًا ضمن سياسة تتوزع عالميًا. يمكن للنظام اجتياز آلاف اختبارات إيقاف المخدمات ثم ينهار عند استيراد صفّ إضافي من قاعدة البيانات.

في علوم البرمجة ثمة فرق بين عطل المورد (Resource Fault) وعطل الدلالة (Semantic Fault). الأول يسأل: ماذا لو غاب المخدم؟ والثاني: ماذا لو حضر المخدم سريعًا، وقرأ معلومات تسمح صياغتها لكنها تخالف افتراضًا دفينًا في البرمجيات؟ قد يعالج الاختبار الثاني تشوه البيانات (Data Corruption)، أو تبدل المخطط (Schema Drift)، أو تعارض نسختين (Version Skew)، أو فشلًا في إبطال عملية مكررة (Idempotency Failure)، أو عاصفة إعادة المحاولة (Retry Storm).

ليس كل إدخال سيئ علةً يجب التعامل معها بالطريقة نفسها. في خدمة مالية لا يجوز تحويل كل خطأ صلاحية إلى «اسمح بالمرور كي لا تتوقف الخدمة». وفي خدمة قراءة عامة قد يكون سلوك الاستمرار المشروط (Fail Open) مناسبًا أكثر من حجب الجميع. الثابت الوظيفي يُشتق من وظيفة الخدمة وحدودها، ولا يُنسخ من مقال إخباري. هنا تبرز أهم خدمة مهنية يمكن بيعها مع المنتج: تحويل معنى النشاط إلى شروط قابلة للقياس، لا ترجمة الكلمات إلى ملف تكوين فحسب.

في صميم الاختبار البرمجي نملك أدوات أخرى: اختبار الخصائص (Property-Based Testing) يولّد مدخلات متنوعة يبحث بها عن نقض الثابت، واختبار التحوّلات (Metamorphic Testing) يقارن نتيجة النظام قبل تعديل المدخل وبعده حين يصعب معرفة الجواب الصحيح لكل حالة، والاختبار التفاضلي (Differential Testing) يقارن تنفيذين يدعيان اتباع القاعدة نفسها. وحين توجد معاملات متزامنة، يزداد الأمر صعوبة: فقد تبدو كل استجابة منفردة سليمة، بينما يكون تاريخ الأحداث كله مخالفًا لضمان الاتساق (Consistency Guarantee). وقد جعل مشروع «جيبسن» (Jepsen) من تشغيل نظم موزعة فعلية تحت الأعطال وفحص سجل العمليات عملًا منهجيًا منشورًا منذ سنوات S09.

إذن لسنا أمام وكالة إبداع تتخيل أسوأ يوم للشركة وتطلب من نموذج لغوي أن يرسمه. نحتاج باحثين في الدلالات البرمجية (Programming Language Semantics)، وبروتوكولات الأنظمة الموزعة (Distributed Protocols)، ومهندسي تشغيل يعرفون أن «لا تنهَر» شرط أضعف كثيرًا من «أنجز المهمة الصحيحة دون تكرار أو ضياع».

قد يبدو حديث الملف المضاعف والفهرسة والنسخ الموزعة تسليةً لمبرمج يجيد شرب القهوة أثناء قراءة الأعطال. لكنه يصبح مختلفًا عند النظر إلى حادثة شركة «إيه تي آند تي» (AT&T Mobility) الأمريكية في 22 فبراير 2024. أفاد تقرير مكتب السلامة العامة والأمن الداخلي التابع لهيئة الاتصالات الفيدرالية الأمريكية (Federal Communications Commission; FCC) بأن انقطاعًا واسعًا لخدمة الاتصالات الخلوية استمر اثنتي عشرة ساعة على الأقل بعد تهيئة خاطئة لعنصر شبكي، وأن الحادثة حجبت أكثر من 92 مليون مكالمة صوتية وأكثر من 25 ألف محاولة اتصال بمراكز الطوارئ 911، وفق بيانات حصلت عليها الهيئة من المشغّل S03.

لا نختلق هنا اسم مريض لم يتمكن من طلب إسعاف، ولا نفترض مآلًا لكل مكالمة محجوبة. يكفي الرقم ونوع الخدمة لتصبح المسألة اجتماعية بامتياز. صار تغيير عنصر تقني عملًا في قدرة ملايين الناس على الاتصال. والدرس القابل للنقل ليس رقم المكالمات إلى شبكة سعودية بعينها، بل ضرورة اختبار انتشار تغيير واحد واستجابة بقية النظام لاستعادته قبل أن يُطلَق. فالضرر لم ينتهِ عند لحظة إدراك الخطأ؛ يمكن لجحافل الأجهزة التي تحاول العودة إلى الشبكة أن تُطيل ازدحامها بعد الإصلاح.

على هذا المستوى تختلف ثلاثة ملفات للحوادث: ملف خصائص تضاعف، حصة لها حقل فارغ، وعنصر شبكة سيئ التهيئة. ومع ذلك تتلاقى عند سؤال واحد: متى تتحول معلومة تحكم محلية إلى قرار جماعي سريع يصعب الرجوع عنه؟ لا يبرهن جمعها أن منصة واحدة تكشفها جميعًا. لكنه يصنع بنك فروض علمية أصدق من عبارة عامة من نوع «لدينا ذكاء اصطناعي يتنبأ بالهجمات والأعطال».

لو أردنا منتجًا سعوديًا أوليًا، فلن أبدأ بمنصة ضخمة ولا بلوحة تحمل خريطة العالم وشعارات التأهب. سأبدأ بمترجم تجارب (Incident-to-Test Compiler) يعمل على سجل معلن من الحوادث، وثلاثة أنواع من البرمجيات يستطيع الفريق فهمها جيدًا. لا يُوصل المترجم إلى نظام العميل مباشرة؛ يطلب أولًا نموذجًا مجرّدًا لواجهات الخدمة، والخصائص التي يعدها العميل أساسية، وحدود البيئة المصرح بها.

تستخرج مرحلة الذكاء الاصطناعي المرشحات: «ربما يكون التعطل ناتجًا عن حجم ملف»، «ربما لا يعالج القارئ الحقول الفارغة»، «ربما تزيد إعادة المحاولة الحمل». لكنها ترسل لكل جملة دليلها من التقرير وتمنحها حالة: مثبتة في المصدر، أو محتملة، أو غير قابلة للنقل. النموذج اللغوي هنا مساعد في استخراج الفرضيات (Hypothesis Extraction)، لا قاضيًا يصدر تصريح تشغيل. يمكن أن يخطئ في أسماء الحقول أو يختلق علاقة سببية، ولذلك لا ينبغي أن تتحول مخرجاته مباشرة إلى أوامر مؤثرة على خدمات حقيقية.

بعد ذلك تتحول الفرضية إلى صيغة وسيطة (Intermediate Representation; IR). قد ينتج عنها مُحوّل (Adapter) لتجارب «كوبرنيتس» (Kubernetes)، وآخر لاختبارات واجهة برمجية (Application Programming Interface; API)، وثالث لاختبار مكتبة مستقلة بلا بنية تحتية. لا قيمة للاشتراك التجاري ما لم يكن المعنى محفوظًا عبر هذه الصيغ؛ فقد يكون إيقاف مجموعة حاويات في بيئة أولى شبيهًا ظاهريًا بعطب في الثانية، لكنه يفتقد الحالة المشتركة التي جعلت الحادثة الأصلية واسعة.

تُجمع النتائج من مقاييس الخدمة، وسجل العمليات، وآثار التنفيذ عبر الواجهات. يشكّل إطار «أوبن تليمِتري» (OpenTelemetry) أحد المسارات المتاحة للبيانات، بواجهات مشتركة للمقاييس (Metrics) والسجلات (Logs) وآثار التتبع (Traces)، كما توضح مؤسسة الحوسبة السحابية الأصيلة (Cloud Native Computing Foundation; CNCF) S11. لا نحتاج إنشاء بروتوكول مراقبة سعودي جديد لنصنع منتجًا سعوديًا. قد تكمن المعرفة الأصلية في تصميم التجربة وحدود تفسيرها، بينما نستعمل المعايير المفتوحة لنقل الشواهد.

أخيرًا، يتكون «جواز التجربة» (Execution Evidence Passport) من نسخة الحزمة، ونسخة البيئة، والتغييرات التي حُقنت، ومخرجات قاضي الاختبار، وسبب أي توقف، وحدود صحة الاستنتاج. هذا اسم بحثي مقترح، لا ختم اعتماد مستقل. التوقيع الرقمي (Digital Signature) يحفظ سلامة السجل من العبث، لكنه لا يجعل الاستنتاج صادقًا إذا كانت قاعدة الحكم ضعيفة. يصح أن تكون التجربة موثقة بالكامل وتجيب عن السؤال الخطأ بالكامل أيضًا.

شكل 2. بنية منتج مقترحة وليست منظومة سعودية منشورة أو مطبقة. الأسهم مراحل ترجمة معرفية تحتاج مراجعة بشرية، وليست دليلًا على أن أتمتتها ممكنة أو آمنة في كل قطاع S06S07S09S11.

لكيلا تنتهي الأطروحة إلى برنامج مؤتمرات، نفّذنا نموذجًا حاسوبيًا صغيرًا ومعلن الحدود. كتبنا 16 عقد اختبار اصطناعيًا لأربع عائلات: سياسات ناقصة الحقول، وحزم خصائص متكررة تتجاوز قيود السعة، ونسخ إعدادات قديمة أو غير موثقة، ومحاولات اتصال لا تكف عن التكرار. وشغّلنا العقود على أربعة تنفيذات برمجية اصطناعية: تنفيذًا هشًا، وآخر يراجع سلامة المدخلات فحسب، وثالثًا يضبط حدود الموارد فحسب، ورابعًا يجمع الحواجز الأربعة المطلوبة.

نفّذ البرنامج 64 حالة اختبار بالفعل، وأخرج سجلًا لكل حالة ونتيجتها المتوقعة والمشاهدة. حقق التنفيذ الهش الاتفاق مع 7 حالات من أصل 16، وتنفيذ فحص المدخلات 12، وتنفيذ ضبط الموارد 11، والتنفيذ الجامع 16 S13. كل هذه الأرقام نتائج شيفرة كتبناها لتمثيل المثال، لا نسب كشف أعطال في شركات حقيقية. ولم يُستخدم ذكاء اصطناعي فعلي لاستخراج الحالات من تقارير الحوادث؛ صممنا العقود يدويًا كي نختبر فكرة تمثيلها وتنفيذها.

شكل 1. عدد الحالات التي وافقت فيها مخرجات كل تنفيذ قاضي الاختبار المعلَن، من أربع حالات في كل عائلة. لا تمثل النسب قدرة تجارية على اكتشاف الأعطال ولا احتمالًا لوقوعها. توجد الشيفرة وملفات الحالات والنتائج في المرفق المستقل S13.

أهم ما تظهره التجربة ليس أن حارسًا أكثر يؤدي دائمًا إلى صمود أكبر. هذا سيكون استنتاجًا دائريًا، لأننا كتبنا النسخة الرابعة لتنجح في العقود التي كتبناها. إنما تظهر شيئًا أكثر تواضعًا ومفيدًا: يمكن تحويل وصفٍ وظيفي إلى مدخلات، وقاعدة حكم، وسجل نتائج يُعاد تشغيله، مع بقاء الفارق واضحًا بين فشل النظام وفشل الاختبار في فهم النظام. الانتقال من هذه اللعبة المحدودة إلى قاعدة بيانات إنتاجية، أو منصة مدفوعات، أو شبكة اتصالات يحتاج تجارب وعقودًا وتعريفات نجاح أخرى.

العميل الأجنبي لن يشتري «تاريخ الإنترنت» من شركة ناشئة، لأنه متاح للقراءة مجانًا. ولن يشتري إعادة صياغة تقريرٍ كتبه أصحابه بصورة أفضل. سيدفع إذا اختصرت الحزمة عملًا صعبًا لديه: تحويل حادثة إلى نمط يمكن تمثيله بأمان في بنيته، وربط نتيجة التنفيذ بالتزامات خدمته. هذه خدمة ذات تكلفة تطبيق (Integration Cost) قد تلتهم ثمن الترخيص إذا احتاج كل عميل شهرين من التخصيص.

أتصور ثلاثة منتجات أولية مختلفة، ويجب ألا نخلط بينها في المبيعات:

هذه فئات مقترحة وليست أسماء شركات أُنشئت أو خدمات بيعت. ويمكن أن يبدأ العمل بالحزمة الأولى ثم ينمو إلى الثانية إذا أثبت العملاء أنهم يحتاجون النقل بين البيئات. أما القفز مباشرة إلى منتج شامل يفهم كل شيء، فغالبًا سيُنتج نشاط استشارات عالي التكلفة يرتدي قناع منصة برمجية.

في أبريل 2025، شاركت هيئة تنمية الصادرات السعودية (Saudi Export Development Authority; Saudi Exports) في معرض «جيتكس أفريقيا» (GITEX AFRICA) بمدينة مراكش (Marrakech) بجناح ضم 28 شركة وطنية في التقنية والاتصالات، وفق وكالة الأنباء السعودية (Saudi Press Agency; SPA) S04. وفي يوليو 2026 شهد معرض «ليب إيست» (LEAP East) في هونغ كونغ (Hong Kong) مشاركة سعودية وعلاقات بين شركات تقنية، ومن ذلك إعلان شركة «علم» (Elm) توقيع مذكرة تفاهم مع «هواوي» (Huawei) في مجالي الذكاء الاصطناعي والبنية الرقمية S05.

هذه مؤشرات ملموسة إلى وجود قنوات اتصال وترويج دولية. لكنها ليست سجل مشتريات لمنتج مرونة سعودي، ولا تثبت حصول إيراد متكرر من عميل أجنبي. الوصول إلى معرض يفيد في مقابلة المشترين. أما إنشاء صناعة تصديرية فيظهر عندما يوقّع مشترٍ مستقل عقدًا ثانيًا لأنه لم يعد يريد الاستغناء عن المنتج الأول.

ليس على السعودية أن تُنشئ لوازم البرمجيات العالمية كلها حتى تتخصص في هذه الفجوة. لديها سوق تشغيل كبير، ومشغّلون محتملون عبر الحوسبة والاتصالات والخدمات والمدفوعات واللوجستيات، وكفاءات بحثية وهندسية يمكن تنميتها. لكن وصف هذه البيئة بأنها «مختبر مثالي» افتراض يحتاج اختبارًا: قد يكون العميل المحلي بارعًا في تنظيم مشروع كبير، لكنه لا يقبل تعريض خدماته لاختبارات افتراضية بعد، وقد يبقى المنتج محصورًا في طلبات خاصة يصعب تكرارها. الاستعداد للدفع، وسماح الهندسة بالاختبار، وحقوق استخدام بيانات الحوادث، والتكلفة الحدّية لإضافة عميل جديد، كلها أسئلة لا تختصرها المزايا الوطنية العامة.

ثم إن الخبرة الخليجية في الضغوط المركبة يمكن أن تساعد في ابتكار حالات اختبار مفيدة لسلاسل التوريد الرقمية، والتوقيت الشبكي، والأحمال الحرارية على الحوسبة، وتغير مصادر الاتصال. هذا انتقال مشروع من واقعٍ معقد إلى معرفةٍ عامة، بشرط أن تُستخرج الأنماط من بيانات علنية أو بيئات مأذون بها، لا من خرائط حساسة لمنشآت أو من تفاصيل وصول تمنح مهاجمًا قائمة أهداف جاهزة.

قد تصنع مؤسسة محلية منصة جميلة وقادرة على تشغيل مائة عقد، ثم تكتشف أن الصيانة بعد البيع تكلّف أكثر من رسوم الترخيص. البرمجيات القابلة للتصدير تحتاج اقتصاديات وحدة (Unit Economics) لا تلتبس فيها الإيرادات المتكررة بمشروع تطوير منفرد. فالتجربة الواحدة قد تستدعي فهمًا جديدًا لمعاملات العميل وواجهاته وقواعد سلامته، وتحتاج مراجعة قانونية وتوثيقًا بلغته ودعمًا للتنفيذ، ثم تتغير عند تحديث النظام.

لن أفترض حجم السوق أو متوسط سعر اشتراك عالمي. بدل ذلك يختبر المؤسس أربع نسب في العملاء التجريبيين الفعليين: ساعات التخصيص لكل عميل، نسبة العقود التي تعمل دون تدخل متخصص، تكلفة الصيانة لكل نسخة جديدة، ومعدل التجديد المدفوع خارج السعودية. وليست عبارة «لدينا عميل دولي» معيارًا كافيًا؛ فالاستشارة التي تُنفّذ في دولة أخرى تصدير لخدمة مهنية، لكنها قد لا تكون منتجًا برمجيًا عميق التقنية يمكن نسخه بمضاعفات اقتصادية مجزية.

ومن جهة المشتري يمكن كتابة حدّ تقريبي للقيمة السنوية المتوقعة من الاختبارات: عدد عائلات الأعطال التي يمكن أن تمنعها قبل وصولها إلى المستخدم، مضروبًا في الاحتمال الحقيقي لحدوثها والخسارة الممكن تجنبها، مطروحًا منه تكلفة الاختبارات وتأثيرها في التطوير والسعر المدفوع. لكن احتمالات الأعطال النادرة والخسائر المضادة للواقع ليست معروفة بسهولة. لذلك يصلح التعبير إطارًا للتفكير في الشراء، ولا يجوز ملؤه بأرقام متخيلة ثم إعلان عائد استثمار (Return on Investment; ROI) مضمون.

يوجد أيضًا حرج تجاري عميق: إذا باعت الشركة «نجاح الاختبار»، صار لها حافز إلى كتابة اختبارات يسهل النجاح فيها. وإذا باعت «عدد الأعطال المكتشفة»، صار لها حافز إلى جعل الحالات أكثر غرابة وأقل صلة بالواقع. لهذا يحتاج المنتج إلى مقاييس أصعب في التلاعب: اختبارات عمياء لم تُكتب أثناء تطوير الخدمة، وحالات مضادة لا ينبغي أن تُرفض، ومقارنة مع أدوات قائمة، وتكلفة التشغيل كاملة. ليست هذه حوكمة فوق العمل؛ إنها جودة السلعة نفسها.

يمكن لنموذج لغوي أن يقرأ آلاف تقارير الحوادث بسرعة وينشئ عائلات أولية من الفروض. ويمكن لنماذج توليد الشيفرة (Code Generation Models) كتابة محوّل أو مُولِّد حالات، ثم تشغيله في معمل حاسوبي مغلق. لكن نصّ تقرير عطل ليس مواصفة كاملة للنظام الذي تعطّل. ربما أغفل التقرير واجهة داخلية، أو جرت إزالة بيانات حساسة منه، أو استعمل عبارة عامة لا تحدد ترتيب الأحداث. وما يبدو في النص «سببًا» قد يكون مصادفة زمنية أو تلخيصًا للقرار التنفيذي الأخير.

لذلك أقترح تقييم المترجم على ثلاثة مستويات مستقلة: دقة استرجاع الأدلة من التقرير (Evidence Grounding)، وصحة الصيغة التنفيذية (Executable Validity)، وصدق الحكم على سلوك النظام في بيئات جديدة (Cross-System Transfer Validity). لا يثبت المستوى الأول الثاني، ولا تضمن صحة الشيفرة الثالثة. يمكن كتابة اختبارٍ يعمل دون أخطاء ويُصدر حكمًا فاسدًا على سلوك مشروع.

وهنا تظهر إحدى أجمل مفارقات الذكاء الاصطناعي: من السهل نسبيًا جعل آلة تقترح «ما الذي ينبغي أن ينكسر»؛ الأصعب أن نجعلها تفهم ما الذي يجب أن يبقى صحيحًا حين تتغير الظروف. تلك وظيفة علوم الحاسب العميقة، من الدلالات والاتساق إلى المنطق الزمني (Temporal Logic) ونمذجة الحالات (State Modeling). كلما سهل توليد الشيفرة، ازدادت قيمة السؤال الذي يستطيع الإنسان والآلة معًا صياغته بصورة قابلة للتكذيب.

أقوى اعتراض على الفكرة لا يقول إنها سيئة، بل يقول إنها قد تكون ميزةً داخل أدوات قائمة وليست شركة مستقلة. فإذا كان بإمكان خدمة سحابية أن تولّد التجربة وتنفذها وتعرض نتيجتها من داخل منصة العميل، فما السبب الذي يدعوه إلى شراء مترجم خارجي؟ وإذا كان مشروع متخصص كـ«جيبسن» يقدم اختبارات اتساق مستقلة للأنظمة الموزعة منذ سنوات، فأين الفجوة الجديدة تحديدًا؟ وإذا كان سجل الحادثة لا يضم المواصفات الخاصة التي صنعت العطل، فكم تكلف إعادة اكتشافها لدى كل عميل؟

الإجابة ليست ادعاء التفوق. نحتاج تجربة تجارية تفصل ثلاثة احتمالات: قد تربح الحزم المتخصصة التي تُباع مع دعم محدود؛ وقد تكون الخدمة الجيدة استشارة هندسية عالية القيمة ولكنها لا تتضاعف كالبرمجيات؛ وقد يفشل كلاهما أمام أدوات مجانية أو خدمات المنصات الكبرى. ليست النتيجة الثالثة هزيمة وطنية، بل توفير مالٍ وزمن كان يمكن استثمارهما في مشكلة أخرى.

يمكن أن يُحسم ذلك باختبار دخول حقيقي: فريق سعودي صغير، حزمتان أو ثلاث لعائلات حوادث معلنة، عميلان محليان يوافقان على تجارب آمنة، ثم عملاء من دول أخرى لا يملكون سببًا لمجاملة البلد أو المؤسس. في كل عميل يُقاس زمن التثبيت، وكم سطرًا من الشيفرة تغيّر، وهل اكتشف الاختبار خللًا لا تكشفه المجموعة الحالية، وهل بقيت فائدته بعد إصدارين، وهل دُفع له ثمنٌ جديد. يجب أن يأتي الاختبار المضاد أولًا: عميل ناجح أصلًا في الاختبارات وقد لا يحتاج المنتج.

بين 2026 و2035 يمكن تصور ثلاث نهايات شرطية لهذه الفكرة. الأولى أن تُستوعب ضمن منتجات مقدمي السحابة، فيصبح من الذكاء بيع محوّلات متخصصة أو خدمات اختبار متقدمة لهم لا منافستهم على المنصة العامة. الثانية أن تستقر سوق في قطاعات تحتاج شواهد مستقلة عبر مورّدين مختلفين، فينجح منتج مستقل قادر على إثبات حدود الاختبارات ونقلها. والثالثة أن يبقى العمل استشارات متفرقة؛ معرفة هندسية نافعة، لكنها غير كافية لبناء صناعة ذات إيراد برمجي متكرر.

هذه ليست احتمالات مقدَّرة. ولكل مستقبل إشارة يمكن ملاحظتها: اعتماد المشترين على أدوات مدمجة، أو نمو العقود المتعددة الموردين، أو ارتفاع ساعات التخصيص في كل مشروع. لا يصح أن نكتب النتيجة ثم نختار من الأخبار ما يجعلها تبدو قدرًا.

أهم فرصة وطنية هنا أعمق من بناء شركة تستعمل الذكاء الاصطناعي. إنها تكوين أصل معرفي قابل للتشغيل: مسائل سبق أن واجهها العالم، نعيد صياغتها في صورة اختبارات يمكن نقلها وتشغيلها وفحصها، ثم نتعلم من الفروق بين نتيجة التجربة ونتيجة الواقع. يكتسب فريق سعودي خبرة بحثية في المكان الذي يصعب فيه على الكلمات أن تحل محل البرهان، ويكتسب العميل سلعة لا يحتاج إلى الإيمان بمجازاتها.

تُدخل المصانع التقليدية مادةً خامًا لتخرج قطعة يمكن وزنها. قد يُدخل المصنع المقترح تقرير حادثة ليخرج شرطًا يمكن تكذيبه. وإذا باع هذا الشرط مرارًا إلى مشترين مستقلين، فربما نكون أمام نواة صناعة جديدة. وإن لم يستطع، فسنكون على الأقل قد أجبنا جوابًا مفيدًا عن سؤال لم تُحلّه الأسماء اللامعة: أي جزء من خبرة الفشل يستطيع عبور الحدود دون أن يضيع معناه؟

1. Cloudflare (Matthew Prince), Cloudflare outage on November 18, 2025, 18 November 2025. https://blog.cloudflare.com/18-november-2025-outage/
2. Google Cloud, Incident details: June 12, 2025 Google Cloud service outage, original post-incident timeline and root-cause updates, 2025. https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW
3. Federal Communications Commission, Public Safety and Homeland Security Bureau, February 22, 2024 AT&T Mobility Network Outage, July 22, 2024. https://docs.fcc.gov/public/attachments/DOC-404150A1.pdf
4. Saudi Press Agency, ‘Made in Saudi’ Pavilion at GITEX AFRICA Showcases 28 Leading Tech Companies, 14 April 2025. https://www.spa.gov.sa/en/N2297562
5. Saudi Press Agency, Elm Signs MoU with Huawei to Advance Cooperation in AI and Digital Infrastructure, 9 July 2026. https://www.spa.gov.sa/en/N2630981
6. AWS, Bootstrap your chaos engineering journey with AWS Fault Injection Service Scenarios Library, 1 October 2024. https://aws.amazon.com/blogs/mt/bootstrap-your-chaos-engineering-journey-with-aws-fault-injection-service-scenarios-library/
7. AWS, Chaos engineering made clear: Generate AWS FIS experiments using natural language through Amazon Bedrock, 13 May 2025. https://aws.amazon.com/blogs/publicsector/chaos-engineering-made-clear-generate-aws-fis-experiments-using-natural-language-through-amazon-bedrock/
8. AWS, Stop conditions for AWS FIS, official documentation. https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html
9. Jepsen, Analyses and Research Ethics, author-operated research and testing documentation. https://jepsen.io/analyses and https://jepsen.io/analyses/ethics
10. Principles of Chaos Engineering, Principles of Chaos Engineering. https://principlesofchaos.org/
11. Cloud Native Computing Foundation, OpenTelemetry has graduated… Now what?, 24 July 2026. https://www.cncf.io/blog/2026/07/24/opentelemetry-has-graduated-now-what/
12. AWS, REL12-BP04 Test resiliency using chaos engineering, AWS Well-Architected Reliability Pillar. https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html
13. Author-supplied materials, Executable incident contract toy demonstration. See analysis/reproduce.py, data/contract_cases.json, data/contract_test_results.csv, data/contract_summary.csv, and data/execution_meta.json in the article package. These are explicitly artificial inputs and outputs, not observed Saudi or other operators' incidents.

العقد التنفيذي للفشل (Executable Failure Contract)؛ المترجم من الحادثة إلى الاختبار (Incident-to-Test Compiler)؛ الثابت الوظيفي (Invariant)؛ قاعدة الحكم (Test Oracle)؛ اختبار الخصائص (Property-Based Testing)؛ الاختبار التفاضلي (Differential Testing)؛ اختبار التحولات (Metamorphic Testing)؛ عاصفة إعادة المحاولة (Retry Storm)؛ الآثار الموزعة (Distributed Traces)؛ سجل شواهد التنفيذ المقترح (Execution Evidence Passport)؛ اقتصاديات الوحدة (Unit Economics)؛ القيمة القابلة للنقل (Transferable Value).

إفصاح: تحرير وتحليل بمساعدة الذكاء الاصطناعي، مع الرجوع إلى مصادر علنية. لم تُجر مقابلات أو تجارب على أنظمة إنتاجية، ولم تخضع المقالة أو الورقة المرافقة لتحكيم مستقل. المفاهيم ذات الأسماء المقترحة ليست منتجات أو معايير منشورة.