"बचाव के लिए आओ" आदेश से खेल के उदाहरण (उदाहरण के साथ एक दर्जन घटनाओं का विश्लेषण)

कभी-कभी ऐसा होता है:

- आओ, हम गिर गए हैं। यदि आप इसे अभी नहीं बढ़ाते हैं, तो इसे टीवी पर दिखाया जाएगा।

और हम जा रहे हैं। रात को। देश के दूसरी तरफ।


वह स्थिति जब कोई भाग्य नहीं: ग्राफ़ DBMS पर लोड में तेज वृद्धि दिखाता है। बहुत बार यह पहली चीज है जो सिस्टम प्रशासक देखता है और यह पहला संकेत है कि एक गधा आया है

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

कैसे होता है?

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

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

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

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

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

कोड के इन वर्गों को कैसे खोजा जाता है?

मानक टूल (थ्रेड डंप, लॉग, मेट्रिक्स, AWR, सिस्टम रिप्रेजेंटेशन से डेटा आदि) के अलावा, हम कमर्शियल वाले सहित अधिक सिविल टूल का उपयोग करते हैं।

उदाहरण 1: धीमी लेन-देन लॉग

उपयोगकर्ताओं से शिकायतें पत्रिका के धीमे संचालन (एक ज्ञात और लगातार समस्या) के बारे में प्राप्त हुई हैं।

हम समस्या को देखते हैं, फिर हम deal_journal_view दृश्य के संचालन में अनुरोध की तलाश करते हैं। हम उन सभी लेनदेन की खोज करते हैं, जहां इस तरह का अनुरोध है।



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



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



उदाहरण 2: धीमे उपयोगकर्ता के काम के कारणों का पता लगाना 1

उपयोगकर्ता 1 को आवेदन के धीमे संचालन के बारे में शिकायतें मिलीं। हम देखते हैं:



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



बगल की टीम को इशारा किया, उसे ठीक किया।

उदाहरण 3: एक अन्य उपयोगकर्ता एप्लिकेशन के धीमे संचालन के बारे में शिकायत करता है

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



उदाहरण 4: जब पर्याप्त विवरण नहीं है

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



उदाहरण 5: अधिक ब्रेक

उपयोगकर्ता ने अनुबंध कार्ड के साथ धीमे काम के बारे में शिकायत की।



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



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

यह कितना सरल है: आपको एक अड़चन खोजने की जरूरत है - और यह बात है?

नहीं।

और फिर से, नहीं।

यह सभी लक्षणों का इलाज है।

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

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

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

आर्किटेक्चर की गलत पसंद से लेकर वर्कफ़्लो की कुछ विशेषताओं तक, कुछ भी दर्द हो सकता है। ये उदाहरण देश भर की विभिन्न कंपनियों में प्रक्रियाओं के खेल के बारे में हैं।

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

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

ऐसी निगरानी की आवश्यकता क्यों हो सकती है?

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

दूसरी पंक्ति में सिर्फ इस उपकरण का सेट है। अब लगभग 50% मामलों में, वे निगरानी का उपयोग निदान करने के लिए, अड़चनों की खोज और फ्रीज के कारणों के लिए करते हैं, ताकि उनके स्वयं के डेवलपर्स देख सकें, समझ सकें और अनुकूलन कर सकें। समस्या के कारण की शीघ्रता से पहचान कर बहुत से सहायता समय की बचत की जाती है। पायलट लेनदेन के बाद बढ़ाया। यही चार महीने लग गए: किसी भी कार्रवाई के लिए एक व्यवसाय संचालन होता है। एक दस्तावेज़ कार्ड खोलना एक व्यवसाय लेनदेन है। वर्कफ़्लो सिस्टम में साइन इन करना एक व्यापारिक लेनदेन है। रिपोर्ट अपलोड या खोज, भी। चार महीने में इस तरह के 1,500 कारोबार संचालन को समझने के लिए वर्णित है कि कहां और क्या काम करता है। निगरानी इससे पहले कि http कॉलों को देखती है और तथाकथित तरीकों और कार्यों को देखती है, विशिष्ट अनुरोधों को देखती है। इससे पहले, केवल डेवलपर्स ने समझा कि यह समझौता था या खोज। निगरानी प्रणाली के लिए विभिन्न समर्थन लाइनों और व्यापार के लिए प्रासंगिक डेटा दिखाने के लिए, हमने इन सभी बंडलों की स्थापना की है।



व्यवसाय ने अपने स्वयं के आईटी विकास पर रिपोर्ट में कटौती करना शुरू कर दिया। लॉग पर अधिक विशेष रूप से कोई नहीं चुनता है।

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

तकनीकी पक्ष से "प्लग" क्या हैं?

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

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

खैर, मैं यह कहना चाहता हूं कि समस्या हमेशा नियमित सफाई या उचित समर्थन की कमी नहीं है। अक्सर समस्याएं प्रक्रियाओं में होती हैं।

हमें अपने लाइव डेवलपर्स के साथ ऐसी सेवाओं की आवश्यकता क्यों है?

क्योंकि व्यवसाय निर्णयों को पसंद करता है, प्रक्रियाओं को नहीं। यह मुख्य कारण है।

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

ठीक है, यदि आप विवरणों में गोता लगाने में रुचि रखते हैं, तो 1 अक्टूबर को सब कुछ गिरने से पहले आप क्या कर सकते हैं, इसके बारे में हमारी वेबिनार होगी । और यहाँ सवालों के लिए मेरा मेल है - sstrelkov@croc.ru।