उत्पादन में सुरक्षित परीक्षण का संगठन। भाग 1

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

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

(नोट: जैसा कि मूल लेख लोंग्रिड है, पाठकों की सुविधा के लिए इसे दो भागों में विभाजित किया गया है)।

उत्पादन में परीक्षण आवश्यक क्यों है यदि इसे मंचन में किया जा सकता है?

अलग-अलग लोगों द्वारा स्टेजिंग क्लस्टर (या मंचन के माहौल) का महत्व अलग-अलग माना जाता है। कई कंपनियों के लिए, स्टेजिंग में एक उत्पाद की तैनाती और परीक्षण एक अंतिम चरण है जो इसके अंतिम रिलीज से पहले होता है।

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

इस दृष्टिकोण (मेरे अनुभव में) के साथ समस्या यह है कि अंतर केवल वास्तविक उत्पादन डेटा डेटा वाले डेटाबेस के एक अलग उदाहरण के उपयोग में नहीं है। अक्सर अंतर निम्नलिखित पहलुओं तक फैलता है:

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

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

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

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

उत्पादन में परीक्षण की कला

ऐसा ऐतिहासिक रूप से हुआ है कि "उत्पादन में परीक्षण" की अवधारणा कुछ रूढ़ियों और नकारात्मक अर्थों ("गुरिल्ला प्रोग्रामिंग", इकाई की कमी या अनुपस्थिति और एकीकरण परीक्षण, लापरवाही या अंत उपयोगकर्ता द्वारा उत्पाद की धारणा में असावधानता) से जुड़ी है।

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

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


नोट परीक्षण माइक्रोसर्विस से, साने का तरीका ("परीक्षण सेवाओं के लिए एक स्मार्ट दृष्टिकोण")

दिसंबर 2017 के अंत में नोट के प्रकाशन के बाद से, मैं इसकी सामग्री और आम तौर पर कई लोगों के साथ उत्पादन में परीक्षण के विषय पर चर्चा कर रहा हूं।

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

"उत्पादन में परीक्षण" की अवधारणा में तीन अलग-अलग चरणों में लागू तकनीकों की एक पूरी श्रृंखला शामिल है। कौन से - चलो समझते हैं।

उत्पादन के तीन चरण

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

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

चरण 1. तैनाती

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

दूसरे शब्दों में, परीक्षणों को ऐसे वातावरण में चलाने की आवश्यकता होती है जो काम के माहौल को सबसे अच्छा बनाता है ।

और काम के माहौल की सबसे अच्छी नकल है ... काम का माहौल। उत्पादन वातावरण में अधिकतम संभव संख्या में परीक्षण करने के लिए, यह आवश्यक है कि उनमें से किसी का भी असफल परिणाम अंतिम उपयोगकर्ता को प्रभावित न करे।

यह बदले में, केवल तभी संभव है, जब उत्पादन वातावरण में सेवा को तैनात करते समय, उपयोगकर्ताओं को इस सेवा तक सीधी पहुंच नहीं मिलती है ।

इस लेख में, मैंने टर्बाइन लैब्स द्वारा लिखित डिप्लॉय! = रिलीज लेख से शब्दावली का उपयोग करने का निर्णय लिया। यह "तैनाती" शब्द को इस प्रकार परिभाषित करता है:

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

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

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

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

स्टेज 2. रिलीज़

नोट तैनात करें! = रिलीज इस प्रकार जारी की गई अवधि को परिभाषित करती है:

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

SRE पर Google की पुस्तक में, "रिलीज़" शब्द का उपयोग अध्याय में इसका वर्णन करने के लिए सॉफ़्टवेयर रिलीज़ के आयोजन पर किया जाता है ।

“एक समस्या एक तार्किक तत्व है जिसमें एक या अधिक अलग-अलग कार्य शामिल हैं। हमारा लक्ष्य इस सेवा के जोखिम प्रोफाइल के साथ तैनाती की प्रक्रिया का समन्वय करना है ।

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

इस शब्दावली में, "रिलीज़" और "रिलीज़" शब्द का अर्थ है कि सामान्य शब्दावली "परिनियोजन" को संदर्भित करती है, और शब्द अक्सर विभिन्न तैनाती रणनीतियों (उदाहरण के लिए, नीली-हरी तैनाती या कैनरी परिनियोजन) का वर्णन करते हैं जो एक नई की रिहाई को संदर्भित करते हैं। सॉफ्टवेयर।

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

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

चरण 3. विमोचन के बाद

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


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

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

---

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

परिनियोजन परीक्षण

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

एकीकरण परीक्षण

आमतौर पर, एकीकरण परीक्षण प्रत्येक Git शाखा के लिए एक अलग परीक्षण वातावरण में एक निरंतर एकीकरण सर्वर द्वारा किया जाता है। संपूर्ण सेवा टोपोलॉजी (डेटाबेस, कतार, परदे के पीछे, आदि सहित) की एक प्रति सभी सेवाओं के परीक्षण सूट के लिए तैनात की जाती है जो एक साथ काम करेंगे।

मेरा मानना ​​है कि यह कई कारणों से विशेष रूप से प्रभावी नहीं है। सबसे पहले, परीक्षण वातावरण, जैसे कि मचान वातावरण, को इस तरह से तैनात नहीं किया जा सकता है कि यह वास्तविक उत्पादन वातावरण के समान है, भले ही परीक्षण उसी डॉकटर कंटेनर में चलाए जाएं जो उत्पादन में उपयोग किया जाएगा। यह विशेष रूप से सच है जब एक परीक्षण वातावरण में चलने वाली एकमात्र चीज स्वयं परीक्षण है।

भले ही परीक्षण डॉकटर कंटेनर या POSIX प्रक्रिया के रूप में चलाया जाता है, लेकिन यह सबसे अधिक संभावना एक बेहतर सेवा, डेटाबेस या कैश के लिए एक या एक से अधिक कनेक्शन बनाता है, जो कि दुर्लभ है यदि सेवा एक उत्पादन वातावरण में है जहां यह एक साथ हो सकता है कई समवर्ती कनेक्शनों की प्रक्रिया करें, अक्सर निष्क्रिय टीसीपी कनेक्शन का पुन: उपयोग किया जाता है (इसे पुन: उपयोग HTTP कनेक्शन कहा जाता है)।

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

लेकिन इसका मतलब यह नहीं है कि एकीकरण परीक्षण सिद्धांत रूप में बेकार है। हम केवल यह कह सकते हैं कि एक नियम के रूप में, एक पूरी तरह से अलग-थलग पर्यावरण में एकीकरण परीक्षणों के कार्यान्वयन का कोई मतलब नहीं है। सेवा के नए संस्करण को सत्यापित करने के लिए एकीकरण परीक्षण अभी भी किया जाना चाहिए:

• अपस्ट्रीम या डाउनस्ट्रीम सेवाओं के साथ बातचीत में हस्तक्षेप नहीं करता है;
• उच्च या निम्न सेवाओं के लक्ष्यों और उद्देश्यों पर प्रतिकूल प्रभाव नहीं डालता है।

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

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

हालांकि, एक नया संस्करण जारी करने से पहले, न केवल इंटरफेस के सही संचालन की जांच करना आवश्यक हो सकता है। , , , RPC- . , , , .

, , — , , ( , ).
: ?

. – , : - - ( C) MySQL ( D) memcache ( B).

, ( ), stateful- stateless- .


, .

service discovery ( ), . .

, C .


, , , . , , . , , .

Google Just Say No to More End-to-End Tests (« »), :

« ( ) . , ? , . , , , ».

, : . , A .

, C MySQL, .


( , , «» , ). MySQL , , .

— -. , . -, .

, - , /:

• C / ;
• , «» .

, (, ).

, , . IP- , , , , , , , , .

, , , , . . Facebook, Kraken , :

« — , . - , . , . - , , , ».

, , , , , .

- . service mesh . -. -, , , :


यदि हम सेवा बी का परीक्षण करते हैं, तो इसके आउटगोइंग प्रॉक्सी सर्वर को प्रत्येक परीक्षण अनुरोध में एक विशेष X-ServiceB-Test हेडर जोड़ने के लिए कॉन्फ़िगर किया जा सकता है। इस स्थिति में, बेहतर सेवा C का आने वाला प्रॉक्सी सर्वर निम्न में सक्षम होगा:

• इस शीर्ष लेख का पता लगाएं और सेवा बी को एक मानक प्रतिक्रिया भेजें;
• सेवा सी को बताएं कि अनुरोध एक परीक्षा है ।

सेवा C के रिलीज़ किए गए संस्करण के साथ सेवा B के परिनियोजित संस्करण के इंटरैक्शन का एकीकरण परीक्षण, जहाँ लिखने का संचालन डेटाबेस तक कभी नहीं पहुँचता है

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

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

छाया डेटा दोहराव (परीक्षण डार्क डेटा स्ट्रीम या मिररिंग)

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

अराजकता इंजीनियरिंग के सिद्धांत निम्नलिखित हैं:

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

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

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

कुछ कंपनियां डेटा स्ट्रीम का एक हिस्सा नहीं पकड़ना पसंद करती हैं, लेकिन एप्लिकेशन के नए संस्करण में इस स्ट्रीम की पूरी प्रतिलिपि प्रसारित करती हैं। फेसबुक के मैक राउटर ( मेम्केडेड प्रॉक्सी) इस प्रकार के मेम्केच डेटा स्ट्रीम के दोहराव का समर्थन करता है।

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

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

“ एक राउटर एक क्लस्टर से दूसरे क्लस्टर डेटा प्रवाह की छाया दोहराव प्रदर्शन कर सकता है। वर्तमान में, फायर-एंड-भूल मोड कार्यान्वित किया जाता है, जिसमें Envoy प्रॉक्सी सर्वर मुख्य क्लस्टर से प्रतिक्रिया लौटने से पहले छाया क्लस्टर से प्रतिक्रिया की प्रतीक्षा नहीं करता है। छाया क्लस्टर के लिए, सभी सामान्य आंकड़े एकत्र किए जाते हैं, जो परीक्षण के प्रयोजनों के लिए उपयोगी है। छाया दोहराव के साथ, होस्ट / प्राधिकरण -shadow में -shadow विकल्प जोड़ा जाता है। यह लॉगिंग के लिए उपयोगी है। उदाहरण के लिए, cluster1 cluster1-shadow में बदल जाता है । "

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

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

TAP तुलना

इस शब्द का एकमात्र उल्लेख ट्विटर ब्लॉग के एक लेख में सेवा की गुणवत्ता के उच्च स्तर के साथ सेवाओं के शुभारंभ के लिए समर्पित है।

“मौजूदा प्रणाली के नए कार्यान्वयन की शुद्धता को सत्यापित करने के लिए, हमने टैप-तुलना नामक एक विधि का उपयोग किया। हमारा नल तुलना उपकरण नए सिस्टम में नमूना उत्पादन डेटा को पुन: पेश करता है और पुराने के परिणामों के साथ प्राप्त उत्तरों की तुलना करता है। प्राप्त परिणामों ने हमें अंतिम उपयोगकर्ताओं के सामने आने से पहले ही सिस्टम में त्रुटियों को खोजने और ठीक करने में मदद की। ”

एक अन्य ट्विटर ब्लॉग पोस्ट नल तुलना की परिभाषा इस प्रकार है:

"उत्पादन में और परिणामों को जाँचने और प्रदर्शन विशेषताओं के मूल्यांकन के साथ स्टेजिंग वातावरण में सेवा के उदाहरणों के लिए अनुरोध भेजना।"

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

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

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

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

डिफी ट्विटर द्वारा 2015 में शुरू किया गया एक स्काला ओपन सोर्स टूल है। टेस्टिंग राइटिंग के बिना टेस्टिंग नाम के ट्विटर ब्लॉग का एक लेख शायद यह समझने का सबसे अच्छा संसाधन है कि व्यवहार में नल की तुलना कैसे काम करती है।

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

जब दो संस्करण एक ही परिणाम देते हैं, तो आपको तुलना करने के लिए नल की तुलना बहुत अच्छी है। मार्क मैकब्राइड के अनुसार,

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

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

लोड परीक्षण

जो लोग तनाव परीक्षण से परिचित नहीं हैं, उनके लिए यह लेख एक अच्छे शुरुआती बिंदु के रूप में काम कर सकता है। ओपन सोर्स लोड टेस्टिंग के लिए टूल्स और प्लेटफॉर्म की कोई कमी नहीं है। उनमें से सबसे लोकप्रिय Apache Bench , Gatling , wrk2 , Tsung हैं , जो Erlang, घेराबंदी , Iago में ट्विटर से लिखे गए हैं, जो Scala में लिखे गए हैं (जो एक परीक्षण उदाहरण में एक HTTP सर्वर, प्रॉक्सी सर्वर या नेटवर्क पैकेट विश्लेषक के लॉग को पुन: पेश करता है)। कुछ विशेषज्ञों का मानना ​​है कि लोड उत्पन्न करने के लिए सबसे अच्छा उपकरण mzbench है , जो विभिन्न प्रकार के प्रोटोकॉल का समर्थन करता है, जिसमें MySQL, Postgres, Cassandra, MongoDB, TCP, आदि शामिल हैं। Netflix का NDBench लोड परीक्षण डेटा वेयरहाउस के लिए एक और खुला स्रोत उपकरण है। , जो अधिकांश ज्ञात प्रोटोकॉल का समर्थन करता है।

Iago आधिकारिक ट्विटर ब्लॉग में अधिक विस्तार से वर्णन किया गया है कि एक अच्छे लोड जनरेटर में क्या विशेषताएं होनी चाहिए:

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

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

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

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

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

यहाँ पेशेवर स्लैक समुदाय में पूर्व लिंक्डइन इंजीनियर क्या लिखते हैं:

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

दरअसल, एक Google खोज एक पूर्ण श्वेत पत्र के लिए एक लिंक और इस विषय पर एक लिंक्डइन ब्लॉग लेख प्रदान करती है:

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

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

रेडलाइनर कैनरी और प्रोडक्शन उदाहरणों के समानांतर परीक्षण निष्पादन का समर्थन करता है। यह इंजीनियरों को समान मात्रा में डेटा को दो अलग-अलग सेवा उदाहरणों में स्थानांतरित करने की अनुमति देता है: 1) एक सेवा उदाहरण जिसमें नवाचार होते हैं, जैसे नए कॉन्फ़िगरेशन, गुण या नया कोड; 2) वर्तमान कार्यशील संस्करण का एक सेवा उदाहरण।

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

फेसबुक ने क्रैकन सिस्टम के लिए वास्तविक डेटा स्ट्रीम का उपयोग करके एक नए स्तर पर लोड परीक्षण किया, और इसका विवरण भी पढ़ने लायक है।
प्रॉक्सी डिवाइस (फेसबुक लोड बैलेंसर) में बॉर्डर डिवाइस और क्लस्टर के लिए वेट वैल्यू (डिस्ट्रिब्यूटेड कॉन्फिगरेशन स्टोर से रीड) बदलते समय टेस्टिंग को डेटा स्ट्रीम के पुनर्वितरण द्वारा कार्यान्वित किया जाता है। ये मान किसी दिए गए बिंदु पर प्रत्येक क्लस्टर और क्षेत्र में क्रमशः भेजे गए वास्तविक डेटा की मात्रा निर्धारित करते हैं।


क्रैकन व्हाइट पेपर से डेटा

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

कॉन्फ़िगरेशन परीक्षण

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

इसके अलावा, कोड की रिहाई से पहले नए कॉन्फ़िगरेशन का परीक्षण करने से इनकार करना महत्वपूर्ण संख्या में रुकावट का कारण बन गया।


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


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


, , blue-green , . ( Jamie Wilkinson ), Google , :

« , , , - . . - , — , , . .

, . , , — ».

Facebook :

« . — , . . , .

• 
  
  . Facebook , . , .
• 
  
  (, JSON). , . .
  
  (, Facebook Thrift) . , .
• 
  
  , , - . . — A/B-, 1 % . A/B-, . A/B- . , , , , . , A/B- . , A/B-. Facebook .
  
  , A/B- 1% , 1% , ( « »). , . , .
• 
  
  Facebook . , . , , . , , .
• परिवर्तनों का सरल और सुविधाजनक रद्दकरण
  
  कुछ मामलों में, सभी निवारक उपायों के बावजूद, एक निष्क्रिय कॉन्फ़िगरेशन की तैनाती का प्रदर्शन किया जाता है। इस तरह की समस्या से निपटने के लिए त्वरित रूप से परिवर्तन खोजना और वापस लाना महत्वपूर्ण है। "संस्करण नियंत्रण उपकरण हमारे विन्यास प्रणाली में उपलब्ध हैं जो इसे पूर्ववत करने में बहुत आसान बनाते हैं।"

जारी रखा जाए!

UPD: यहां जारी रहा ।