रोलआउट कथा ज्याने प्रत्येक गोष्टीवर परिणाम केला

वास्तवाचे शत्रू 12f-2 द्वारे

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

मी आता आम्ही घेतलेल्या वास्तुशास्त्रीय आणि तांत्रिक निर्णयांचे वर्णन करणार नाही किंवा हे सर्व कसे कार्य करते ते सांगणार नाही. सर्वात कठीण रोलआउट्सपैकी एक कसे घडले, ज्याचे मी निरीक्षण केले आणि ज्यामध्ये मी थेट सामील होतो त्या मार्जिनमधील या नोट्स आहेत. मी पूर्णता किंवा तांत्रिक तपशीलांचा दावा करत नाही; कदाचित ते दुसर्‍या लेखात दिसतील.

पार्श्वभूमी + ही कोणत्या प्रकारची कार्यक्षमता आहे?

आम्ही क्लाउड प्लॅटफॉर्म तयार करत आहोत Mail.ru क्लाउड सोल्यूशन्स (MCS), जिथे मी तांत्रिक संचालक म्हणून काम करतो. आणि आता आमच्या प्लॅटफॉर्मवर IAM (ओळख आणि प्रवेश व्यवस्थापन) जोडण्याची वेळ आली आहे, जे सर्व वापरकर्ता खाती, वापरकर्ते, पासवर्ड, भूमिका, सेवा आणि बरेच काही यांचे एकत्रित व्यवस्थापन प्रदान करते. क्लाउडमध्ये त्याची आवश्यकता का आहे हा एक स्पष्ट प्रश्न आहे: सर्व वापरकर्ता माहिती त्यात संग्रहित आहे.

सहसा अशा गोष्टी कोणत्याही प्रकल्पाच्या अगदी सुरुवातीला बांधल्या जाऊ लागतात. पण ऐतिहासिकदृष्ट्या MCS मध्ये गोष्टी थोड्या वेगळ्या होत्या. MCS दोन भागांमध्ये बांधले होते:

• ओपनस्टॅक त्याच्या स्वतःच्या कीस्टोन अधिकृतता मॉड्यूलसह,
• Hotbox (S3 स्टोरेज) Mail.ru क्लाउड प्रोजेक्टवर आधारित,

ज्याभोवती नंतर नवीन सेवा दिसू लागल्या.

मूलत:, हे अधिकृततेचे दोन भिन्न प्रकार होते. शिवाय, आम्ही काही वेगळ्या Mail.ru विकासाचा वापर केला, उदाहरणार्थ, सामान्य Mail.ru पासवर्ड स्टोरेज, तसेच स्व-लिखित ओपनआयड कनेक्टर, ज्यासाठी क्षितिज पॅनेलमध्ये SSO (एंड-टू-एंड ऑथोरायझेशन) प्रदान केले गेले. आभासी मशीनचे (नेटिव्ह ओपनस्टॅक UI).

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

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

आम्ही काय रोल आउट करणार आहोत?

अगदी अंदाजे सांगायचे तर, सुमारे 4 महिन्यांत आम्ही खालील गोष्टी तयार केल्या:

• आम्‍ही अनेक नवीन डिमन तयार केले आहेत ज्यात फंक्‍शन एकत्रित केले आहेत जे पूर्वी पायाभूत सुविधांच्या विविध भागांमध्ये कार्य करत होते. उर्वरित सेवांना या राक्षसांच्या रूपात एक नवीन बॅकएंड विहित करण्यात आला होता.
• आम्ही आमच्या सर्व सेवांसाठी उपलब्ध असलेले संकेतशब्द आणि कळांचे आमचे स्वतःचे केंद्रीय संचयन लिहिले आहे, जे आम्हाला आवश्यकतेनुसार मुक्तपणे सुधारित केले जाऊ शकते.
• आम्ही कीस्टोनसाठी सुरवातीपासून (वापरकर्ते, प्रकल्प, भूमिका, भूमिका असाइनमेंट) 4 नवीन बॅकएंड्स लिहिले, ज्याने खरेतर, त्याचा डेटाबेस बदलला आणि आता आमच्या वापरकर्ता संकेतशब्दांसाठी एकल भांडार म्हणून कार्य करते.
• आम्ही आमच्या सर्व ओपनस्टॅक सेवांना प्रत्येक सर्व्हरवरून स्थानिक पातळीवर ही धोरणे वाचण्याऐवजी त्यांच्या धोरणांसाठी तृतीय-पक्ष पॉलिसी सेवेकडे जाण्यास शिकवले (होय, डीफॉल्टनुसार ओपनस्टॅक असेच कार्य करते!)

अशा मोठ्या पुनर्कार्यासाठी विविध विकास संघांनी लिहिलेल्या अनेक प्रणालींमध्ये मोठ्या, जटिल आणि सर्वात महत्त्वाचे म्हणजे समकालिक बदल आवश्यक आहेत. एकदा एकत्र केल्यावर, संपूर्ण यंत्रणा कार्य करेल.

असे बदल कसे आणायचे आणि ते खराब कसे करायचे? प्रथम आम्ही थोडे भविष्यात पाहण्याचा निर्णय घेतला.

रोलआउट धोरण

• उत्पादनास अनेक टप्प्यांत रोल आउट करणे शक्य होईल, परंतु यामुळे विकास कालावधी तीन पटीने वाढेल. याव्यतिरिक्त, काही काळासाठी डेटाबेसमधील डेटाचे संपूर्ण डिसिंक्रोनाइझेशन होईल. तुम्हाला तुमची स्वतःची सिंक्रोनाइझेशन साधने लिहावी लागतील आणि बर्याच काळासाठी एकाधिक डेटा स्टोअरसह राहावे लागेल. आणि यामुळे विविध प्रकारचे धोके निर्माण होतात.
• वापरकर्त्यासाठी जे काही पारदर्शकपणे तयार केले जाऊ शकते ते आगाऊ केले गेले. 2 महिने लागले.
• आम्‍ही अनेक तासांसाठी स्‍वत:ला स्‍वत:ला स्‍वत:ला डाउनटाइम परवानगी दिली – केवळ वापरकर्ता ऑपरेशनसाठी संसाधने तयार करण्‍यासाठी आणि बदलण्‍यासाठी.
• आधीच तयार केलेल्या सर्व संसाधनांच्या ऑपरेशनसाठी, डाउनटाइम अस्वीकार्य होता. आम्ही योजना आखली की रोलआउट दरम्यान, संसाधनांनी डाउनटाइमशिवाय काम केले पाहिजे आणि क्लायंटवर परिणाम केला पाहिजे.
• काही चूक झाल्यास आमच्या ग्राहकांवर होणारा परिणाम कमी करण्यासाठी, आम्ही रविवारी संध्याकाळी रोल आउट करण्याचा निर्णय घेतला. कमी ग्राहक रात्री व्हर्च्युअल मशीन व्यवस्थापित करतात.
• आम्ही आमच्या सर्व क्लायंटना चेतावणी दिली की रोलआउटसाठी निवडलेल्या कालावधी दरम्यान, सेवा व्यवस्थापन अनुपलब्ध असेल.

विषयांतर: रोलआउट म्हणजे काय?

<सावधगिरी, तत्वज्ञान>

रोलआउट म्हणजे काय याचे उत्तर प्रत्येक आयटी तज्ञ सहज देऊ शकतात. तुम्ही CI/CD इन्स्टॉल करा आणि सर्व काही आपोआप स्टोअरमध्ये वितरित केले जाईल. 🙂

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

आणि संपूर्ण चित्र असे आहे. रोलआउटमध्ये चार प्रमुख पैलू असतात:

1. कोडचे वितरण, डेटा बदलासह. उदाहरणार्थ, त्यांचे स्थलांतर.
2. कोड रोलबॅक म्हणजे काही चूक झाल्यास परत जाण्याची क्षमता. उदाहरणार्थ, बॅकअप तयार करून.
3. प्रत्येक रोलआउट/रोलबॅक ऑपरेशनची वेळ. तुम्हाला पहिल्या दोन मुद्यांच्या कोणत्याही ऑपरेशनची वेळ समजून घेणे आवश्यक आहे.
4. प्रभावित कार्यक्षमता. अपेक्षित सकारात्मक आणि संभाव्य नकारात्मक प्रभाव दोन्हीचे मूल्यांकन करणे आवश्यक आहे.

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

कायदा 1..n, प्रकाशनाची तयारी

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

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

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

यादरम्यान, तांत्रिक समर्थनातील मुलांनी ग्राहकांसाठी कनेक्शन पद्धतींवर सूचना लिहिण्यासाठी त्यांचे स्वतःचे स्वतंत्र प्रयोग केले, ज्या रोलआउटनंतर बदलल्या पाहिजेत. त्यांनी वापरकर्ता UX वर काम केले, सूचना तयार केल्या आणि वैयक्तिक सल्लामसलत केली.

आम्ही शक्य असलेल्या सर्व रोलआउट ऑपरेशन्स स्वयंचलित केल्या. प्रत्येक ऑपरेशन स्क्रिप्टेड होते, अगदी सोप्या सुद्धा, आणि चाचण्या सतत केल्या जात होत्या. त्यांनी सेवा बंद करण्याच्या सर्वोत्तम मार्गाबद्दल युक्तिवाद केला - डिमन वगळा किंवा फायरवॉलसह सेवेचा प्रवेश अवरोधित करा. आम्ही रोलआउटच्या प्रत्येक टप्प्यासाठी टीमची चेकलिस्ट तयार केली आणि ती सतत अपडेट केली. आम्ही वेळेसह सर्व रोलआउट कामांसाठी एक Gantt चार्ट काढला आणि सतत अपडेट केला.

आणि म्हणून…

अंतिम कृती, रोल आउट करण्यापूर्वी

... रोल आउट करण्याची वेळ आली आहे.

जसे ते म्हणतात, कलेचे काम पूर्ण होऊ शकत नाही, फक्त त्यावर काम केले जाते. तुम्हाला सर्व काही सापडणार नाही हे समजून तुम्हाला इच्छाशक्तीचा प्रयत्न करावा लागेल, परंतु तुम्ही सर्व वाजवी गृहीतके तयार केली आहेत, सर्व संभाव्य प्रकरणांसाठी प्रदान केले आहेत, सर्व गंभीर दोष बंद केले आहेत आणि सर्व सहभागींनी शक्य ते सर्व केले आहे. तुम्ही जितके जास्त कोड आउट कराल तितके स्वतःला हे पटवून देणे अधिक कठीण आहे (याशिवाय, प्रत्येकाला हे समजते की प्रत्येक गोष्टीचा अंदाज लावणे अशक्य आहे).

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

1. (आमच्यासाठी पवित्र, सर्वात मौल्यवान) वापरकर्ता पायाभूत सुविधांवर परिणाम करा,
2. कार्यक्षमता: रोलआउटनंतर आमच्या सेवेचा वापर पूर्वीसारखाच असावा.

आणणार

दोन रोल, 8 हस्तक्षेप करू नका

आम्ही वापरकर्त्यांच्या सर्व विनंत्यांसाठी 7 तासांसाठी डाउनटाइम घेतो. यावेळी, आमच्याकडे रोलआउट योजना आणि रोलबॅक योजना दोन्ही आहेत.

• रोलआउट स्वतःच अंदाजे 3 तास घेते.
• चाचणीसाठी 2 तास.
• 2 तास - बदलांच्या संभाव्य रोलबॅकसाठी राखीव.

प्रत्येक क्रियेसाठी एक Gantt तक्ता तयार केला आहे, त्याला किती वेळ लागतो, क्रमाने काय होते, समांतर काय केले जाते.

रोलआउट Gantt चार्टचा एक भाग, सुरुवातीच्या आवृत्त्यांपैकी एक (समांतर अंमलबजावणीशिवाय). सर्वात मौल्यवान सिंक्रोनाइझेशन साधन

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

घटनांचा इतिहास

तर, 15 जण रविवार, 29 एप्रिल रोजी रात्री 10 वाजता कामावर आले. प्रमुख सहभागींव्यतिरिक्त, काहीजण फक्त संघाला पाठिंबा देण्यासाठी आले, ज्यासाठी त्यांचे विशेष आभार.

हे देखील नमूद करण्यासारखे आहे की आमचे मुख्य परीक्षक सुट्टीवर आहेत. चाचणीशिवाय रोल आउट करणे अशक्य आहे, आम्ही पर्याय शोधत आहोत. एक सहकारी सुट्टीतून आमची चाचणी घेण्यास सहमत आहे, ज्यासाठी तिला संपूर्ण टीमकडून खूप कृतज्ञता प्राप्त होते.

00:00. थांबा
आम्ही वापरकर्त्याच्या विनंत्या थांबवतो, तांत्रिक काम सांगणारे चिन्ह टांगतो. निरीक्षण ओरडते, परंतु सर्व काही सामान्य आहे. आम्ही तपासतो की जे पडायचे होते त्याशिवाय दुसरे काहीही पडले नाही. आणि आम्ही स्थलांतराचे काम सुरू करतो.

प्रत्येकाकडे मुद्रित रोलआउट प्लॅन पॉइंट बाय पॉइंट आहे, प्रत्येकाला माहित आहे की कोण काय आणि कोणत्या क्षणी करत आहे. प्रत्येक कृतीनंतर, आम्ही ते ओलांडत नाही हे सुनिश्चित करण्यासाठी आम्ही वेळ तपासतो आणि सर्वकाही योजनेनुसार होते. जे लोक सध्याच्या टप्प्यावर थेट रोलआउटमध्ये सहभागी होत नाहीत ते त्यांच्या सहकाऱ्यांना त्रास होऊ नये म्हणून ऑनलाइन खेळणी (Xonotic, type 3 quacks) लाँच करून तयारी करत आहेत. 🙂

02:00. बाहेर आणले
एक सुखद आश्चर्य - आम्ही आमच्या डेटाबेस आणि स्थलांतर स्क्रिप्ट्सच्या ऑप्टिमायझेशनमुळे एक तास आधी रोलआउट पूर्ण करतो. सामान्य ओरड, "रोल आउट!" सर्व नवीन फंक्शन्स उत्पादनात आहेत, परंतु आतापर्यंत फक्त आम्ही त्यांना इंटरफेसमध्ये पाहू शकतो. प्रत्येकजण चाचणी मोडमध्ये जातो, त्यांना गटांमध्ये वर्ग करतो आणि शेवटी काय झाले ते पाहू लागतो.

हे फार चांगले घडले नाही, आम्हाला हे 10 मिनिटांनंतर कळते, जेव्हा टीम सदस्यांच्या प्रोजेक्टमध्ये काहीही कनेक्ट केलेले किंवा काम करत नाही. द्रुत समक्रमण, आम्ही आमच्या समस्या मांडतो, प्राधान्यक्रम सेट करतो, संघांमध्ये प्रवेश करतो आणि डीबगिंगमध्ये जातो.

02:30. दोन मोठ्या समस्या वि चार डोळे
आम्हाला दोन मोठ्या समस्या आढळतात. आम्हाला जाणवले की ग्राहक काही कनेक्ट केलेल्या सेवा पाहणार नाहीत आणि भागीदार खात्यांमध्ये समस्या निर्माण होतील. दोन्ही काही धार प्रकरणांसाठी अपूर्ण स्थलांतर स्क्रिप्टमुळे आहेत. आम्हाला ते आता दुरुस्त करावे लागेल.

आम्ही किमान 4 डोळ्यांनी हे रेकॉर्ड करणार्‍या क्वेरी लिहितो. ते कार्य करतात आणि काहीही खंडित होणार नाहीत याची खात्री करण्यासाठी आम्ही पूर्व-उत्पादनादरम्यान त्यांची चाचणी करतो. आपण पुढे रोल करू शकता. त्याच वेळी, आम्ही आमची नियमित एकीकरण चाचणी चालवतो, जे आणखी काही समस्या उघड करते. ते सर्व लहान आहेत, परंतु त्यांची दुरुस्ती करणे देखील आवश्यक आहे.

03:00. -2 समस्या +2 समस्या
मागील दोन मोठ्या समस्यांचे निराकरण केले गेले आहे आणि जवळजवळ सर्व किरकोळ समस्या देखील आहेत. निराकरणांमध्ये व्यस्त नसलेले सर्व त्यांच्या खात्यांमध्ये सक्रियपणे कार्य करत आहेत आणि त्यांना जे सापडले त्याचा अहवाल देत आहेत. आम्ही प्राधान्य देतो, संघांमध्ये वितरित करतो आणि सकाळसाठी गंभीर नसलेल्या वस्तू सोडतो.

आम्ही पुन्हा चाचण्या चालवतो, त्यांना दोन नवीन मोठ्या समस्या आढळतात. सर्व सेवा धोरणे योग्यरित्या आली नाहीत, म्हणून काही वापरकर्ता विनंत्या अधिकृतता पास करत नाहीत. तसेच भागीदार खात्यांसह एक नवीन समस्या. बघायला घाई करूया.

03:20. आणीबाणी समक्रमण
एक नवीन समस्या निश्चित केली. दुसऱ्यासाठी, आम्ही आपत्कालीन सिंक आयोजित करत आहोत. काय होत आहे ते आम्हाला समजते: मागील निराकरणाने एक समस्या निश्चित केली, परंतु दुसरी तयार केली. ते योग्यरित्या आणि परिणामांशिवाय कसे करावे हे शोधण्यासाठी आम्ही थोडा ब्रेक घेतो.

03:30. सहा डोळे
आम्ही समजतो की बेसची अंतिम स्थिती काय असावी जेणेकरून सर्व भागीदारांसाठी सर्वकाही चांगले होईल. आम्ही 6 डोळ्यांनी एक विनंती लिहितो, ती प्री-प्रॉडक्शनमध्ये रोल आउट करतो, त्याची चाचणी करतो, उत्पादनासाठी रोल आउट करतो.

04:00. सर्व काही कार्यरत आहे
सर्व चाचण्या उत्तीर्ण झाल्या, कोणतीही गंभीर समस्या दिसत नाही. वेळोवेळी, संघातील काहीतरी एखाद्यासाठी कार्य करत नाही, आम्ही त्वरित प्रतिक्रिया देतो. बहुतेकदा अलार्म खोटा असतो. परंतु कधीकधी काहीतरी येत नाही किंवा वेगळे पृष्ठ कार्य करत नाही. आम्ही बसतो, निराकरण करतो, निराकरण करतो, निराकरण करतो. एक वेगळी टीम शेवटचे मोठे वैशिष्ट्य - बिलिंग लाँच करत आहे.

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

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

07:00. API लोडसह समस्या
हे स्पष्ट होते की आम्ही आमच्या API वर लोडचे थोडेसे चुकीचे नियोजन केले आणि या लोडची चाचणी केली, ज्यामुळे समस्या ओळखता आली नाही. परिणामी, ≈5% विनंत्या अयशस्वी होतात. चला जमवाजमव करून कारण शोधूया.

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

08:00. दुरुस्त API
आम्ही लोडसाठी एक निराकरण केले, अपयश निघून गेले. आम्ही घरी जायला लागतो.

10:00. सर्व
सर्व काही निश्चित आहे. हे निरीक्षणात शांत आहे आणि ग्राहकांच्या ठिकाणी, टीम हळूहळू झोपायला जाते. बिलिंग शिल्लक आहे, आम्ही ते उद्या पुनर्संचयित करू.

त्यानंतर दिवसभरात असे रोलआउट्स आले ज्याने आमच्या काही क्लायंटसाठी लॉग, सूचना, रिटर्न कोड आणि कस्टमायझेशन निश्चित केले.

तर, रोलआउट यशस्वी झाला! हे नक्कीच चांगले असू शकते, परंतु आम्हाला परिपूर्णता मिळविण्यासाठी काय पुरेसे नव्हते याबद्दल आम्ही निष्कर्ष काढला.

एकूण

रोलआउटसाठी 2 महिन्यांच्या सक्रिय तयारीदरम्यान, 43 कार्ये पूर्ण झाली, जी काही तासांपासून अनेक दिवसांपर्यंत चालली.

रोलआउट दरम्यान:

• नवीन आणि बदललेले भुते - 5 तुकडे, 2 मोनोलिथ्सच्या जागी;
• डेटाबेसमधील बदल - वापरकर्ता डेटासह आमचे सर्व 6 डेटाबेस प्रभावित झाले आहेत, तीन जुन्या डेटाबेसमधून एका नवीन डेटाबेसमध्ये डाउनलोड केले गेले आहेत;
• पूर्णपणे पुन्हा डिझाइन केलेले फ्रंटएंड;
• डाउनलोड केलेल्या कोडची रक्कम - नवीन कोडच्या 33 हजार ओळी, ≈ चाचण्यांमध्ये कोडच्या 3 हजार ओळी, ≈ स्थलांतर कोडच्या 5 हजार ओळी;
• सर्व डेटा अबाधित आहे, एकाही ग्राहकाचे आभासी मशीन खराब झालेले नाही. 🙂

चांगल्या रोलआउटसाठी चांगल्या पद्धती

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

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

आणि एका वाक्यात, चांगले नियोजन आणि विस्ताराने तुम्ही विक्रीच्या परिणामांशिवाय तुम्हाला हवे असलेले काहीही रोल आउट करू शकता. उत्पादनातील तुमच्या सर्व सेवांवर परिणाम करणारी गोष्ट देखील.

स्त्रोत: www.habr.com