ما المقصود بمقاييس DORA؟

طوّر فريق Google لأبحاث وتقييم DevOps (DORA) مقاييس DORA لتوفير معايير قياسية معتمدة في القطاع لقياس تسليم البرمجيات ومدى نضج ممارسات DevOps.

تركّز مقاييس DORA في جوهرها على بُعدين:

1. معدل الإنتاج: مدى سرعة إرسال فرق DevOps للبرمجيات.
   
   
2. الاستقرار: مدى قدرة فرق DevOps على تسليم البرمجيات بموثوقية وأمان.

تكشف المقاييس الموجّهة نحو معدل الإنتاجية مدى سرعة انتقال تغييرات التعليمات البرمجية عبر دورة حياة تطوير البرمجيات، من الفكرة إلى الإنتاج، بينما تُظهر المقاييس الموجّهة نحو الاستقرار مدى تكرار تعطّل عمليات النشر وسرعة تعافي الفِرق. ومعًا، تمنح هذه المقاييس قادة الأعمال وفرق DevOps رؤى قائمة على الأدلة وقابلة للتكرار حول أداء DevOps. ولا تحتاج الشركات إلى الاعتماد على مقاييس أداء ذاتية أو مؤشرات سطحية مثل "عدد أسطر التعليمات البرمجية المكتوبة" أو "ساعات العمل".

يمكّن تتبّع مقاييس DORA فرق DevOps من معرفة موقعها مقارنةً بمستويات الأداء المعترف بها في القطاع، وهي: منخفض، ومتوسط، وعالٍ، ونخبوي، ومعرفة ما إذا كانت متوائمة مع الأهداف على مستوى المؤسسة. ويساعد الشركات على تحديد معوقات الأداء بموضوعية في مسارات CI/CD، واختبار البرمجيات، وإدارة الحوادث.   

كما تسهّل مقاييس DORA على القيادة توضيح حالة أقسام الهندسة للأطراف المعنية بالأعمال، وتبرير الاستثمارات في أدوات الأتمتة المتقدمة وقابلية الملاحظة وهندسة موثوقية المواقع (SRE)، وهي أدوات تساعد على تحسين ممارسات DevOps.

في سياق DevOps، تشير DORA إلى فريق أبحاث وتقييم DevOps الذي أسهم في نشر مقاييس أداء المؤسسات بين فرق تطوير البرمجيات.

بدأت DORA، التي أصبحت الآن جزءًا من Google Cloud، كمشروع بحثي مستقل درس أثر عمليات تسليم البرمجيات في نتائج الأعمال. وكان فريق DORA يسعى إلى الإجابة عن سؤال أساسي واحد: ما الذي يميّز فرق البرمجيات عالية الأداء عن الفرق ذات الأداء المنخفض؟

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

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

يمكن تصنيف مقاييس DORA الخمسة ضمن فئتين رئيسيتين: "معدل الإنتاجية" و"الاستقرار".

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

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

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

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

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

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

من منظور القيادة، يمكن أن يكشف تتبّع تكرار النشر بمرور الوقت عن معوقات في مسار تسليم البرمجيات. فعلى سبيل المثال، قد يشير انخفاض تكرار النشر بعد استحداث لجنة موافقات جديدة إلى أن العملية أصبحت مثقلة بالإجراءات. وعلى العكس، فإن الزيادة المطردة في تكرار النشر، متى اقترنت بتحسّن مقاييس الموثوقية، تُعد مؤشرًا قويًا على أن الاستثمارات في مسارات CI/CD وممارسات DevOps بدأت تؤتي ثمارها.

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

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

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

ويتطلب تقليل مدة إنجاز التغيير، في معظم الحالات، أن تعمل فرق DevOps على أتمتة مسار التسليم وتبسيطه. وتشمل هذه العملية عادةً الاستثمار في أدوات التكامل المستمر (CI)، بحيث يجري بناء كل إيداع واختباره بسرعة، إلى جانب تبسيط عمليات الموافقة بحيث تُدمج الموافقات ضمن مهام سير عمل التطوير.  

يقيس وقت التعافي من عمليات النشر الفاشلة، ويُسمى أيضًا متوسط وقت التعافي (MTTR) أو متوسط وقت استعادة الخدمة، المدة التي تستغرقها استعادة الخدمة إلى وضعها الطبيعي بعد حدوث فشل مرتبط بعملية نشر.

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

وعندما يكون وقت التعافي قصيرًا، أي في غضون دقائق، فإن ذلك يعني عادةً أن عدة مكوّنات من DevOps تعمل معًا بكفاءة.

تكون قابلية الملاحظة قوية. وتكون بيانات القياس عن بُعد في الوقت الفعلي، بما يشمل المقاييس والسجلات ومسارات التتبع، مجمّعة ومركزية بالكامل في لوحات المعلومات. وتُكتشف الحوادث بسرعة، وغالبًا بصورة تلقائية، من دون انتظار شكاوى المستخدمين.

وتكون آلية التنبيهات مضبوطة على نحو مناسب، بحيث يُخطر المهندسون بسرعة من دون إغراقهم بضوضاء التنبيهات.

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

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

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

معدل فشل التغيير (CFR) هو مقياس "جودة التسليم" الذي يوضح لفرق DevOps مدى تكرار فشل عمليات النشر في بيئات الإنتاج الفعلية. يُعد أي نشر إشكالي في بيئة الإنتاج يجبر الفريق على التدخل فورًا، بدلًا من الانتظار حتى الإصدار المخطط التالي لمعالجة المشكلة، عملية نشر "فاشلة".

يساعد تتبّع معدل فشل التغييرات (CFR) بمرور الوقت الفِرق على فهم مدى موثوقية تسليمها للتغييرات، كما يشكّل عامل توازن مقابل مقاييس معدل الإنتاجية، مثل تكرار النشر ومدة إنجاز التغييرات، التي تعطي الأولوية للسرعة.

يُعبَّر عن معدل فشل التغييرات (CFR) عادةً كنسبة مئوية، ويُحسب بقسمة عدد عمليات النشر الفاشلة على إجمالي عدد عمليات النشر خلال الفترة نفسها، ثم ضرب الناتج في 100.

يشير انخفاض معدل فشل التغييرات إلى أن الفريق يسلّم تغييرات تعمل عمومًا كما هو متوقع في بيئة الإنتاج. وعندما يكون معدل فشل التغييرات منخفضًا ومستقرًا، يمكن للفِرق زيادة وتيرة النشر بأمان وتقليل مدة إنجاز التغيير دون الإضرار بتجربة المستخدم.

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

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

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

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

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

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

بالنسبة إلى كل مقياس من مقاييس DORA، تُصنَّف الفِرق ضمن أحد مستويات الأداء الأربعة: النخبوي، أو العالي، أو المتوسط، أو المنخفض، ويستند كل مستوى إلى عتبات محددة لذلك المقياس. وفيما يلي هذه العتبات:

نظرًا إلى أن معدل إعادة العمل في عمليات النشر مقياس أحدث، فلم تُحدَّد له بعد عتبات أو مستويات أداء معتمدة. ومع ذلك، تتتبّع كثير من المؤسسات وفرق DevOps خطوط الأساس الخاصة بمعدلات إعادة العمل لديها، وتهدف إلى خفضها تدريجيًا بمرور الوقت. ويساعد استخدام بيانات معدل إعادة العمل إلى جانب معدل فشل التغييرات ومقاييس الموثوقية الأخرى الفِرق على تحسين معدلات إعادة العمل في عمليات النشر دون المبالغة في التصحيح استنادًا إلى رقم واحد. 

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

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

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

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