माइग्रेट करते समय बचने के लिए सामान्य गलतियाँ

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

COVID-19 ने त्वरित तकनीकी समयसीमा की मांग में वृद्धि के साथ-साथ तकनीकी प्रतिभा की कमी दोनों को पैदा किया है। कई कंपनियां " रेड क्वीन " प्रभाव का सामना करना शुरू कर रही हैं, जहां कंपनियों को फिर से परिभाषित करना है कि वे कैसे और कहां बाजार में प्रतिस्पर्धा कर रहे हैं ताकि यह सुनिश्चित हो सके कि वे प्रासंगिक बने रहें। आज जो व्यवसाय संतुष्ट रहते हैं उन्हें एक काटने वाले नुकसान और एक सतत पकड़ चक्र के साथ पुरस्कृत किया जाता है। मौजूदा प्रौद्योगिकियों से अधिक प्रतिक्रियाशील और लागत प्रभावी समाधानों की ओर स्थानांतरण किसी भी उद्यम के कायापलट का एक महत्वपूर्ण हिस्सा है; हालाँकि, यह अप्रस्तुत के लिए नुकसान से भरा हो सकता है।

2020 में बोस्टन कंसल्टिंग ग्रुप के एक अध्ययन के अनुसार, जिसमें 895 डिजिटल ट्रांसफ़ॉर्मेशन वाली 70 कंपनियों में 825 वरिष्ठ अधिकारी शामिल थे, केवल 30% ट्रांसफ़ॉर्मेशन अपने ट्रांसफ़ॉर्मेशन लक्ष्यों को पूरा कर पाए।

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

दस्तावेज़ एक प्रदर्शन आधार रेखा

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

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

• घटक चलने का समय
• आवेदन प्रतिक्रिया समय
• आवेदन समग्र निष्पादन समय
• घटक कनेक्टिविटी और सेवाओं की पहुंच को मान्य करने के लिए परीक्षण एप्लिकेशन
• एपीआई मेट्रिक्स (पेज लोड, मेमोरी उपयोग, सीपीयू, सर्वर प्रदर्शन)
• लॉग आउटपुट लोड
• समय के साथ घटना रिपोर्टिंग लोड
• स्वचालन (और स्वचालन को प्रथम श्रेणी के नागरिक के रूप में मानें क्योंकि यह समग्र प्रदर्शन में सुधार करेगा)
• प्रवासन और कार्य स्वचालन के कारण परिचालन लागत में परिवर्तन
• आपके परिवेश को मॉडल करने वाले एप्लिकेशन प्रकारों के साथ परीक्षण करें।

अच्छे डैशबोर्ड: जो आपको नहीं मिल रहा है उसे आप माइग्रेट नहीं कर सकते

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

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

इसलिए, फोकस "इन्वेंट्री, इन्वेंट्री, इन्वेंट्री" है क्योंकि कई कंपनियों के पास एक केंद्रीय स्थान नहीं होता है जो कैटलॉग करता है कि प्रत्येक एप्लिकेशन का मालिक कौन है, प्रत्येक एप्लिकेशन का क्या है या क्या करता है, और एप्लिकेशन का व्यावसायिक प्रभाव क्या है। संचालन, दक्षता और व्यावसायिक निर्णय लेने के लिए प्रासंगिक जानकारी को जल्दी से क्वेरी करने और खोजने की क्षमता महत्वपूर्ण है।

कहा से शुरुवात करे? सबसे पहले, व्यापक प्रश्नों का उत्तर दें:

• आप किन क्षेत्रों में चल रहे हैं और क्यों?
• प्रत्येक क्षेत्र में कौन से अनुप्रयोग चल रहे हैं?
• प्रत्येक एप्लिकेशन प्रत्येक क्षेत्र में किन सेवाओं का उपयोग कर रहा है?
• Linux का कौन सा संस्करण उपयोग में है?
• एक क्षेत्र में अन्य अनुप्रयोगों के लिए कौन से अनुप्रयोग संचार करते हैं?
• क्लाइंट-फेसिंग बनाम आंतरिक कौन से एप्लिकेशन हैं?

इन शुरुआती डेटा बिंदुओं को इकट्ठा करने से सभी अज्ञात का जवाब नहीं मिलेगा, लेकिन वे आपको आवश्यक अंतर्दृष्टि प्रदान करना शुरू कर देंगे।

ऑडिट आप क्या कर सकते हैं: और अनजानों को स्वीकार करें

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

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

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

सुरक्षा: SecOps टीम को लंच पर ले जाएं

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

स्कोप क्रीप का विरोध करें: यह वास्तव में एक महान विचार है… अगले वर्ष के लिए

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

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

मिररिंग: उस दुनिया से मेल खाना जिसे आप पीछे छोड़ना चाहते हैं

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

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

प्रबंधन के मामले: उच्च स्थानों में मित्र बनाएं

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

असफल होना: इसे सफल बनाना

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

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

हमारे सामने आई इन सामान्य गलतियों को ध्यान में रखते हुए, आपकी अगली परियोजना के उस 70% का हिस्सा बनने की संभावना कम है, जो बोस्टन कंसल्टिंग ग्रुप ने सुझाव दिया है कि वे जो उम्मीद करते हैं उसे प्राप्त न करें।

यहाँ भी प्रकाशित हो चुकी है।.