आपका स्वागत है! मेरा नाम इवान डेविडोव है, मैं Yandex.Money में प्रदर्शन अनुसंधान में व्यस्त हूं।

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

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

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

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

समस्या 100% से अधिक टीसीपी सॉकेट के उपयोग में है। यह तब होता है जब सर्वर पर सभी सॉकेट लगातार खुलते और बंद होते हैं। इस वजह से, अनुप्रयोगों और विभिन्न प्रकार की त्रुटियों के बीच बातचीत की नेटवर्क समस्याएं हैं - दूरस्थ होस्ट अनुपलब्ध है, HTTP / HTTPS कनेक्शन (कनेक्शन / रीड टाइमआउट, SSL सहकर्मी गलत तरीके से बंद) टूट गया है और अन्य।

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

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

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

• वर्तमान में एक आवेदन उदाहरण में कौन सा प्रदर्शन मार्जिन है?
• आवेदन कैसे बढ़ाया जाता है और क्या वर्तमान कॉन्फ़िगरेशन में संसाधन अतिरेक है?
• क्या एक उदाहरण के प्रदर्शन में सुधार करना संभव है और क्या अड़चन है?

ऐसे सवालों के साथ, सहकर्मी हमारे पास आए - प्रदर्शन शोधकर्ताओं की एक टीम।

हम क्या कर रहे हैं?

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

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

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

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

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

क्षमता प्रबंधन का सार भस्म संसाधनों और उत्पादकता के बीच संतुलन खोजना है।

पेशेवरों:

• किसी भी क्षण यह ज्ञात होता है कि प्रत्येक एप्लिकेशन के प्रदर्शन का क्या होता है।
• नए माइक्रोसर्विसेज को जोड़ने पर कम जोखिम।
• नए उपकरणों की खरीद के लिए कम लागत।
• वे क्षमताएँ जो पहले से मौजूद हैं, अधिक समझदारी से उपयोग की जाती हैं।

कैसे क्षमता प्रबंधन काम करता है

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

संक्षेप में, कार्य योजना इस प्रकार है:

1. विशिष्ट अनुप्रयोगों पर उपयोगकर्ता की तीव्रता को परिभाषित करें।
2. एक शूटिंग प्रोफ़ाइल बनाओ।
3. प्रत्येक आवेदन उदाहरण के प्रदर्शन का मूल्यांकन करें।
4. दर मापनीयता।
5. एक मुकाबला वातावरण में प्रत्येक आवेदन के लिए न्यूनतम आवश्यक संख्या पर रिपोर्ट और निष्कर्ष संकलित करें।

और अब और अधिक विस्तार से।

उपकरण

हम कस्टम तीव्रता मैट्रिक्स एकत्र करने के लिए हेका और ज़ैबिक्स का उपयोग करते हैं। ग्राफ्टाना का उपयोग एकत्रित मैट्रिक्स की कल्पना करने के लिए किया जाता है।

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

उदाहरण के लिए, Grafana दिखा सकते हैं, ऐसी चीजें

Apache JMeter का उपयोग एक ट्रैफ़िक जनरेटर के रूप में किया जाता है। इसकी मदद से, एक शूटिंग परिदृश्य संकलित किया जाता है, जिसमें अनुरोधों का कार्यान्वयन, प्रतिक्रिया की वैधता की निगरानी, ​​फ़ीड स्ट्रीम का लचीला नियंत्रण और बहुत कुछ शामिल है। इस उपकरण में इसके पेशेवरों और विपक्ष दोनों हैं, लेकिन गहराई में जाने के लिए "यह विशेष उत्पाद क्यों?" मैं नहीं करूंगा

जेमीटर के अलावा, यैंडेक्स-टैंक ढांचे का उपयोग किया जाता है - तनाव परीक्षण और वेब सेवाओं और अनुप्रयोगों के प्रदर्शन के विश्लेषण के लिए एक उपकरण। यह आपको अपने मॉड्यूल को किसी भी वांछित कार्यों को प्राप्त करने और कंसोल में या ग्राफ़ के रूप में परिणाम प्रदर्शित करने के लिए कनेक्ट करने की अनुमति देता है। हमारी शूटिंग के परिणाम लूनपार्क में प्रदर्शित होते हैं ( https://overload.yandex.net के अनुरूप), जहां हम उन्हें वास्तविक समय में विस्तार से देख सकते हैं, दूसरी चोटियों तक, आवश्यक और पर्याप्त असुविधा प्रदान करते हैं, और इस तरह फटने के लिए जल्दी से प्रतिक्रिया करते हैं। शूटिंग से उत्पन्न। ग्रेफेन में, कोई भी असुविधा को समायोजित कर सकता है, लेकिन यह समाधान भौतिक और तार्किक संसाधनों के मामले में अधिक महंगा है। और कभी-कभी हम कच्चा डेटा भी अपलोड करते हैं और GUI Jmeter के माध्यम से इसकी कल्पना करते हैं। लेकिन केवल - शाह!

गिरावट की बात कर रहे हैं। ट्रैफ़िक के एक बड़े प्रवाह के तहत एप्लिकेशन में होने वाली लगभग किसी भी दुर्घटना का Kibana का उपयोग करके जल्दी से विश्लेषण किया जाता है । लेकिन यह भी एक रामबाण नहीं है - कुछ नेटवर्क समस्याओं का विश्लेषण केवल ट्रैफिक को हटाने और विश्लेषण करके किया जा सकता है।

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

कई महीनों के लिए प्रति एप्लिकेशन उपयोगकर्ता तीव्रता

शूटिंग और देख प्रोफाइल

हम एक प्रयोग के एक भाग के रूप में एक स्क्रिप्ट लॉन्च फायरिंग कहते हैं। प्रोफ़ाइल दो भागों से बना है।

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

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

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

प्रतिशत का प्रतिशत

यह अध्ययन एक निरंतर प्रवाह में उपयोगकर्ता की तीव्रता की जांच करता है, और समय-समय पर "फट" होता है जिसे अक्सर निजी माना जाता है।

हमारे उदाहरण में, दो समूहों पर विचार किया जाता है। पहले समूह में 1 से 2 के अनुपात में "अनुरोध 1" और "अनुरोध 2" शामिल थे। इसी तरह, दूसरे समूह में अनुरोध 3 और 4 शामिल थे। घटक के लिए शेष अनुरोध बहुत कम गहन हैं, इसलिए हम उन्हें स्क्रिप्ट में शामिल नहीं करते हैं।

जेमीटर में ग्रुपिंग क्वेश्चन

प्रत्येक समूह के लिए माध्य प्रतिक्रिया समय के आधार पर, सूत्र द्वारा प्रदर्शन का अनुमान लगाया जाता है:

x = 1000 / t, जहां t का माध्य समय है, ms

हम गणना परिणाम प्राप्त करते हैं और धागे की बढ़ती संख्या के साथ अनुमानित तीव्रता का अनुमान लगाते हैं:

टीपीएस = एक्स * पी, जहां पी धागे की संख्या है, टीपीएस प्रति सेकंड लेनदेन है, और एक्स पिछले गणना का परिणाम है।

यदि अनुरोध 500 एमएस में संसाधित किया जाता है, तो एक स्ट्रीम के साथ हमारे पास 2 टीपीएस हैं, और 100 थ्रेड्स के साथ आदर्श रूप से 200 टीपीएस होना चाहिए। प्राप्त परिणामों के आधार पर, प्रारंभिक विकास मापदंडों का चयन किया जा सकता है। अनुसंधान के पहले पुनरावृत्ति के बाद, इन मापदंडों को आमतौर पर समायोजित किया जाता है।

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

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

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

तीव्रता विकास विकल्प

तीव्रता वृद्धि पैरामीटर निम्नानुसार थे:

• थ्रेड्स की लक्ष्य संख्या 100 है (देखने के दौरान निर्धारित)।
• 1000 सेकंड के लिए विकास (~ 16 मिनट।)।
• 100 कदम।

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

अग्निशमन

आमतौर पर, रिमोट सर्वर से रात में फायरिंग शुरू होती है। इस समय, उपयोगकर्ता ट्रैफ़िक न्यूनतम है - इसका मतलब है कि शूटिंग शायद ही उपयोगकर्ताओं को प्रभावित करेगी, और परिणामों में त्रुटि कम होगी।

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

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

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

सर्वर प्रदर्शन तुलना

स्केलेबिलिटी और अड़चन

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

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

उत्पादकता में वृद्धि का कारण बाद के बैकेंड से पहले कनेक्टर पूलों की थकावट थी। यह आउटगोइंग और इनकमिंग साइड पर पूल के आकार को नियंत्रित करके हल किया जाता है और आवेदन प्रदर्शन में वृद्धि की ओर जाता है।

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

अंत में अपने डर को मनाने के लिए, हमने 3 उदाहरणों पर गोलीबारी की। परिणाम लगभग पहले दो के समान थे, सिवाय इसके कि वे जल्दी से एक विकार में आए।

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

परिणाम

नतीजतन, हमारे उदाहरण के आवेदन में जांच की गई आवेदन मार्जिन में 5 गुना से अधिक का प्रदर्शन मार्जिन है।

उत्पादकता बढ़ाने के लिए, एप्लिकेशन सेटिंग्स में पर्याप्त संख्या में प्रोसेसर पूल की गणना करना आवश्यक है। एक विशिष्ट अनुप्रयोग के लिए दो उदाहरण पर्याप्त हैं, और उपलब्ध सभी 15 का उपयोग बेमानी है।

अध्ययन के बाद, निम्नलिखित परिणाम प्राप्त हुए:

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

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

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

आज के लिए बस इतना ही। टिप्पणियों में प्रश्न पूछें और Yandex.Money ब्लॉग की सदस्यता लें - जल्द ही हम फ़िशिंग के बारे में बात करेंगे और इससे कैसे बचें।