ग्रेसफुल डिग्रेडेशन। रिपोर्ट Yandex.Taxi

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

न केवल अच्छी तरह से काम करने वाली सेवाओं को लिखना महत्वपूर्ण है, बल्कि अच्छी तरह से टूटने वाली सेवाओं को भी लिखना है।

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



चलिए परिभाषा के साथ शुरू करते हैं। हकीकत में क्या दिखता है?



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

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

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

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

आइए इन समाधानों पर अधिक विस्तार से विचार करें।



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

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





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

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



जैसा कि आप देख सकते हैं, ग्राहक एक आदेश देने और ड्राइवर के साथ संवाद करने के लिए विभिन्न एपीआई, विभिन्न अनुरोधों का उपयोग करता है।

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



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

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



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

आइए देखें कि यह व्यवहार में कैसे काम करता है।



हमारे पास एक ग्राहक है, वह गंतव्य सेवा से संपर्क करता है और एक त्रुटि प्राप्त करता है।



अब दो स्थितियां संभव हैं। पहली स्थिति, यदि विफलता एकल थी, तो बस एक असफल अनुरोध है। इस मामले में, हम सिर्फ ग्राहक से एक गलती करते हैं, वह फिर से अनुरोध करेगा और अपने पसंदीदा गंतव्य प्राप्त करेगा।

लेकिन अगर विफलता बड़े पैमाने पर है, तो हम कद्दू को चालू करते हैं और उपयोगकर्ता को डिफ़ॉल्ट व्यवहार मिलता है।



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



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



कोई त्रुटि नहीं - एक सफल प्रतिक्रिया। एक गलती है - एक कद्दू। हम कहते हैं कि कमबैक चालू हो गया है।

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

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



बड़ी संख्या में एजेंटों के साथ बातचीत करने वाली किसी भी जटिल प्रणाली में, हमेशा त्रुटियों की पृष्ठभूमि होती है। इस स्लाइड पर हम अपनी सेवाओं में से एक पर कॉल का वास्तविक शेड्यूल देखते हैं। कई हजार आरपीएस इसमें आते हैं, हमें 1% से कम त्रुटियां मिलती हैं। यहाँ लॉगरिदमिक पैमाना है।

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



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

चयनित क्षेत्रों पर ध्यान दें। 19:01 बजे पहली त्रुटियां दिखाई देने लगीं, लेकिन अब तक उनका हिस्सा काफी छोटा है, और 19:02 तक हम फॉलबैक को शामिल नहीं करते हैं। 19:02 को दहलीज पार हो गई, हम पतन की ओर अग्रसर हो गए। 19:08 पर रिवर्स प्रक्रिया: त्रुटियां समाप्त हो गईं, लेकिन कुछ समय के लिए हमने फॉलबैक चालू कर दिया है, क्योंकि हमारी स्लाइडिंग विंडो में सीमा अभी भी पार हो गई है। 19:09 पर हम फॉलबैक हो गए।

हमें पता चला कि सेवा कब बंद करनी है। दूसरे प्रश्न का उत्तर देना आवश्यक है: इसे कब चालू करना है। यह सरल है: हम आँकड़ों के आधार पर एक ही समाधान का उपयोग करते हैं।



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



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

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

सब कुछ मुख्य भाग के साथ है।

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



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

यह जटिल लगता है, लेकिन आइए एक उदाहरण के साथ समझाने की कोशिश करते हैं। शायद यह स्पष्ट हो जाएगा।



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



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

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



शायद अन्य सेवाओं के लिए अलग-अलग स्थितियां और अन्य बारीकियां होंगी।

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