كما فعلت إيفان قياسات DevOps. موضوع التأثير

لقد مر أسبوع منذ أن فكرت إيفان لأول مرة في مقاييس DevOps وأدركت أنها بحاجة لإدارة وقت التسليم للمنتج (Time-To-Market) بمساعدتهم .

حتى في عطلة نهاية الأسبوع ، فكر في المقاييس: "إذن ، ماذا أقيس الوقت؟ ماذا سوف يعطيني؟ "

في الواقع ، ماذا ستعرف معرفة الوقت؟ لنفترض أن التسليم يستغرق 5 أيام. إذن ماذا بعد؟ هل هو جيد أم سيء؟ حتى لو كان هذا سيئًا ، فأنت بحاجة إلى تقليل هذه المرة بطريقة ما. لكن كيف؟
هذه الأفكار لم تعطيه الراحة ، لكن لم يأت أي حل.

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

كيف تكون؟ ...

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

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

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

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

أدرك إيفان أن مقاييس DevOps يجب ألا تمثل الرسوم البيانية على الإطلاق. يجب أن تكون أداة لإيجاد فرق "متميزة" تشكل وقت التسليم النهائي.

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

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

من دون تردد ، التقط إيفان الهاتف وطالب عدد من الأشخاص على دراية جيدة بالداخلية في DevOps:

- دينيس ، أخبرني ، من فضلك ، هل من الممكن أن نفهم بطريقة أو بأخرى أن الفريق قد تجاوز هذا الموقف أو ذاك؟
- بالطبع. لدينا جنكينز يسقط العلم إذا كان التجمع قد خرج بنجاح (اجتاز الاختبار) على الحامل.
- سوبر. ما هو العلم؟
- هذا ملف نصي عادي من النوع "stand_OK" أو "stand_FAIL" ، والذي يشير إلى أن التجميع قد مر أو لم يجتز الحامل. حسنا ، هل تفهم؟
- من حيث المبدأ ، نعم. هل هو مكتوب على نفس المجلد في المستودع ، أين التجميع؟
- نعم
- وماذا سيحدث إذا لم يجتاز التجمع الحامل؟ هل ستحتاج إلى القيام بتجميع جديد؟
- نعم
- حسنا شكرا. وسؤال آخر: هل أفهم بشكل صحيح أنه يمكنني استخدام تاريخ إنشاء العلم كتاريخ مرور الحامل؟
- بالتأكيد!
- سوبر!

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

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

ليوم غد ، حدد لنفسه مهمة رسم بنية النظام التي يتم رسمها.

أن تستمر ...