كيفية منع تحديث برنامجك من أن يكون بمثابة CrowdStrike التالي

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

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

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

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

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

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

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

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

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

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

كيفية منع الأخطاء من التسلل

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

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

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

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

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

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

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

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

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