ما يمكن أن تعلمك إياه كل عملية إصدار عن التسليم
وصل إصدار جديد إلى بيئة الإنتاج. اجتازت جميع الاختبارات. بدت بيئة الاختبار جيدة. وافق مدير المنتج على الميزة. بدا كل شيء جيدًا على الورق.
بعد عشرين دقيقة، بدأ زمن الاستجابة في الارتفاع. ليس بشكل كبير، لكنه ملحوظ. استغرقت عملية ترحيل قاعدة البيانات التي كانت تعمل في أقل من دقيقة أثناء الاختبار خمس دقائق على بيانات الإنتاج. بدأ المستخدمون في الإبلاغ عن بطء الصفحات. هرع الفريق للتحقيق.
هذا ليس سيناريو فشل. هذا هو يوم ثلاثاء عادي.
سيتم إصلاح الإصدار الذي تسبب في التباطؤ. لكن الفرصة الحقيقية تكمن في ما يحدث بعد ذلك: ما يتعلمه الفريق من هذا الإصدار وكيف يستخدمون تلك المعرفة لتحسين الإصدار التالي.
القيمة الحقيقية للإصدار هي التغذية الراجعة
عند بناء خط أنابيب CI/CD، من المغري قياس النجاح بسلاسة عمليات النشر. بنيات خضراء، خطوط أنابيب سريعة، عدم وجود استرجاع. هذه المقاييس تشعرك بالرضا. لكنها تفتقد الهدف.
كل عملية نشر، سواء سارت بشكل مثالي أو تسببت في حادث، تحتوي على معلومات. الإصدار الذي أبطأ الإنتاج يخبرك شيئًا عن استراتيجية بيانات الاختبار الخاصة بك. الميزة التي لا يستخدمها أحد تخبرك شيئًا عن كيفية التحقق من صحة الافتراضات. الترحيل الذي استغرق وقتًا أطول من المتوقع يخبرك شيئًا عن دقة بيئة الاختبار.
السؤال هو ما إذا كان فريقك يلتقط تلك المعلومات بشكل منهجي أم يتركها تتلاشى في الذاكرة حتى الاستعراض التالي.
توقف عن انتظار الحوادث الكبيرة للتعلم
تقوم العديد من الفرق بإجراء تحليلات ما بعد الحادث فقط عندما يحدث شيء سيء بشكل كبير. انقطاع كبير، فقدان بيانات، خطأ يواجه العملاء ويصبح خبرًا. تحليلات ما بعد الحادث هذه ضرورية، لكنها تفقد معظم فرص التعلم.
المفاجآت الصغيرة لا تقل أهمية. النشر الذي استغرق ضعف الوقت المعتاد. التنبيه الذي انطلق لكن لم يلاحظه أحد. الاسترجاع الذي تطلب تنسيق ثلاثة أشخاص عبر الدردشة. هذه إشارات على وجود فجوة في عمليتك.
تحليل ما بعد الحادث الجيد لا يسأل من ارتكب الخطأ. يسأل ما الذي في النظام سمح بحدوث هذا الخطأ. لماذا ذهب التغيير إلى جميع المستخدمين بدلاً من طرح تدريجي؟ لماذا لم يتم تشغيل أي تنبيه قبل وصول الأخطاء إلى حد معين؟ لماذا استغرقت إجراءات الاسترجاع وقتًا أطول من المتوقع؟
يجب أن ينتج كل تحليل ما بعد الحادث إجراءً ملموسًا واحدًا بالضبط يمكن للفريق البدء فيه الأسبوع المقبل. ليس قائمة طويلة من التحسينات التي تُحفظ وتُنسى. شيء واحد. قم به. ثم انتقل إلى التالي.
استخدم المقاييس لطرح الأسئلة، وليس لإلقاء اللوم
المقاييس الأربعة الرئيسية من أبحاث DORA - تكرار النشر، زمن الوصول للتغييرات، معدل فشل التغيير، ووقت استعادة الخدمة - هي أدوات مفيدة. لكنها تصبح مدمرة عندما تعاملها الفرق كأهداف أداء.
عندما ينخفض تكرار النشر، لا تلوم الفريق. اسأل ما الذي تغير. هل أدى تغيير في البنية التحتية إلى إبطاء خط الأنابيب؟ هل يعمل الفريق على ميزة كبيرة يصعب تقسيمها إلى أجزاء أصغر؟ هل أصبحت عملية المراجعة عنق زجاجة؟
عندما يزيد معدل فشل التغيير، لا تضف المزيد من بوابات الموافقة. انظر إلى أنواع التغييرات التي تفشل في أغلب الأحيان. ربما تتسبب تغييرات قاعدة البيانات دائمًا في مشاكل. ربما تستمر التغييرات في وحدة قديمة بدون تغطية اختبارية في الانهيار. يخبرك النمط أين تستثمر جهد التحسين التالي.
المقاييس هي أدوات تشخيصية، وليست بطاقات تقرير. استخدمها للعثور على الشيء التالي الذي يجب إصلاحه، وليس لتقييم من يؤدي بشكل جيد.
أدخل ملاحظات المستخدمين في دورة التعلم
لا يقتصر CI/CD على سرعة وصول الكود إلى الإنتاج. يتعلق بمدى سرعة تعلم الفريق ما إذا كان هذا الكود يساعد المستخدمين بالفعل.
الميزة التي تجتاز جميع الاختبارات الفنية لكن لا يستخدمها أحد هي فشل لا يمكن لأي خط أنابيب اكتشافه. التدفق المربك الذي يبعد المستخدمين غير مرئي للوحات مراقبة الأداء. الصفحة البطيئة التي يتحملها المستخدمون لكن يشكون منها في تذاكر الدعم هي إشارة قد تفوتها مقاييسك.
بعد كل إصدار، انظر إلى بيانات الاستخدام. هل يستخدم الأشخاص الميزة الجديدة؟ هل تغير سلوك المستخدم بعد التحديث؟ هل هناك تذاكر دعم تذكر شيئًا لم تلتقطه مراقبتك؟
لا يتطلب هذا منصة تحليلات معقدة. أحيانًا تكون نظرة سريعة على السجلات، أو محادثة مع دعم العملاء، أو استبيان بسيط كافيًا. المفتاح هو جعله عادة، وليس مشروعًا خاصًا.
بناء روتين تعلم صغير
التعلم من كل إصدار لا يعني عقد اجتماع بعد كل عملية نشر. يعني بناء عادات صغيرة ومتسقة.
بعد خمس دقائق من الإصدار، انظر إلى المقاييس والسجلات. ليس غوصًا عميقًا، مجرد فحص سريع. هل تغير زمن الاستجابة؟ هل الأخطاء طبيعية؟ هل هناك شيء غير معتاد؟
بعد حادث، اقضِ خمس عشرة دقيقة في كتابة ما حدث وما يمكن تحسينه. ليس مستندًا رسميًا، مجرد ملاحظات تلتقط النقاط الرئيسية. شاركها مع الفريق.
مرة واحدة في الشهر، انظر إلى الأنماط عبر جميع الإصدارات. هل تتسبب أنواع معينة من التغييرات في مشاكل باستمرار؟ هل هناك تحسينات يتم تأجيلها باستمرار؟ هل يقضي الفريق وقتًا طويلاً على جزء واحد من خط الأنابيب؟
هذه الروتينات لا تستغرق الكثير من الوقت. لكن على مدى أشهر، تتراكم لتشكل مجموعة من المعرفة تجعل كل إصدار مستقبلي أكثر سلاسة.
قائمة تحقق عملية للتعلم من الإصدارات
- بعد كل نشر، اقضِ خمس دقائق في فحص المقاييس والسجلات
- بعد أي حادث، اكتب تحليلًا قصيرًا لما بعد الحادث مع عنصر إجراء واحد ملموس
- راجع أنماط النشر شهريًا للعثور على المشكلات المتكررة
- انظر إلى بيانات الاستخدام بعد إصدارات الميزات، وليس فقط المقاييس الفنية
- عندما يتغير مقياس، اسأل ماذا حدث بدلاً من إلقاء اللوم
- حافظ على إجراءات التحسين صغيرة ومركزة على شيء واحد في كل مرة
الإصدار ليس النهاية
يقوم خط أنابيب CI/CD بأتمتة آليات التسليم. لكن القيمة الحقيقية تأتي مما يحدث بعد تشغيل الكود في الإنتاج. كل إصدار، سواء كان سلسًا أو مؤلمًا، يحتوي على دروس تجعل الإصدار التالي أفضل.
الفرق التي تتحسن بأسرع ما يمكن ليست تلك التي لديها أكثر خطوط الأنابيب تطورًا. إنها تلك التي تعامل كل عملية نشر كمصدر للمعلومات. يلتقطون ما يتعلمونه، يعملون به، ويستمرون في التحرك.
كل إصدار ليس نهاية دورة. إنه بداية الدورة التالية.