90 हजार साइटों पर दस लोग: पागल कैसे न हों

हाय, मेरा नाम वेरा शिवकोवा है। मैं Yandex.Kassi के प्रमुख सहयोगियों के साथ काम करता हूं - मैं बड़े स्टोर और सेवाओं को जोड़ता हूं, परियोजनाओं को लॉन्च करता हूं और दुनिया भर की बैठकों में यात्रा करता हूं। सामान्य तौर पर, मैं यह मानता हूं कि सब कुछ ठीक था।

प्रत्येक Yandex.Money कर्मचारी वर्ष में एक बार अपना व्यवसाय बदल सकता है - एक विभाग चुन सकता है और कई दिनों तक वहां काम कर सकता है। इसलिए, एक महीने पहले, मैं सैपसन में बैठ गया और सेंट पीटर्सबर्ग में आ गया। एक निगरानी विभाग वहां काम करता है, जो यह भी निगरानी करता है कि टिकट कार्यालय से जुड़ी 90,000 साइटें अच्छा काम कर रही हैं, और हमने बलों में शामिल होने का फैसला किया।

पागल कैसे न हो? बिल्कुल समान नहीं (स्रोत: reddit.com)

यह एक कहानी है कि हमारी निगरानी कैसे काम करती है, और मैंने कुछ दिनों में एक और विभाग में क्या सीखा।

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

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

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

हम निगरानी के तीन स्तरों में अंतर करते हैं, जिनमें से प्रत्येक के अपने महत्वपूर्ण संकेतक हैं - सिस्टम का स्तर, व्यावसायिक तर्क का स्तर और समकक्षों का स्तर।

सिस्टम स्तर

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

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

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

व्यापार तर्क स्तर

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

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

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

प्रतिपक्ष स्तर

यहां हम विशिष्ट समकक्षों के बारे में बात कर रहे हैं - उदाहरण के लिए, बैंकों और व्यापारियों को प्राप्त करना।

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

एक बैंक विफल रहा, लेकिन एक और स्वचालित रूप से जुड़ा हुआ है

हमने त्रुटियों को ठीक करने और समय पर ढंग से त्रुटियों को शुरू करने पर पुनर्निर्देशित करना सीखा।

एक बैंक ने भुगतान त्रुटियों में वृद्धि दर्ज की

अनुवादित - और सब कुछ क्रम में है। Y- अक्ष मान कम्यूट नहीं हैं

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

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

त्रुटियों की पूरी विविधता को दो बड़े समूहों में विभाजित किया जा सकता है।

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

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

रूपांतरण लाभ को कैसे प्रभावित करता है

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

जैसा कि उदाहरण से देखा जा सकता है, व्यवसाय के लिए एक बेहतर समाधान बेहतर सेवा लेना होगा और इस तथ्य के बावजूद कि अधिग्रहण करने की गुणवत्ता में अंतर के कारण आयोग अधिक है, अंत में हमारे पास 3 538 080 - 2 847 000/691 080 रूबल प्रति माह अंतर है! और यह एक वर्ष में 8 मिलियन है, जो व्यापार के लिए बहुत पैसा है।

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

व्यापारी कैसे जुड़ा हुआ है

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

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

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

किसी बॉट से संदेश का एक वास्तविक उदाहरण

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

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

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

सबसे महत्वपूर्ण बात

मेरा "अवज्ञा का दिन" (जिसे हम दूसरे विभाग के लिए एक अस्थायी संक्रमण कहते हैं) समाप्त हो गया, और मैं मास्को लौट आया। निगरानी विभाग में 2 दिनों के लिए, मैंने बहुत कुछ सीखा और वर्तमान ज्ञान को सुव्यवस्थित किया।

• निगरानी कार्य सभी स्तरों पर सिस्टम की स्थिति पर प्रासंगिक जानकारी प्रदान करना है;
• सक्षम मीट्रिक और ट्रिगर्स चुनें - 90% सफलता;
• भुगतान सेवाओं में, रूपांतरण बोली लगाता है;
• आपको तकनीक का पालन करने और व्यावसायिक मैट्रिक्स के बारे में याद रखने की आवश्यकता है;
• हमें प्रक्रियाओं के व्यवस्थित दृष्टिकोण और रिश्तों का विश्लेषण करने की क्षमता की आवश्यकता है;

और फिर भी - आभारी रहें। निगरानी रखने वाले लोग, धन्यवाद!

वह सब है। प्रश्न पूछें, हमारे ब्लॉग की सदस्यता लें और यात्रा करने के लिए आएं ।