هل من الضروري حظر النشر إلى الإنتاج في أوقات معينة؟ أو أصبحت حركة
#NoDeployFriday من بقايا العصر الذي لم تكن فيه اختبارات تكامل شاملة ونشر مستمر؟
في فريقك ، قد تواجه نفس المعضلة. من هو الصحيح ومن يقع اللوم؟ هل التخلي عن النشر يوم الجمعة هو استراتيجية معقولة للحد من المخاطر ، أم أنها ثقافة ضارة تمنعنا من إنشاء أنظمة أفضل وأكثر استقرارًا؟
أقرع دينغ
أنا متأكد من أن المهندسين الذين حظوا بفرصة "التواصل" فقدوا أيام العطلة بسبب كل التغييرات التي حدثت يوم الجمعة. كنت في هذا الموقف أيضا. مكالمة هاتفية عند الخروج مع عائلتك أو في منتصف الليل ، لإعلامك بتعطل التطبيق. بعد الدخول إلى جهاز الكمبيوتر والتحقق من السجلات سريعة النمو ، يصبح من الواضح أن كل شيء تم تدميره بواسطة استثناء نادر غير معالج. مثير للاشمئزاز.
يكشف التحليل أنه بالنسبة للسيناريو الذي أدى إلى الفشل ، لم تتم كتابة أي اختبارات ، على ما يبدو لأنه لم يكن محتملاً. بعد سلسلة من المكالمات الهاتفية المطولة مع المهندسين الآخرين بحثًا عن طريقة أفضل لاستعادة التغييرات وإصلاح كل شيء ، يبدأ النظام في العمل مرة أخرى. تفو.
يعقد اجتماع خمسة أسباب يوم الاثنين.
"
دعونا نتوقف عن النشر يوم الجمعة. ثم في نهاية الأسبوع ، سيعمل كل شيء بثبات ، وفي الأسبوع القادم سنكون في حالة تأهب بعد كل أنواع الإصدارات ."
إيماءات الجميع. إذا لم يتم تشغيل شيء ما قبل الظهر يوم الخميس ، فسيتم الانتظار حتى صباح الاثنين. هل هذا النهج يضر أم يساعد؟
كما تعلم ، غالبًا ما تكون بيانات Twitter ذاتية للغاية. على الرغم من أن حظر إصدارات الجمعة يبدو معقولًا ، إلا أن شخصًا ما سيشير بسرعة إلى أن هذا مجرد عكاز نظرًا لضعف هشاشة النظام الأساسي ، بسبب سوء عمليات الاختبار والنشر.
يقترح البعض أنك تحب النشر الهادئ أكثر من عطلة نهاية الأسبوع نفسها:
يعتقد المستخدمون الآخرون أن تنفيذ علامات الوظائف قد يكون حلاً ممكنًا.
يعتقد هذا المستخدم أن مشاكل النشر المحفوف بالمخاطر يجب ألا تنشأ بسبب العمليات والأدوات المتاحة لنا اليوم.
من الذي يتخذ القرارات؟
يشير كل هذا التبادل للآراء إلى أننا ، كمجتمع من المهندسين ، يمكننا أن نختلف بشدة ولا نتفق بالضرورة مع بعضنا البعض. من كان يظن. ربما يوضح هذا الموقف أيضًا أن الصورة العامة باستخدام #NoDeployFriday تحتوي على مثل هذه الفروق الدقيقة التي لا تنعكس جيدًا على Twitter. هل صحيح أننا جميعا يجب أن نطبق النشر المستمر ، وإلا فإننا "نفعل ذلك خطأ"؟
في اتخاذ مثل هذا القرار ، هناك جانب نفسي. تأتي العداء لإطلاق سراح الجمعة من الخوف من ارتكاب أخطاء خلال الأسبوع (بسبب التعب أو الاندفاع) ، والتي يمكن أن تلحق الضرر بينما يستريح معظم الموظفين لمدة يومين. نتيجة لذلك ، يمكن أن يفسد التزام الجمعة الذي يحتوي على مشكلة محتملة عطلة نهاية الأسبوع لمجموعة من الناس: مهندسون واجبون ، ومهندسون آخرون سيساعدون عن بُعد في حل المشكلة ، وربما متخصصون في البنية التحتية يتعين عليهم استعادة البيانات التالفة. إذا تبين أن الفشل خطير ، فقد يشارك أيضًا موظفو الشركة الآخرون في الموقف ، والذين سيحتاجون إلى الاتصال بالعملاء وتقليل الضرر.
عند اتخاذ موقف المثالي ، يمكننا أن نفترض أنه في عالم مثالي مع رمز مثالي وتغطية اختبار مثالية وضمان الجودة المثالي ، لا توجد تغييرات يمكن أن تؤدي إلى مشكلة. لكننا أناس ، ويميل الناس إلى ارتكاب الأخطاء. سيكون هناك دائمًا بعض الحالات الحدودية الغريبة التي لم يتم إغلاقها أثناء التطوير. هذه هي الحياة. لذا فإن حركة #NoDeployFriday منطقية ، على الأقل من الناحية النظرية. ومع ذلك ، هذه ليست سوى أداة أعمى. أعتقد أنه من الضروري تقييم التغييرات التي تم إجراؤها اعتمادًا على الموقف ، ومن الضروري أن نبدأ من حقيقة أننا ننشر في أي يوم ، حتى يوم الجمعة ، ولكن في نفس الوقت يجب أن نتمكن من عزل تلك التغييرات التي يجب أن تنتظر حتى يوم الاثنين.
هناك بعض القضايا التي يمكننا مناقشتها. لقد قسمتهم إلى فئات:
- فهم "نصف قطر التدمير" للتغيير.
- سلامة عملية النشر.
- القدرة على اكتشاف الأخطاء تلقائيا.
- كم من الوقت يستغرق لحل المشاكل.
الآن دعونا نناقش.
فهم "نصف قطر الدمار"
عندما تبدأ مرة أخرى في كسر الرماح على الإنترنت يوم الجمعة ، فإنهم ينسون دائمًا الأهمية - حول طبيعة التغييرات ذاتها. لا توجد تغييرات مماثلة في قاعدة الكود. بعض الالتزامات تحكم الواجهة قليلاً ولا شيء أكثر ؛ refactor الآخرين مئات الفئات دون التأثير على وظائف البرنامج ؛ لا يزال البعض الآخر يغير مخططات قاعدة البيانات وإجراء تغييرات كبيرة على عملية استهلاك البيانات في الوقت الفعلي ؛ يمكن للرابع إعادة تشغيل مثيل واحد ، في حين أن أخماس يمكن بدء إعادة تشغيل تتالي لجميع أنواع الخدمات.
عند النظر إلى الكود ، يجب أن يكون لدى المهندسين فكرة جيدة عن "نصف قطر التدمير" للتغيرات التي تم إجراؤها. أي جزء من الكود والتطبيق سوف يتأثر؟ ماذا يمكن أن تسقط إذا تعطل الرمز الجديد؟ هل هو مجرد نقرة على زر من شأنه أن يلقي خطأ ، أو سوف تضيع جميع الإدخالات الجديدة؟ هل تم إجراء تغيير على خدمة معزولة واحدة ، أم هل ستتغير العديد من الخدمات والتبعيات في وقت واحد؟
لا أستطيع أن أتخيل من سيرفض إجراء تغييرات باستخدام "نصف قطر دمار" صغير ونشر بسيط في أي يوم من أيام الأسبوع. ولكن في الوقت نفسه ، يجب إجراء تغييرات كبيرة - خاصة تلك المتعلقة بالبنية الأساسية للتخزين - بشكل أكثر دقة ، وربما في وقت يكون فيه عدد المستخدمين على الإنترنت أقل. سيكون من الأفضل لو تم تشغيل مثل هذه التغييرات الواسعة النطاق بالتوازي مع اختبار وتقييم عملهم تحت عبء حقيقي ، ولن يعرف أحد عن ذلك.
هنا تحتاج إلى اتخاذ قرارات حسب الموقف. هل يدرك كل مهندس "نصف قطر التدمير" للتغيرات في بيئة الإنتاج ، وليس فقط في بيئة التطوير؟ إذا لم يكن كذلك ، لماذا؟ هل من الممكن تحسين التوثيق والتدريب وعرض تأثيرات تغييرات الكود في الإنتاج؟
هل "نصف قطر الدمار" صغير؟ إطلاق يوم الجمعة.
هل "نصف قطر الدمار" كبير؟ انتظر حتى الاثنين.
سلامة عملية النشر
تتمثل إحدى طرق تقليل المخاطر في التحسين المستمر لعملية النشر. إذا كان لبدء إصدار جديد من التطبيق ، فلا يزال من الضروري بالنسبة للمتخصص معرفة البرنامج النصي المطلوب تشغيله ، والملف الذي يجب نسخه ، ثم حان الوقت لتولي الأتمتة. في السنوات الأخيرة ، تقدمت الأدوات في هذا المجال إلى الأمام. غالبًا ما نستخدم
Jenkins Pipeline and
Concourse ، فهي تسمح لك بتعيين خطوط أنابيب التجميع والاختبار والنشر مباشرة مع الكود.
تعتبر عملية النشر الكامل للنشر أمرًا مثيرًا للاهتمام. يتيح لك التراجع ومحاولة استخراج ما يجب أن يحدث منذ اللحظة التي تتم فيها تهيئة طلب السحب حتى يتم تشغيل التطبيق. سيساعدك وصف لجميع الخطوات في الكود ، على سبيل المثال ، في الأدوات المذكورة أعلاه ، على تعميم تعريفات الخطوات وإعادة استخدامها في جميع التطبيقات. بالإضافة إلى ذلك ، سيكون من المثير للاهتمام بالنسبة لك أن تلاحظ بعض القرارات الغريبة أو الكسلية التي اتخذتها ذات يوم والتي تصالحت معها.
لكل مهندس قرأ الفقرتين السابقتين ورد في أسلوب "حسنًا بالطبع! لقد تم القيام بذلك منذ سنوات! أستطيع أن أضمن أن 9 آخرين قدّموا البنية التحتية للتطبيقات الخاصة بهم وقللوا من حجمها ، وأدركوا حجم العمل الذي يجب القيام به لنقل النظام إلى خط أنابيب نشر حديث. يتضمن ذلك الاستفادة من الأدوات الحديثة التي لا تؤدي تكاملًا مستمرًا فحسب ، بل تتيح لك أيضًا توفير الأخطاء باستمرار للمنتج ، ويحتاج المهندسون فقط إلى الضغط على الزر للتكليف (أو حتى القيام بذلك تلقائيًا إذا كنت شجاعًا بما يكفي).
يتطلب تحسين ناقل النشر مشاركة وموظفين مناسبين - وهذا بالتأكيد ليس مشروعًا جانبيًا. والحل الجيد هو تسليط الضوء على فريق لتحسين الأدوات الداخلية. إذا كانوا لا يزالون لا يعرفون عن المشكلات الحالية - وربما يعرفون - فيمكنك جمع معلومات عن أكثر المواقف إيلاما المرتبطة بعملية الإطلاق ، ثم تحديد الأولويات وحلها مع الآخرين. سيتم تحسين الموقف ببطء ولكن بثبات: سيتم تشغيل الرمز بشكل أسرع ومع وجود مشاكل أقل. سيتمكن المزيد والمزيد من الأشخاص من تعلم أساليب أفضل وإجراء تحسينات بمفردهم. مع تحسن الموقف ، سيتم توزيع النهج في فرق ، وسيتم الانتهاء من هذا المشروع الجديد بشكل صحيح ، دون نسخ المعتاد من العادات السيئة القديمة.
من لحظة الدمج ، يجب أن يكون طلب السحب إلى الالتزام آليًا حتى لا تحتاج حتى للتفكير فيه. هذا لا يساعد فقط في عزل المشاكل الحقيقية في ضمان الجودة ، لأن المتغير الوحيد هو الكود الذي تم تغييره ، ولكنه يجعل كتابة الكود أكثر إمتاعًا. التكليف لا مركزي ، مما يزيد من الاستقلالية الشخصية والمسؤولية. وهذا بدوره يؤدي إلى اتخاذ قرارات أكثر تعمداً فيما يتعلق بموعد وكيفية طرح مدونة جديدة.
ناقل نشر موثوق؟ طرح يوم الجمعة.
نسخ البرامج النصية يدويا؟ انتظر حتى الاثنين.
القدرة على اكتشاف الأخطاء
التكليف لا يتوقف بعد أن يبدأ الكود في العمل. إذا حدث خطأ ما ، فنحن بحاجة إلى معرفة ذلك ، ومن المستحسن أن يتم إطلاعنا على ذلك ، وليس من الضروري البحث عن معلومات بمفردنا. للقيام بذلك ، تحتاج إلى فحص سجلات التطبيق تلقائيًا بحثًا عن الأخطاء ، وتتبع مقاييس المفاتيح بشكل صريح (على سبيل المثال ، عدد الرسائل التي تتم معالجتها في الثانية ، أو نسبة الأخطاء) ، بالإضافة إلى نظام تحذير يُعلم المهندسين بالمشاكل الحرجة ويظهر اتجاهًا سلبيًا لبعض المقاييس.
تختلف العملية دائمًا عن التطوير ، ويحتاج المهندسون إلى مراقبة تشغيل أجزاء معينة من النظام. تحتاج إلى إجابة أسئلة حول كل تغيير لاحق: هل أدى إلى تسريع أو إبطاء النظام؟ هناك أكثر أو أقل من المهلات؟ هل نحن مقيدون بالمعالج أو I / O؟
يجب إرسال بيانات المقاييس والأخطاء إلى نظام التحذير. يجب أن تكون الفرق قادرة على تحديد الإشارات التي تشير إلى موقف سلبي ، وإرسال رسائل تلقائية حول هذا الموضوع. لفرقنا والحوادث الأكثر خطورة ، نستخدم PagerDuty.
يعني قياس مقاييس نظام الإنتاج أن المهندسين يمكنهم معرفة ما إذا كان هناك شيء قد تغير بعد كل عملية نشر ، للأفضل أو للأسوأ. وفي أسوأ الحالات ، سيقوم النظام تلقائيًا بإبلاغ شخص ما بالمشكلة.
مراقبة جيدة ، والإخطارات والمتخصصين عند الطلب؟ نشر يوم الجمعة.
عرض سجلات يدويا عبر سه؟ انتظر حتى الاثنين.
كم من الوقت يستغرق لحل المشاكل؟
أخيرًا ، المعيار الرئيسي هو المدة التي سيستغرقها حل المشكلات. يعتمد هذا جزئيًا على "نصف قطر الضرر" للتغيرات التي تم إجراؤها. حتى إذا كان لديك خط أنابيب نشر مسدود ، فمن الصعب إصلاح بعض التغييرات بسرعة. قد يتطلب التراجع عن التغييرات في نظام استخراج البيانات وفي مخطط فهرس البحث إعادة فحص شاقة ، بالإضافة إلى إصلاح بعض سطر التعليمات البرمجية. قد يستغرق متوسط نشر تغييرات CSS والتحقق منها وتصحيحها وإعادة نشرها دقائق ، بينما قد تتطلب التغييرات الرئيسية في المستودع أيام عمل.
بالنسبة لجميع الأعمال التي تتم داخل خط أنابيب النشر ، والتي على مستوى الماكرو يمكن أن تزيد من موثوقية التغييرات ، لا توجد تغييرات هي نفسها ، لذلك تحتاج إلى تقييمها بشكل منفصل. إذا حدث خطأ ما ، فهل يمكننا إصلاحه بسرعة؟
هل هو ثابت بالكامل مع التزام استعادة واحدة؟ نشر يوم الجمعة.
هل هناك صعوبات كبيرة إذا حدث خطأ ما؟ انتظر حتى الاثنين.
فكر بنفسك ، قرر بنفسك
ما هو موقفي في #NoDeployFriday؟ أعتقد أن كل هذا يتوقف على الإصدار. يمكن نشر التغييرات ذات "دائرة نصف قطرها" الصغيرة التي يسهل استرجاعها في أي وقت وفي أي يوم. مع التغييرات الكبيرة ، التي يجب مراقبة تأثيرها عن كثب في نظام الإنتاج ، أوصي بشدة بالانتظار حتى يوم الاثنين.
في الواقع ، الأمر متروك لك للنشر يوم الجمعة. إذا كنت تعمل بنظام صعب وهش ، فمن الأفضل تجنب أيام الجمعة حتى تقوم بكل ما يلزم لتحسين عملية النشر. فقط تأكد من القيام بذلك ، لا تنزعها. رفض إصدار الجمعة هو وسيلة طبيعية للتغطية على عيوب البنية التحتية المؤقتة. هذا هو الحد من الأضرار معقولة لصالح الشركة. ولكن من السيء أن تغطي هذه القاعدة العيوب المستمرة.
إذا لم تكن متأكدًا من التأثير الذي ستحدثه التغييرات ، فاجئه حتى يوم الاثنين. لكن فكر فيما يمكنك القيام به في المرة القادمة لفهم هذا التأثير بشكل أفضل ، وتحسين البنية الأساسية المرتبطة بذلك. كما هو الحال دائمًا في الحياة ، كل قرار له فروقه الخاصة. لا يتم تقسيم الحلول إلى "أسود" و "أبيض" ، إلى "صواب" و "خطأ": بينما نقوم بكل ما في وسعنا من أجل الأعمال والتطبيقات وبعضنا البعض ، وتحسين أنظمتنا ، فإننا نقوم بكل شيء جيدًا.
النشر الناجح.