إن تحقيق أعلى أداء هو هدف كل فريق لتطوير البرمجيات، ونحن في Deriv لسنا استثناءً من ذلك. ولتحقيق هذا الطموح، فإن فهم وضعنا الحالي أمر بالغ الأهمية. تُعد مقاييس DevOps الرئيسية بمثابة منارة تسلط الضوء على نقاط قوتنا ومجالات التحسين.
إن فكرة استخدام المقاييس، بما في ذلك تلك التي تم تطويرها في برنامج تقييم أبحاث ديف أوبس & (مقاييس DORA)، لتعزيز أداء الفريق هي فكرة واضحة من الناحية النظرية، ولكن تطبيقها على أرض الواقع غالباً ما يكون أكثر تعقيداً. وعلى الرغم من أن هذه المقاييس تبشر بالخير، إلا أن العديد من فرق التطوير تكافح من أجل تتبعها أو حتى استخدامها بفعالية عند تتبعها.
بصرف النظر عن تحديد المقاييس التي يجب التركيز عليها، كان علينا ابتكار طرق فعالة لقياسها وتمثيلها بصرياً، والأهم من ذلك، كان علينا ضمان ألا يذهب كل هذا العمل الجيد سدى.
في منشور المدونة هذا، نتعمق في المقاييس التي اخترنا التركيز عليها والعملية التي أنشأناها لتتبعها.
شرح مقاييس DORA
تُعد مقاييس DORA حجر الزاوية في مشهد DevOps، وهي بمثابة مؤشرات أساسية لأداء فريق التطوير. تتضمن هذه المقاييس أربعة معايير رئيسية: تكرار النشر، ومهلة إجراء التغييرات، ومعدل فشل التغيير، والوقت اللازم لاستعادة الخدمة (المعروف أيضًا باسم متوسط الوقت اللازم للإصلاح أو MTTR).
- يقيس تكرار النشر عدد المرات التي يتم فيها نشر التعليمات البرمجية للإنتاج أو إصدارها للمستخدمين النهائيين. يعكس قدرة الفريق على تنفيذ ميزات أو تحديثات أو إصلاحات جديدة وتقديمها.
- تقيس المهلة الزمنية للتغييرات مقدار الوقت الذي يستغرقه التغيير - من الالتزام إلى النشر. تشير المهل الزمنية الأقصر إلى عملية تطوير أكثر مرونة واستجابة.
- يقيّم معدل فشل التغيير النسبة المئوية لعمليات النشر التي تفشل في الإنتاج، مما يستلزم معالجة فورية. يدل المعدل المنخفض على موثوقية أعلى في عملية النشر.
- يقيس الوقت اللازم لاستعادة الخدمة الوقت المستغرق للتعافي من عطل في بيئة الإنتاج. يشير وقت التعافي الأقصر إلى فعالية الفريق في إدارة الحوادث وحلها.
في حين أن مقاييس DORA لا تقدر بثمن، حيث تقدم رؤية عالية المستوى لكفاءة وفعالية التطوير، إلا أنها ليست شاملة. يركزون في الغالب على مرحلتي النشر وما بعد النشر، تاركين الجوانب المهمة من دورة حياة التطوير.
اكتساب رؤى أوسع نطاقاً من تقارير حالة DevOps وLineearB
وإدراكاً منا للحاجة إلى توسيع منظورنا إلى ما هو أبعد من مقاييس DORA، لجأنا إلى تقارير الصناعة المؤثرة للحصول على رؤى أعمق. كانت تقارير حالة DevOps وLearB محورية في تحسين نهجنا لقياس كفاءة DevOps.
يقدم التقرير السنوي عن حالة DevOps تحليلاً شاملاً للممارسات التي تميز فرق DevOps "النخبة"، ويسلط الضوء بشكل خاص على أوقات التعافي الملحوظة وتكرار النشر والكفاءة الإجمالية. وهو يؤكد على أهمية عدم الاكتفاء بقياس النتائج (مثل معدل تكرار النشر ومعدل فشل التغيير) بل أيضاً فهم العمليات الأساسية التي تقود هذه النتائج، مثل ممارسات الترميز ومراجعات العلاقات العامة وتعاون الفريق.
ربما ليس من المستغرب أن يسلط التقرير الضوء على كيف يمكن لمراجعات العلاقات العامة المبسطة أن تعزز الإنتاجية وجودة التعليمات البرمجية بشكل كبير.
الذهاب إلى ما هو أبعد من DORA: دمج مقاييس إضافية لعمليات التطوير والعمليات
وإدراكًا منا لمحدودية مقاييس DORA، قمنا بتوسيع مجموعة مقاييسنا لتشمل معلمات إضافية توفر رؤية أكثر شمولاً لأداء DevOps لدينا. تتضمن هذه المقاييس الإضافية ما يلي:
- وقت الترميز: يقيس هذا الوقت الفعلي المستغرق في كتابة التعليمات البرمجية وتحريرها. يساعدنا على فهم إنتاجية وكفاءة مطورينا في مرحلة البرمجة.
- تكرار الدمج: من خلال تتبع عدد المرات التي يتم فيها دمج التعليمات البرمجية في الفرع الرئيسي، نقيس تدفق التعليمات البرمجية عبر خط التطوير ونحدد الاختناقات المحتملة.
- وقت مراجعة العلاقات العامة (طلب السحب): يشير هذا المقياس إلى الوقت المستغرق لمراجعة طلبات السحب والموافقة عليها. تعتبر عمليات مراجعة العلاقات العامة الفعالة ضرورية للحفاظ على جودة التعليمات البرمجية وضمان تكامل الميزات في الوقت المناسب.
- حجم العلاقات العامة: تساعد مراقبة حجم طلبات السحب في تقييم مدى تعقيد التغييرات في التعليمات البرمجية وإمكانية إدارتها. يُفضّل عمومًا إجراء علاقات عامة أصغر حجمًا وأكثر تواترًا من أجل عمليات دمج ومراجعة أكثر سلاسة وسهولة.
ومن خلال دمج هذه المقاييس في إطار قياس الأداء، نهدف إلى الوصول إلى فهم عملية التطوير بأكملها. يمكّننا هذا النهج من تحديد أوجه القصور ومعالجتها ليس فقط في مرحلتي النشر وما بعد النشر، بل في دورة حياة تطوير البرمجيات بأكملها.
تتبُّع مقاييس DevOps في Deriv باستخدام أدوات وحلول مخصصة
إن منهجيتنا في جمع مقاييس DevOps وتحليلها هي مزيج من الحلول مفتوحة المصدر والبرامج المملوكة لنا.
من العناصر الحيوية في مجموعة أدواتنا أداة Monocle، وهي أداة مفتوحة المصدر تُستخدم بشكل أساسي لجمع إحصائيات GitHub. تُعد Monocle بارعة في تخزين بيانات GitHub في قاعدة بيانات Elasticsearch، وتقدم واجهة أمامية سهلة الاستخدام على الويب باسم Kibana لتصور البيانات بشكل فعال.
ولتعظيم إمكانات البيانات المخزنة في Elasticsearch، لجأنا إلى Kibana لتصور تقاريرنا. تمنحنا إمكانات Kibana القوية لتصور البيانات مرونة كبيرة، مما يتيح لنا تصميم عرض بياناتنا بدقة وفقًا لمتطلباتنا. يسمح لنا هذا الخيار الاستراتيجي ليس فقط بالوصول إلى البيانات، بل بتفسيرها بالطرق الأكثر ملاءمة لاحتياجاتنا التحليلية.
التنفيذ التقني
على الرغم من نقاط قوته، يفتقر Monocle إلى القدرة على تغطية المعلومات المتعلقة بالنشر. ولمعالجة هذه المشكلة، قمنا بتطوير خدمة مصممة خصيصاً لتلبية احتياجاتك لتكمل وظائف Monocle. صُممت هذه الخدمة المخصصة لجمع بيانات النشر مباشرةً من GitHub، ودمجها بسلاسة في متجر Elasticsearch الخاص بنا، وبالتالي ضمان رؤية شاملة لدورة حياة التطوير لدينا.
مثّل حساب مقاييس المهلة الزمنية تحدياً فريداً من نوعه، حيث ثبت أن القيام بذلك مباشرةً باستخدام استعلامات Elasticsearch فقط أمر معقد. للتغلب على هذا التحدي، قمنا بتحسين خدمتنا لحساب هذا المقياس بشكل أكثر فعالية. يستعلم Elasticsearch عن طلبات السحب ذات الصلة ويلتزم بالبيانات، وبالتالي تبسيط عملية الحساب وتحسينها.
علاوة على ذلك، قمنا بدمج واجهة برمجة تطبيقات PagerDuty للحصول على البيانات المتعلقة بالحوادث. يعد هذا التكامل أمرًا بالغ الأهمية لتصور MTTR، وهو جانب أساسي من جوانب تقييم الأداء لدينا. تزوّدنا واجهة برمجة تطبيقات PagerDuty ببيانات مفصّلة عن الحوادث، مما يمكّننا من قياس وتحليل أوقات الاستجابة والحل بفعالية.
وقد أثبت هذا النهج المركب - الذي يجمع بين Monocle وKibana وحلولنا المخصصة وواجهة برمجة تطبيقات PagerDuty - أنه حل معقول لمنحنا رؤية شاملة لمقاييسنا التشغيلية. شكراً جزيلاً لفريق دعم Monocle على مساعدتهم الاستثنائية في تطوير لوحة تحكم مخصصة تلبي متطلباتنا الخاصة. كما أن استجابتهم السريعة والفعالة لبلاغاتنا عن الأخطاء كانت ذات قيمة لا تقدر بثمن.
تتبُّع التقدم المحرز وتحسين ممارسات DevOps
منذ بدء تتبع مقاييسنا المحسّنة في عام 2023، ومن خلال مراقبة أوقات مراجعة العلاقات العامة عن كثب وتحسينها، حققنا عملية تكامل أكثر انسيابية في عملية تكامل التعليمات البرمجية، مما أدى إلى انخفاض ملحوظ في حالات التأخير والتعارض في النشر. وبالمثل، مكننا التحليل التفصيلي لمقاييس وقت الترميز من تحديد ومعالجة اختناقات الإنتاجية، مما أدى إلى استخدام أكثر كفاءة لوقت المطورين ومواردهم.
لا تتعلق هذه التحسينات المستمرة في تتبع المقاييس وتحليلها بالأرقام فقط؛ فهي تعكس تحولاً أعمق في ثقافة التطوير لدينا نحو حل المشكلات الاستباقية وتحسين الكفاءة. ومع مواصلة تحسين هذه العمليات، نتوقع تحقيق خطوات أكبر في كفاءة التطوير وجودة المنتج بشكل عام.
فيما يلي بعض الأمثلة على مخططات Kibana البيانية.
تعزيز الثقافة القائمة على البيانات في فرق التكنولوجيا
نحن ملتزمون بتعزيز ثقافة تعتمد على البيانات بين فريقنا العالمي الذي يضم أكثر من 300 مطور. من خلال دمج هذه المقاييس في عملياتنا اليومية، يجب أن تشعر فرقنا بمزيد من القدرة على تحديد اختناقات الكفاءة وحلها بشكل استباقي. لا يقتصر هذا النهج على تعزيز إنتاجيتنا فحسب، بل ينمي أيضاً الشعور بالملكية والمساءلة داخل فرقنا.
ندعوك للانضمام إلينا في هذه الرحلة الطموحة نحو وضع معايير جديدة في كفاءة وأداء DevOps. استكشف فرص العمل لدينا واطمح لأن تكون من النخبة.
.webp)
