ماذا علينا أن نتعلم من عطل كراود سترايك؟

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

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

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

أنا أكره هذه الأشياء، لطالما كرهتها، لا أستطيع تحملها، تدفعني للجنون.

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

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

أحسنتم، هذا هو العالم الذي بنيناه. تهانينا. 

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

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

ماذا  يعني ذلك في عالم البرمجيات؟

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

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

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

"وحين ننتقل إلى دائرة العمل ـ المعلوماتي، لم يعد رأس المال يُجنِّد الناس، بل يشتري حُزَما من الزمن، منفصلةً عن حامليها المؤقتين والقابلين للتبادل. الزمن اللا ـ شخصي هو الآن الفاعل الحقيقي لسيرورة إكساب القيمة، والزمن اللا ـ شخصي ليس له حقوق." فرانكو (بيفو) براردي - من كتاب "الروح في العمل: من الاستلاب إلى الاستقلال الذاتي"

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

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

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