التراث الشعبي للمبرمجين والمهندسين (الجزء الأول)

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

حساسية السيارة تجاه آيس كريم الفانيليا

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

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

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

جاء المهندس ثلاث أمسيات أخرى. أول مرة كان الآيس كريم شوكولاتة. بدأت السيارة. المرة الثانية كان هناك آيس كريم الفراولة. بدأت السيارة. وفي الليلة الثالثة طلب تناول الفانيليا. السيارة لم تبدأ.

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

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

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

العبرة: حتى المشاكل المجنونة تكون حقيقية في بعض الأحيان.

Crash Bandicoot

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

هذه هي قصتي حول خطأ الأجهزة.

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

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

بعد فترة، بدأت منتجتنا في شركة سوني، كوني باص، بالذعر. لم نتمكن من شحن اللعبة مع هذا الخطأ، وبعد ستة أسابيع لم أفهم سبب المشكلة. من خلال كوني، اتصلنا بمطوري PS1 الآخرين: هل واجه أي شخص شيئًا مشابهًا؟ لا. لم يكن أحد لديه مشاكل مع بطاقة الذاكرة.

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

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

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

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

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

في وقت ما، ربما حوالي الساعة الثالثة صباحًا، خطرت في بالي فكرة. تتضمن عمليات القراءة والكتابة (الإدخال/الإخراج) أوقات تنفيذ دقيقة. عند العمل باستخدام محرك أقراص ثابتة أو بطاقة ذاكرة أو وحدة Bluetooth، فإن الكود منخفض المستوى المسؤول عن القراءة والكتابة يفعل ذلك وفقًا لنبضات الساعة.

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

ماذا لو كان هناك شيء في الكود الخاص بنا يربك التوقيت؟ لقد قمت بفحص كل ما يتعلق بهذا في كود برنامج الاختبار ولاحظت أننا قمنا بضبط المؤقت القابل للبرمجة في PS1 على 1 كيلو هرتز (1000 نقرة في الثانية). هذا كثير جدًا، بشكل افتراضي، عند بدء تشغيل وحدة التحكم، يتم تشغيلها بسرعة 100 هرتز. ومعظم الألعاب تستخدم هذا التردد.

قام آندي، مطور اللعبة، بضبط المؤقت على 1 كيلو هرتز حتى يتم حساب الحركات بشكل أكثر دقة. يميل آندي إلى المبالغة في الأمور، وإذا قمنا بمحاكاة الجاذبية، فإننا نفعل ذلك بأكبر قدر ممكن من الدقة!

ولكن ماذا لو كان تسريع المؤقت يؤثر بطريقة أو بأخرى على التوقيت العام للبرنامج، وبالتالي على الساعة التي تنظم معدل الباود لبطاقة الذاكرة؟

لقد علقت على رمز الموقت. الخطأ لم يحدث مرة أخرى. لكن هذا لا يعني أننا أصلحناه، لأن العطل حدث بشكل عشوائي. ماذا لو كنت محظوظا فقط؟

وبعد بضعة أيام قمت بتجربة برنامج الاختبار مرة أخرى. ولم يتكرر الخلل. لقد عدت إلى قاعدة بيانات اللعبة الكاملة وقمت بتعديل رمز الحفظ والتحميل بحيث تتم إعادة تعيين المؤقت القابل للبرمجة إلى قيمته الأصلية (100 هرتز) قبل الوصول إلى بطاقة الذاكرة، ثم إعادة التعيين مرة أخرى إلى 1 كيلو هرتز. لم يكن هناك المزيد من الأعطال.

لكن لماذا حدث هذا؟

لقد عدت إلى برنامج الاختبار مرة أخرى. لقد حاولت العثور على نمط ما في حدوث خطأ باستخدام مؤقت 1 كيلو هرتز. في النهاية لاحظت أن الخطأ يحدث عندما يلعب شخص ما باستخدام وحدة تحكم PS1. نظرًا لأنني نادرًا ما أفعل ذلك بنفسي - فلماذا أحتاج إلى وحدة تحكم عند اختبار كود الحفظ والتحميل؟ - لم ألاحظ حتى هذا الاعتماد. لكن في أحد الأيام كان أحد فنانينا ينتظرني حتى أنهي الاختبار - ربما كنت أشتم في تلك اللحظة - وقام بتدوير وحدة التحكم بين يديه بعصبية. حدث خطأ. "انتظر ماذا؟!" حسنًا، افعلها مرة أخرى!"

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

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

اتصل بي المهندس وتجادلنا بلغته الإنجليزية المكسورة واليابانية المكسورة (للغاية). أخيرًا قلت: "اسمح لي أن أرسل برنامج الاختبار المكون من 30 سطرًا حيث يؤدي تحريك وحدة التحكم إلى حدوث خطأ." هو وافق. وقال إن ذلك كان مضيعة للوقت وأنه كان مشغولاً للغاية بالعمل على مشروع جديد، لكنه سيستسلم لأننا كنا مطورين مهمين للغاية لشركة Sony. قمت بتنظيف برنامج الاختبار الخاص بي وأرسلته إليه.

في مساء اليوم التالي (كنا في لوس أنجلوس وكان هو في طوكيو) اتصل بي واعتذر بخجل. لقد كانت مشكلة في الأجهزة.

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

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

الأبقار السيئة

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

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

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

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

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

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

من خلال الأنابيب

ذات مرة، قامت شركة Movietech Solutions بإنشاء برنامج لدور السينما، مصمم للمحاسبة ومبيعات التذاكر والإدارة العامة. حظي إصدار DOS من التطبيق الرئيسي بشعبية كبيرة بين سلاسل دور السينما الصغيرة والمتوسطة الحجم في أمريكا الشمالية. لذلك ليس من المستغرب أنه عندما تم الإعلان عن إصدار Windows 95، المتكامل مع أحدث شاشات اللمس وأكشاك الخدمة الذاتية، والمزود بجميع أنواع أدوات إعداد التقارير، سرعان ما أصبح هذا الإصدار شائعًا أيضًا. في أغلب الأحيان تم التحديث دون مشاكل. قام موظفو تكنولوجيا المعلومات المحليون بتركيب معدات جديدة وترحيل البيانات واستمرت الأعمال. إلا عندما لم يستمر. وعندما حدث ذلك، أرسلت الشركة جيمس الملقب بـ "المنظف".

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

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

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

- لم يعودوا إلى النظام القديم؟ - أجاب جيمس بجدية تامة، على الرغم من أنه قام بتوسيع عينيه عقليًا في مفاجأة.

- بالضبط: قام متخصص تكنولوجيا المعلومات لديهم "بتغيير أولوياته" وقرر المغادرة مع خادمهم القديم. جيمس، لقد قاموا بتثبيت النظام في ستة مواقع ودفعوا للتو مقابل الدعم المتميز، ويتم تشغيل أعمالهم الآن كما كانت في الخمسينيات.

استقام جيمس قليلا.

- وهذا أمر آخر. حسنًا، لنبدأ.

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

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

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

-هل أنت عامل نظافة؟ - جاء صوت أجش من الداخل.

- نعم، هذا أنا... جئت لإصلاح كل شيء.

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

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

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

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

ثم دخل أحد الموظفين

– النظام يعمل مرة أخرى.

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

- النظام معطل.

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

ضغط جيمس على الزر واختفى النمط. سارع إلى مكتب التذاكر وفي الطريق التقى بموظف عائد إليه.

– النظام يعمل مرة أخرى.

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

عاد جيمس إلى غرفة الخادم، وقام بتسجيل الدخول، واستبدل شاشة التوقف بالأنابيب الجميلة ذات الشاشة الفارغة. وهذا هو، بدلا من شاشة التوقف التي تستهلك 100٪ من موارد المعالج، قمت بتثبيت شاشة أخرى لا تستهلك الموارد. ثم انتظرت 10 دقائق للتحقق من تخميني.

عندما وصل جيمس إلى السينما التالية، كان يتساءل كيف يشرح لمديره أنه قد طار للتو مسافة 800 كيلومتر لإيقاف تشغيل شاشة التوقف.

تحطم خلال مرحلة معينة من القمر

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

الطبعة الورقية الأولى ملف المصطلحات (Steele-1983) يحتوي على مثال لمثل هذا السطر الذي أدى إلى الخطأ الموصوف، لكن آلة الطباعة "أصلحته". وقد تم وصف هذا منذ ذلك الحين بأنه "خلل في مرحلة القمر".

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

تنظيف المرحاض يوقف القطار

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

خلال إحدى عمليات التفتيش، ذهب مهندس مسافر في القطار إلى المرحاض. سرعان ما جرفته المياه، بوم! التوقف في حالات الطوارئ.

اتصل المهندس بالسائق وسأله:

- ماذا كنت تفعل قبل الفرملة مباشرة؟

- حسنًا، لقد تباطأت في النزول..

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

- انا ذاهب لإبطاء.

لم يحدث شيء.

- ماذا فعلت أثناء الكبح الأخير؟ - سأل السائق.

-حسنا...كنت في المرحاض...

- حسنًا، اذهب إلى المرحاض وافعل ما فعلته عندما ننزل مرة أخرى!

ذهب المهندس إلى المرحاض، وعندما حذر السائق: "أنا أبطئ"، قام بشطف الماء. وبالطبع توقف القطار على الفور.

الآن يمكنهم إعادة إنتاج المشكلة ويحتاجون إلى العثور على السبب.

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

البوابة التي كرهت FORTRAN

منذ بضعة أشهر لاحظنا أن اتصالات الشبكة في البر الرئيسي [كان ذلك في هاواي] أصبحت بطيئة جدًا جدًا. يمكن أن يستمر هذا لمدة 10-15 دقيقة ثم يحدث فجأة مرة أخرى. وبعد مرور بعض الوقت، اشتكى لي زميلي من انقطاع اتصالات الشبكة في البر الرئيسي بشكل عام لا يعمل. كان لديه بعض رموز FORTRAN التي يلزم نسخها إلى جهاز في البر الرئيسي، لكن لم يكن من الممكن ذلك لأن "الشبكة لم تصمد لفترة كافية لإكمال تحميل FTP."

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

عندما قمنا بفحص المقاطع الإشكالية، اكتشفنا أن لديها شيئًا مشتركًا: فهي جميعها تحتوي على كتل تعليق تبدأ وتنتهي بأسطر تتكون من حرف C الكبير (كما فضل أحد الزملاء التعليق باستخدام لغة FORTRAN). أرسلنا بريدًا إلكترونيًا إلى خبراء الشبكة في البر الرئيسي وطلبنا المساعدة. بالطبع أرادوا رؤية نماذج من ملفاتنا التي لا يمكن نقلها عبر FTP... لكن رسائلنا لم تصلهم. وأخيراً توصلنا إلى فكرة بسيطة يصفكيف تبدو الملفات غير القابلة للتحويل. لقد نجحت :) [هل أجرؤ على إضافة مثال لأحد تعليقات FORTRAN الإشكالية هنا؟ ربما لا يستحق كل هذا العناء!]

في النهاية تمكنا من معرفة ذلك. تم مؤخرًا تركيب بوابة جديدة بين الجزء الخاص بنا من الحرم الجامعي وشبكة البر الرئيسي. كان يواجه صعوبة كبيرة في إرسال الحزم التي تحتوي على أجزاء متكررة من الأحرف الكبيرة C! يمكن لعدد قليل فقط من هذه الحزم أن تشغل جميع موارد البوابة وتمنع معظم الحزم الأخرى من الوصول إليها. لقد اشتكينا إلى الشركة المصنعة للبوابة... فأجابوا: "أوه، نعم، أنت تواجه خطأً متكررًا في لغة C! نحن نعرف عنه بالفعل." لقد قمنا في النهاية بحل المشكلة عن طريق شراء بوابة جديدة من شركة مصنعة أخرى (دفاعًا عن الشركة الأولى، قد تكون عدم القدرة على نقل برامج FORTRAN ميزة للبعض!).

اوقات صعبة

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

في الأيام الخوالي، كانت أجهزة كمبيوتر أبل تقوم أحيانًا تلقائيًا بإعادة ضبط تاريخها إلى الأول من يناير عام 1. كان السبب بسيطًا: فقد استخدم "ساعة النظام" التي تعمل بالبطارية لتتبع التاريخ والوقت. ماذا حدث عندما نفدت البطارية؟ بدأت أجهزة الكمبيوتر في تتبع التاريخ بعدد الثواني منذ بداية العصر. كنا نعني بالعصر التاريخ الأصلي المرجعي، وبالنسبة لأجهزة Macintoshes، كان التاريخ هو 1904 يناير 1. وبعد نفاد البطارية، تمت إعادة تعيين التاريخ الحالي إلى التاريخ المحدد. ولكن لماذا حدث هذا؟

في السابق، كانت شركة Apple تستخدم 32 بت لتخزين عدد الثواني منذ التاريخ الأصلي. يمكن للبت الواحد تخزين إحدى القيمتين - 1 أو 0. يمكن للبتتين تخزين إحدى القيم الأربع: 00، 01، 10، 11. ثلاث بتات - قيمة واحدة من أصل ثمانية: 000، 001، 010، 011، 100 ، 101، 110، 111، الخ. ويمكن للرقم 32 تخزين قيمة واحدة من 232 قيمة، أي 4 ثانية. بالنسبة لتواريخ Apple، فإن هذا يعادل حوالي 294 عامًا، لذلك لا تستطيع أجهزة Mac القديمة التعامل مع التواريخ بعد عام 967. وإذا نفدت بطارية النظام، تتم إعادة ضبط التاريخ على 296 ثانية منذ بداية العصر، وعليك ضبط التاريخ يدويًا في كل مرة تقوم فيها بتشغيل الكمبيوتر (أو حتى تشتري بطارية جديدة).

إلا أن قرار آبل بتخزين التواريخ بالثواني منذ العصر يعني عدم قدرتنا على التعامل مع التواريخ التي تسبق العصر، مما كان له عواقب بعيدة المدى، كما سنرى. قدمت شركة Apple ميزة، وليس خطأً. ومن بين أمور أخرى، كان هذا يعني أن نظام تشغيل ماكنتوش كان محصنًا ضد "خطأ الألفية" (وهو ما لا يمكن قوله عن العديد من تطبيقات ماك التي كانت لديها أنظمة تاريخ خاصة بها للتحايل على القيود).

تفضل. استخدمنا Lotus 1-2-3، "التطبيق القاتل" لشركة IBM والذي ساعد في إطلاق ثورة الكمبيوتر الشخصي، على الرغم من أن أجهزة كمبيوتر Apple كانت تحتوي على VisiCalc، الأمر الذي جعل الكمبيوتر الشخصي ناجحًا. في الإنصاف، إذا لم تظهر 1-2-3، فمن الصعب أن تقلع أجهزة الكمبيوتر الشخصية، وكان من الممكن أن يتطور تاريخ أجهزة الكمبيوتر الشخصية بشكل مختلف تمامًا. لوتس 1-2-3 تعامل بشكل غير صحيح مع عام 1900 على أنه سنة كبيسة. عندما أصدرت مايكروسوفت أول جدول بيانات لها، Multiplan، استحوذت على حصة صغيرة من السوق. وعندما أطلقوا مشروع Excel، قرروا ليس فقط نسخ نظام تسمية الصفوف والأعمدة من Lotus 1-2-3، ولكن أيضًا ضمان توافق الأخطاء من خلال التعامل مع عام 1900 عمدًا على أنه سنة كبيسة. ولا تزال هذه المشكلة موجودة حتى اليوم. أي أنه في 1-2-3 كان هذا خطأً، ولكن في Excel كان قرارًا واعيًا يضمن أن جميع المستخدمين 1-2-3 يمكنهم استيراد جداولهم إلى Excel دون تغيير البيانات، حتى لو كانت غير صحيحة.

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

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

في Excel، يمكن تمثيل تاريخ 5 يوليو 1998 بالتنسيق "07-05-98" (النظام الأمريكي عديم الفائدة)، أو "5 يوليو 98"، أو "5 يوليو 1998"، أو "5 يوليو 98" أو تنسيق آخر، تنسيق آخر عديم الفائدة (ومن المفارقات أن أحد التنسيقات التي لم يقدمها إصدار Excel الذي أستخدمه هو ISO 8601). ومع ذلك، ضمن الجدول، تم تخزين التاريخ غير المنسق كـ "35981" للعصر 1900 أو "34519" للعصر 1904 (تمثل الأرقام عدد الأيام منذ العصر). لقد استخدمت ببساطة محللًا بسيطًا لاستخراج السنة من التاريخ المنسق، ثم استخدمت محلل Excel لاستخراج السنة من التاريخ غير المنسق. إذا اختلفت القيمتان بمقدار 4 سنوات، فقد علمت أنني كنت أستخدم نظامًا مع Epoch-1904.

لماذا لم أستخدم التواريخ المنسقة فقط؟ لأنه يمكن تنسيق 5 يوليو 1998 كـ "يوليو 98" مع فقدان اليوم من الشهر. لقد تلقينا جداول من العديد من الشركات التي أنشأتها بعدة طرق مختلفة، وكان الأمر متروكًا لنا (في هذه الحالة، أنا) لمعرفة التواريخ. علاوة على ذلك، إذا نجح برنامج Excel في تحقيق ذلك، فيجب علينا أيضًا القيام بذلك!

في الوقت نفسه، واجهت 39082. اسمحوا لي أن أذكركم أن لوتس 1-2-3 اعتبرت 1900 سنة كبيسة، وقد تكرر هذا بأمانة في Excel. وبما أن هذا أضاف يومًا واحدًا إلى عام 1900، فقد تكون العديد من وظائف حساب التاريخ خاطئة في ذلك اليوم بالذات. أي أن الرقم 39082 كان من الممكن أن يكون 1 يناير 2011 (على أجهزة Mac) أو 31 ديسمبر 2006 (على نظام Windows). إذا استخرج "محلل السنة" الخاص بي عام 2011 من القيمة المنسقة، فكل شيء على ما يرام. ولكن نظرًا لأن محلل Excel لا يعرف ما هو العصر المستخدم، فإنه يتم تعيينه افتراضيًا على Epoch-1900، ويعيد العام 2006. رأى طلبي أن الفارق كان 5 سنوات، واعتبره خطأ، وقام بتسجيله، وأعاد قيمة غير منسقة.

للتغلب على هذا، كتبت هذا (الكود الكاذب):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

وبعد ذلك تم تحليل جميع التواريخ البالغ عددها 40 بشكل صحيح.

في منتصف مهام الطباعة الكبيرة

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

لقد أعادوا تصميم محركات الأقراص بحيث يمكن أن يكون لديهم محرك أقراص مركزي واحد "A" متصل بسبعة محركات أقراص "B"، ويمكن لنظام التشغيل الصغير في ذاكرة الوصول العشوائي الذي يتحكم في محرك الأقراص "A" تفويض عمليات القراءة والكتابة لجميع محركات الأقراص "B".

في كل مرة يتم فيها تشغيل محرك الأقراص "A"، كان من الضروري إدخال قرص مرن في محرك الأقراص المحيطي المتصل بالمحرك "A" من أجل تحميل نظام التشغيل في ذاكرته. لقد كانت بدائية للغاية: تم توفير الطاقة الحاسوبية بواسطة وحدة تحكم دقيقة 8 بت.

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

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

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

ثم اتصل الفنيون بالمقر واستدعوا الخبير.

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

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

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

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

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

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

إنه المد العالي!

حدثت القصة في غرفة الخادم، في الطابق الرابع أو الخامس من مكتب في بورتسموث (على ما أظن)، في منطقة المرافئ.

في أحد الأيام، تعطل خادم Unix مع قاعدة البيانات الرئيسية. لقد أعادوا تشغيله، لكنه استمر في السقوط بسعادة مرارًا وتكرارًا. قررنا الاتصال بشخص ما من خدمة الدعم.

رجل الدعم... أعتقد أن اسمه كان مارك، لكن هذا لا يهم... لا أعتقد أنني أعرفه. لا يهم، حقا. دعنا نبقى مع مارك، حسنًا؟ عظيم.

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

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

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

في منتصف اليوم تقريبًا، يتعطل الخادم (خذ الأمور ببساطة!). يبدو من المعقول هذه المرة الاستعانة بأشخاص دعم الأجهزة لاستبدال الخادم. لكن لا، بعد حوالي 10 ساعات يسقط أيضًا.

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

مر الأسبوع خاليًا من الهموم... وكان الجميع سعداء. سعيد حتى يبدأ كل شيء من جديد. الصورة هي نفسها. 10 ساعات عمل، 2-3 ساعات راحة.

ثم قال أحدهم (أعتقد أنهم أخبروني أن هذا الشخص لا علاقة له بتكنولوجيا المعلومات):

"إنه المد!"

قوبلت علامة التعجب بنظرات فارغة، وربما ترددت يد شخص ما عند زر الاتصال الأمني.

"إنه يتوقف عن العمل مع المد."

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

"في الأسبوع الماضي كان المد منخفضا، لكنه مرتفع هذا الأسبوع."

القليل من المصطلحات لأولئك الذين ليس لديهم رخصة لليخوت. يعتمد المد والجزر على الدورة القمرية. وبينما تدور الأرض، كل 12,5 ساعة، تخلق جاذبية الشمس والقمر موجة مد وجزر. في بداية الدورة التي تبلغ مدتها 12,5 ساعة، يكون هناك مد مرتفع، وفي منتصف الدورة يوجد انحسار، وفي النهاية يحدث مد مرتفع مرة أخرى. ولكن مع تغير مدار القمر، يتغير أيضًا الفرق بين المد والجزر المنخفض والمرتفع. عندما يكون القمر بين الشمس والأرض أو على الجانب الآخر من الأرض (البدر أو عدم وجود القمر)، نحصل على المد والجزر Syzygyn - أعلى المد والجزر وأدنى المد والجزر. عند نصف القمر نحصل على المد والجزر التربيعي - أدنى المد والجزر. الفرق بين الطرفين يتضاءل بشكل كبير. تستمر الدورة القمرية 28 يومًا: الزيجي - التربيعي - الزيجي - التربيعي.

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

مهمة الطيران للصاروخ

لقد تم تكليفي بنقل نظام كبير للتحكم في إطلاق الصواريخ ومراقبتها (حوالي 400 ألف سطر) إلى الإصدارات الجديدة من نظام التشغيل والمترجم واللغة. بتعبير أدق، من Solaris 2.5.1 إلى Solaris 7، ومن نظام تطوير Verdix Ada (VADS)، المكتوب في Ada 83، إلى نظام Rational Apex Ada، المكتوب في Ada 95. تم شراء VADS بواسطة Rational، وكان منتجها هو عفا عليه الزمن، على الرغم من أن Rational حاول تنفيذ إصدارات متوافقة من الحزم الخاصة بـ VADS لتسهيل الانتقال إلى مترجم Apex.

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

وفي يوم الجمعة الذي سبق عيد الشكر، رن الهاتف.

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

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

وقد تم الاهتمام بي باعتباري الشخص الذي قام بنقل النظام.

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

لقد قمنا باستدعاء الأشخاص من Apex إلى Rational لأنهم هم الذين طوروا المترجم وتم استدعاء بعض الإجراءات الروتينية التي طوروها في التعليمات البرمجية المشبوهة. لقد انبهروا (والجميع) بالحاجة إلى الوصول إلى جذور المشكلة ذات الأهمية الوطنية بالمعنى الحرفي للكلمة.

نظرًا لعدم وجود أي شيء مثير للاهتمام في المجلات، قررنا محاولة إعادة إنتاج المشكلة في مختبر محلي. لم تكن هذه مهمة سهلة حيث أن الحدث وقع مرة واحدة تقريبًا لكل 1000 مرة. أحد الأسباب المشتبه بها هو استدعاء وظيفة كائن المزامنة (mutex) التي طورها البائع (جزء من حزمة ترحيل VADS) Unlock لم يؤدي إلى فتح. يقوم مؤشر ترابط المعالجة الذي يطلق عليه الوظيفة بمعالجة رسائل نبضات القلب، والتي تصل اسميًا كل ثانية. قمنا برفع التردد إلى 10 هرتز، أي 10 مرات في الثانية، وبدأنا في التشغيل. وبعد حوالي ساعة أغلق النظام نفسه. في السجل، رأينا أن تسلسل الرسائل المسجلة كان هو نفسه أثناء الاختبار الفاشل. وقمنا بعدة عمليات تشغيل أخرى، وتم حظر النظام باستمرار بعد 45 إلى 90 دقيقة من البداية، وفي كل مرة كان السجل يحتوي على نفس المسار. على الرغم من أننا كنا نقوم بتشغيل تعليمات برمجية مختلفة من الناحية الفنية - كان تردد الرسالة مختلفًا - إلا أن سلوك النظام كان هو نفسه، لذلك كنا واثقين من أن سيناريو التحميل هذا كان يسبب نفس المشكلة.

نحن الآن بحاجة إلى معرفة مكان حدوث الحجب بالضبط في تسلسل التعبيرات.

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

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

لفهم أي سطر من التعليمات البرمجية كان يسبب المشكلة، كنت بحاجة إلى إيجاد طريقة لتسجيل التقدم من خلال سلسلة من البيانات دون تشغيل مفتاح تبديل المهام، وهو ما قد يمنع حدوث عطل. لذلك لم أتمكن من الاستفادة Put_Line()لتجنب إجراء عمليات الإدخال/الإخراج. يمكنني تعيين متغير عداد أو شيء مشابه، ولكن كيف يمكنني رؤية قيمته إذا لم أتمكن من عرضه على الشاشة؟

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

كان هذا هو الدليل اللازم لتقييم تعبير الحظر.

لقد قمت بإنشاء حزمة Ada تحتوي على مهمة ونوع معدود ومتغير عام من هذا النوع. تم ربط عدد لا يحصى من القيم الحرفية بتعبيرات محددة للتسلسل الإشكالي (على سبيل المثال: Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked)، ثم أدخلت فيه تعبيرات المهمة التي خصصت التعداد المقابل لمتغير عام. نظرًا لأن كود الكائن لكل هذا يخزن ببساطة ثابتًا في الذاكرة، فإن تبديل المهام نتيجة لتنفيذه كان غير مرجح للغاية. كنا متشككين في المقام الأول من التعبيرات التي يمكنها تبديل المهمة، نظرًا لأن الحظر حدث عند التنفيذ بدلاً من العودة عند تبديل المهمة مرة أخرى (لعدة أسباب).

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

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

قمت بتشغيل الكود مع التتبع. لقد تجمد. وعملت المراقبة كالساعة.

يحتوي السجل على التسلسل المتوقع، والذي تمت مقاطعته بقيمة تشير إلى أنه تم استدعاء كائن المزامنة (mutex). Unlockولم تكتمل المهمة، كما هو الحال مع آلاف المكالمات السابقة.

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

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

لقد أدخلته في الكود وأجريت الاختبار. وبعد سبع ساعات كان الرمز لا يزال يعمل.

تم إرسال الكود الخاص بي إلى Rational، حيث قاموا بتجميعه وتفكيكه والتحقق من أنه لا يستخدم نفس الأسلوب الذي تم استخدامه في وظائف كائن المزامنة (mutex) التي بها مشكلات.

كانت هذه هي مراجعة التعليمات البرمجية الأكثر ازدحامًا في مسيرتي المهنية 🙂 كان معي حوالي عشرة مهندسين ومديرين في الغرفة، وكان عشرة أشخاص آخرين في مكالمة جماعية - وقاموا جميعًا بفحص حوالي 20 سطرًا من التعليمات البرمجية.

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

حسنًا، كل هذا جيد وجيد، لكن ما المغزى من القصة؟

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

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

لقد فهمت طبيعة المشكلة. لم أكن أعرف بالضبط أين كان يحدث أو لماذا، لكنني كنت أعرف ما كان يحدث.

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

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

لحل المشكلات الصعبة حقًا، عليك أن تكون أكثر من مجرد مبرمج. أنت بحاجة إلى فهم "مصير" الكود، وكيف يتفاعل مع بيئته، وكيف تعمل البيئة نفسها.

ومن ثم سيكون لديك أسبوع عطلتك المدمر.

أن تستمر.

المصدر: www.habr.com