💊 👎🏽 🛢️ ठेस पर परीक्षण: कैनरी तैनाती 🦏 🤰🏾 🤘🏻

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

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

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

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

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

इन्फोबिप आईटी इन्फ्रास्ट्रक्चर इन नंबर्स:

दुनिया भर में 15 डेटा सेंटर;
ऑपरेशन में 500 अनूठी सेवाएं;
सेवाओं के 2500 उदाहरण, जो टीमों की तुलना में बहुत अधिक है;
मासिक यातायात के 4.5 टीबी;
4.5 बिलियन फोन नंबर;

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

विज्ञप्ति

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

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

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

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

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

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

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

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

तैनाती के मुद्दे

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

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

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

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

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

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

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

परीक्षण लिखें । टेस्ट काम करते हैं, लेकिन कभी-कभी यह बिल्कुल नहीं होता है कि व्यवसाय क्या चाहता है। पैसा कमाना कोई टेस्ट का काम नहीं है।

स्टेज पर टेस्ट । इन्फोबिप में अपने काम के 3.5 वर्षों में, मैंने कभी भी उत्पादन के साथ कम से कम आंशिक रूप से एक अवस्था नहीं देखी है।

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

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

अतिरिक्त कठिनाइयाँ भी हैं। एक डेवलपर के लिए, यह तनावपूर्ण है - मैन्युअल रूप से सब कुछ जांचने के लिए बहुत समय बिताना।

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

धुआँ परीक्षण

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

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

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

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

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

यहां केवल बोनस यह है कि आप प्रदर्शन की जांच कर सकते हैं ।

कैनरी जारी

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

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

कार्यान्वयन और बारीकियों

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

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

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

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

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

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

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

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

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

संतुलन;
, , , ;
, , ;
— (deployment pipeline).

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

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

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

निगरानी

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

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

, . , . , .
(latency). , .
(throughput).
.
95% .
-: . , , .

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

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

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

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

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

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

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

उपकरण

ईएलके स्टैक । आप एलीस्टिक्स खोज का उपयोग करके कैनरी को लागू कर सकते हैं - जब घटनाएँ होती हैं तो हम उसमें त्रुटियाँ लिखते हैं। बस एपीआई को कॉल करें, आप किसी भी समय त्रुटियों को प्राप्त कर सकते हैं, और पिछले खंडों के साथ तुलना कर सकते हैं 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 मिनट पहले हुआ था। जब तक कोई व्यक्ति किसी समस्या को नोटिस नहीं करता, तब तक समर्थन लिखता है, और हम ग्राहकों को समर्थन वापस लेने के लिए खो सकते हैं।

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

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

बाधाओं

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

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

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

कैनरी रिलीज से हमें क्या फायदा हुआ है

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

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

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

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

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

— TechLead Conf. , , — .

TechLead Conf 8 9 . , , — , .

ठेस पर परीक्षण: कैनरी तैनाती