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

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

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

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

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

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

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

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

जिसके बाद नई सेवाएँ दिखाई दीं।

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

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

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

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

अगर यह बहुत असभ्य है, तो 4 महीने में हमने इसे तैयार किया:

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

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

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

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

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

पाचन: रोल-आउट क्या है?

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

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

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

और पूरी तस्वीर इस प्रकार है। रोलआउट में चार बड़े पहलू शामिल हैं:

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

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

अधिनियम 1..n, रिलीज की तैयारी

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

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

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

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

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

और इसलिए ...

अंतिम कार्य, बाहर रोल करने से पहले

... यह रोल करने का समय है।

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

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

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

रोल आउट करें

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

03:00 a.m. -2 समस्याएं +2 समस्याएं
पिछली दो बड़ी समस्याएं तय हो गई हैं, लगभग सभी छोटी-मोटी भी। सभी सुधारों में निर्लिप्त सक्रिय रूप से अपने खातों में काम करते हैं और रिपोर्ट करते हैं कि वे क्या पाते हैं। हम प्राथमिकता देते हैं, आदेशों के द्वारा वितरित करते हैं, सुबह अलिखित छोड़ देते हैं।

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

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

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

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

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

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

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

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

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

सुबह 10 बजे। सब
सब कुछ तय है। निगरानी और ग्राहक शांत हैं, टीम धीरे-धीरे बिस्तर पर जाती है। बिलिंग बनी हुई है, हम इसे कल बहाल करेंगे।

फिर दिन के दौरान ऐसे रोलआउट हुए जिन्होंने हमारे कुछ ग्राहकों के लॉग, नोटिफिकेशन, रिटर्न कोड और कस्टम कोड तय किए।

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

कुल मिलाकर

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

रोलिंग के दौरान:

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

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

हम इस कठिन परिस्थिति में उनके द्वारा निर्देशित थे। लेकिन, आम तौर पर बोलना, उन्हें किसी भी रोलिंग आउट में निरीक्षण करना उपयोगी होता है। लेकिन जितना कठिन रोलआउट, उतनी ही बड़ी भूमिका।

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

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