क्लाउड मायग्रेशन प्लॅनिंग: अपयश टाळण्यासाठी आवश्यक पावले

मेघ स्थलांतर नियोजन इमारतीचे नूतनीकरण करणे म्हणजे लोक अजूनही तिच्या आत राहतात. हे क्षुल्लक नूतनीकरणाबद्दल नाही जसे की पॉवर बंद करणे जेणेकरुन तुम्ही ते पुन्हा वायर करू शकता किंवा कोणीतरी शॉवरमध्ये असताना पाईप काढून टाकू शकता. आणि हे निश्चितपणे भाडेकरूंना काही दिवस बाहेर थांबण्यास सांगण्यासारखे नाही, जसे की ते सामान्य आहे.

हे ढग स्थलांतर आहे; तुमच्या उत्पादनाला 24/7 वास्तविक लोकांना सेवा द्यावी लागेल, जेव्हा तुम्ही त्यांच्या खाली जे आहे ते पुन्हा तयार करता. आपण फक्त सेवा थांबवू शकत नाही आणि एकाच वेळी सर्वकाही हलवू शकत नाही; काम चालू असताना तुम्हाला ते उभे ठेवावे लागेल.

आणि होय, संख्या, जसे तुम्ही कल्पना कराल, स्थलांतर किती वेळा अडचणीत येते याबद्दल जोरात आहेत.

गार्टनरचे 2025 मार्गदर्शन डेटा माइग्रेशन प्रकल्पांचे वर्णन करते कारण त्यांची किंमत, जटिलता आणि स्केल यांचा अंदाज लावणे कठीण आहे. तथापि, 83% डेटा स्थलांतरण प्रकल्प अयशस्वी होतात, उशीरा पूर्ण होतात किंवा बजेट ओलांडतात असा वारंवार पुनरावृत्ती केलेला दावा अधिकृत गार्टनर स्त्रोताकडून सत्यापित केला जाऊ शकत नाही.

मॅकिन्सेने नोंदवले की स्थलांतराच्या अकार्यक्षमतेमुळे सरासरी कंपनीला दरवर्षी नियोजित पेक्षा 14% जास्त खर्च होतो, तर 38% कंपन्यांनी स्थलांतराला एक चतुर्थांशपेक्षा जास्त विलंब होतो.

यापैकी काहीही याचा अर्थ क्लाउड इन्फ्रास्ट्रक्चर मूळतः अस्थिर किंवा अविश्वसनीय आहे. हे बहुतेक कारण आहे की स्थलांतर हे एखाद्या कार्याप्रमाणे वागले जाते, शिस्त नाही, जसे की एक चेकलिस्ट आहे आणि मग तुमचे काम झाले. हे सोपे आहे असे ढोंग करण्याची आपल्याला गरज नाही. कामाचे पाच टप्प्यात विभाजन करून आपण त्याचे नियोजन करू शकतो.

1. मूल्यमापन: क्लाउड मायग्रेशन प्लॅनिंग नकाशासह सुरू होते

प्रत्येक स्थलांतर एका प्रश्नाने सुरू होते ज्याचे उत्तर संघ काहीवेळा त्यांच्यापेक्षा कमी काळजीपूर्वक उत्तर देतात: आपण नेमके काय करत आहोत?

मूल्यांकन म्हणजे सर्वकाही कॅटलॉग करणे. यामध्ये ते भाग समाविष्ट आहेत जे कोणालाही इमारत आठवत नाहीत, यासह:

• अंतर्गत API ज्यावर विपणन साधन अवलंबून असते
• तीन वर्षांच्या क्रॉन जॉबचा कोणीही संदर्भ देत नाही परंतु तरीही त्यावर अवलंबून आहे
• कथित तात्पुरते एकीकरण जे 2023 पासून शांतपणे लोड-बेअरिंग आहे

फक्त व्यवस्थेने काय करायचे आहे ते पाहिल्यास पूर्ण उत्तर मिळणार नाही. संस्थात्मक मेमरीवर पूर्णपणे विसंबून राहण्याऐवजी वास्तविक रहदारी आणि कॉल पथ शोधणारी अवलंबित्व-मॅपिंग साधने वापरून ते प्रत्यक्षात काय करते ते आम्ही शोधू शकतो, ज्यामध्ये अंतर आणि थोडे निवडक कथाकथन असू शकते.

आपल्याला वास्तविकतेमध्ये आधारभूत वापर बेसलाइन देखील आवश्यक आहे: वास्तविक CPU, मेमरी, स्टोरेज आणि नेटवर्क लोड कालांतराने, केवळ कोणीतरी काय तरतूद केली आहे असे नाही. वाढणारी उत्पादने शोधू शकतात की काही संसाधने काही महिन्यांपासून जास्त तरतूद केली गेली आहेत. ते उपयुक्त आहे कारण तुम्हाला नवीन वातावरणात कचरा वाहून नोयचा नाही आणि त्याला ऑप्टिमायझेशन म्हणायचे आहे. या टप्प्यावर काळजीपूर्वक क्लाउड कॉस्ट ऑप्टिमायझेशन नवीन वातावरणात अनावश्यक पायाभूत खर्चास प्रतिबंध करू शकते.

AWS मार्गदर्शन पोर्टफोलिओ शोध, सर्व्हर-टू-ॲप्लिकेशन मॅपिंग आणि अवलंबित्व विश्लेषणाला स्थलांतर लहरींचे नियोजन करण्यासाठी मुख्य इनपुट म्हणून हाताळते. औपचारिक मूल्यांकन यशाची हमी देत ​​नाही, परंतु कार्यभार हलविण्याआधी ते कार्यसंघाला उच्च-विश्वसनीय माहिती देते.

2. आर्किटेक्चर: जाताना तुम्ही किती बदलले पाहिजे?

तुम्ही कशासोबत काम करत आहात हे एकदा कळल्यावर, पुढची पायरी म्हणजे तुम्ही हलवताना किती बदल करावेत हे ठरवणे. AWS सध्या सात स्थलांतर धोरणांचे वर्णन करते, ज्यांना सहसा “7 रुपये” म्हटले जाते, जुन्या फ्रेमवर्कमध्ये सामान्यतः उद्धृत केलेल्या सहा पद्धतींमध्ये “रिलोकेट” जोडून. फ्रेमवर्क सर्व काही एकाच वेळी बदलण्याऐवजी परिवर्तनाची योग्य पातळी निवडण्यात संघांना मदत करते.

वाढत्या उत्पादन संघांनी केलेली चूक म्हणजे प्रत्येक गोष्टीसाठी एक धोरण निवडणे. वास्तविक स्थलांतरे सहसा अनेक पद्धतींचे मिश्रण करतात: जे स्थिर आणि अस्पृश्य आहे ते पुनर्संचयित करणे, उत्पादनाची स्पर्धा कशी होते याचे मुख्य घटक रीफॅक्टर करणे आणि एक किंवा अधिक वर्षात कोणीही उघडलेले नाही ते निवृत्त करणे. जेव्हा काही वर्कलोड लगेच हलू शकत नाहीत किंवा करू नयेत तेव्हा काळजीपूर्वक डिझाइन केलेले हायब्रिड क्लाउड आर्किटेक्चर देखील योग्य असू शकते.

हे “प्रत्येक वर्कलोडसाठी कोणता R?” फक्त “कोणता आर?” ऐवजी तुम्हाला संपूर्ण उत्पादनासाठी एकच लेन निवडण्याऐवजी प्रत्येक घटकाचा निर्णय घ्यावा लागेल.

3. डेटा ट्रान्सफर: जिथे विश्वास तुटतो

जेव्हा काहीतरी चूक होते तेव्हा वापरकर्त्यांच्या लक्षात येण्याची शक्यता असते. अयशस्वी मोड नाटकीय आउटेजऐवजी हळूहळू डेटा ड्रिफ्ट असू शकतो, ज्यामुळे ते शोधणे कठीण होऊ शकते.

हे बऱ्याचदा असे होते: संघ एका विशाल कटओव्हरची योजना आखतात आणि एका आठवड्याच्या शेवटी सर्वकाही हलवतात कारण ते अधिक सुरक्षित आणि जलद वाटते. पकड अशी आहे की जुनी प्रणाली अद्याप थेट असू शकते आणि अंतिम समक्रमण दरम्यान लेखन स्वीकारत आहे कारण कोणीही महत्त्वाचे व्यवहार पूर्णपणे गोठवू इच्छित नाही.

त्या विंडोमधले प्रत्येक लिखाण हे स्थलांतराने जुळवून घेतलेला बदल बनतो. ते उत्तम प्रकारे करणे, प्रत्येक वेळी, मोठ्या प्रमाणावर, नियोजनादरम्यान वाटते त्यापेक्षा खूप कठीण आहे.

अधिक सुरक्षित नमुना सामान्यतः:

• अंतिम कटओव्हरपूर्वी लहान, अवलंबित्व-जागरूक लहरींमध्ये स्थलांतर करा
• ऐतिहासिक आणि कमी-जोखीम डेटा लवकर समक्रमित करा
• जेथे प्लॅटफॉर्म सपोर्ट करतो तेथे चालू प्रतिकृती किंवा बदल-डेटा कॅप्चर वापरा
• जेव्हा स्थलांतर डिझाइनची आवश्यकता असेल तेव्हाच लाइव्ह सिस्टमला नियंत्रित वाचन-वाचण्यासाठी किंवा लेखन-फ्रीझ विंडोमध्ये ठेवा आणि ती विंडो शक्य तितक्या लहान ठेवा

हे तितके नाट्यमय नाही, परंतु ते असण्याची गरज नाही. ते कार्य करते, आणि तो मुद्दा आहे.

4. चाचणी: ते वास्तविक आहे हे सिद्ध करा

स्थलांतराच्या दिवशी प्रथमच उत्पादनाला काहीही स्पर्श करू नये. कधी. चाचणीमध्ये हे समाविष्ट असावे:

• प्रातिनिधिक भार आणि वास्तववादी रहदारी नमुने अंतर्गत कामगिरी, केवळ स्वच्छ कृत्रिम गृहीतकेच नाही
• सुरक्षा, ओळख, प्रवेश आणि नेटवर्क कॉन्फिगरेशन
• कटओव्हर यंत्रणा स्वतः, केवळ गंतव्य वातावरण नाही
• रहदारी हलवण्यापूर्वी आणि नंतर डेटा-अखंडता आणि ऍप्लिकेशन-फंक्शन तपासते

कॅनरी रिलीझ रिअल ट्रॅफिकची एक लहान टक्केवारी प्रथम हलवते आणि निळ्या-हिरव्या डिप्लॉयमेंटने जुने वातावरण उपलब्ध ठेवत असताना नवीन व्हॅलिडेट केले जाते ते तैनाती जोखीम कमी करू शकतात आणि रोलबॅक पर्याय सुधारू शकतात. ते त्याच ऑपरेशनल स्नायूचा चाचणी आणि रोलबॅक भाग बनवतात. आम्ही त्यांना पूर्णपणे स्वतंत्र चिंता मानू शकत नाही.

तुमच्या टीमने खऱ्याच्या आधी आंशिक कटओव्हर किंवा रिअलिस्टिक ड्रेस रिहर्सलचा सराव केला नसेल, तर स्थलांतराचा दिवस हा पहिल्यांदाच योजना प्रत्यक्षात येईल.

5. रोलबॅक नियोजन: दस्तऐवज कोणीही लिहू इच्छित नाही

रोलबॅक योजना बऱ्याचदा शेवटच्या, घाईघाईने लिहिल्या जातात आणि अभ्यास न करता सोडल्या जातात. जे, स्पष्टपणे, सुरक्षिततेच्या विरुद्ध आहे.

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

रोलबॅक योजना जी केवळ कागदावर किंवा सिद्धांतानुसार अस्तित्वात आहे ती योग्य सुरक्षा जाळी म्हणून पात्र ठरत नाही. मायक्रोसॉफ्टच्या क्लाउड-माइग्रेशन मार्गदर्शनानुसार, रोलबॅक तयारीमध्ये परिभाषित ट्रिगर, बॅकअप आणि पुनर्संचयित प्रक्रिया, पुनर्प्राप्ती प्रमाणीकरण आणि नियमित चाचणी यांचा समावेश असावा. सराव मध्ये, योजनेची आवश्यकता आहे:

• एक वातावरण आणि डेटा स्नॅपशॉट वापरून एक तालीम जे उत्पादनासारखेच व्यावहारिक आहे
• पूर्व-सहमत ट्रिगर, जसे की विशिष्ट त्रुटी दर, विलंब मर्यादा, प्रतिकृती-लॅग थ्रेशोल्ड किंवा अयशस्वी डेटा-अखंडता तपासणी
• घटना सुरू होण्याआधी नामांकित निर्णय घेणारा आणि गो/नो-गो प्रक्रियेत सहमती झाली
• डेटा पुनर्संचयित करण्यासाठी, रहदारी पुनर्निर्देशित करण्यासाठी आणि पुनर्प्राप्ती प्रमाणित करण्यासाठी स्पष्ट प्रक्रिया

वापरकर्ते आधीच प्रभावित असताना रोलबॅक थ्रेशोल्ड सेट करण्याचा प्रयत्न करण्यासाठी रोलबॅक प्लॅन प्रतिबंधित करण्याची अपेक्षा आहे.

वास्तविक टेकअवे

मूल्यमापन, आर्किटेक्चर, डेटा ट्रान्सफर, चाचणी आणि रोलबॅक हे पर्यायी नाहीत आणि स्लाइड डेक दिसण्याइतके ते रेखीय नाहीत. ते एकमेकांना सतत माहिती देत ​​असतात.

लोक कॉन्फरन्समध्ये ज्या गोष्टी शेअर करतात त्या कथेत बदलण्याऐवजी स्थलांतर शांतपणे जाण्यास कारणीभूत ठरणारी गोष्ट म्हणजे केवळ क्लाउड प्रदाता, बजेट किंवा अगदी शुद्ध तांत्रिक कौशल्य नाही. या योजनेला प्रत्यक्ष प्रकल्प मानले गेले होते की नाही, संघ आणि प्रत्येकाला ज्या निकालापर्यंत पोहोचायचे होते त्यामध्ये काही कंटाळवाणे मध्यम पाऊल म्हणून नाही.