एक रोलआउट कथा जसले सबैलाई असर गर्यो

वास्तविकताका शत्रुहरू 12f-2 द्वारा

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

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

पृष्ठभूमि + यो कस्तो प्रकारको कार्यक्षमता हो?

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

सामान्यतया यस्ता चीजहरू कुनै पनि परियोजनाको सुरुमा निर्माण गर्न सुरु हुन्छ। तर ऐतिहासिक रूपमा MCS मा चीजहरू अलि फरक छन्। MCS दुई भागमा बनाइएको थियो:

• यसको आफ्नै कीस्टोन प्राधिकरण मोड्युलको साथ ओपनस्ट्याक,
• Hotbox (S3 भण्डारण) Mail.ru क्लाउड परियोजनामा ​​आधारित,

जसको वरिपरि नयाँ सेवाहरू देखा पर्यो।

अनिवार्य रूपमा, यी दुई फरक प्रकारको प्राधिकरण थिए। साथै, हामीले केही अलग-अलग Mail.ru विकासहरू प्रयोग गर्यौं, उदाहरणका लागि, एक सामान्य Mail.ru पासवर्ड भण्डारण, साथै एक स्व-लिखित ओपनिड कनेक्टर, जसको लागि होराइजन प्यानलमा SSO (अन्त-देखि-अन्त प्राधिकरण) प्रदान गरिएको थियो। भर्चुअल मेसिनहरूको (नेटिभ ओपनस्ट्याक UI)।

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

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

हामी के रोल आउट गर्न जाँदैछौं?

यसलाई धेरै मोटे रूपमा राख्नको लागि, लगभग 4 महिनामा हामीले निम्न तयार गर्यौं:

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

यस्तो प्रमुख पुन: कार्यको लागि विभिन्न विकास टोलीहरूद्वारा लिखित धेरै प्रणालीहरूमा ठूला, जटिल र सबैभन्दा महत्त्वपूर्ण रूपमा समकालिक परिवर्तनहरू आवश्यक पर्दछ। एक पटक भेला भएपछि, सम्पूर्ण प्रणालीले काम गर्नुपर्छ।

त्यस्ता परिवर्तनहरू कसरी रोल आउट गर्ने र यसलाई पेंच नगर्ने? पहिले हामीले भविष्यमा थोरै हेर्ने निर्णय गर्यौं।

रोलआउट रणनीति

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

डिग्रेसन: रोलआउट के हो?

<सावधानी, दर्शन>

प्रत्येक आईटी विशेषज्ञले सजिलै जवाफ दिन सक्छ कि रोलआउट के हो। तपाइँ CI/CD स्थापना गर्नुहुन्छ, र सबै चीज स्वचालित रूपमा स्टोरमा डेलिभर हुन्छ। 🙂

पक्कै पनि यो सत्य हो। तर कठिनाई यो हो कि आधुनिक कोड डेलिभरी स्वचालन उपकरणहरूको साथ, रोलआउटको बुझाइ हराएको छ। आधुनिक यातायात हेर्दा चक्र को आविष्कार को महाकाव्य को बारे मा कसरी बिर्सनु हुन्छ। सबै कुरा यति स्वचालित छ कि रोलआउट प्रायः सम्पूर्ण तस्विर नबुझेर गरिन्छ।

र सम्पूर्ण तस्विर यस्तै छ। रोलआउटले चार प्रमुख पक्षहरू समावेश गर्दछ:

1. डाटा परिमार्जन सहित कोड को वितरण। उदाहरणका लागि, तिनीहरूको प्रवास।
2. कोड रोलब्याक भनेको केहि गलत भएमा फिर्ता जाने क्षमता हो। उदाहरणका लागि, ब्याकअपहरू सिर्जना गरेर।
3. प्रत्येक रोलआउट/रोलब्याक सञ्चालनको समय। तपाईंले पहिलो दुई बिन्दुहरूको कुनै पनि सञ्चालनको समय बुझ्न आवश्यक छ।
4. प्रभावित कार्यक्षमता। अपेक्षित सकारात्मक र सम्भावित नकारात्मक प्रभाव दुवैको मूल्याङ्कन गर्न आवश्यक छ।

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

ऐन १..एन, रिलिजको तयारी

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

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

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

यस बीचमा, प्राविधिक समर्थनका केटाहरूले जडान विधिहरूमा ग्राहकहरूको लागि निर्देशनहरू लेख्नको लागि आफ्नै स्वतन्त्र प्रयोगहरू सञ्चालन गरे, जुन रोलआउट पछि परिवर्तन हुनुपर्दछ। तिनीहरूले प्रयोगकर्ता UX मा काम गरे, निर्देशनहरू तयार गरे र व्यक्तिगत परामर्श प्रदान गरे।

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

र त्यसैले…

रोल आउट गर्नु अघि अन्तिम कार्य

... यो रोल आउट गर्ने समय हो।

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

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

1. प्रभावित (हाम्रो लागि पवित्र, सबैभन्दा बहुमूल्य) प्रयोगकर्ता पूर्वाधार,
2. कार्यक्षमता: रोलआउट पछि हाम्रो सेवाको प्रयोग पहिले जस्तै हुनुपर्छ।

रोल आउट गर्दै

दुई रोल, 8 हस्तक्षेप गर्दैन

हामी 7 घण्टाको लागि प्रयोगकर्ताहरूबाट सबै अनुरोधहरूको लागि डाउनटाइम लिन्छौं। यस समयमा, हामीसँग रोलआउट योजना र रोलब्याक योजना दुवै छ।

• रोलआउट आफैमा लगभग 3 घण्टा लाग्छ।
• परीक्षणको लागि २ घण्टा।
• २ घण्टा - परिवर्तनहरूको सम्भावित रोलब्याकको लागि रिजर्भ गर्नुहोस्।

प्रत्येक कार्यको लागि एक Gantt चार्ट बनाइएको छ, यसले कति समय लिन्छ, क्रमिक रूपमा के हुन्छ, के समानान्तरमा गरिन्छ।

रोलआउट Gantt चार्टको एक टुक्रा, प्रारम्भिक संस्करणहरू मध्ये एक (समानान्तर कार्यान्वयन बिना)। सबैभन्दा मूल्यवान सिंक्रोनाइजेसन उपकरण

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

घटनाहरूको क्रॉनिकल

त्यसोभए, 15 जना आइतबार, अप्रिल 29, 10 बजे काममा आए। मुख्य सहभागीहरू बाहेक, कोही टोलीलाई समर्थन गर्न आएका थिए, जसको लागि उनीहरूलाई विशेष धन्यवाद।

यो पनि उल्लेखनीय छ कि हाम्रो मुख्य परीक्षक छुट्टीमा छ। परीक्षण बिना रोल आउट गर्न असम्भव छ, हामी विकल्पहरू खोजिरहेका छौं। एक सहकर्मी छुट्टीबाट हामीलाई परीक्षण गर्न सहमत छ, जसको लागि उनले सम्पूर्ण टोलीबाट अपार कृतज्ञता प्राप्त गर्दछ।

००:००। रोक
हामी प्रयोगकर्ता अनुरोधहरू रोक्छौं, प्राविधिक काम भनी एउटा साइन ह्याङ्ग अप गर्छौं। अनुगमन चिच्याउछ, तर सबै सामान्य छ। हामी जाँच गर्छौं कि खस्नु पर्ने बाहेक अरु केहि खसेको छैन। र, बसाइँसराइको काम सुरु गर्छौं ।

सबैसँग बिन्दुमा छापिएको रोलआउट योजना छ, सबैलाई थाहा छ कसले के गरिरहेको छ र कुन क्षणमा। प्रत्येक कार्य पछि, हामी समयहरू जाँच गर्छौं कि हामी तिनीहरूलाई पार गर्दैनौं, र सबै कुरा योजना अनुसार जान्छ। हालको चरणमा प्रत्यक्ष रूपमा रोलआउटमा सहभागी नहुनेहरूले आफ्ना सहकर्मीहरूलाई बाधा नपरोस् भनेर अनलाइन खेलौना (Xonotic, type 3 quacks) लन्च गरेर तयारी गरिरहेका छन्। 🙂

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

यो धेरै राम्रो देखिएन, हामीले यो 10 मिनेट पछि महसुस गर्छौं, जब केहि पनि जडान गरिएको छैन वा टोली सदस्यहरूको परियोजनाहरूमा काम गर्दैनौं। द्रुत सिंक, हामी हाम्रा समस्याहरू सुनाउँछौं, प्राथमिकताहरू सेट गर्छौं, टोलीहरूमा विभाजन गर्छौं र डिबगिङमा जान्छौं।

०२:३०। चार आँखा बनाम दुई ठूला समस्या
हामी दुई ठूला समस्याहरू फेला पार्छौं। हामीले महसुस गर्यौं कि ग्राहकहरूले केही जडान गरिएका सेवाहरू देख्ने छैनन्, र साझेदार खाताहरूमा समस्याहरू उत्पन्न हुनेछन्। दुबै केहि किनारा केसहरूको लागि अपूर्ण माइग्रेसन स्क्रिप्टहरूको कारणले हो। हामीले यसलाई अब ठीक गर्न आवश्यक छ।

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

०३:००। -03 समस्या +00 समस्या
अघिल्ला दुईवटा ठूला समस्याहरू समाधान भइसकेका छन्, र लगभग सबै साना समस्याहरू पनि। फिक्सहरूमा अव्यवस्थित सबै सक्रिय रूपमा तिनीहरूको खाताहरूमा काम गरिरहेका छन् र उनीहरूले के फेला पार्छन् रिपोर्ट गर्दैछन्। हामी प्राथमिकता दिन्छौं, टोलीहरू बीच वितरण गर्छौं, र बिहानको लागि गैर-महत्वपूर्ण वस्तुहरू छोड्छौं।

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

०३:२०। आपतकालीन सिंक
एउटा नयाँ मुद्दा फिक्स गरियो। दोस्रोको लागि, हामी आपतकालीन सिङ्क व्यवस्थित गर्दैछौं। हामी के हुँदैछ बुझ्छौं: अघिल्लो फिक्सले एउटा समस्या फिक्स गर्यो, तर अर्को सिर्जना गर्यो। हामी यसलाई सही र नतिजा बिना कसरी गर्ने भनेर पत्ता लगाउन ब्रेक लिन्छौं।

०३:३०। छ वटा आँखा
हामी बुझ्दछौं कि आधारको अन्तिम अवस्था कस्तो हुनुपर्छ ताकि सबै साझेदारहरूका लागि सबै कुरा राम्ररी जान्छ। हामी 6 आँखाको साथ अनुरोध लेख्छौं, यसलाई पूर्व-उत्पादनमा रोल आउट गर्नुहोस्, परीक्षण गर्नुहोस्, उत्पादनको लागि रोल आउट गर्नुहोस्।

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

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

०६:००। UI मा सबैका लागि खोल्नुहोस्
बगहरू फिक्स गरियो। प्रयोगकर्ताहरूलाई अपील नगर्ने केही पछिका लागि छोडिन्छन्। हामी सबैको लागि इन्टरफेस खोल्छौं। हामी बिलिङ मा काम जारी राख्छौं, प्रयोगकर्ता प्रतिक्रिया र अनुगमन परिणाम को लागी प्रतीक्षा गर्दै।

०७:००। API लोड संग समस्या
यो स्पष्ट हुन्छ कि हामीले हाम्रो API मा लोडलाई थोरै गलत योजना बनायौं र यो लोडको परीक्षण गर्‍यौं, जसले समस्या पहिचान गर्न सकेन। नतिजाको रूपमा, ≈ 5% अनुरोधहरू असफल हुन्छन्। परिचालन गरौं र कारण खोजौं।

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

०८:००। एपीआई फिक्स गर्नुहोस्
हामीले लोडको लागि फिक्स आउट गर्यौं, असफलताहरू गए। हामी घर जान थाल्यौं।

१०:००। सबै
सबै ठीक छ। यो निगरानीमा शान्त छ र ग्राहकहरूको ठाउँमा, टोली बिस्तारै सुत्न जान्छ। बिलिङ बाँकी छ, हामी यसलाई भोलि पुनर्स्थापित गर्नेछौं।

त्यसपछि दिनको समयमा त्यहाँ रोलआउटहरू थिए जसले निश्चित लगहरू, सूचनाहरू, रिटर्न कोडहरू र हाम्रा केही ग्राहकहरूको लागि अनुकूलनहरू।

त्यसैले, रोलआउट सफल भयो! यो, निस्सन्देह, राम्रो हुन सक्छ, तर हामीले पूर्णता प्राप्त गर्नको लागि पर्याप्त थिएन भनेर निष्कर्ष निकाल्यौं।

कुल

रोलआउटको लागि 2 महिनाको सक्रिय तयारीको अवधिमा, 43 कार्यहरू पूरा भए, केही घण्टादेखि धेरै दिनसम्म।

रोलआउट को समयमा:

• नयाँ र परिवर्तन गरिएका राक्षसहरू - 5 टुक्राहरू, 2 मोनोलिथहरू प्रतिस्थापन गर्दै;
• डाटाबेसहरू भित्र परिवर्तनहरू - प्रयोगकर्ता डेटा भएका हाम्रा सबै 6 डाटाबेसहरू प्रभावित भएका छन्, तीनवटा पुरानो डाटाबेसबाट एउटा नयाँमा डाउनलोडहरू गरिएका छन्;
• पूर्ण रूपमा पुन: डिजाइन फ्रन्टएन्ड;
• डाउनलोड गरिएको कोडको मात्रा - नयाँ कोडको 33 हजार लाइनहरू, ≈ परीक्षणहरूमा कोडको 3 हजार लाइनहरू, ≈ माइग्रेसन कोडको 5 हजार लाइनहरू;
• सबै डाटा अक्षुण्ण छ, एकल ग्राहकको भर्चुअल मेसिन बिग्रिएको छैन। 🙂

राम्रो रोलआउटको लागि राम्रो अभ्यासहरू

यो कठिन परिस्थितिमा उहाँहरूले हामीलाई मार्गदर्शन गर्नुभयो। तर, सामान्यतया बोल्दै, कुनै पनि रोलआउटको समयमा तिनीहरूलाई पछ्याउन उपयोगी छ। तर रोलआउट जति जटिल हुन्छ, उनीहरूले खेल्ने भूमिका त्यति नै बढी हुन्छ।

1. तपाईंले गर्नु पर्ने पहिलो कुरा यो बुझ्नु हो कि रोलआउटले प्रयोगकर्ताहरूलाई कसरी असर गर्न सक्छ वा असर गर्छ। त्यहाँ डाउनटाइम हुनेछ? यदि हो भने, डाउनटाइम के हो? यसले प्रयोगकर्ताहरूलाई कसरी असर गर्नेछ? सम्भावित उत्तम र सबैभन्दा खराब अवस्थाहरू के हुन्? र जोखिमहरू कभर गर्नुहोस्।
2. सबै योजना गर्नुहोस्। प्रत्येक चरणमा, तपाईंले रोलआउटका सबै पक्षहरू बुझ्न आवश्यक छ:
   • कोड वितरण;
   • कोड रोलब्याक;
   • प्रत्येक सञ्चालनको समय;
   • प्रभावित कार्यक्षमता।
3. रोलआउटका सबै चरणहरू, साथै तिनीहरूमध्ये प्रत्येकमा जोखिमहरू स्पष्ट नभएसम्म परिदृश्यहरू मार्फत खेल्नुहोस्। यदि तपाइँसँग कुनै शङ्का छ भने, तपाइँ एक ब्रेक लिन सक्नुहुन्छ र शंकास्पद चरण अलग रूपमा जाँच गर्न सक्नुहुन्छ।
4. प्रत्येक चरणले हाम्रा प्रयोगकर्ताहरूलाई मद्दत गर्छ भने सुधार गर्न सकिन्छ र हुनुपर्छ। उदाहरणका लागि, यसले डाउनटाइम कम गर्नेछ वा केही जोखिमहरू हटाउनेछ।
5. रोलब्याक परीक्षण कोड वितरण परीक्षण भन्दा धेरै महत्त्वपूर्ण छ। यो जाँच गर्न आवश्यक छ कि रोलब्याकको परिणामको रूपमा प्रणाली यसको मूल स्थितिमा फर्किनेछ, र परीक्षणहरूको साथ यो पुष्टि गर्नुहोस्।
6. स्वचालित हुन सक्ने सबै कुरा स्वचालित हुनुपर्छ। स्वचालित हुन नसक्ने सबै चीजहरू धोखा पानामा अग्रिम लेखिनुपर्छ।
7. सफलताको मापदण्ड रेकर्ड गर्नुहोस्। कुन कार्यक्षमता उपलब्ध हुनुपर्छ र कुन समयमा? यदि यो भएन भने, रोलब्याक योजना चलाउनुहोस्।
8. र सबैभन्दा महत्त्वपूर्ण - मानिसहरू। सबैलाई आफूले के गर्दैछ, किन र के रोलआउट प्रक्रियामा उनीहरूको कार्यहरूमा निर्भर गर्दछ भन्ने बारे सचेत हुनुपर्दछ।

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

स्रोत: www.habr.com