एक रोलआउट कहानी जिसने हर चीज़ को प्रभावित किया

हकीकत के दुश्मन 12f-2 द्वारा

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

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

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

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

आमतौर पर ऐसी चीजें किसी भी प्रोजेक्ट की शुरुआत में ही बननी शुरू हो जाती हैं। लेकिन ऐतिहासिक रूप से एमसीएस में चीजें थोड़ी अलग रही हैं। एमसीएस को दो भागों में बनाया गया था:

• अपने स्वयं के कीस्टोन प्राधिकरण मॉड्यूल के साथ ओपनस्टैक,
• Mail.ru क्लाउड प्रोजेक्ट पर आधारित हॉटबॉक्स (S3 स्टोरेज),

जिसके चारों ओर फिर नई सेवाएँ सामने आईं।

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

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

कार्य गैर-तुच्छ निकला: पायथन और पर्ल, कई बैकएंड, स्वतंत्र रूप से लिखित सेवाएँ, कई विकास दल और व्यवस्थापक। और सबसे महत्वपूर्ण बात यह है कि लड़ाकू उत्पादन प्रणाली पर हजारों लाइव उपयोगकर्ता हैं। यह सब लिखा जाना था और सबसे महत्वपूर्ण बात यह थी कि इसे बिना किसी नुकसान के पूरा किया जाना था।

हम क्या करने जा रहे हैं?

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

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

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

इस तरह के बदलाव कैसे करें और इसे खराब न करें? सबसे पहले हमने भविष्य पर थोड़ा गौर करने का फैसला किया।

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

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

विषयांतर: रोलआउट क्या है?

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

प्रत्येक आईटी विशेषज्ञ आसानी से उत्तर दे सकता है कि रोलआउट क्या है। आप सीआई/सीडी स्थापित करते हैं, और सब कुछ स्वचालित रूप से स्टोर पर पहुंचा दिया जाता है। 🙂

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

और पूरी तस्वीर इस प्रकार है. रोलआउट में चार प्रमुख पहलू शामिल हैं:

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

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

अधिनियम 1..एन, रिहाई की तैयारी

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

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

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

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

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

इसलिए…

रोल आउट करने से पहले अंतिम कार्य

...इसे शुरू करने का समय आ गया है।

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

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

1. उपयोगकर्ता के बुनियादी ढांचे को प्रभावित करें (हमारे लिए पवित्र, सबसे कीमती),
2. कार्यक्षमता: रोलआउट के बाद हमारी सेवा का उपयोग पहले की तरह ही होना चाहिए।

बेलना

दो रोल, 8 हस्तक्षेप नहीं करते

हम उपयोगकर्ताओं से सभी अनुरोधों के लिए 7 घंटे का डाउनटाइम लेते हैं। इस समय, हमारे पास रोलआउट योजना और रोलबैक योजना दोनों हैं।

• रोलआउट में लगभग 3 घंटे लगते हैं।
• परीक्षण के लिए 2 घंटे।
• 2 घंटे - परिवर्तनों के संभावित रोलबैक के लिए आरक्षित।

प्रत्येक क्रिया के लिए एक गैंट चार्ट तैयार किया गया है, इसमें कितना समय लगता है, क्रमिक रूप से क्या होता है, समानांतर में क्या किया जाता है।

रोलआउट गैंट चार्ट का एक टुकड़ा, शुरुआती संस्करणों में से एक (समानांतर निष्पादन के बिना)। सबसे मूल्यवान तुल्यकालन उपकरण

रोलआउट में सभी प्रतिभागियों की भूमिका निर्धारित है, वे क्या कार्य करते हैं और वे किसके लिए जिम्मेदार हैं। हम प्रत्येक चरण को स्वचालितता में लाने का प्रयास करते हैं, इसे रोल आउट करते हैं, इसे वापस रोल करते हैं, फीडबैक एकत्र करते हैं और इसे फिर से रोल आउट करते हैं।

घटनाओं का क्रॉनिकल

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

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

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

हर किसी के पास बिंदुवार एक मुद्रित रोलआउट योजना होती है, हर कोई जानता है कि कौन क्या कर रहा है और किस समय कर रहा है। प्रत्येक कार्रवाई के बाद, हम यह सुनिश्चित करने के लिए समय की जांच करते हैं कि हम उससे आगे न बढ़ें, और सब कुछ योजना के अनुसार होता है। जो लोग वर्तमान चरण में सीधे रोलआउट में भाग नहीं ले रहे हैं, वे एक ऑनलाइन खिलौना (एक्सोनोटिक, टाइप 3 क्वैक्स) लॉन्च करके तैयारी कर रहे हैं ताकि उनके सहयोगियों को परेशानी न हो। 🙂

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

यह बहुत अच्छा नहीं हुआ, हमें इसका एहसास 10 मिनट के बाद हुआ, जब टीम के सदस्यों की परियोजनाओं में कुछ भी जुड़ा या काम नहीं कर रहा था। त्वरित सिंक, हम अपनी समस्याओं को व्यक्त करते हैं, प्राथमिकताएँ निर्धारित करते हैं, टीमों में विभाजित होते हैं और डिबगिंग में जाते हैं।

02:30. दो बड़ी समस्याएँ बनाम चार आँखें
हमें दो बड़ी समस्याएँ मिलती हैं। हमने महसूस किया कि ग्राहकों को कुछ कनेक्टेड सेवाएँ नहीं दिखेंगी और भागीदार खातों के साथ समस्याएँ उत्पन्न होंगी। दोनों कुछ किनारे के मामलों के लिए अपूर्ण माइग्रेशन स्क्रिप्ट के कारण हैं। हमें इसे अभी ठीक करने की जरूरत है.

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

03:00. -2 समस्याएँ +2 समस्याएँ
पिछली दो बड़ी समस्याओं को ठीक कर दिया गया है, और लगभग सभी छोटी समस्याओं को भी। फिक्स में वे सभी बेरोजगार सक्रिय रूप से अपने खातों में काम कर रहे हैं और जो भी पाते हैं उसकी रिपोर्ट कर रहे हैं। हम प्राथमिकताएँ निर्धारित करते हैं, टीमों के बीच वितरित करते हैं, और गैर-महत्वपूर्ण वस्तुओं को सुबह के लिए छोड़ देते हैं।

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

03:20. आपातकालीन सिंक
एक नया मुद्दा ठीक किया गया. दूसरे के लिए, हम एक आपातकालीन सिंक का आयोजन कर रहे हैं। हम समझते हैं कि क्या हो रहा है: पिछले सुधार ने एक समस्या ठीक कर दी, लेकिन दूसरी समस्या पैदा कर दी। हम यह जानने के लिए एक ब्रेक लेते हैं कि इसे सही तरीके से और बिना किसी परिणाम के कैसे किया जाए।

03:30. छह आँखें
हम समझते हैं कि आधार की अंतिम स्थिति क्या होनी चाहिए ताकि सभी भागीदारों के लिए सब कुछ ठीक रहे। हम 6 आँखों से एक अनुरोध लिखते हैं, इसे प्री-प्रोडक्शन में रोल आउट करते हैं, इसका परीक्षण करते हैं, इसे प्रोडक्शन के लिए रोल आउट करते हैं।

04:00. सब कुछ काम कर रहा है
सभी परीक्षण उत्तीर्ण हुए, कोई गंभीर समस्या नजर नहीं आई। समय-समय पर, टीम में कोई बात किसी के काम नहीं आती तो हम तुरंत प्रतिक्रिया देते हैं। अक्सर अलार्म ग़लत होता है. लेकिन कभी-कभी कुछ नहीं आता है, या एक अलग पेज काम नहीं करता है। हम बैठते हैं, ठीक करते हैं, ठीक करते हैं, ठीक करते हैं। एक अलग टीम आखिरी बड़ी सुविधा - बिलिंग - लॉन्च कर रही है।

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

06:00. यूआई में सभी के लिए खुला है
सुधार दिया। कुछ जो उपयोगकर्ताओं को पसंद नहीं आते उन्हें बाद के लिए छोड़ दिया जाता है। हम सभी के लिए इंटरफ़ेस खोलते हैं। हम बिलिंग पर काम करना जारी रखते हैं, उपयोगकर्ताओं की प्रतिक्रिया की प्रतीक्षा करते हैं और परिणामों की निगरानी करते हैं।

07:00. एपीआई लोड के साथ समस्याएँ
यह स्पष्ट हो जाता है कि हमने अपने एपीआई पर लोड को थोड़ा गलत तरीके से नियोजित किया और इस लोड का परीक्षण किया, जिससे समस्या की पहचान नहीं हो सकी। परिणामस्वरूप, ≈5% अनुरोध विफल हो जाते हैं। आइए संगठित हों और कारण खोजें।

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

08:00. एपीआई ठीक करें
हमने लोड के लिए एक समाधान तैयार किया, विफलताएं दूर हो गईं। हम घर जाने लगते हैं.

10:00. सभी
सब कुछ तय है. मॉनिटरिंग में शांति रहती है और ग्राहकों के यहां टीम धीरे-धीरे सो जाती है. बिलिंग बाकी है, हम इसे कल बहाल कर देंगे।

फिर दिन के दौरान हमारे कुछ ग्राहकों के लिए लॉग, नोटिफिकेशन, रिटर्न कोड और अनुकूलन को ठीक करने वाले रोलआउट हुए।

तो, रोलआउट सफल रहा! बेशक, यह बेहतर हो सकता है, लेकिन हमने इस बारे में निष्कर्ष निकाला कि पूर्णता प्राप्त करने के लिए हमारे लिए क्या पर्याप्त नहीं था।

कुल मिलाकर

रोलआउट के लिए 2 महीने की सक्रिय तैयारी के दौरान, 43 कार्य पूरे किए गए, जो कुछ घंटों से लेकर कई दिनों तक चले।

रोलआउट के दौरान:

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

अच्छे रोलआउट के लिए अच्छे अभ्यास

उन्होंने इस कठिन परिस्थिति में हमारा मार्गदर्शन किया. लेकिन, सामान्यतया, किसी भी रोलआउट के दौरान उनका अनुसरण करना उपयोगी होता है। लेकिन रोलआउट जितना अधिक जटिल होगा, उनकी भूमिका उतनी ही अधिक होगी।

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

और एक वाक्य में, अच्छी योजना और विस्तार के साथ आप बिक्री पर प्रतिकूल प्रभाव डाले बिना अपनी इच्छानुसार कुछ भी पेश कर सकते हैं। यहां तक ​​कि कुछ ऐसा भी जो उत्पादन में आपकी सभी सेवाओं को प्रभावित करेगा।

स्रोत: www.habr.com