एक बड़े बैंग पुनर्लेखन के लिए प्रदर्शन परीक्षण का प्रतिरोध?

Question

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

अंत में, वे इसे करने के लिए सहमत हुए हैं (और हमने उन्हें उत्पादन में मौजूद समांतर बीटा सर्वर को लाकर सफलतापूर्वक रोक दिया है और परीक्षणों का लक्ष्य होगा)। मुझे यह पसंद नहीं है कि वे इसे प्राथमिकता देने के अंत तक इंतजार कर रहे थे, लेकिन यह कभी भी देर से बेहतर नहीं है।

भविष्य में इन तरह की स्थितियों से निपटने के लिए हर किसी के पास क्या सुझाव हैं? इस तरह के परीक्षणों की आवश्यकता के बारे में प्रबंधकों/ग्राहकों को शिक्षित करने का सबसे अच्छा तरीका क्या है।

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

कई प्रबंधकों और पुराने स्कूल इंजीनियरों जिन्होंने केवल एएसपी लिखा था, लेकिन कभी भी .NET नहीं किया जाता था, उन्हें स्वयं सब कुछ कोड करने के लिए उपयोग किया जाता है और नए .NET ऐप्स में कैशिंग, ट्यूनिंग और स्वास्थ्य निगरानी के लिए सभी विकल्पों को समझ में नहीं आता है।

धन्यवाद

Answer 1

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

Answer 2

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

Answer 3

जो आपको नहीं पता था (और कई इंजीनियरों नहीं) यह है कि यह एक "बिक्री की स्थिति" थी, न कि इंजीनियरिंग एक। इससे कोई फर्क नहीं पड़ता कि ग्राहक घर में है या नहीं, प्रक्रिया काफी हद तक समान है।

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

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

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

Answer 4

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

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

आप अभी भी प्रदर्शन हॉटस्पॉट काम कर सकते हैं; आपको सिर्फ पॉइंटी बालों वाले मालिकों को कॉमफ्रेट देने की ज़रूरत है कि आपका पूरा काम मूर्त व्यावसायिक उद्देश्यों पर जा रहा है।

Answer 5

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

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

जोखिम: सिस्टम प्रदर्शन उपयोगकर्ता की उम्मीदों

संभावना को पूरा करने में विफल रहता है:

पुनर्लेखन के बहुत शुरुआत में, अपने जोखिम लॉग निम्नलिखित प्रविष्टि हो सकता था अज्ञात

प्रभाव: अत्यधिक लोड समय के कारण अंतिम उपयोगकर्ता वेबसाइट छोड़ देते हैं। परियोजना विफल

प्रभाव की लागत: $$$ जो भी आपकी परियोजना लागत है।

कमी: पखवाड़े प्रदर्शन परीक्षण।

शमन लागत: $$$ जो कुछ भी आपको लगता है कि यह समय और पैसा

सिफारिश में खर्च आएगा: रन प्रदर्शन जोखिम अंदाजा लगाना परीक्षण।

अधिकतर प्रबंधकों को जोखिम के साथ बहुत असहज होगा, जिनकी संभावना अज्ञात है, लेकिन जिनकी लागत परियोजना की विफलता है। दूसरी ओर, आप एक बड़ी प्रतिबद्धता नहीं मांग रहे हैं - जोखिम को मापने के लिए पर्याप्त है।

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

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

इस मुद्दे को मापकर, आप इसे एक व्यावसायिक निर्णय में बदलते हैं, न कि इंजीनियरिंग निर्णय।