تبدو المحاكاة الطويلة بلغة بايثون مسألة حوسبة فقط طالما يشغلها شخص واحد. ولكن ما إن يعتمد عليها عدة أشخاص، تنتقل الصعوبة إلى إدارة الطوابير، والتعافي من الأعطال، ورؤية حالة المهام، وإمكانية إعادة الإنتاج. تصل الطلبات أسرع مما تنتهي به المهام، وتنهار بعض التشغيلات في منتصف الطريق، ويتوقع الناس أن تكون النتائج السابقة قابلة لإعادة الإنتاج عند الطلب.
يرى الكاتب أن الهندسة الحقيقية تكمن في الفجوة بين برنامج يعمل وخدمة يمكن للناس الاعتماد عليها. يواجه تقييم النماذج والمعالجة الدفعية المشكلة نفسها. فتشغيل الشيفرة مرة واحدة أمر سهل، أما تشغيلها مراراً لمستخدمين كثيرين، بحيث يمكن العثور على كل تشغيل وتتبعه وتكراره دون التأثير على الآخرين، فهو عمل من نوع مختلف.
خلال العمل على البنية التحتية لمحاكاة النقل المعتمدة على AWS في Amazon UK، لم تكن الحوسبة هي الاختناق. كان سير العمل يدوياً إلى حد كبير، إذ كان المشغلون يتولون المدخلات والإعدادات وتهيئة البنية التحتية يدوياً. وكان كل طلب جديد يستهلك انتباه المهندسين قبل أن تُستخدم أي حوسبة، وكانت التشغيلات الفاشلة يصعب تتبعها لأن الأدلة كانت موزعة بين المدخلات والإعدادات والأجهزة. إن إضافة أجهزة كان سيرفع السقف النظري، لكنه لم يحل مشكلات الطوابير والعزل بين التشغيلات والتنفيذ المكرر.
لذلك تحوّل السؤال من كيفية تشغيل المحاكاة بشكل أسرع إلى كيفية تمكين عدة أشخاص من تقديم أعمالهم بأمان، ومراقبة حالة كل مهمة، والتعافي عند حدوث عطل. ويرى الكاتب أن المشكلة الأساسية، عندما يعتمد عدة أشخاص على محاكاة طويلة الأمد، هي التحكم بالمهام، وهي تنقسم إلى اهتمامات أصغر: الطوابير، وإدارة الحالة، والعزل، والتعافي، والتتبع.
المصدر: Towards Data Science · لخّصه HeadlinesBriefing