لأكون صادقًا، غالبًا ما كان إيفان يضحك على الجهود غير المجدية التي يبذلها زملاؤه في قسم المراقبة. لقد بذلوا جهودًا كبيرة لتنفيذ المقاييس التي أمرتهم إدارة الشركة بتحقيقها. لقد كانوا مشغولين للغاية لدرجة أنهم لم يريدوا أن يفعل أي شخص آخر أي شيء.
لكن هذا لم يكن كافيا للإدارة - فقد طلبوا باستمرار المزيد والمزيد من المقاييس الجديدة، وسرعان ما توقفوا عن استخدام ما تم القيام به من قبل.
في الآونة الأخيرة، كان الجميع يتحدثون عن LeadTime - وهو الوقت المناسب لتسليم ميزات الأعمال. أظهر المقياس رقمًا مجنونًا - 200 يوم لتسليم مهمة واحدة. كيف أهدى الجميع واهد ورفعوا أيديهم إلى السماء!
وبعد مرور بعض الوقت، تضاءلت الضوضاء تدريجيًا وتلقت الإدارة أمرًا بإنشاء مقياس آخر.
كان من الواضح تمامًا لإيفان أن المقياس الجديد سيموت بهدوء في زاوية مظلمة.
في الواقع، اعتقد إيفان أن معرفة الرقم لا تخبر أحدًا بأي شيء على الإطلاق. 200 يوم أو يومين - لا فرق، لأنه من المستحيل تحديد السبب بالعدد وفهم ما إذا كان جيدًا أم سيئًا.
هذا فخ نموذجي للمقاييس: يبدو أن المقياس الجديد سيخبر جوهر الوجود ويشرح بعض الأسرار السرية. الجميع يأمل كثيرا في هذا، ولكن لسبب ما لم يحدث شيء. نعم، لأن السر لا ينبغي أن يكون في المقاييس!
بالنسبة لإيفان، كانت هذه مرحلة مرت. لقد فهم ذلك للقياسات، ويجب البحث عن جميع الأسرار فيها ، أي. هو أن يتم تشكيل هذا المقياس.
بالنسبة لمتجر عبر الإنترنت، سيكون موضوع التأثير هو العملاء الذين يجلبون الأموال، وبالنسبة لـ DevOps، ستكون الفرق التي تنشئ التوزيعات وتنشرها باستخدام خط الأنابيب.
في أحد الأيام، أثناء جلوسه على كرسي مريح في القاعة، قرر إيفان أن يفكر مليًا في الطريقة التي يريد بها رؤية مقاييس DevOps، مع الأخذ في الاعتبار حقيقة أن موضوع التأثير هو الفرق.
الغرض من مقاييس DevOps
من الواضح أن الجميع يريد تقليل وقت التسليم. 200 يوم بالطبع ليست جيدة.
ولكن كيف، هذا هو السؤال؟
توظف الشركة مئات الفرق، ويتم إجراء آلاف التوزيعات عبر خط أنابيب DevOps يوميًا. سيظهر وقت التسليم الفعلي كتوزيع. سيكون لكل فريق وقته الخاص وخصائصه الخاصة. كيف يمكنك العثور على أي شيء وسط هذه الفوضى؟
ظهرت الإجابة بشكل طبيعي - نحتاج إلى العثور على الفرق التي تسبب المشاكل ومعرفة ما يحدث معهم ولماذا يستغرق الأمر وقتًا طويلاً، والتعلم من الفرق "الجيدة" كيفية القيام بكل شيء بسرعة. وللقيام بذلك، تحتاج إلى قياس الوقت الذي تقضيه الفرق في كل منصة من منصات DevOps:
"الغرض من النظام هو اختيار الفرق بناءً على الوقت الذي تمر فيه على المدرجات، أي. ونتيجة لذلك، يجب أن نحصل على قائمة الأوامر مع الوقت المحدد، وليس رقما.
"إذا اكتشفنا إجمالي الوقت الذي أمضيناه على المدرجات ومقدار الوقت الذي أمضيناه في فترة التوقف بين المدرجات، فيمكننا العثور على الفرق والاتصال بهم وفهم الأسباب بمزيد من التفصيل والقضاء عليها"، فكر إيفان.
كيفية حساب وقت التسليم لـ DevOps
لحساب ذلك، كان من الضروري الخوض في عملية DevOps وجوهرها.
تستخدم الشركة عدداً محدوداً من الأنظمة، ولا يمكن الحصول على المعلومات إلا منها فقط وليس من أي مكان آخر.
تم تسجيل جميع المهام في الشركة في جيرا. عندما يتم تنفيذ مهمة ما، يتم إنشاء فرع لها، وبعد التنفيذ، يتم الالتزام بـ BitBucket وPull Request. عندما يتم قبول PR (طلب السحب)، يتم إنشاء التوزيع تلقائيًا وتخزينه في مستودع Nexus.
بعد ذلك، تم توزيع التوزيع على عدة منصات باستخدام Jenkins للتحقق من صحة التوزيع والاختبار التلقائي واليدوي:
وصف إيفان الأنظمة التي يمكن من خلالها الحصول على المعلومات التي يمكن أخذها لحساب الوقت في المدرجات:
- من Nexus - وقت إنشاء التوزيع واسم المجلد الذي يحتوي على رمز الأمر
- من Jenkins - وقت البدء، المدة والنتيجة لكل وظيفة، اسم المنصة (في معلمات الوظيفة)، المراحل (خطوات المهمة)، رابط للتوزيع في Nexus.
- قرر إيفان عدم إدراج Jira وBitBucket في خط الإنتاج، لأن... لقد كانوا أكثر ارتباطًا بمرحلة التطوير، وليس بطرح التوزيع النهائي على المدرجات.
وبناء على المعلومات المتوفرة تم رسم المخطط التالي:
بمعرفة الوقت المستغرق لإنشاء التوزيعات ومقدار الوقت المستغرق في كل منها، يمكنك بسهولة حساب إجمالي تكاليف المرور عبر مسار DevOps بالكامل (دورة كاملة).
فيما يلي مقاييس DevOps التي انتهى بها إيفان:
- عدد التوزيعات التي تم إنشاؤها
- حصة التوزيعات التي "جاءت" إلى المنصة و"مرت" على المنصة
- الوقت المستغرق على الحامل (دورة الوقوف)
- دورة كاملة (الوقت الإجمالي لجميع المدرجات)
- مدة الوظيفة
- التوقف بين المدرجات
- وقت التوقف عن العمل بين إطلاق الوظائف على نفس المنصة
من ناحية، ميزت المقاييس مسار DevOps بشكل جيد للغاية من حيث الوقت، ومن ناحية أخرى، تم اعتبارها بسيطة للغاية.
بعد أن كان إيفان راضيًا عن العمل الجيد، قدم عرضًا تقديميًا وذهب لتقديمه إلى الإدارة.
لقد عاد كئيبًا ويداه إلى أسفل.
ابتسم الزميل الساخر: "هذا إخفاق تام يا أخي".
اقرأ المزيد في المقال "".
المصدر: www.habr.com