किन बोरिंग सफ्टवेयर माइग्रेसन परियोजनाहरू तपाईंको गोप्य हतियार हुन सक्छ

युद्ध-कठोर सफ्टवेयर विकासकर्ता/नेता बन्नको लागि आफ्नो यात्रालाई कसरी तीव्र बनाउने भन्ने बारेमा यो विपरीत दृष्टिकोण अन्वेषण गर्नुहोस्।

मेरो १४ वर्षको इन्जिनियरिङ अनुभवमा, मैले धेरै मानिसहरूलाई एकदमै नयाँ सेवामा काम गर्ने अवसरको आधारमा करियर निर्णयहरू गरेको देखेको छु। त्यो निर्णयमा केही गलत छैन। यद्यपि, आज हामी बोरिंग माइग्रेसन परियोजनाहरूमा काम गर्ने विरोधाभासी मामला बनाउन जाँदैछौं। मेरो करियरको सुरुमा मैले महसुस नगरेको कुरा के थियो भने मेरो धेरैजसो आधारभूत सफ्टवेयर विकास सिकाइ माइग्रेसन परियोजनाहरूबाट आएको थियो - जस्तै, अन्तर्निहित डेटा स्टोरलाई अर्को क्लाउड-आधारित प्रविधिमा स्थानान्तरण गर्ने वा नयाँ माइक्रोसेवाहरूको पक्षमा एकाधिकार सेवालाई बेवास्ता गर्ने, आदि।

यो किनभने माइग्रेसनहरू स्वाभाविक रूपमा कठिन हुन्छन्: तपाईंले उपलब्धता, स्केल, विलम्बता, र ग्राहक अनुभवमा अवस्थित बार पूरा गर्न बाध्य हुनुहुन्छ, यदि पार गर्नुहुन्न भने, जुन धेरै इन्जिनियरहरूद्वारा वर्षौंदेखि निर्माण र परिष्कृत गरिएको थियो। तपाईंले ब्रान्ड-नयाँ प्रणालीमा ती बाधाहरूको सामना गर्नुहुने छैन किनभने तपाईं तिनीहरूलाई परिभाषित गर्न स्वतन्त्र हुनुहुन्छ। त्यति मात्र होइन, तपाईं माइग्रेसनहरूसँग जतिसुकै गहन भए पनि, प्रणालीको नयाँ भागहरूमा स्विच गर्दा व्यवहार गर्न कोठरीमा लुकेका कंकालहरू हुनेछन् (डाटाबेस फिल्डको लागि Int बाट BigInt मा Doordash को माइग्रेसन कसरी ब्लकरहरूले भरिएको थियो भन्ने बारे यो रोचक लेख हेर्नुहोस्)।

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

१. तर के तपाईंलाई साँच्चै बसाइँसराइ चाहिन्छ?

म प्रायः नयाँ इन्जिनियरहरूलाई नयाँ प्रविधि प्रयोग गर्न र अवस्थित कार्यक्षमतालाई प्रतिस्थापन गर्न चाहने, वा कोड आधारको पूर्ण रिफ्याक्टर गर्न चाहने कसैलाई देख्छु। यदि यो समावेश गरिएको परिवर्तन हो (जस्तै, सेवामा सानो अपरेशन गर्न राम्रोसँग परीक्षण गरिएको खुला स्रोत पुस्तकालय प्रयोग गर्ने, आदि), मलाई यसमा आपत्ति छैन। तर, यदि यो एक प्रमुख वास्तुकला परिवर्तन हो वा सम्पूर्ण कोड आधार पुन: काम गर्ने हो भने, प्रसिद्ध इन्जिनियरिङ सिद्धान्त "Respect What Came Before" सम्झनु महत्त्वपूर्ण छ। (मैले यो ट्विट रमाइलो पाएँ जसले लेगेसी कोडलाई लेगेन्डरी कोडको रूपमा बुझाउँछ।)

माइग्रेसन परियोजनाहरूको बिन्दुमा फर्किँदै, कोडबेस वा वास्तुकलाको ठूलो ओभरहाल गर्नुको सट्टा तुलनात्मक रूपमा कम प्रयासले उही समस्या समाधान गर्न सकिन्छ कि भनेर मूल्याङ्कन गर्नु सधैं बुद्धिमानी हुन्छ। तर नयाँ प्रविधि वा डिजाइन ढाँचा प्रयोग गर्ने आकर्षण सधैं लोभलाग्दो हुन्छ, त्यसैले हामी यो निर्णयलाई कसरी मूल्याङ्कन गर्छौं? माइग्रेसन यात्रा सुरु गर्नु अघि तपाईंलाई सुरु गर्न मद्दत गर्न यहाँ केही प्रश्नहरू र विचारहरू छन्:

1. के व्यवसाय (वा ग्राहक अनुभव) मा प्रतिकूल असर परेको छ वा भविष्यमा यसले असर पार्नेछ यदि हामीले यो समस्या समाधान गरेनौं र के टोलीले प्रमुख माइग्रेसन परियोजनाको प्रमुख कार्यवाही बिना यसलाई समाधान गर्न सबै विकल्पहरू समाप्त गरिसकेका छन्? अर्को वरिष्ठ इन्जिनियरबाट समीक्षाको लागि छनौट गर्नुहोस् जो तपाईंको टोलीमा छैन र जसले तपाईंको तर्क परीक्षण गर्न दबाब दिन शैतानको वकालतकर्ताको रूपमा काम गर्न सक्छ। औचित्यका केही उदाहरणहरू प्रत्येक सुविधा सुरुवातको लागि ४ विकासकर्ता महिनामा चपलता सुधार गर्ने, p99 विलम्बतालाई ४००ms ले सुधार गर्न विभिन्न सेवाहरूको लागि फरक टेक स्ट्याकहरू प्रयोग गर्ने, X TPS भन्दा बाहिर स्केलिंग अवरोधहरू हटाउने, आदि हुन सक्छन्। त्यस्ता परिस्थितिहरूमा तपाईंको पुष्टिकरण पूर्वाग्रह तोड्न सधैं असहमतिहरू खोज्नुहोस्।

   
   

2. माइग्रेसन गर्ने प्रयासलाई यसले दिने फाइदाहरूसँग तुलना गर्नुहोस्, ताकि तपाईं परियोजनाको फाइदा उठाउन कति समय लाग्नेछ भनेर अनुमान गर्न सक्नुहुन्छ। मैले साझा गर्न सक्ने एउटा व्यक्तिगत उदाहरण यस प्रकार छ:

   • मेरो टोलीसँग दुई फरक ग्राहक आधारहरूको सेवा गर्ने दुई छुट्टाछुट्टै प्रणालीहरू थिए, र प्रत्येक नयाँ सुविधा सुरुवातले टोलीलाई यी छुट्टाछुट्टै प्रणालीहरूमा समान, तर सटीक परिवर्तनहरू गर्न आवश्यक थियो। समग्रमा, डुप्लिकेशनले प्रति महिना १ विकासकर्ताको अतिरिक्त प्रयास निम्त्यायो। हामीले प्रत्येक वर्ष लगभग ४ वटा यस्ता सुविधाहरू सुरु गर्यौं जसले गर्दा ४ विकासकर्ता महिनाको डुप्लिकेट वा खेर जाने प्रयास भयो। यो इन्जिनियरहरूको लागि निराशाजनक थियो। एक इन्जिनियरले यी दुई प्रणालीहरूलाई संयोजन गर्ने प्रस्ताव ल्याए र २४ विकासकर्ता महिनाको प्रयास अनुमान गरे। माइग्रेसनको फाइदा उठाउन टोलीलाई २४ सुविधा सुरुवात र ६ वर्ष (प्रति वर्ष ४ सुविधाहरू सुरु भएको मान्दै) लाग्नेछ। हामीले माइग्रेसन गरेनौं र डुप्लिकेशन प्रयासलाई ५०% ले घटाउन साझा पुस्तकालयहरू प्रयोग गर्ने वैकल्पिक दृष्टिकोणमा सर्यौं, र पछि, हामीले अर्को सेवाको पक्षमा ३ वर्ष पछि प्रणालीलाई अस्वीकार गर्यौं।

     
     

3. कतिपय अवस्थामा, माइग्रेसन भनेको फराकिलो लक्ष्य (जस्तै, अमेजनले ओरेकलबाट टाढा जानु ) पूरा गर्न माथिबाट तलसम्मको मार्गदर्शन हो जहाँ तपाईं अझै पनि विश्लेषण गर्न सक्नुहुन्छ तर परियोजना अगाडि बढाउन स्वीकृति लिन आवश्यक पर्दैन।

एकपटक तपाईंले माइग्रेसन गर्ने सही औचित्यहरू पहिचान गरिसकेपछि र केही बाह्य इन्जिनियरहरू वा नेताहरूसँग तर्कको दबाब-परीक्षण गरिसकेपछि, अर्को चरणहरूमा जाने समय आएको छ।

२. प्रणालीको कार्यात्मक र गैर-कार्यात्मक आवश्यकताहरूको लेआउट

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

यो अभ्यास गर्नुको कारण यो हो कि धेरै अवस्थित टोली सदस्यहरूमा नयाँ प्रणाली निर्माण गर्ने अवचेतन पूर्वाग्रह हुनेछ जुन अवस्थित प्रणाली भन्दा धेरै फरक छैन, धेरै अवस्थामा बसाइँसराइको उद्देश्यलाई पराजित गर्दछ। मेरो विगतको अर्को उदाहरणलाई विचार गर्नुहोस्:

• स्केलिंग अवरोधहरू र मर्मतसम्भार समस्याहरूको कारण हामीले अन-प्रिमाइस SQL डाटाबेसबाट टाढा सर्ने निर्णय गरेका थियौं। यो किनभने हाम्रो सेवाले इन्भेन्टरी-सम्बन्धित अपडेटहरू ट्र्याक गर्न SQL डाटाबेसलाई तालिका इन्जिनको रूपमा प्रयोग गरिरहेको थियो। हामीले प्रत्येक सेकेन्ड SQL डाटाबेस विरुद्ध धेरै जटिल प्रश्नहरू चलायौं, जुन बेकार थियो। हाम्रा इन्जिनियरहरूले हाम्रो SQL डाटाबेसलाई क्लाउड SQL डाटाबेसले प्रतिस्थापन गर्न डिजाइन प्रस्तुत गरे। औचित्य यो थियो कि क्लाउड SQL बढी स्केलेबल थियो, तर हामीले प्रभावकारी रूपमा गरिरहेको कुरा खराब ढाँचाहरूबाट उत्पन्न हुने हाम्रो समस्यालाई क्लाउड प्रविधिमा धकेल्नु थियो। हामीले समस्यालाई क्लाउड प्रविधिमा धकेल्नुको सट्टा खराब ढाँचालाई समाधान गर्नुपर्थ्यो। एक प्रमुख इन्जिनियरले पब/सब सूचना र स्ट्रिमिङ क्यु (जस्तै, काफ्का वा AWS किनेसिस , आदि) प्रयोग गरेर घटना-संचालित प्रणाली निर्माण गर्न हाम्रो दृष्टिकोणलाई निर्देशित गरे जसले हाम्रो मूल प्रस्ताव भन्दा धेरै परिमाणहरू राम्रोसँग स्केल गर्यो।

अवस्थित प्रणालीहरूमा काम नगर्ने बढी अनुभवी व्यक्तिलाई संलग्न गर्नाले कुराकानीलाई पूर्ण रूपमा फरक प्रणाली निर्माण गर्न प्रेरित गर्‍यो जुन अझ स्केलेबल, वास्तविक-समय, र मर्मत गर्न सजिलो थियो। यद्यपि यो सधैं सम्भव नहुन सक्छ, तर यो अभ्यास मार्फत जाने प्रयास गर्न हानि गर्दैन।

यदि तपाईंले हामीले पहिले प्रस्ताव गरेको जस्तै (अर्थात्, अन-प्रिम SQL DB लाई क्लाउड SQL DB मा सार्दै) जस्तै माइग्रेसन गर्दै हुनुहुन्छ भने, तपाईंलाई गैर-कार्यात्मक आवश्यकताहरू पूरा गर्न सजिलो हुन सक्छ। यद्यपि, यदि तपाईंको अन्तिम प्रणाली हालको प्रणाली भन्दा एकदमै फरक छ भने, तपाईंले कम्तिमा प्रणालीमा निर्मित एन्टी-प्याटर्न ठीक गर्ने प्रयास गर्नुपर्छ। उदाहरणका लागि, डाटाबेसमा कुञ्जीमा अद्यावधिक परिवर्तनको लागि मतदान गर्नुको सट्टा, तपाईंले ग्राहकहरूलाई पब/सब सेवा प्रयोग गरेर परिवर्तन सूचना प्रकाशित गर्न सक्नुहुन्छ।

यद्यपि, वितरित प्रणालीहरूमा भएका हरेक परियोजनाहरू जस्तै, माइग्रेसनहरूमा गैर-कार्यात्मक आवश्यकताहरूको सन्दर्भमा व्यापार-अफहरू हुनेछन्, र तपाईंले यसको लागि योजना बनाउनु पर्नेछ। उदाहरणका लागि, यदि ९९.९% को उपलब्धता भएको मोनोलिथ सेवा छ जसले दुई अलग-अलग व्यवसाय-सम्बन्धित गणनाहरू (डेलिभरी मिति अनुमान र ढुवानी शुल्क अनुमान) ह्यान्डल गर्छ, र हामीले यो जिम्मेवारीलाई दुई माइक्रो-सेवाहरू A (डेलिभरी मिति अनुमान सेवा) र B (ढुवानी शुल्क अनुमान) मा विभाजन गर्ने निर्णय गर्छौं जसमा प्रत्येकको ९९.९% उपलब्धता हुन्छ, तब प्रणालीको समग्र उपलब्धता हुन्छ:

P(A) * P (B) = ०.९९९ * ०.९९९ = ९९.८% उपलब्धता

मोनोलिथबाट माइक्रोसर्भिसेजहरू सिर्जना गर्नाले उपलब्धता ९९.९% बाट ९९.८% मा घट्यो।

सधैं सम्झनुहोस्, यदि तपाईंलाई आफ्नो ग्राहकलाई प्रतिक्रिया दिन 'n' सेवा कलहरू (क्रमिक वा समानान्तर सेवा कलहरू) बाट परिणामहरू चाहिन्छ भने, तपाईंले प्रणालीको अन्तिम उपलब्धतामा पुग्न प्रत्येक 'n' सेवाहरूको व्यक्तिगत उपलब्धतालाई गुणा गर्नुहुन्छ।

प्रणालीको मूल उपलब्धता (अर्थात् ९९.९%) पूरा गर्न वा त्योभन्दा बढी गर्न, हामीले क्यासिङ, पुन: प्रयासहरू, आदि जस्ता अन्य प्रविधिहरूको बारेमा सोच्न आवश्यक पर्दछ। तर यी प्रत्येक विकल्पहरूको आफ्नै कमजोरीहरू छन्। उदाहरणका लागि, केही अवस्थामा क्यासिङको अर्थ तपाईंको प्रणालीले पुरानो डेटा सहन सक्षम हुनुपर्छ; पुन: प्रयासहरूले ढिलाइ थप्न सक्छ र प्रणालीलाई पुन: प्रयास आँधीबेहरी, आदिको लागि संवेदनशील बनाउन सक्छ।

यद्यपि, यो अभ्यास गर्नाले तपाईंले कम्तिमा गैर-कार्यात्मक आवश्यकताहरूमा अवस्थित प्रतिबन्ध पूरा गरिरहनुभएको छ कि छैन वा तपाईंले आफ्ना ग्राहकहरूलाई प्रदान गर्न चाहनुभएको नयाँ गैर-कार्यात्मक आवश्यकताहरूमा नेतृत्व स्वीकृति आवश्यक छ कि छैन भनेर हेर्न अनुमति दिनुपर्छ।

३. के ग्राहकहरूले कुनै कारबाही गर्न आवश्यक छ?

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

अन्य अवस्थामा, यो सम्भव छैन। उदाहरणका लागि, यदि तपाईंसँग उद्योगमा व्यापक रूपमा अपनाइएको ठूलो क्लाउड सेवा छ भने, तपाईंले सबै ग्राहकहरूलाई क्लाइन्टको नयाँ संस्करणमा सार्न बाध्य पार्न सक्ने कुनै तरिका छैन। यसले टोलीको लागि महत्त्वपूर्ण ब्लकरहरू साथै मर्मतसम्भार ओभरहेड थप्न सक्छ, र केही अवस्थामा, समाधान भनेको पुरानो प्रणाली मर्मतसम्भार मोडमा रहेको प्रणालीहरूको दुई संस्करणहरू कायम राख्नु हो (अर्थात्, यस प्रणालीमा कुनै पनि नयाँ ग्राहकहरू थपिएका छैनन्) र तपाईंले पुराना ग्राहकहरूलाई प्रणालीको नयाँ संस्करणमा सार्न प्रोत्साहन प्रदान गर्नुहुन्छ किनभने यसले ग्राहकहरूलाई सुधारिएको फाइदाहरू प्रदान गर्दछ।

यद्यपि, यदि तपाईंसँग माथि Doordash सँग साझा गरिएको लिङ्क जस्तो परिस्थिति छ जहाँ प्राथमिक कुञ्जीको डेटा प्रकारको रूपमा Int प्रयोग गर्दा ओभरफ्लो हुने थियो भने, तपाईंसँग सबैलाई माइग्रेसन गर्न बाध्य पार्नु बाहेक अरू कुनै विकल्प छैन।

४. के यस्तै प्रकारका बसाइँसराइहरू पहिले नै भइसकेका छन्?

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

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

धेरैजसो बसाइँसराइ सामान्यतया तलका दुई श्रेणीहरू मध्ये एकमा वा दुवैको संयोजनमा हुन्छ:

1. सेवा माइग्रेसन: नयाँ वास्तुकलाको पक्षमा अवस्थित सेवालाई बेवास्ता गर्ने जसमा हालको सेवाका भागहरू र नयाँ सेवा प्रयोग गर्ने वा अवस्थित प्रणालीलाई प्रतिस्थापन गर्न नयाँ माइक्रोसेवाहरू सुरु गर्ने समावेश हुन सक्छ।

   
   

2. डेटास्टोर माइग्रेसन: अवस्थित डेटा स्टोरलाई हटाएर नयाँ डेटा स्टोरले प्रतिस्थापन गर्ने वा घटना-संचालित प्रणालीको प्रयोग गर्ने।

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

५. पुरानो र नयाँ प्रणालीहरू समानान्तर रूपमा चलाउने

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

धेरै वर्ष पहिले, मैले नयाँ प्राविधिक स्ट्याकमा सेवा माइग्रेसनमा काम गरेको थिएँ। जब हाम्रो पुरानो सेवाले ग्राहक अनुरोधहरू प्राप्त गर्थ्यो, हामी ब्याकएन्डमा हाम्रो नयाँ सेवामा समानान्तर एसिन्क्रोनस कल गर्थ्यौं। हामी अवस्थित र नयाँ सेवा परिणामहरू S3 स्थानमा लग गर्थ्यौं। त्यसपछि हामीले दिनको अन्त्यमा कुनै पनि विसंगतिहरू पत्ता लगाउन र नयाँ सेवामा कुनै पनि समस्याहरू पहिचान गर्न AWS एथेना क्वेरी चलायौं। हामीले डेटा स्टोरसँग ह्यान्डल गरेको अर्को कठिन माइग्रेसनको तुलनामा त्यो अझै पनि केही हदसम्म अनुमान गर्न सकिने कुरा थियो।

हामी पुरानो SQL डेटा स्टोरलाई नयाँ NoSQL डेटा स्टोरमा सार्दै थियौं जुन अझ भरपर्दो र नयाँ डेटा स्रोतबाट भरिएको थियो। यद्यपि, पुरानो र नयाँ डेटा स्टोरहरू बीच विशिष्ट कुञ्जीहरू अद्यावधिक हुने समय अप्रत्याशित थियो, किनकि तिनीहरू दुई पूर्णतया फरक प्रणालीहरूबाट आएका थिए।

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

६. चीजहरू गलत हुने अपेक्षा गर्नुहोस्: के तपाईं अघिल्लो संसारमा फर्कन सक्नुहुन्छ?

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

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

जहाँ यो सम्भव छैन, त्यहाँ तपाईंको भर पर्ने एक मात्र कुरा चरण ५ मा पूर्ण हुनु हो। (पुरानो र नयाँ प्रणालीहरू समानान्तर रूपमा चलाउनु)। यसपछि नयाँ प्रणालीको ढिलो क्रमिक रोलआउट हुन्छ। तपाईंले नयाँ सेवाद्वारा सेवा प्रदान गर्नको लागि सानो प्रतिशत (१% पछि ५%, १०%, २५%, ५०%, १००%) ट्राफिक सार्ने, वा माइग्रेसनको समयमा तपाईं नजिकबाट काम गरिरहनुभएको नयाँ सेवाद्वारा सेवा प्रदान गर्न केही ग्राहकहरूलाई हातले छनोट गर्ने जस्ता प्रविधिहरू प्रयोग गरेर ढिलो क्रमिक रोलआउट परिभाषित गर्न सक्नुहुन्छ।

यदि चीजहरू गलत भएमा अपरेटरहरूले पछ्याउने घटना प्रतिक्रिया रनबुकको व्यापक रूपमा समीक्षा गर्नु पनि महत्त्वपूर्ण छ। यदि सबै कुरा असफल भयो भने, म्यानुअल हस्तक्षेपले छुटेका किनाराका केसहरूमा मद्दत गर्न सक्छ, तर प्रभावित ग्राहकहरूको संख्या हजारौंमा बढ्यो भने यो चाँडै अव्यवस्थित हुन सक्छ। यो बुँदा ५ र ६ मा वर्णन गरिएका चरणहरूलाई पर्याप्त समय दिने कारण हो।

निष्कर्ष

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

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