مقاييس DORA وصحة CI/CD

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

توفر مقاييس DORA إطارًا قويًا لقياس حالة CI/CD وتحسينها، إلى جانب أداء DevOps العام.

يشير DORA إلى مجموعة أبحاث وتقييم DevOps، التي حدّدت أربعة مقاييس أساسية تتنبأ بأداء تسليم البرامج والنتائج التنظيمية.

• معدل تكرار النشر (DF)
• المدة اللازمة لإجراء التغييرات (LTFC)
• متوسط الوقت اللازم للاستعادة (MTTR)
• معدل فشل التغييرات (CFR)

لنستكشف كل مقياس منها!

يقيس معدل تكرار النشر مدى تكرار إصدار مؤسستكم للشيفرة بنجاح إلى بيئة الإنتاج. وهو يوضح مدى سرعة تمكّنكم من تقديم قيمة للمستخدمين.

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

لتتبّع معدل تكرار النشر، ما عليكم سوى عدّ عمليات النشر الناجحة إلى بيئة الإنتاج خلال فترة محددة (مثل يوميًا أو أسبوعيًا أو شهريًا).

• مثال: إذا نشر فريقكم 15 مرة في أسبوع، فإن DF لديكم يساوي 15/أسبوع.
• الهدف: زيادة هذا العدد. تنفّذ الفرق ذات الأداء المتميز عمليات نشر عدة مرات يوميًا.

المدة اللازمة لإجراء التغييرات هي الوقت الذي يستغرقه انتقال تغيير في الشيفرة من تنفيذ commit إلى تشغيله بنجاح في بيئة الإنتاج. وهي تقيس سرعة مسار التطوير بأكمله.

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

تبدأ LTFC عندما ينفّذ المطوّر commit للشيفرة، وتنتهي عندما تصبح الشيفرة متاحة للمستخدمين. وغالبًا ما تُقاس بالساعات أو الأيام.

• مثال: إذا أُجريت عملية commit لميزة صباح الاثنين وأصبحت متاحة في بيئة الإنتاج مساء الثلاثاء، فإن LTFC تساوي نحو 36 ساعة.
• الهدف: تقليل هذه المدة. فالفترات الأقصر تعني تسليمًا أسرع وتكرارًا أسرع للتحسينات.

يقيس متوسط الوقت اللازم للاستعادة (MTTR) المدة التي يستغرقها استعادة الخدمة بعد وقوع حادث أو فشل في بيئة الإنتاج. وهو يعكس قدرة فريقكم على الاستجابة للمشكلات والتعافي منها.

يشير انخفاض MTTR إلى مرونة تشغيلية قوية وإجراءات فعّالة للاستجابة للحوادث.

يُحتسب MTTR من لحظة اكتشاف الحادث إلى أن تتم استعادة الخدمة بالكامل. ويُقاس عادةً بالدقائق أو الساعات.

• مثال: إذا استغرق انقطاع تطبيق ساعتين لتحديده وتشخيصه وإصلاحه، فإن MTTR لذلك الحادث يساوي ساعتين.
• الهدف: تقليل هذه المدة. فالتعافي الأسرع يقلل أثر الحادث في المستخدمين وتعطّل الأعمال.

معدل فشل التغييرات هو النسبة المئوية للتغييرات التي تُجرى على بيئة الإنتاج وتؤدي إلى تدهور الخدمة أو تتطلب التراجع عنها أو تستلزم بأي شكل آخر معالجة فورية.

يُعد هذا المقياس بالغ الأهمية لفهم استقرار عملية النشر وموثوقيتها. ويشير ارتفاع CFR إلى وجود مشكلات في ممارسات الاختبار أو النشر.

يُحتسب CFR بقسمة عدد عمليات النشر الفاشلة على إجمالي عدد عمليات النشر خلال فترة معينة، ثم ضرب الناتج في 100.

• مثال: إذا تسببت 5 عمليات من أصل 100 عملية نشر في حادث في بيئة الإنتاج، فإن CFR لديكم يساوي 5%.
• الهدف: إبقاء هذا العدد منخفضًا قدر الإمكان. وغالبًا ما تحافظ الفرق ذات الأداء المتميز على CFR أقل من 15%.

لقد تعلّمتم مقاييس DORA الأربعة. والآن، لنختبر مدى فهمكم لما يقيسه كل مقياس منها.

تهانينا! لقد تعلّمتم مقاييس DORA الأربعة:

• تواتر النشر: مدى تكرار إصداركم للتحديثات.
• المهلة الزمنية للتغييرات: مدى سرعة وصول التعليمات البرمجية إلى بيئة الإنتاج.
• متوسط زمن الاستعادة: مدى سرعة إصلاحكم للمشكلات.
• معدل فشل التغييرات: مدى تكرار تسبب عمليات النشر في حدوث مشكلات.

من خلال تتبّع هذه المقاييس، يمكنكم الحصول على رؤى عميقة حول سلامة CI/CD وتحقيق التحسين المستمر في ممارسات DevOps لديكم.