تجاوز مقاييس DORA في تقييم أداء DevOps

تحقيق الأداء المثالي هو هدف كل فريق تطوير برمجيات، وفي Deriv، نحن لسنا استثناء. لتحقيق هذا الطموح، من الضروري فهم موقعنا الحالي. مقاييس DevOps الرئيسية بمثابة منارة، تبرز نقاط قوتنا ومجالات التحسين.

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

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

في هذا المنشور، نتعمق في المقاييس التي اخترنا التركيز عليها والعملية التي أنشأناها لتتبعها.

شرح مقاييس DORA

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

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

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

الحصول على رؤى أوسع من تقارير State of DevOps وLinearB

مع إدراك الحاجة إلى توسيع منظورنا خارج مقاييس DORA، لجأنا إلى تقارير صناعية مؤثرة للحصول على رؤى أعمق. لعبت تقارير State of DevOps وLinearB دورًا حيويًا في تحسين منهجيتنا لقياس كفاءة DevOps.

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

ربما ليس من المستغرب، يبرز التقرير كيف يمكن لمراجعات PR المبسطة تعزيز الإنتاجية وجودة الشيفرة بشكل كبير.

تجاوز مقاييس DORA: دمج مقاييس DevOps إضافية

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

1. وقت الترميز: يقيس هذا الوقت الفعلي المنقضي في كتابة وتحرير الشيفرة. يساعدنا على فهم إنتاجية وكفاءة المطورين في مرحلة الترميز.
2. تكرار الدمج: من خلال تتبع عدد مرات دمج الشيفرة في الفرع الرئيسي، نقيس تدفق الشيفرة من خلال خط أنابيب تطوير البرنامج ونحدد اختناقات محتملة.
3. وقت مراجعة PR (طلب السحب): تشير هذه المقياس إلى الوقت المستغرق لمراجعة واعتماد طلبات السحب. تعد عمليات مراجعة PR الفعالة ضرورية للحفاظ على جودة الشيفرة وضمان دمج الميزات في الوقت المناسب.
4. حجم PR: يساعد مراقبة حجم طلبات السحب في تقييم تعقيد ومدى إمكانية إدارة تغييرات الشيفرة. يفضل عمومًا أن تكون PRs أصغر وأكثر تكرارًا لسهولة دمجها ومراجعتها بسلاسة.

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

تتبع مقاييس DevOps لـ Deriv باستخدام الأدوات والحلول المخصصة

تجمع منهجيتنا لجمع وتحليل مقاييس DevOps بين الحلول مفتوحة المصدر والبرمجيات الخاصة.

عنصر حيوي في مجموعة أدواتنا هو Monocle، أداة مفتوحة المصدر تستخدم بشكل أساسي لجمع إحصائيات GitHub. يتميز Monocle بكفاءته في تخزين بيانات GitHub في قاعدة بيانات Elasticsearch، مع توفير واجهة ويب سهلة الاستخدام تسمى Kibana لعرض البيانات بشكل فعّال.

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

التنفيذ التقني

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

قدم حساب مقاييس الوقت المستغرق لتغيير التحديات الفريدة، حيث ثبت أن القيام بذلك مباشرة باستخدام استعلامات Elasticsearch فقط أمر معقد. لتجاوز هذا التحدي، قمنا بتحسين خدمتنا لحساب هذا المقياس بشكل أكثر فعالية. تستعلم الخدمة Elasticsearch عن طلبات السحب والبيانات المرتبطة بالالتزامات المناسبة، مما يبسط ويطور عملية الحساب.

علاوة على ذلك، دمجنا PagerDuty API للحصول على بيانات مرتبطة بالحوادث. هذا التكامل ضروري لتصور MTTR، وهو جانب أساسي في تقييم أدائنا. يتيح لنا PagerDuty API بيانات مفصلة عن الحوادث، مما يمكننا من قياس وتحليل أوقات الاستجابة والحل بفعالية.

هذا النهج المركب – الذي يجمع بين Monocle وKibana وحلولنا المخصصة وPagerDuty API – أثبت أنه حل معقول يمنحنا رؤية شاملة لمقاييس عملياتنا. شكر كبير لفريق دعم Monocle على مساعدتهم الاستثنائية في تطوير لوحة تحكم مخصصة تلبي متطلباتنا الخاصة. وكان ردهم السريع وفعال على تقارير الأخطاء لدينا ذا قيمة كبيرة أيضًا.

تتبع التقدم وتحسين ممارسات DevOps

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

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

فيما يلي بعض الأمثلة على مخططات Kibana.

تعزيز ثقافة معتمدة على البيانات في فرق التكنولوجيا

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

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

‍