طابور المهام

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

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

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

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

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