أخطاء البيانات الصامتة تعيد تعريف اختبار المعالجات وصيانة أساطيل الخوادم

تكشف أخطاء البيانات الصامتة، أو فساد البيانات الصامت (Silent Data Errors/Silent Data Corruption)، عن فجوة متزايدة بين اجتياز الشريحة لاختبارات التصنيع التقليدية وبين قدرتها على إنتاج نتائج صحيحة طوال فترة تشغيلها. فقد يمر المعالج باختبارات ATPG واختبارات عيوب الانتقال والعيوب العالقة والاختبارات البنيوية عند السرعة، ثم ينفذ عملية حسابية بطريقة خاطئة من دون تسجيل عطل واضح، قبل أن تنتقل النتيجة الفاسدة إلى تطبيق أو مهمة تدريب للذكاء الاصطناعي.

تستند هذه القراءة إلى تحليل نشرته Semiconductor Engineering في 10 سبتمبر 2026، ويجمع آراء ونتائج من Advantest وSiemens EDA وNXP وSynopsys وIntel وMeta وGoogle وproteanTecs. ولا يتعلق الأمر بإطلاق منتج محدد، بل بتحول في طريقة تعريف جودة المعالج واختبار تغطيته وإدارته بعد وصوله إلى مركز البيانات.

مشكلة نادرة على مستوى الشريحة، واسعة على مستوى الأسطول

تبدو أخطاء البيانات الصامتة نادرة عند قياسها على جهاز منفرد، لكنها تصبح متكررة ومكلفة عندما تعمل ملايين المعالجات بمعدلات استخدام مرتفعة. وتشير تحليلات مبكرة من Google وMeta إلى أن هذه الأخطاء قد تصيب خادماً واحداً من كل ألف، بما يعادل مستوى يتراوح بين 100 و1,000 جزء معيب في المليون. وحتى معدل يبلغ 10 FIT، أي عطل واحد لكل مليار ساعة تشغيل، يمكن أن يعني وقوع خطأ كل أربعة أيام تقريباً عند نشر 10 ملايين جهاز.

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

لماذا تفشل الاختبارات التقليدية؟

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

تقدر الصناعة أن نحو 80% من أخطاء التنفيذ الفاسدة مرتبطة بعيوب تفلت من اختبارات وقت الصفر، بينما تظهر نسبة 20% المتبقية بصورة متقطعة أو نتيجة التقادم. لكن اختبار جميع التركيبات الممكنة للجهد والتردد والحرارة والعمر ونوع الحمل غير عملي. كما أن ربط عطل ظهر على مستوى النظام بنمط عيب محدد في اختبار الشريحة قد يستغرق أسابيع ويتطلب تعاون فرق التصميم والاختبار وتحليل الأعطال وتكامل الأنظمة.

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

اختبار أعمق من المصنع إلى مركز البيانات

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

توضح تجربة Intel حجم التحدي. فبعد اختبار 1.2 مليون معالج عبر خمسة أجيال من معالجات Intel Xeon، احتاجت الشركة إلى أكثر من 1,000 اختبار وظيفي في مجموعة DCDiag، وإلى 5,000 اختبار إجهاد اصطناعي لرصد عيوب الأخطاء الصامتة. ولم تكن الاختبارات موزعة بالتساوي على العيوب؛ إذ أمكن كشف نحو 50% من الأجزاء المعيبة باستخدام 5% فقط من الاختبارات، بينما احتاج كشف 90% من الأخطاء إلى أكثر من نصف الاختبارات الألف. كما أظهرت النتائج أن أكثر من 70% من العيوب لم يكشفها سوى اختبار واحد، وأن وصفة الاختبار الفعالة لجيل من المنتجات لم تكن قابلة للنقل مباشرة إلى الجيل التالي.

ما الذي يتغير عملياً في الأساطيل؟

لا تتوقف الاستجابة عند بوابة المصنع. تستخدم شركات تشغيل مراكز البيانات طبقات من الفحص البرمجي والاختبار الميداني لعزل الخوادم أو الأنوية التي تظهر سلوكاً غير طبيعي. لدى Meta، يخرج برنامج Fleetscanner الخادم من الخدمة ويشغله على اختبارات حسابية ذات نتائج معروفة، بينما ينفذ برنامج Ripple أنماطاً قصيرة أثناء التشغيل الطبيعي. أما Hardware Sentinel فيحلل استثناءات التطبيقات وسلوك النظام من دون تخصيص أحمال اختبار، وذكرت Meta أنه حسّن الكشف بنسبة 40% مقارنة بالأساليب القائمة على الاختبار عبر معماريات وتطبيقات ومراكز بيانات مختلفة.

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

من اختبار الشحن إلى إدارة دورة حياة السيليكون

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

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