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