वास्तविक अभिलेख⑤: सपोर्ट सकिएको सर्भरबाट दुई दिनमा उद्धार

AI केस स्टडी

“चलिरहेको छ, त्यसैले छुँदैनौं।” यसै भनिइरहेको प्रणाली, थाहै नपाई १० वर्ष अघिकै अवस्थामा कम्पनीको केन्द्रमा चलिरहेको थियो — धेरै कम्पनीलाई यसको अनुभव होला। यसपटक, २०१६ मा रिलिज भएको परियोजना व्यवस्थापन प्रणाली,२०२० मा सपोर्ट सकिएको OS माथि इन्टरनेटमा सार्वजनिक भइरहेकै अवस्थामाप्रयोग भइरहेको अवस्थाबाट, नवीनतम वातावरणमा स्थानान्तरण गरेको वास्तविक अभिलेख हो। वास्तविक काम दुई दिन।३,६२३ टिकट र ४.० GB एट्याचमेन्ट, एउटै हानि नभई हस्तान्तरण गर्‍यौं।

“चलिरहेको छ त्यसैले छुन सकिँदैन” भन्ने कुरा, १० वर्ष निरन्तर रह्यो।

लक्ष्य भनेको कम्पनीको परियोजना व्यवस्थापन प्रणाली (Redmine)। परियोजनाको प्रगति, गडबडी सम्बोधनको अभिलेख, ग्राहकसँगको आदानप्रदानको इतिहास — १० वर्षको सामग्री यहीँ जम्मा भएको छ। साँच्चैरोक्न नसकिने भएकाले छुन सकिँदैनभन्ने अवस्था थियो।

तर भित्री कुरा जाँच्दा, कदापि छाडिराख्न मिल्ने अवस्था थिएन।

OS को सपोर्ट सकिएको ६ वर्ष।त्यस अवधिमा सार्वजनिक भएका जोखिमका सुधार, एक पनि लागू भएका छैनन्। त्यो कम्पनी बाहिरबाट पहुँच गर्न मिल्ने अवस्थामा चलिरहेको थियो। “चलिरहेको छ त्यसैले सुरक्षित” होइन,“चलिरहेको मात्र हो, सुरक्षित छैन”भन्नु नै सटीक अभिव्यक्ति हो।

स्थानान्तरणको सफलता-असफलता, काम सुरु गर्नुअघिकै वास्तविक मापनले निर्धारण भइसकेको थियो।

स्थानान्तरणमा प्रवेश गर्नुअघि, वर्तमान अवस्थालाई अंकमा टिपियो। यसैले परिणामतः, श्रम-मात्रालाई ठूलो प्रभाव पार्‍यो।

• डेटाबेस 38MB / एट्याचमेन्ट फाइल ४.० GB
• प्रति दिन २०–३० अनुरोध =सक्रिय रूपमा प्रयोगमा छ
• एक्सटेन्सन प्लगइन: शून्य। आफ्नै डिजाइन: छैन

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

यस वास्तविक मापनका आधारमा, काम सुरु गर्नुअघि तीन नीति निर्धारण गरिएको छ।

१. संस्करण एक-एक तह गरी बढाउने काम त्यागियो

सुरुमा 3.2 → 4.2 → 5.1 → 6.x गरी चरणबद्ध रूपमा बढाउने पूर्वमान्यतामा अनुमान गरिएको थियो। तर परीक्षण गर्दा,१० वर्षको खण्ड एकैचोटि नाघेर अद्यावधिक गर्न सकिनेकुरा थाहा भयो। अनुमान गरिएको श्रम-मात्रा पूरै अनावश्यक भयो।

२. डेटाबेसको प्रकार परिवर्तन गरिएन

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

३. विद्यमान सर्भरलाई सिधै अपग्रेड गरिएन

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

समय खाएको, Redmine थिएन।

यहाँबाट व्यावहारिक काम सुरु हुन्छ। स्थानान्तरणका क्रममा भेटिएका समस्या सूचीबद्ध गर्दा, प्रवृत्ति स्पष्ट देखियो।

आठमध्ये,Redmine मूलबाट आएका केवल तीन। त्यसमाथि तीमध्ये एउटा त “सोचेभन्दा सजिलो थियो” भन्ने राम्रो गलत-अनुमान हो। वास्तवमा दिक्क पारेका दुई मात्र हुन्।

बाँकी OS को पुस्तान्तर, सुरक्षा संयन्त्र, सञ्चार मार्ग, इन्क्रिप्सन, बाह्य प्रणाली जडान —सबै एप्लिकेसनको बाहिरपट्टि छन्।

“एक लाइनमा फर्काउन सकिने” कुरालाई अन्त्यसम्म नछोड्ने।

स्विच भनेको, प्रवेशद्वार सर्भरको फर्वार्ड गन्तव्य नयाँ सर्भरतिर फर्काउने मात्र। फर्काउँदा पनि एक लाइन। रपुरानो वातावरण नरोकी, चलिरहेकै अवस्थामा राखियो।

स्विच गरेको दिन “चलिरहेको पुरानो वातावरण” र “चलिरहेको नयाँ वातावरण” सँगै रहन्छन्, र दुवैतिर एक लाइनमा आउजाउ गर्न सकिने अवस्था कायम राखिएको छ। केही दिन पर्खेर समस्या नभएको पुष्टि गरेपछि, पुरानोतर्फ बन्द गरियो।

स्थानान्तरणमै नटुंग्याई, १० वर्षको कमीलाई पूरा गरियो।

नयाँ वातावरणमा, पुरानो वातावरणमा नभएका कुरा सँगसँगै मिलाइएका छन्।

• दैनिक ब्याकअप (७ पुस्ता) — पुरानो वातावरणमा ब्याकअपको संयन्त्र नै थिएन
• पहुँच-स्रोतको अभिलेख — स्थानान्तरण अघि सबै पहुँच एउटै जस्तो देखिन्थ्यो, र को कहाँबाट आइरहेको हो पत्ता लगाउन नसकिने अवस्था थियो
• लगइन प्रयासको सीमा — मानक सुविधा नभएकाले, वेब सर्भरतर्फ सुदृढीकरण
• स्रोत कोड जडानको स्वचालित अद्यावधिक — व्यावहारिक रूपमा स्थिर भइरहेको जडान हरेक १५ मिनेटमा अद्यावधिक हुने गरी

परिणामस्वरूप हस्तान्तरण गरिएको डेटा निम्नानुसार छ। पुरानो वातावरण र नयाँ वातावरणमा, संख्या पूर्ण रूपमा मेल खाएको पुष्टि गरिएको छ।

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

“हामीसँग पनि, उस्तै सर्भर छ” भने।

यसपटकको स्थानान्तरण छोटो अवधिमा सकिनुका कारण, तीनमा समेट्न सकिन्छ।

• एक्सटेन्सन जडान थिएन— त्यसैले १० वर्षको खण्ड एकैचोटि नाघ्न सकियो
• काम सुरु गर्नुअघि वास्तविक मापन गरियो— निर्णयका आधार अंकमा तयार थिए
• फर्काउन सकिने अवस्था कायम राखियो— स्विच गरेको दिन जुवा खेल्नुपरेन

उल्टो भन्नु पर्दा,यी तीन कुरा काम सुरु गर्नुअघि नै पुष्टि गर्न सकिन्छ।“सपोर्ट सकिएको सर्भरमा, रोक्न नसकिने प्रणाली चलिरहेको छ” — यदि यसको अनुभव छ भने, पहिले वर्तमान अवस्थालाई अंकमा बुझ्ने काम बाट परामर्श सुरु गर्नुहोस्। सार्न सकिन्छ कि सकिँदैन, प्रायः जाँचे थाहा हुन्छ।

शृंखला “लिगेसी to AI वास्तविक अभिलेख”

• समग्र संस्करण: एउटै PC मा २२ प्रणाली र 246,000 लाइन ― AI विकासको ३.५ महिनाको मापन-अभिलेख
• वास्तविक अभिलेख①: २० वर्ष पुरानो Java लाई, करिब एक हप्तामा पूर्ण नवीकरण
• वास्तविक अभिलेख②: विद्यमान कोडमा ० लाइन परिवर्तनसहित, मूल प्रणालीमा नयाँ प्रवेशद्वार बनाउने
• वास्तविक अभिलेख③: एक महिना स्तरको संरचना अध्ययनलाई, दुई दिनमा प्रोटोटाइप + वास्तविक मापनले
• वास्तविक अभिलेख④: पुरानो माइनिङ PC दुई दिनमा “आन्तरिक निजी ChatGPT” मा
• वास्तविक अभिलेख⑤: सपोर्ट सकिएको सर्भरबाट, १० वर्ष पुरानो प्रणालीलाई दुई दिनमा उद्धार (यही लेख)

※ यस लेखका अंकहरू २०२६ अगस्टको वास्तविक मापन हुन्। स्थानान्तरणमा लाग्ने अवधि र कार्य-विवरण प्रणालीको संरचना र एक्सटेन्सनको उपस्थितिअनुसार फरक हुन्छ।