ربما لا يزال الكثيرون منكم يستذكرون الاضطراب الذي أحدثته ما عُرفت بـ "مشكلة عام 2000" (Y2K) عند مطلع القرن الماضي. حسناً، نطلق الآن تحذيراً مفاده أن هذا السيناريو قد يتكرر خلال سنوات قليلة مقبلة، وتحديداً في القطاع التكنولوجي.
تحذرنا بعض الكيانات حالياً من أن أعداداً هائلة من الأجهزة والأنظمة قد تبدأ في إظهار سلوكيات غير متوقعة بتاريخ 19 يناير 2038. وتشمل الأعطال المحتملة أخطاء في معالجة المدفوعات عبر البطاقات، وإطلاق إنذارات أمنية غير صحيحة، وتعطّل في المعدات الطبية، وغيرها الكثير. وعلى الرغم من أن هذا التاريخ لا يزال بعيداً نسبياً، إلا أن هذا لا يمثل سبباً للتراخي، فقد لا يكون الوقت المتاح للاستعداد كافياً على الإطلاق.
يكمن السبب الرئيسي وراء هذه المشاكل الوشيكة في تجاوز سعة الأعداد الصحيحة المستخدمة لتخزين بيانات التاريخ والوقت على الأجهزة. وفي حين أن السبب الجذري للخطأ واضح ومباشر، فإن عملية إصلاحه ستتطلب جهداً هائلاً على كافة المستويات. وسيؤثر هذا التحدي على الحكومات والمنظمات الدولية، بالإضافة إلى الشركات والمستخدمين النهائيين على حدٍ سواء.
من المهم إدراك أنه خلال عصر يونكس (Unix)، انتشر نظام حساب الوقت الذي تبنته هذه الأنظمة على نطاق واسع في مختلف البيئات التقنية. يقوم هذا النظام بحساب الثواني بدءاً من الساعة 00:00:00 بالتوقيت العالمي المنسق (UTC) في 1 يناير 1970، والتي تُعتبر نقطة الصفر (Epoch). وبالنسبة للتواريخ التي تسبق عام 1970، يتم استخدام قيم سالبة. لقد اختار مطورو يونكس هذا النهج بسبب بساطته. واليوم، يُستخدم هذا النظام على نطاق أوسع بكثير من مجرد أنظمة يونكس؛ فهو سائد في قواعد البيانات، ولغات البرمجة، وبروتوكولات الشبكات، وحتى في أنظمة التشغيل مثل iOS وأندرويد.
ومع ذلك، في البداية، كانت هذه الطريقة تخزن الوقت كعدد صحيح موقع (Signed Integer) مكون من 32 بت. وقد أتاح ذلك تمثيل فترة زمنية تمتد تقريباً من عام 1901 حتى عام 2038. تكمن العقدة في أنه في 19 يناير 2038، عند الساعة 03:14:07 بالتوقيت العالمي المنسق (UTC)، سيصل هذا العدد إلى أقصى قيمة له وسيتجاوز الحد المسموح به، ليتحول إلى قيمة سالبة. ومن هنا ينشأ الخطأ الذي سيقع في تلك اللحظة الزمنية.
قد يؤدي هذا الحدث، المعروف باسم مشكلة عام 2038 أو Y2K38، إلى أعطال مشابهة لتلك التي ذكرناها سابقاً. وستطال هذه الأعطال أجهزة نقاط البيع (POS)، والأنظمة المدمجة، وأجهزة التوجيه (Routers)، والسيارات، والمعدات الصناعية.
الحلول المقترحة لمواجهة تأثير Y2K38
من الضروري معرفة أن الأنظمة الحديثة تتغلب على هذه المشكلة باستخدام 64 بت لتخزين التاريخ والوقت. لذا، إذا كان لديك نظام تشغيل مبني على بنية 64 بت، فلن تواجه أي متاعب. ومع ذلك، لا تزال ملايين الحواسيب التي تعتمد على تخزين تاريخ 32 بت قيد التشغيل، وستحتاج إلى تحديث أو استبدال قبل حلول ذلك اليوم. في الحالات التي لا تتطلب التعامل مع تواريخ سابقة لعام 1970، يتم تخزين التاريخ كعدد صحيح غير موقع (Unsigned Integer) 32 بت، والذي يمكنه تمثيل التواريخ من عام 1970 حتى عام 2106.
في الوقت ذاته، يكمن الاختلاف الجوهري بين مشكلة عام 2038 ومشكلة عام 2000 في النطاق الهائل للتحول الرقمي الذي نعيشه اليوم. إن عدد الأنظمة التي تتطلب تحديثات حالياً يفوق بكثير ما كان عليه الأمر في عام 2000.
في هذه المرحلة، وكما نعلم الآن، تم بالفعل وضع الأساس اللازم لحل مشكلة عام 2038 بنجاح في أنظمة التشغيل الرئيسية. أضافت نواة لينكس دعماً لأنظمة 64 بت حتى على معمارية 32 بت بدءاً من الإصدار 5.6 في عام 2020. وفي المقابل، تستخدم لغات مثل جافا وبايثون وجو عادةً أنواع بيانات تمنع تجاوز السعة، لكن أمان المشاريع المجمّعة (Compiled Projects) يعتمد على تفاعلها مع المكتبات الضعيفة المكتوبة بلغة سي (C).
وبالفعل، لا يزال عدد كبير من أنظمة وأجهزة وتطبيقات 32 بت عرضة بشدة لهذه الثغرة الزمنية. والآن، أصبحت الطرق المبتكرة لتصحيح الثغرات الأمنية قابلة للتطبيق على مشكلة عام 2038. لكن التحدي الأكبر يكمن في عدم توفر أداة شاملة قادرة حالياً على إنشاء قائمة دقيقة بالبرامج والأجهزة المعرضة لهذه الثغرة تحديداً.
من الضروري تحديث قائمة أصول الشركة والتأكد من احتوائها على تفاصيل دقيقة حول البرامج الثابتة (Firmware) والبرامج المثبتة على الأجهزة المعرضة للخطر. يجب أن يتم ترتيب الأولويات بناءً على مدى أهمية أنظمة العمل والبيانات التي يعالجها كل نظام. والخطوة التالية هي التشاور مع دعم الموردين، والتواصل مع مصنعي الأجهزة والبرامج للاستفسار عن وضعهم فيما يتعلق بمشكلة عام 2038، وكحل أخير، يجب التحقق من كل شيء بدقة من خلال إجراء الاختبارات اللازمة.
ما هي النقطة الزمنية الدقيقة التي سيحدث فيها تجاوز سعة التاريخ في أنظمة 32 بت؟
النقطة الزمنية الحرجة هي 19 يناير 2038، عند الساعة 03:14:07 بالتوقيت العالمي المنسق (UTC)، حيث يصل العدد الصحيح الموقع (32 بت) الذي يمثل الثواني منذ عام 1970 إلى أقصى قيمة له ثم يعود إلى الصفر (قيمة سالبة)، مما يسبب الخلل.
هل يؤثر هذا التحدي على أنظمة تشغيل 64 بت الحديثة؟
بشكل عام، لا تؤثر مشكلة عام 2038 مباشرة على أنظمة التشغيل 64 بت لأنها تستخدم مساحة تخزين أكبر بكثير (64 بت) تسمح بتمثيل التواريخ حتى ما بعد عام 292 مليار، لكن الخطر يكمن في المكتبات القديمة المكتوبة بلغة C التي قد تستخدمها هذه الأنظمة.
ما هو التشابه الرئيسي بين مشكلة 2038 ومشكلة عام 2000؟
التشابه يكمن في أن كلتا المشكلتين ناتجة عن حدود تصميمية قديمة (نقص في عدد الخانات المخصصة لتخزين السنة أو الوقت)، مما يؤدي إلى فشل النظام عند الوصول إلى سقف محدد مسبقاً.
ما هي الخطوة الأولى التي يجب على الشركات اتخاذها للتحضير لـ Y2K38؟
الخطوة الأولى والأكثر أهمية هي إجراء جرد وتحديث شامل لقائمة أصول الشركة، مع تحديد البرامج الثابتة والبرمجيات المثبتة عليها، لتحديد مدى تعرضها لخطر الاعتماد على نظام التوقيت 32 بت.
هل هناك حلول تخزينية بديلة تمنع تجاوز سعة التاريخ لبعض الأنظمة القديمة؟
نعم، في بعض الحالات التي لا تتطلب التعامل مع تواريخ ما قبل 1970، يمكن استخدام تخزين التاريخ كعدد صحيح غير موقع 32 بت، مما يمد عمر النظام حتى عام 2106، ولكن هذا ليس حلاً شاملاً لجميع السيناريوهات.
🔎 في الختام، بينما يبدو تحدي "مشكلة عام 2038" بعيد المنال مقارنة بضغوط العمل اليومية، إلا أنه يمثل تحدياً وجودياً للبنية التحتية الرقمية المعتمدة على تقنيات قديمة. إن الاستباقية في تحديد الأصول المعرضة للخطر واعتماد حلول 64 بت أو استراتيجيات الترقية المناسبة ليست مجرد إجراء وقائي، بل هي ضرورة لضمان استمرارية الأعمال وتجنب تكرار فوضى تاريخية كبرى في عالم التكنولوجيا.
قم بالتعليق على الموضوع