उत्पादों पर परीक्षण: कैनरी परिनियोजन

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

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

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

इन्फोबिप के बारे में

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

संख्या में इन्फोबिप आईटी अवसंरचना:

• दुनिया भर में 15 डेटा सेंटर;
• संचालन में 500 अद्वितीय सेवाएँ;
• सेवाओं के 2500 उदाहरण, जो आदेशों से कहीं अधिक है;
• 4,5 टीबी मासिक ट्रैफ़िक;
• 4,5 अरब फ़ोन नंबर;

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

विज्ञप्ति

एक सामान्य रिलीज़ इस प्रकार होती है. उदाहरण के लिए, ए, बी, सी, डी और ई सेवाएं हैं, उनमें से प्रत्येक को एक अलग टीम द्वारा विकसित किया गया है।

किसी बिंदु पर, सेवा ए की टीम एक नया संस्करण तैनात करने का निर्णय लेती है, लेकिन सेवा बी, सी, डी और ई की टीमों को इसके बारे में पता नहीं होता है। सेवा दल A कैसे कार्य करेगा, इसके लिए दो विकल्प हैं।

रोक लेंगे वृद्धिशील रिलीज़: पहले एक संस्करण बदलें, और फिर दूसरा।

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

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

तो हम क्या चाहते हैं?

हमें समस्याओं की जरूरत नहीं है. यदि ग्राहक उन्हें हमसे अधिक तेजी से ढूंढते हैं, तो इससे उनकी प्रतिष्ठा को नुकसान पहुंचेगा। इसलिए हमें अवश्य करना चाहिए ग्राहकों की तुलना में समस्याओं का अधिक तेजी से पता लगाते हैं. सक्रिय रूप से काम करते हुए, हम क्षति को कम करते हैं।

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

परिनियोजन समस्याएँ

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

प्रदाता समस्याएँ. संदेशवाहक और प्रदाता हमारे भागीदार हैं। कभी-कभी वे क्रैश हो जाते हैं जो नए संस्करणों की तैनाती के दौरान त्रुटियों का कारण बनते हैं।

वितरित टीमें. क्लाइंट साइड और बैकएंड विकसित करने वाली टीमें अलग-अलग समय क्षेत्रों में हैं। इस वजह से वे अक्सर आपस में सहमत नहीं हो पाते।

डेटा सेंटर को मंच पर दोहराया नहीं जा सकता. एक डेटा सेंटर में 200 रैक होते हैं - आप इसे सैंडबॉक्स में भी लगभग दोहरा नहीं सकते।

टाइमगवारा नहीं! उदाहरण के लिए, जब हम 99,99% समय काम कर रहे होते हैं तो हमारे पास एक त्रुटि बजट होता है, और शेष प्रतिशत "त्रुटि मार्जिन" होता है। 100% विश्वसनीयता हासिल करना असंभव है, लेकिन गिरावट और डाउनटाइम की लगातार निगरानी करना महत्वपूर्ण है।

क्लासिक समाधान

बग के बिना कोड लिखें. जब मैं एक युवा डेवलपर था, तो प्रबंधकों ने बिना बग के रिलीज़ करने के अनुरोध के साथ मुझसे संपर्क किया, लेकिन यह हमेशा संभव नहीं है।

परीक्षण लिखें. परीक्षण काम करते हैं, लेकिन कभी-कभी उस तरह से नहीं जैसे व्यवसाय चाहता है। पैसा कमाना परीक्षाओं का काम नहीं है.

मंच पर परीक्षण. इन्फोबिप में अपने 3,5 वर्षों के काम के दौरान, मैंने कभी नहीं देखा कि मंच की स्थिति कम से कम आंशिक रूप से उत्पादन के साथ मेल खाती हो।

हमने इस विचार को विकसित करने का भी प्रयास किया: पहले हमारे पास स्टेज था, फिर प्री-प्रोडक्शन, और फिर प्री-प्रोडक्शन। लेकिन इससे भी कोई मदद नहीं मिली - वे सत्ता में भी बराबरी नहीं कर सके। स्टेज के साथ, हम बुनियादी कार्यक्षमता की गारंटी दे सकते हैं, लेकिन हम नहीं जानते कि यह लोड के तहत कैसे काम करेगा।

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

अतिरिक्त जटिलताएँ भी हैं। किसी डेवलपर के लिए हर चीज़ को मैन्युअल रूप से जांचने में बहुत समय व्यतीत करना तनावपूर्ण होता है।

सहमत विज्ञप्ति. यह विकल्प आमतौर पर प्रबंधन द्वारा पेश किया जाता है: "आइए सहमत हों कि हर दिन आप परीक्षण करेंगे और नए संस्करण जोड़ेंगे।" यह काम नहीं करता है: हमेशा एक आदेश अन्य सभी के लिए प्रतीक्षा कर रहा होता है, या इसके विपरीत।

धुआं परीक्षण

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

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

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

धूम्रपान परीक्षण के नुकसान:

• परीक्षणों पर भरोसा नहीं किया जा सकता. उत्पादन के समान ट्रैफ़िक कहाँ से प्राप्त करें? आप कल या एक सप्ताह पहले उपयोग कर सकते हैं, लेकिन यह हमेशा वर्तमान से मेल नहीं खाता।
• बनाए रखना मुश्किल है. आपको परीक्षण खाते बनाए रखने होंगे, प्रत्येक परिनियोजन से पहले उन्हें लगातार रीसेट करना होगा, जब सक्रिय रिकॉर्ड रिपॉजिटरी में भेजे जाएंगे। यह आपके अपने सैंडबॉक्स में परीक्षा लिखने से भी कठिन है।

यहाँ एकमात्र बोनस है प्रदर्शन की जाँच की जा सकती है.

कैनरी रिलीज

धूम्रपान परीक्षणों की कमियों के कारण, हमने कैनरी रिलीज़ का उपयोग करना शुरू कर दिया।

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

कार्यान्वयन और बारीकियाँ

हमने कैनरी रिलीज़ कैसे लागू की? उदाहरण के लिए, ग्राहकों का एक समूह हमारी सेवा के माध्यम से संदेश भेजता है।

परिनियोजन इस प्रकार होता है: हम बैलेंसर (1) के नीचे से एक नोड हटाते हैं, संस्करण बदलते हैं (2) और कुछ ट्रैफ़िक अलग से देते हैं (3)।

सामान्य तौर पर, समूह में हर कोई खुश होगा, भले ही एक उपयोगकर्ता नाखुश हो। यदि सब कुछ ठीक रहा तो हम सभी संस्करण बदल देंगे।

मैं योजनाबद्ध रूप से दिखाऊंगा कि ज्यादातर मामलों में यह माइक्रोसर्विसेज के लिए कैसा दिखता है।

सर्विस डिस्कवरी और दो अन्य सेवाएँ हैं: S1N1 और S2। पहली सेवा (S1N1) शुरू होने पर सर्विस डिस्कवरी को सूचित करती है, और सर्विस डिस्कवरी इसे याद रखती है। दो नोड्स (S2N1 और S2N2) वाली दूसरी सेवा भी शुरू होने पर सर्विस डिस्कवरी को सूचित करती है।

पहली के बदले दूसरी सेवा सर्वर के रूप में कार्य करती है। पहला व्यक्ति सर्विस डिस्कवरी से उसके सर्वर के बारे में जानकारी मांगता है, और जब वह इसे प्राप्त करता है, तो वह उन्हें ढूंढता है और उनकी जांच करता है ("स्वास्थ्य जांच")। जब वह जाँच करेगा, तो वह उन्हें संदेश भेजेगा।

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

हम संस्करण बदलते हैं और सर्विस डिस्कवरी को पता है कि दूसरा नोड अब कैनरी है - आप इसे कम लोड (5%) दे सकते हैं। यदि सब कुछ ठीक है, तो हम संस्करण बदलते हैं, लोड लौटाते हैं और काम करते हैं।

यह सब लागू करने के लिए, हमें चाहिए:

• संतुलन;
• निगरानीक्योंकि यह जानना महत्वपूर्ण है कि प्रत्येक उपयोगकर्ता क्या अपेक्षा करता है और हमारी सेवाएँ कैसे काम करती हैं;
• संस्करण विश्लेषणयह समझने के लिए कि नया संस्करण उत्पादन में कितनी अच्छी तरह काम करेगा;
• स्वचालन - हम परिनियोजन अनुक्रम (परिनियोजन पाइपलाइन) लिखते हैं।

संतुलन

यह पहली चीज़ है जिसके बारे में हमें सोचना चाहिए। दो संतुलन रणनीतियाँ हैं।

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

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

निगरानी

कैनरी रिलीज़ की आधारशिला। हमें ठीक से समझना चाहिए कि हम ऐसा क्यों कर रहे हैं और हम कौन से मेट्रिक्स एकत्र करना चाहते हैं।

मेट्रिक्स के उदाहरण जो हम अपनी सेवाओं से एकत्र करते हैं।

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

सर्वाधिक लोकप्रिय निगरानी प्रणालियों में मेट्रिक्स के उदाहरण।

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

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

पहले संस्करण में कुछ त्रुटियाँ थीं, शायद ऑडिट काम नहीं आया। दूसरे संस्करण में, सब कुछ बहुत खराब है। हम निश्चित रूप से कह सकते हैं कि समस्याएँ हैं, इसलिए हमें इस संस्करण को वापस ले लेना चाहिए।

थाह लेना। मेट्रिक्स काउंटर के समान हैं, लेकिन हम ऐसे मान रिकॉर्ड करते हैं जो या तो बढ़ सकते हैं या घट सकते हैं। उदाहरण के लिए, क्वेरी निष्पादन समय या कतार आकार।

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

सारांश। व्यवसाय के लिए सबसे महत्वपूर्ण संकेतकों में से एक प्रतिशत है। मीट्रिक यह दर्शाता है 95% मामले हमारा सिस्टम वैसे ही काम करता है जैसा हम चाहते हैं। यदि कहीं कोई समस्या है तो हम उसे स्वीकार कर सकते हैं, क्योंकि हम सामान्य प्रवृत्ति को समझते हैं कि सब कुछ कितना अच्छा या बुरा है।

उपकरण

ईएलके स्टैक. आप Elasticsearch का उपयोग करके कैनरी को कार्यान्वित कर सकते हैं - घटनाएँ घटित होने पर हम इसमें त्रुटियाँ लिखते हैं। सबसे सरल एपीआई कॉल के साथ, आप किसी भी समय त्रुटियों की संख्या प्राप्त कर सकते हैं और पिछले सेगमेंट के साथ तुलना कर सकते हैं: GET /applg/_cunt?q=level:errr.

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

हम इसका उपयोग कर सकते हैं level, instance, service, उन्हें एक प्रणाली में संयोजित करें। मदद से offset उदाहरण के लिए, आप केवल एक आदेश से एक सप्ताह पहले के मान का मान देख सकते हैं GET /api/v1/query?query={query}जहां {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

संस्करण विश्लेषण

कई संस्करण रणनीतियाँ हैं।

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

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

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

स्वचालन

हम इंजीनियरों को मैन्युअल तुलना से मुक्त करना चाहते हैं, इसलिए स्वचालन लागू करना महत्वपूर्ण है। परिनियोजन पाइपलाइन आमतौर पर इस तरह दिखती है:

• हम शुरू करें;
• बैलेंसर के नीचे से नोड हटा दें;
• एक कैनरी नोड स्थापित करें;
• सीमित मात्रा में ट्रैफ़िक के साथ बैलेंसर चालू करें;
• तुलना करना।

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

यह ग्रूवी के लिए पाइपलाइन है।

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

यहां लूप में हमने सेट किया है कि हम एक घंटे के लिए नए नोड की तुलना करेंगे। यदि कैनरी प्रक्रिया ने अभी तक प्रक्रिया समाप्त नहीं की है, तो हम फ़ंक्शन को कॉल करते हैं। वह रिपोर्ट करती है कि सब कुछ ठीक है या नहीं: def isOk = compare(srv, canary, time, base, offset, metrics).

यदि सब कुछ अच्छा है - sleep DEFAULT SLEEP, उदाहरण के लिए, एक सेकंड के लिए, और जारी रखें। यदि नहीं, तो बाहर निकलें - परिनियोजन विफल रहा।

मीट्रिक का विवरण. आइए देखें कि फ़ंक्शन कैसा दिख सकता है compare डीएसएल के उदाहरण पर.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

मान लीजिए कि हम त्रुटियों की संख्या की तुलना कर रहे हैं और हम पिछले 5 मिनट में प्रति सेकंड त्रुटियों की संख्या जानना चाहते हैं।

हमारे पास दो मान हैं: आधार और कैनरी नोड्स। कैनरी नोड का मान वर्तमान है। बुनियादी - baseValue किसी अन्य गैर-कैनरी नोड का मान है। हम मूल्यों की तुलना सूत्र के अनुसार एक दूसरे से करते हैं, जिसे हम अपने अनुभव और टिप्पणियों के आधार पर निर्धारित करते हैं। यदि मान canaryValue ख़राब, फिर परिनियोजन विफल हो गया, और हम वापस आ गए।

ये सब क्यों जरूरी है?

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

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

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

बाधाओं

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

व्यवहार में परीक्षण की आवश्यकता है मीट्रिक स्थिरता. जाँचने से आपको समझने में मदद मिलती है गुणवत्ता सुनिश्चित करने के लिए आवश्यक मैट्रिक्स का न्यूनतम सेट क्या है.

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

कैनरी रिलीज़ से हमें क्या लाभ हुआ?

बग से होने वाले नुकसान का प्रतिशत न्यूनतम किया गया। अधिकांश परिनियोजन त्रुटियाँ कुछ डेटा या प्राथमिकता में विसंगतियों के कारण होती हैं। ऐसी त्रुटियाँ बहुत कम हैं, क्योंकि हम समस्या को पहले सेकंड में ही हल कर सकते हैं।

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

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

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

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

इंजीनियरिंग दृष्टिकोण और प्रथाएँ - टेकलीड कॉन्फ्रेंस का मुख्य फोकस. यदि आपने तकनीकी उत्कृष्टता की राह पर सफलता हासिल की है और आपको यह बताने के लिए तैयार हैं कि इससे आपको क्या मदद मिली, - एक रिपोर्ट के लिए आवेदन करें.

हम योजना बना रहे हैं टेक लीड कॉन्फ़ 8 जून. हम समझते हैं कि अब सम्मेलन में भागीदारी के बारे में निर्णय लेना कठिन है। लेकिन साथ ही, हम मानते हैं कि संगरोध पेशेवर संचार और विकास को रोकने का एक कारण नहीं है। इसलिए, किसी भी मामले में, हम तकनीकी नेतृत्व के कार्यों और उन्हें हल करने के तरीकों पर चर्चा करने का एक तरीका ढूंढेंगे - यदि आवश्यक हो, तो हम ऑनलाइन जाएंगे और वहां नेटवर्किंग स्थापित करेंगे!

स्रोत: www.habr.com