मेट्रिक्स - परियोजना स्वास्थ्य के संकेतक

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



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


स्पीकर और कंपनी के बारे में: 2010 से आईटी में रुस्लान ओस्ट्रोपोलस्की , ब्याज का मुख्य क्षेत्र गुणवत्ता आश्वासन है। पिछले 5 वर्षों से वह DocDoc में काम कर रही है, जो एक ऐसी कंपनी है जो मेडिकल इंटरनेट सेवाओं का विकास करती है। मुख्य उत्पाद एक डॉक्टर के साथ एक ऑनलाइन नियुक्ति है, 2 मिलियन से अधिक रोगियों ने डॉक्टर के लिए डॉकडॉक के माध्यम से हस्ताक्षर किए हैं, निदान, टेलीमेडिसिन और वीएचआई बीमा की एक पंक्ति भी है।

जब गुणवत्ता और व्यवसाय मित्र नहीं हैं

गुणवत्ता आश्वासन के बिना, व्यवसाय के लिए लंबे समय में पैसा बनाना मुश्किल होगा। गुणवत्ता और व्यवसाय का एक गुच्छा चाहिए। यदि यह नहीं है, तो निम्नलिखित स्थितियां संभव हैं।

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

• व्यवसाय को समझना - इस समय क्या प्रासंगिक है: पैसे कमाएं, बाजार या पैमाने पर जल्दी से प्रवेश करें। व्यवसाय का कार्य इन लक्ष्यों को तकनीकी विभाग में स्थानांतरित करना है।
• सही जगह और सही मात्रा में गुणवत्ता। कभी-कभी, आप बग के साथ रिलीज जारी कर सकते हैं, लेकिन जोखिमों को समझ सकते हैं, और तदनुसार, इसे ध्यान में रखें।

दूसरे, एक और मामला है - गुणवत्ता के बिना एक व्यवसाय । एक आईटी कंपनी के पास एक परीक्षण विभाग भी हो सकता है, लेकिन अगर QA हल्का है या बंदर परीक्षण के रूप में मौजूद है, जो बस प्रतिगमन को मिटा देता है और वहां रुक जाता है, तो इससे बहुत सुधार नहीं होगा।

एनबी: क्यूए वास्तव में परीक्षण नहीं कर रहा है, लेकिन एक सामान्य कंपनी-स्तरीय दृष्टिकोण है कि आप अच्छे उत्पाद कैसे बनाते हैं।

कैसे समझें कि आप उच्च-गुणवत्ता विकसित कर रहे हैं या नहीं?


एक वस्तुनिष्ठ मूल्यांकन के लिए मीट्रिक की आवश्यकता होती है जो दिखाती है:

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

मेट्रिक्स कैसे चुनें

आप तीन सिद्धांतों के अनुसार मैट्रिक्स चुन सकते हैं।

जहां दर्द होता है। यदि कोई घटना होती है, तो उसे डिसबैलेंस किया जाना चाहिए, मेट्रिक्स के साथ वेट किया जाना चाहिए और दर्द को देखना चाहिए: उपचार कैसा चल रहा है, क्या डायनेमिक्स, क्या बग्स ठीक हैं।


लक्षित दृष्टिकोण के साथ, हम स्पष्ट रूप से लक्ष्यों पर ध्यान केंद्रित करते हैं, उदाहरण के लिए, त्वरण और स्वचालन। पहले, हमारे स्वचालित परीक्षण में दो घंटे लगते थे। हमने 10 मिनट में एक लक्ष्य निर्धारित किया और यह देखने के लिए कि क्या हम इस मूल्य से संपर्क कर रहे हैं, मैट्रिक्स को देखा।


लेकिन एक स्वस्थ परियोजना प्राप्त करना असंभव है अगर मैट्रिक्स का व्यवसाय से कोई संबंध नहीं है, तो वे केवल तकनीकी हैं, और व्यवसाय को परिणाम नहीं मिलता है। इसके विपरीत, अगर कोई कीड़े नहीं हैं, और व्यवसाय पैसे खो देता है, तो कुछ अजीब हो रहा है।


यह याद रखना महत्वपूर्ण है कि एक परियोजना के विभिन्न व्यवसाय और विभिन्न चरण हैं। एक स्टार्टअप, एक बढ़ती हुई कंपनी या एक विस्तार परियोजना के लिए अलग-अलग मीट्रिक की आवश्यकता होती है। यह एक बीमारी की तरह है - यदि आपको बस खांसी है, तो आप तापमान को माप सकते हैं, एस्कॉर्बिक एसिड पी सकते हैं, और सब कुछ गुजर जाएगा। यदि आपको निमोनिया का संदेह है, तो आपको चित्र लेने, एक परीक्षा के लिए जाने और अलग तरीके से इलाज करने की आवश्यकता है।

परियोजना के विभिन्न चरणों में मेट्रिक्स

हम आपको बताएंगे कि जब हम एक स्टार्टअप थे, तब हमने कौन से मैट्रिक्स मापे थे, और फिर बढ़ना और विस्तार करना शुरू कर दिया था।

स्टार्टअप

इस स्तर पर, उत्पाद केवल अपनी प्रारंभिक अवस्था में है, आप एक परिकल्पना का परीक्षण कर रहे हैं, यह जांच कर रहे हैं कि लोगों को इसकी आवश्यकता है या नहीं।


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

क्यूए भाग में, हमारे पास केवल 3-5 मीट्रिक थे:

• लड़ाई से कीड़े की संख्या;
• रिलीज तक पहुंचने वाले कीड़े की संख्या;
• बग की आलोचना।

मेट्रिक्स कैसे इकट्ठा करें, इस सवाल का जवाब सरल है: हाथ हैं और एक्सेल है। महीने में लगभग एक बार, अपने हाथ डेटा टेबल में रखें, यह पर्याप्त होना चाहिए।

बढ़ रहे हैं

अगले चरण में, हम पहले से ही अपने पैरों पर खड़े होना सीख चुके हैं, हम थोड़ा चलते हैं।


व्यवसाय की आवश्यकताएं विकसित हो रही हैं, यह मापना महत्वपूर्ण हो जाता है:

• यातायात। जब यह स्पष्ट हो गया कि उपयोगकर्ताओं को उत्पाद की आवश्यकता है, जितना संभव हो उतना यातायात उत्पन्न होता है, उदाहरण के लिए, सहबद्ध कार्यक्रम दिखाई देते हैं।
• स्केलिंग - उत्पाद के पक्ष से और विकास के पक्ष से दोनों को विकसित करने के लिए जितना संभव हो सके।

क्यूए पहले से ही बड़ा हो रहा है: 10-15 मीट्रिक। यदि किसी स्टार्टअप में हमने अपनी भावनाओं के अनुसार उत्पाद बनाया है, उदाहरण के लिए, संस्थापक ने कहा: "मुझे एक नीला बटन चाहिए", और सभी ने इसे किया, अब पहला आंकड़ा है। आप ए / बी परीक्षणों के माध्यम से सुविधाओं को छोड़ सकते हैं और परिणामों को मापने के लिए याद रख सकते हैं।

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

यह देखने के लिए कि क्या 5 डेवलपर्स के बजाय, यह 15 हो गया है, यह देखने के लिए रिलीज़ वॉल्यूम भी मापा जाता है , लेकिन किसी कारण से रिलीज़ वॉल्यूम नहीं बढ़ा है।

हाथों और एक्सेल के अलावा, विकास के स्तर पर मैट्रिक्स इकट्ठा करने के लिए, विशेष सिस्टम दिखाई देते हैं। सिस्टम कोई भी उपकरण है जो उत्पाद बनाने में मदद करता है। यदि पहले वही परीक्षण मामले Google डॉक्स में लिखे गए थे, तो वे यहां दिखाई देते हैं:

• सिस्टम मैनेजर, उदाहरण के लिए, TestRail;
• उपयोगकर्ता डेटा एकत्र करने के लिए Google Analytics;
• रिपोर्ट पोर्टल, स्वचालन के लिए लुभाना।

सिस्टम अपने आप ही अतिरिक्त मीट्रिक और रिपोर्ट बनाता है।

वसा के साथ ऊंचा हो गया

हम आगे बढ़ते हैं, "वसा के साथ अतिवृद्धि" - हम उन कार्यालयों में नहीं आते हैं जिनमें हम बैठे थे, और हम समय-समय पर चलना शुरू करते हैं।


व्यवसाय के लिए क्या महत्वपूर्ण है?

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

क्यूए में पहले से ही लगभग 30-50 मीट्रिक शामिल हैं। हम मापते हैं:

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

हम पहले की तरह डेटा एकत्र करते हैं, लेकिन वहाँ अधिक सिस्टम का उपयोग किया जाता है।

कठिनाइयों

सब कुछ आसानी से नहीं होता है, और हम कोई अपवाद नहीं हैं। मैं आपको बताता हूं कि जब परियोजना पर्याप्त रूप से विकसित हो गई थी, तब हमें किन कठिनाइयों का सामना करना पड़ा था।


बहुत सारे सिस्टम हैं , उन्हें किसी तरह प्रबंधित करने की आवश्यकता है। प्रत्येक प्रणाली को देखने में कम से कम बहुत समय लगता है।

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

प्रक्रियाएं अधिक जटिल हो गईं : यदि पहले 5 लोगों ने परियोजना पर काम किया था, तो सहमत होना और तदनुसार कार्य करना आसान था, अब हमें प्रक्रियाओं की निगरानी करने की आवश्यकता है। उदाहरण के लिए, नए लोगों को धीरे-धीरे पेश करने की आवश्यकता है, अन्यथा उनके लिए सिस्टम की संचित संख्या को समझना मुश्किल होगा।

डेटा और रिपोर्ट सेवा के भीतर अद्वितीय हैं । यह इस तथ्य से निम्नानुसार है कि कई प्रणालियां हैं, और आपको उन सभी को देखने की आवश्यकता है। प्रत्येक सेवा अपनी स्वयं की रिपोर्ट तैयार करती है, और आपको उन सभी का पालन करने की आवश्यकता होती है। इसके अलावा, उन्हें अपने लिए कॉन्फ़िगर करना कठिन होता जा रहा है: आपको या तो एक नई रिपोर्ट के लिए तकनीकी सहायता से संपर्क करने की आवश्यकता है, या स्क्रिप्ट का उपयोग करके इसे स्वयं कॉन्फ़िगर करने का प्रयास करें।

और यदि बहुत अधिक डेटा है, तो एक्सेल मदद नहीं करता है । खासकर यदि दर्जनों लोग एक फाइल पर काम करना शुरू करते हैं जिसमें सब कुछ सूत्रों पर सेट किया गया है - किसी ने कुछ बदल दिया, सब कुछ टूट गया - उन्होंने इसे एक सप्ताह में देखा।

शायद यह विश्लेषकों कंपनियों में दिखाई देता है - विशेष लोग जो आंकड़े और डेटा एकत्र करते हैं और बनाए रखते हैं, क्योंकि संयुक्त होने में बहुत अधिक समय लगता है।

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

दुख का इलाज करो

आप समुद्र में जा सकते हैं, आराम कर सकते हैं, वापस आ सकते हैं और अन्य कंपनियों के अनुभव को देख सकते हैं।


तार्किक समाधान डेटा के मामले में सब कुछ एक साथ रखना और इसे मैट्रिक्स में बदलना है।

हमने निम्नलिखित मापदंड तैयार किए:

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

डैशबोर्ड

हमारे पास बहुत सारे डैशबोर्ड हैं, केवल सक्रिय तकनीकी अब लगभग 30 हैं, और कुल मिलाकर लगभग 100 हैं।



डैशबोर्ड के लिए डेटा आम तौर पर हर जगह से एकत्र किया जाता है। यह एक बड़ा कैनवास निकला है जिसमें से आप आवश्यक रिपोर्ट तैयार कर सकते हैं। नीचे कुछ उदाहरण दिए गए हैं।

आलोचना बग टूटना



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

खुद के खेतों द्वारा कीड़े का टूटना

जीरा में, आप किसी भी कस्टम फ़ील्ड को पैक कर सकते हैं, और ये फ़ील्ड एनालिटिक्स हो सकते हैं, जिसे सामान्य सिस्टम में भी लोड किया गया है। उदाहरण के लिए, घटक घटक नीचे हैं।



टीमों, लोगों, दिशाओं के लिए एक ही कटौती है। यह आपको कई प्रकार के स्लाइस देखने की अनुमति देता है।

नए और बंद बग का अनुपात

यदि हम 20 बग बनाते हैं, और केवल 5 को बंद करते हैं, तो कुछ बिंदु पर हम उनमें दीवार बना देंगे। इसलिए, आपको संख्याओं का पालन करने और 1 के बराबर अनुपात के लिए प्रयास करने की आवश्यकता है।



अवधि के लिए बग प्रवृत्ति

हमारे द्वारा पेश की गई सुविधाजनक प्रणाली यह है कि हमने सभी ऐतिहासिक डेटा अपलोड किए हैं और डायनेमिक्स देख सकते हैं।



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

कीड़े खोजने के चरण

यदि पहले हमने लड़ाई में केवल कीड़े को मापा था, तो अब हम यह सुनिश्चित करने का प्रयास करते हैं कि लड़ाई में कोई कीड़े न हों, और हम विभिन्न चरणों में स्लाइस बनाते हैं: लड़ाई, रिलीज़, परीक्षण, स्वचालन, समीक्षा, आवश्यकताएं।



स्वचालन डैशबोर्ड

स्वचालित परीक्षण के लिए, एक डैशबोर्ड भी है। यह बहुत बड़ा है, इसलिए नीचे दो अलग-अलग टुकड़े हैं।



यह मिस्ड बग की संख्या प्रदर्शित करता है। यदि आपके पास 90% कवरेज है, लेकिन वास्तव में आधे कीड़ों को केवल टिप्पणी या छोड़ दिया जाता है, तो यह बहुत महत्वपूर्ण है, क्योंकि वास्तव में कार्यक्षमता का केवल 50% सही ढंग से काम करता है।

विफलताओं के साथ एक ही बात: कितने परीक्षण क्रैश होते हैं। हम आमतौर पर दुर्घटनाओं के विभिन्न कारणों से बाहर निकलते हैं: सिस्टम क्रैश, बग क्रैश, कार्यक्षमता बदल गई है। अलग-अलग, हम सिस्टम और पर्यावरण पर निर्भर क्रैश साझा करते हैं, और जो विशुद्ध रूप से परीक्षणों पर आधारित थे। पहला ऑपरेशन टीम का काम है, दूसरा ऑटोमेशन का।

हम स्वचालन कवरेज को भी देखते हैं। हम TestRial से सभी सूट लेते हैं, और हम कार्यक्षमता के ब्लॉक में भी गोता लगा सकते हैं, उदाहरण के लिए, कि खोज 30% कवर की गई है।



इसके अलावा, स्टेटस कट पर डेटा यहाँ परिलक्षित हैं:

• नई - नई कार्यक्षमता।
• सुधार की आवश्यकता है - आपको मामले को अपडेट करने की आवश्यकता है।
• आवश्यकता नहीं है - स्वचालन को कवर नहीं करना चाहते हैं।
• हो गया - आच्छादित।

आलोचना का भी अपना एक काट होता है।

डैशबोर्ड का प्रदर्शन

हम Grafana में इस डैशबोर्ड का निर्माण कर रहे हैं, और हम एपीआई, फ्रंटएंड, बैकएंड और सर्वर साइड द्वारा अलग से मेट्रिक्स लोड कर रहे हैं। एक ब्लॉक है जो नवीनतम रिलीज के वर्तमान स्लाइस को दर्शाता है। तदनुसार, आप प्रत्येक मैट्रिक्स में गिर सकते हैं और गतिशीलता देख सकते हैं।



यह सभी अलग-अलग कार्यक्षमता, साइट के विभिन्न पृष्ठों के साथ ओवरलैप करता है।

पर उड़ना

ऐसा लगता है कि अब सब कुछ ठीक है: यह खुद को इकट्ठा करता है और एक जगह, मैट्रिक्स का एक गुच्छा। आप सुरक्षित रूप से आगे बढ़ सकते हैं।

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

हमें समग्र ग्राफ बनाने की आवश्यकता है: 10 में से हम एक बनाते हैं जो इन 10 की स्थिति को दिखाएगा। इसके अलावा, हम मुख्य संकेतकों को ऊपर खींचते हैं। आप डैशबोर्ड खोलते हैं और तुरंत वांछित मानों को देखते हैं, और फिर बाकी सब कुछ, जो मैट्रिक्स को और अधिक विस्तार से प्रकट करता है।

हम साझा करते हैं: व्यापार मैट्रिक्स, प्रक्रिया मैट्रिक्स, क्यूए मेट्रिक्स (वेब ​​/ मोबाइल, मैनुअल / स्वचालन, प्रदर्शन)।

यह एग्रीगेटेड ग्राफ (NPS, CSAT) कैसा दिखता है।



पिछली अवधि की तुलना में शीर्ष पर मूल्य और डेल्टा हैं। इस मामले में, यदि तीर लाल है, तो आपको कुछ करने की आवश्यकता है, कम से कम रेखांकन को अधिक विस्तार से देखें। यदि तीर हरा है, तो सब कुछ ठीक है और आप प्रतिक्रिया नहीं कर सकते।

इसके अलावा, ग्राफिक्स कहीं भी जाने के बिना, एक निचले स्तर तक गिरने की क्षमता रखते हैं ।



कीड़े उन लोगों से संबंधित हैं जिन्होंने उन्हें (परीक्षक या डेवलपर्स) अनुमति दी थी। यदि आप किसी परीक्षक पर अलग से क्लिक करते हैं, तो उस पर एक अलग तालिका खुल जाएगी - कार्यों के लिए एक टुकड़ा।

अगला कदम इस समस्या को हल करना है कि ग्राफ़ शायद ही कभी नियंत्रित होते हैं। अर्थात्, हम डेटा और मैट्रिक्स के साथ काम करने की योजना का विस्तार करेंगे: आवश्यक मैट्रिक्स में सूचनाएं जोड़ें।

चेतावनी

हम बहुत सारे अलर्ट का उपयोग करते हैं। मैं श्रेणियों और विशिष्ट स्थितियों का उदाहरण दूंगा:

• प्रदर्शन।
• ऑटो परीक्षण। उदाहरण के लिए, यदि मिस्ड बग का प्रतिशत बहुत अधिक है, या यदि बहुत अधिक नई कार्यक्षमता परीक्षणों द्वारा कवर नहीं की गई है।
• आने वाली कीड़े। हमारी कंपनी में, किसी को भी टिकट सिस्टम में बग मिल सकता है। पहले, यह पीएम में एक संदेश के साथ था, और अब नए बग की सूचना के लिए एक चैनल है, इसके अलावा, बग्स को स्वचालित रूप से बदले में निष्पादक को सौंपा जाता है। निर्दिष्ट व्यक्ति को बग को पार्स करना चाहिए, अन्यथा बॉट उसे हर 15 मिनट में याद दिलाएगा।
• टेस्ट स्पीड / टेस्ट पेंडिंग। यदि यह स्पष्ट है कि किसी व्यक्ति ने किसी कार्य में खुद को दफनाया है - तो कोई बात नहीं, उसने इसे एनकोड किया, एक समीक्षा की, इसका परीक्षण किया - एक अलर्ट आना चाहिए: "आप पहले से ही तीन कार्य कर रहे हैं, हो सकता है कि आप दफनाए गए हों, मदद के लिए पूछें।"
• कार्य / टीम पर दोष।
• परीक्षण मामलों की समीक्षा। यह प्रक्रिया का सिर्फ स्वचालन है, इसलिए इसे हाथ से नहीं करना है।

चेतावनी के उदाहरण

जलने वाले कार्यों के लिए, बॉट कार्य संख्या, स्थिति, प्राथमिकता लिखता है कि कार्य कितने समय पहले से ही परीक्षण किया जा रहा है और कौन इसका परीक्षण कर रहा है।



सारांश के रूप में तैयार की गई एक अधिसूचना, एक व्यक्ति के पास आती है जो यह देखता है कि उसे क्या समस्याएँ हैं। यहाँ टेस्ट केस के लिए अलर्ट का एक उदाहरण है जो TestRial भेजता है।



यह इंगित करता है कि कौन से मामलों को किसको सौंपा गया है, किस स्थिति के साथ और किस पर नजर रखने की आवश्यकता है।

एक अन्य उदाहरण यबेडा बॉट है, जो प्रक्रियाओं की निगरानी करता है।



बग और कार्य को जोड़ने की प्रक्रिया को कॉन्फ़िगर करने के लिए यह आवश्यक था। बग का विश्लेषण करने वाले डेवलपर को उस कार्य को खोजना होगा जिसमें हमने इस बग को याद किया, आगे के विश्लेषण के लिए, यह जानने के लिए कि हमने बग को क्यों याद किया। यह घटना का एक प्रकार का विश्लेषण है, लेकिन देरी के साथ।

आपको कितने अलर्ट की आवश्यकता है और कितनी बार?

यदि बहुत सारे अलर्ट होंगे, तो उनसे बहुत तनाव होगा। इसलिए, हमने अपने लिए सतर्क प्रबंधन नियम बनाए हैं।

बहुत सारे अलर्ट - जवाब देना बंद कर दें। प्रति दिन 500 अलर्ट आप निश्चित रूप से ब्राउज़ करने का समय रोक देंगे, जिसका अर्थ है कि आप महत्वपूर्ण को छोड़ सकते हैं।

बहुत कम - कोई समस्या नहीं। यदि बहुत कम संदेश हैं, उदाहरण के लिए, बस आधा बाहर फेंक दें, तो आपको किसी प्रकार की समस्या नहीं दिख सकती है।

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

आमतौर पर अलर्ट को मीट्रिक के थ्रेशोल्ड मान पर सेट किया जाता है: यदि मीट्रिक ने थ्रेसहोल्ड को पार कर लिया है, तो अलर्ट आता है। लेकिन, एक नियम के रूप में, इस समय कुछ को ठीक करने के लिए बहुत देर हो चुकी है, सिस्टम पहले से ही खराब है। हम इस पर जल गए, इसलिए हमने ट्रैफिक लाइट विधि शुरू की :

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

इसके अलावा, हमने अलर्ट स्तर पेश किए हैं:

• — , , .
• / . , , .
• . , .
• . , . , . , , .

. , . . , , , , . , , : , .


, :

• . , , , . .

• . , , , . , 10 — .
• . , .

, , . . -, , , , , 15 , . -, , . . -, . , , , , , .

Online

. , . , . , .

QA

, QA .

: , , .

: , , .

:



— , X ( ), () (). , - , ( ) : , . , . , , . , , .

: — , , ( , , ).

: « ». , , , , . - . .

, , . , , . .

-

: , , . , .

: , , , .

, 10 , 500, . , .

. , , .



, , , . , , . «5 », .

, , , .

परिणाम

— , . , . , . , , , — , .


:

• ;
• , ;
• , .

. , , , . .

— . , . , , - .

. , .

:

• ~ 50 QA 100 .
• ~ 30 .
• — , .
• .
• .
• QA must have.

हमारा सम्मेलन, जो उच्च-गुणवत्ता वाले उत्पादों के विकास के सभी पहलुओं को जोड़ता है, अगले साल पुनर्जन्म होगा, RIT ++ से बाहर निकल जाएगा और एक स्वतंत्र बड़े पैमाने पर इवेंट TechLead Conf बन जाएगा। हम जल्द ही टेलीग्राम चैनल में तारीख और स्थान की घोषणा करेंगे , लेकिन अगर आपने अपने अनुभव से देखा है कि विकास प्रक्रिया असंबद्ध ईंटों का एक सेट नहीं है, और इंजीनियरिंग प्रक्रियाओं के निर्माण के लिए समाधान साझा करना चाहते हैं, तो घोषणाओं की प्रतीक्षा किए बिना एक रिपोर्ट के लिए आवेदन करें ।