क्या निश्चित समय पर उत्पादन के लिए तैनाती पर रोक लगाना आवश्यक है? या #NoDeployFriday आंदोलन उस समय का अवशेष बन गया जब कोई व्यापक एकीकरण परीक्षण और निरंतर तैनाती नहीं थी?

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

डिंग डिंग

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

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

सोमवार को पांच-बैठक क्यों आयोजित की जाती है।

" चलो बस शुक्रवार को तैनात करना बंद कर दें। फिर सप्ताहांत में सब कुछ निश्चित रूप से काम करेगा, और अगले सप्ताह हम सभी प्रकार के रिलीज के बाद अलर्ट पर रहेंगे ।"

सभी ने सिर हिलाया। यदि कोई चीज गुरुवार को दोपहर से पहले ऑपरेशन में नहीं जाती है, तो वह सोमवार सुबह तक इंतजार करती है। क्या यह दृष्टिकोण नुकसान या मदद करता है?


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

कुछ का यह भी सुझाव है कि आप सप्ताहांत की तुलना में सिर्फ शांत तैनाती पसंद करते हैं:


अन्य उपयोगकर्ताओं का मानना ​​है कि फ़ंक्शन झंडे का कार्यान्वयन संभव समाधान हो सकता है।


यह उपयोगकर्ता मानता है कि आज हमारे लिए उपलब्ध प्रक्रियाओं और उपकरणों के कारण एक जोखिमपूर्ण तैनाती की समस्याएं पैदा नहीं होनी चाहिए।

निर्णय कौन करता है?

विचारों के इस सभी आदान-प्रदान से संकेत मिलता है कि हम, इंजीनियरों के एक समुदाय के रूप में, दृढ़ता से असहमत हो सकते हैं और जरूरी नहीं कि एक-दूसरे के साथ सहमत हों। किसने सोचा होगा। यह स्थिति संभवतः यह भी प्रदर्शित करती है कि #NoDeployFriday के साथ समग्र चित्र में ऐसी बारीकियाँ हैं जो ट्विटर पर बहुत अच्छी तरह से परिलक्षित नहीं होती हैं। क्या यह सच है कि हम सभी को निरंतर तैनाती लागू करनी चाहिए, अन्यथा हम "गलत करते हैं"?

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

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

कुछ मुद्दे हैं जिन पर हम चर्चा कर सकते हैं। मैंने उन्हें श्रेणियों में विभाजित किया:

1. परिवर्तन के "विनाश की त्रिज्या" को समझना।
   
2. परिनियोजन प्रक्रिया की ध्वनि।
   
3. स्वचालित रूप से त्रुटियों का पता लगाने की क्षमता।
   
4. समस्याओं को हल करने में कितना समय लगता है।
   

अब चर्चा करते हैं।

"विनाश की त्रिज्या" को समझना

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

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

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

यहां आपको स्थिति के आधार पर निर्णय लेने की आवश्यकता है। क्या हर इंजीनियर को उत्पादन पर्यावरण में बदलाव के "विनाश की त्रिज्या" के बारे में पता है, और न केवल विकास के माहौल में? यदि नहीं, तो क्यों? क्या प्रलेखन, प्रशिक्षण और उत्पादन में कोड परिवर्तन के प्रभावों के प्रदर्शन में सुधार करना संभव है?

क्या "विनाश की त्रिज्या" छोटी है? शुक्रवार को लॉन्च किया गया।

क्या "विनाश की त्रिज्या" बड़ी है? सोमवार तक प्रतीक्षा करें।

परिनियोजन प्रक्रिया की ध्वनि

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

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

प्रत्येक इंजीनियर के लिए जिसने पिछले दो पैराग्राफ को पढ़ा है और "वेल ऑफ़ कोर्स" की शैली में प्रतिक्रिया व्यक्त की है! हम सालों से ऐसा कर रहे हैं! ” मैं इस बात की गारंटी दे सकता हूं कि एक और 9 लोगों ने अपने आवेदन के बुनियादी ढांचे को प्रस्तुत किया और एक आधुनिक तैनाती पाइपलाइन को सिस्टम को स्थानांतरित करने के लिए जो काम करने की आवश्यकता है, उसे महसूस करते हुए। इसका तात्पर्य आधुनिक उपकरणों से लाभ उठाना है जो न केवल निरंतर एकीकरण करते हैं, बल्कि आपको ठेस को लगातार आपूर्ति करने की अनुमति देते हैं, और इंजीनियरों को केवल कमीशन के लिए बटन दबाने की आवश्यकता होती है (या यदि आप काफी बहादुर हैं तो भी यह स्वचालित रूप से करते हैं)।

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

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

विश्वसनीय तैनाती वाहक? शुक्रवार को रोल आउट करें।

लिपियों की मैन्युअल रूप से नकल? सोमवार तक प्रतीक्षा करें।

त्रुटियों का पता लगाने की क्षमता

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

ऑपरेशन हमेशा विकास से अलग होता है, और इंजीनियरों को सिस्टम के कुछ हिस्सों के संचालन की निगरानी करने की आवश्यकता होती है। आपको प्रत्येक बाद के बदलाव के बारे में सवालों के जवाब देने की आवश्यकता है: क्या इसने सिस्टम को गति दी या धीमा किया? कम या ज्यादा टाइमआउट हैं? क्या हम प्रोसेसर या I / O द्वारा सीमित हैं?

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

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

अच्छी निगरानी, ​​सूचनाएं और ऑन-कॉल विशेषज्ञ? शुक्रवार को तैनात करें।

मैन्युअल रूप से ssh के माध्यम से लॉग देखता है? सोमवार तक प्रतीक्षा करें।

समस्याओं को हल करने में कितना समय लगता है?

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

तैनाती पाइपलाइन के भीतर सभी कार्यों के लिए, जो वृहद स्तर पर परिवर्तनों की विश्वसनीयता बढ़ा सकते हैं, कोई भी परिवर्तन समान नहीं हैं, इसलिए आपको उन्हें अलग से मूल्यांकन करने की आवश्यकता है। अगर कुछ गलत होता है, तो क्या हम इसे जल्दी ठीक कर सकते हैं?

क्या यह पूरी तरह से एकल पुनर्स्थापना प्रतिबद्ध के साथ तय किया गया है? शुक्रवार को तैनात करें।

अगर कुछ गलत हो जाए तो क्या बड़ी मुश्किलें हैं? सोमवार तक प्रतीक्षा करें।

अपने लिए सोचें, अपने लिए तय करें

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

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

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

सफल तैनाती।