DevOps को मापने के लिए मुख्य प्रदर्शन संकेतक (KPI) का क्या उपयोग किया जाता है?

Question

मैं DevOps परिवर्तन कार्यक्रम के भीतर अच्छे व्यवहार को चलाने की कोशिश कर रहा हूं, इसका समर्थन करने के लिए मैं संचालन विषयों के आसपास कार्रवाई योग्य मैट्रिक्स की पहचान कर रहा हूं:

• समस्या और हादसा प्रबंधन
• क्षमता प्रबंधन
• परिवर्तन और रिलीज प्रबंधन

बिल्कुल स्पष्ट होने के लिए, ये ऐसे कार्य हैं जो संचालन संगठन से संबंधित थे और अब Agile / DevOps संगठन के स्वामित्व में हैं। मौजूदा KPI हैं जो बुरे व्यवहार करते हैं:

• रूट कारण विश्लेषण पूरा होने का समय:
  • अपूर्ण आरसीए को केवल समय पर सिस्टम में लाने के लिए ड्राइव करता है।
• परीक्षण निष्पादन की अवधि:
  • लंबे समय से चल रहे परीक्षणों को निष्क्रिय कर देता है, चाहे उनका व्यावसायिक मूल्य कुछ भी हो।
• क्लाउड सेवाओं का औसत उपयोग:
  • कंप्यूट संसाधनों की अधिक प्रतिबद्धता को प्रोत्साहित करता है, जिसके परिणामस्वरूप धीमी प्रतिक्रिया समय होती है

DevOps प्रोग्राम में अच्छे व्यवहार को प्रोत्साहित करने के लिए मुख्य प्रदर्शन संकेतक का क्या उपयोग किया जा सकता है?

Comments

आपने सभी KPI के साथ अंतर्निहित समस्या पाई है । लोग वास्तविक प्रदर्शन को अधिकतम करने के बजाय प्रदर्शन संकेतकों को अधिकतम करने के लिए काम करेंगे । मेट्रिक्स लोगों को स्कोर करने के लिए एक स्कोर देते हैं, और वे अपने काम को अच्छी तरह से करने की कीमत पर भी करेंगे।

— एड्रियन

@ एड्रियन मैं सहमत हूं, हालांकि कुछ केपीआई हैं, जैसे कि चक्र का समय, जो स्वाभाविक रूप से खेल के लिए मुश्किल है।

— रिचर्ड स्लेटर

सच। फिर भी, यहां तक ​​कि जो खेल के लिए कठिन हैं, वे KPI के लिए अनुकूलन का नेतृत्व करेंगे, जो सामान्य रूप से उप-इष्टतम हो सकता है, या बस उन KPI के पक्ष में हो सकता है जो कि लाभान्वित हो सकते हैं। मैंने मैट्रिक्स के साथ स्वचालित रूप से DevOps प्रदर्शन को मापने के लिए बहुत कम तरीके पाए हैं; यह ज्यादातर व्यक्तिपरक है और व्यक्तिगत अवलोकन और सगाई की आवश्यकता है।

— एड्रियन

यह DevOps नहीं है, यह ITIL haha ​​है

— Gaius

Answer 1

मुझे नहीं लगता कि कोई "सार्वभौमिक" DevOps KPI हैं। उदाहरण के लिए, वेग महान है, जब तक कि यह आपके व्यवसाय के लिए महत्वपूर्ण ड्राइवर नहीं है। अमेज़ॅन वेग के बारे में बहुत परवाह करता है क्योंकि उनके पास एक बड़े पैमाने पर खुदरा ऑपरेशन है। यह 100 उपयोगकर्ताओं के साथ एक छोटे ऐप के लिए कम महत्वपूर्ण है।

यह सवाल है: आप अपने व्यवसाय के लिए प्रासंगिक सबसे अच्छा KPI का चयन कैसे करते हैं ? यह एक शोध और खोज प्रक्रिया है जिसमें आपका संपूर्ण उद्यम शामिल है।

तुम्हे किस चीज़ की पर्वाह हैं?

• गुणवत्ता
• विश्वसनीयता
• रख-रखाव
• वेग
• प्रक्रिया में सुधर
• सेवा स्तर

आपके व्यवसाय के हितधारक रात में क्या करते हैं? क्या निर्धारित करता है कि आप इस तिमाही में पैसा बनाते हैं या नहीं? ऊपर दी गई सूची में उन चीजों में से कुछ शामिल हो सकते हैं, या यह नहीं हो सकता है। अपनी सूची बनाएं, फिर यह पता करें कि उन्हें प्राप्त करने के लिए हर विभाग में प्रोत्साहन कैसे संरेखित करें।

प्रोत्साहन व्यवहार को संचालित करते हैं, इसलिए स्मार्ट लक्ष्यों पर सहयोगात्मक रूप से निर्णय लेते हैं। अपनी मंथन सूची से दो या तीन आइटम चुनें, और प्रत्येक के लिए एक माप / फिक्स प्रतिक्रिया चक्र शुरू करें। एक बार में बहुत अधिक मत उठाओ- आप दो या तीन चीजों पर ध्यान केंद्रित करके सफल होने की अधिक संभावना रखते हैं।

Answer 2

DevOps के पास कोई KPI नहीं है । यह पूछना प्यार के KPI क्या हैं। लेकिन आपके द्वारा बताई गई कुछ चीजें ( समस्या और घटना प्रबंधन , क्षमता प्रबंधन , परिवर्तन और रिलीज प्रबंधन ) में अच्छा KPI है, जिनमें से कुछ DevOps के पीछे के सिद्धांत पर आधारित हैं।

सामान्य तौर पर, किसी भी व्यवसाय प्रक्रिया के लिए, आप एक बना सकते हैं मूल्य श्रृंखला मानचित्र हुए बताया कि कैसे मान से बहती है ग्राहक के लिए उद्यम वापस के माध्यम से, ग्राहक । पूरे लूप को हमेशा ग्राहक के साथ शुरू और समाप्त करना पड़ता है, लेकिन कभी-कभी, किसी सेवा संगठन के लिए, ग्राहक आंतरिक हो सकता है। ऐसी श्रृंखला के माध्यम से मूल्य का थ्रूपुट आपके KPI को छेड़छाड़-प्रूफ तरीके से डिजाइन करने का एक अच्छा तरीका हो सकता है। मूल्य श्रृंखला के किसी भी व्यक्तिगत लिंक में किसी भी KPI को मापना केवल तब तक समझ में आता है जब तक कि विशेष लिंक प्रक्रिया की अड़चन है और आप अड़चन का फायदा उठाने या उसे बढ़ाने की कोशिश करते हैं।

KPI के साथ एक आम समस्या यह है कि जब यह श्रृंखला के माध्यम से आधे रास्ते से शुरू होता है। उदाहरण के लिए, एक परिवर्तन और रिलीज़ प्रक्रिया अक्सर डेवलपर्स के साथ शुरू होती है और तैनाती के साथ समाप्त होती है। इस प्रक्रिया को बाहर रखा गया है:

• समस्या वाले ग्राहक
• समस्याओं की पहचान करने वाली टीम का समर्थन करें
• बैकलॉग के लिए समस्या को परिभाषित करने वाली उत्पाद टीम
• ग्राहक के लिए तैनाती को अनुकूलित करने वाली समाधान टीम
• समाधान से ग्राहक साकार मूल्य

समस्या यह है कि अकेले एक चक्र समय को मापने से दो बड़ी समस्याएं हो सकती हैं:

1. अड़चन उपरोक्त वर्णित भागों में से किसी में है और आपके ग्राहक मूल्य का एहसास नहीं कर रहे हैं और आप अपने चक्र समय की गति के अनुपात में राजस्व का एहसास नहीं कर रहे हैं। इसलिए जब आपकी इंजीनियरिंग उत्कृष्ट होती है, तो आपका व्यवसाय प्रभावित होता है।

2. ग्राहकों से डिस्कनेक्ट आपके रिलीज़ साइकिल स्पिन को खाली कर देगा - किसी भी मूल्य का उत्पादन नहीं कर रहा है, परिवर्तन किए जाने के बावजूद - या यहां तक ​​कि अपने ग्राहकों की आवश्यकताओं का मुकाबला करने और किए जा रहे काम का नकारात्मक व्यावसायिक मूल्य हो सकता है।

KPI के साथ एक और समस्या यह है कि ग्राहक के साथ शुरू करने और समाप्त होने के दौरान यह वास्तव में ग्राहक के लिए मूल्य को माप नहीं सकता है। एक अच्छा उदाहरण केपीआई के रूप में एक समस्या और हादसा प्रतिक्रिया प्रक्रिया और MTTR (मीन टाइम टू रिपेयर) होगा। क्या समस्या किसी को प्रभावित करती है? ग्राहकों के लिए मूल्य क्या है? आप 100 से अधिक घटनाओं में 3 घंटे की उत्कृष्ट एमटीटीआर पा सकते हैं। लेकिन यदि उनमें से अधिकांश आंतरिक थे, तो ग्राहकों के लिए कोई न्यूनतम प्रभाव नहीं था या मिनटों में हल हो गया, जबकि विशाल ग्राहक प्रभाव वाली एक बड़ी घटना को संभालने में 3 दिन लगे, यदि आपके पास 1 दिन का एमटीटीआर था, तो व्यापार मूल्य कम है। अधिकांश आंतरिक घटनाओं को अनदेखा करें, लेकिन आपने 1 घंटे के भीतर बड़ी ग्राहक प्रभाव घटना का जवाब दिया।

ध्यान दें: एक आंतरिक ग्राहक के लिए, समर्थन टीम व्यवसाय प्रक्रिया के मामले में, व्युत्पन्न मूल्य आंतरिक ग्राहक को काम का मूल्य नहीं है, लेकिन व्यवसाय द्वारा प्राप्त मूल्य को आंतरिक ग्राहक को अपनी व्यवसाय प्रक्रिया में अनब्लॉक करने में प्राप्त होता है। एक टीम को अनब्लॉक करना जो अपनी प्रक्रिया में एक अड़चन है, एक गैर-अड़चन टीम या व्यक्ति को अनब्लॉक करने की तुलना में अधिक मूल्य प्राप्त करता है। ऐसी सहायता टीम के सभी केपीआई को उनकी गणना में व्यावसायिक मूल्य को शामिल करने की आवश्यकता है।

Answer 3

1. परिनियोजन आवृत्ति
2. तैनाती की गति
3. तैनाती की सफलता दर
4. एक असफल तैनाती
   और आखिरकार, कितनी जल्दी सेवा बहाल की जा सकती है ।
5. DevOps कल्चर, जिसे वास्तव में मापा नहीं जा सकता है

Comments

5.DevOpsCulture, which actually can’t be measured=> सभी के लिए एक गुमनाम प्रश्नावली बनाएं जिसमें थोड़ा भी शामिल हो और उनसे पूछें कि वे इस सब के बारे में कैसा महसूस करते हैं। यह निश्चित रूप से आपको बताएगा कि क्या आपके पास एक ऐसी प्रक्रिया है जो आपके लोगों द्वारा

— जीती है