فولكلور المبرمجين والمهندسين (الجزء الأول)

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

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

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

, , , . : . , , , , . Pontiac, . , , , . , . , , : « Pontiac, - , , , ?».

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



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



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



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



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



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

كراش بانديكوت

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



ها هي قصتي عن خلل في الأجهزة.



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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

أبقار سيئة

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



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



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



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



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



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

عبر الأنابيب

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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



- النظام يعمل من جديد.



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



- النظام يكذب.



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





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



- النظام يعمل من جديد.



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



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



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

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

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



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



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

شطف المرحاض يوقف القطار

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



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



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



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



- حسنًا ، لقد أبطأت سرعة النزول ...



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



- سوف أبطئ.



لم يحدث شيء.



- ماذا فعلت بالفرملة الأخيرة؟ - سأل السائق.



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



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



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



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



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

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

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



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



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



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

اوقات صعبة

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



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



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



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



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



لكن كانت هناك مشكلة أخرى. أصدرت Microsoft لأول مرة برنامج 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 سنوات ، فقد فهمت أنني كنت أستخدم النظام مع حقبة 1904.



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



ثم ركضت إلى 39082. دعني أذكرك أن Lotus 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

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

في خضم مهام الطباعة الكبيرة

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



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



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



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



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



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



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



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



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



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



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



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



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

إنه المد!

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



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



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



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



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



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



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



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



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



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



"هذا هو المد!"



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



"توقف عن العمل مع التيار".



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



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



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



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

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

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



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



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



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



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



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



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



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



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



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



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



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



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



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



كان الخطاف ضروريًا لتقييم تعبير الحظر.



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



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



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



أطلقت رمز التتبع. تم تجميده. وعملت المراقبة كالساعة.



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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

---

يتبع.