गुगल क्लाउड प्राविधिक समर्थनबाट हराएको DNS प्याकेटहरूको बारेमा एउटा कथा

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

समस्या निवारण विज्ञान र कला दुवै हो। यो सबै प्रणाली को गैर-मानक व्यवहार को कारण को बारे मा एक परिकल्पना निर्माण संग सुरु हुन्छ, जस पछि यो बल को लागी परीक्षण गरिन्छ। यद्यपि, हामीले एक परिकल्पना तयार गर्नु अघि, हामीले समस्यालाई स्पष्ट रूपमा परिभाषित र ठीकसँग तयार गर्नुपर्छ। यदि प्रश्न धेरै अस्पष्ट लाग्छ भने, तपाईंले सबै कुरालाई ध्यानपूर्वक विश्लेषण गर्नुपर्नेछ; यो समस्या निवारण को "कला" हो।

गुगल क्लाउड अन्तर्गत, त्यस्ता प्रक्रियाहरू तीव्र रूपमा थप जटिल हुन्छन्, किनकि Google क्लाउडले आफ्ना प्रयोगकर्ताहरूको गोपनीयता सुनिश्चित गर्न सक्दो प्रयास गर्छ। यस कारणले, TSE इन्जिनियरहरूसँग तपाइँको प्रणालीहरू सम्पादन गर्न पहुँच छैन, न त प्रयोगकर्ताहरूले जस्तै व्यापक रूपमा कन्फिगरेसनहरू हेर्ने क्षमता। त्यसकारण, हाम्रो कुनै पनि परिकल्पना परीक्षण गर्न, हामी (इन्जिनियरहरू) प्रणालीलाई द्रुत रूपमा परिमार्जन गर्न सक्दैनौं।

केही प्रयोगकर्ताहरूले विश्वास गर्छन् कि हामी कार सेवामा मेकानिकहरू जस्तै सबै कुरा ठीक गर्नेछौं, र हामीलाई भर्चुअल मेसिनको आईडी पठाउनेछौं, जबकि वास्तविकतामा प्रक्रिया कुराकानीको ढाँचामा हुन्छ: जानकारी सङ्कलन, गठन र पुष्टि (वा खण्डन) परिकल्पनाहरू, र, अन्तमा, निर्णय समस्याहरू ग्राहकसँग सञ्चारमा आधारित हुन्छन्।

प्रश्नमा समस्या

आज हामीसँग राम्रो अन्त्य भएको कथा छ। प्रस्तावित मामला को सफल समाधान को कारणहरु मध्ये एक समस्या को एक धेरै विस्तृत र सही विवरण हो। तल तपाईंले पहिलो टिकटको प्रतिलिपि हेर्न सक्नुहुन्छ (गोपनीय जानकारी लुकाउन सम्पादन गरिएको):

यो सन्देशले हाम्रो लागि धेरै उपयोगी जानकारी समावेश गर्दछ:

• निर्दिष्ट VM निर्दिष्ट
• समस्या आफै संकेत गरिएको छ - DNS ले काम गर्दैन
• यो संकेत गरिएको छ जहाँ समस्या आफै प्रकट हुन्छ - VM र कन्टेनर
• प्रयोगकर्ताले समस्या पहिचान गर्न चालेका कदमहरू संकेत गरिएका छन्।

अनुरोधलाई "P1: क्रिटिकल इम्प्याक्ट - उत्पादनमा प्रयोग गर्न नसकिने सेवा" को रूपमा दर्ता गरिएको थियो, जसको अर्थ "Follow the Sun" योजना अनुसार 24/7 स्थितिको निरन्तर अनुगमन (तपाईंको बारेमा थप पढ्न सक्नुहुन्छ। प्रयोगकर्ता अनुरोधहरूको प्राथमिकता), प्रत्येक समय क्षेत्र परिवर्तनको साथ एक प्राविधिक समर्थन टोलीबाट अर्कोमा यसको स्थानान्तरणको साथ। वास्तवमा, ज्युरिखमा हाम्रो टोलीमा समस्या आइपुग्दा, यसले विश्वको परिक्रमा गरिसकेको थियो। यस समय सम्म, प्रयोगकर्ताले शमन उपायहरू लिएका थिए, तर उत्पादनमा स्थिति दोहोर्याउने डर थियो, किनकि मूल कारण अझै पत्ता लागेको थिएन।

टिकट ज्यूरिख पुग्दा, हामीसँग पहिले नै निम्न जानकारी हातमा थियो:

• सामाग्री /etc/hosts
• सामाग्री /etc/resolv.conf
• निष्कर्षमा iptables-save
• टोलीले भेला गरेको हो ngrep pcap फाइल

यस डेटाको साथ, हामी "अनुसन्धान" र समस्या निवारण चरण सुरु गर्न तयार थियौं।

हाम्रो पहिलो कदम

सबैभन्दा पहिले, हामीले मेटाडेटा सर्भरको लग र स्थिति जाँच गर्यौं र यो ठीकसँग काम गरिरहेको छ भनी सुनिश्चित गर्यौं। मेटाडेटा सर्भरले IP ठेगाना 169.254.169.254 मा प्रतिक्रिया दिन्छ र, अन्य चीजहरू बीच, डोमेन नामहरू नियन्त्रण गर्न जिम्मेवार छ। हामीले यो पनि दोहोरो-जाँच गर्यौं कि फायरवालले VM सँग सही रूपमा काम गर्छ र प्याकेटहरू रोक्दैन।

यो केहि प्रकारको अनौठो समस्या थियो: nmap चेकले UDP प्याकेटहरू हराउने बारे हाम्रो मुख्य परिकल्पनालाई खण्डन गर्‍यो, त्यसैले हामीले मानसिक रूपमा धेरै विकल्पहरू र तिनीहरूलाई जाँच गर्ने तरिकाहरू लिएर आएका छौं:

• के प्याकेटहरू छनौट रूपमा छोडिन्छ? => iptables नियमहरू जाँच गर्नुहोस्
• यो धेरै सानो छैन? MTU? => आउटपुट जाँच गर्नुहोस् ip a show
• के समस्याले UDP प्याकेट वा TCP लाई पनि असर गर्छ? => टाढा ड्राइभ गर्नुहोस् dig +tcp
• के खन्दा उत्पन्न प्याकेटहरू फिर्ता गरिन्छ? => टाढा ड्राइभ गर्नुहोस् tcpdump
• के libdns सही काम गर्दै हुनुहुन्छ? => टाढा ड्राइभ गर्नुहोस् strace दुबै दिशामा प्याकेटहरूको प्रसारण जाँच गर्न

यहाँ हामी प्रयोगकर्तालाई प्रत्यक्ष समस्या निवारण गर्न कल गर्ने निर्णय गर्छौं।

कलको समयमा हामी धेरै चीजहरू जाँच गर्न सक्षम छौं:

• धेरै जाँचहरू पछि हामी कारणहरूको सूचीबाट iptables नियमहरू बहिष्कार गर्छौं
• हामी नेटवर्क इन्टरफेसहरू र राउटिङ तालिकाहरू जाँच गर्छौं, र MTU सही छ कि छैन भनेर डबल-जाँच गर्छौं
• हामीले त्यो पत्ता लगाउँछौं dig +tcp google.com (TCP) ले काम गर्छ, तर dig google.com (UDP) ले काम गर्दैन
• भगाएको हो tcpdump यो अझै काम गरिरहेको छ dig, हामीले UDP प्याकेटहरू फिर्ता भैरहेको फेला पार्छौं
• हामी भाग्छौं strace dig google.com र हामी हेर्छौं कि कसरी सही तरिकाले कल गर्दछ sendmsg() и recvms(), यद्यपि दोस्रो एक टाइमआउट द्वारा अवरोध गरिएको छ

दुर्भाग्यवश, शिफ्टको अन्त्य आइपुग्छ र हामी समस्यालाई अर्को समय क्षेत्रमा बढाउन बाध्य छौं। तथापि, अनुरोधले हाम्रो टोलीमा चासो जगायो, र एक सहकर्मीले स्क्र्यापी पाइथन मोड्युल प्रयोग गरेर प्रारम्भिक DNS प्याकेज सिर्जना गर्न सुझाव दिन्छ।

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

यो टुक्राले DNS प्याकेट सिर्जना गर्छ र मेटाडेटा सर्भरमा अनुरोध पठाउँछ।

प्रयोगकर्ताले कोड चलाउँछ, DNS प्रतिक्रिया फिर्ता हुन्छ, र अनुप्रयोगले यसलाई प्राप्त गर्दछ, नेटवर्क स्तरमा कुनै समस्या छैन भनेर पुष्टि गर्दै।

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

यस बीचमा, प्रयोगकर्ता प्रणाली छविको स्न्यापसट प्रदान गर्न दयालु रूपमा सहमत छन्। यो धेरै राम्रो समाचार हो: प्रणाली आफैले परीक्षण गर्ने क्षमताले समस्या निवारण धेरै छिटो बनाउँछ, किनकि मैले अब प्रयोगकर्तालाई आदेशहरू चलाउन, नतिजाहरू पठाउन र तिनीहरूलाई विश्लेषण गर्न सोध्नु पर्दैन, म आफैं सबै गर्न सक्छु!

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

एक कदम पछि हट्दै

प्रणाली इन्जिनियर स्थितिहरूको लागि सबैभन्दा लोकप्रिय साक्षात्कार प्रश्नहरू मध्ये एक हो: "के हुन्छ जब तपाइँ पिंग गर्नुहुन्छ www.google.com? प्रश्न ठूलो छ, किनकि उम्मेद्वारले शेलबाट प्रयोगकर्ता स्पेस, प्रणाली कर्नेल र त्यसपछि नेटवर्कमा सबै कुरा वर्णन गर्न आवश्यक छ। म मुस्कुराउछु: कहिलेकाहीँ अन्तर्वार्ताका प्रश्नहरू वास्तविक जीवनमा उपयोगी हुन्छन्...

म यो HR प्रश्नलाई हालको समस्यामा लागू गर्ने निर्णय गर्छु। सामान्यतया, जब तपाइँ DNS नाम निर्धारण गर्ने प्रयास गर्नुहुन्छ, निम्न हुन्छ:

1. अनुप्रयोगले प्रणाली पुस्तकालयलाई कल गर्दछ जस्तै libdns
2. libdns ले कुन DNS सर्भरमा सम्पर्क गर्नुपर्छ भन्ने प्रणाली कन्फिगरेसन जाँच गर्दछ (चित्रमा यो 169.254.169.254, मेटाडेटा सर्भर हो)
3. libdns ले UDP सकेट (SOKET_DGRAM) सिर्जना गर्न र दुबै दिशामा DNS क्वेरीको साथ UDP प्याकेटहरू पठाउन प्रणाली कलहरू प्रयोग गर्दछ।
4. sysctl इन्टरफेस मार्फत तपाईंले कर्नेल स्तरमा UDP स्ट्याक कन्फिगर गर्न सक्नुहुन्छ।
5. नेटवर्क इन्टरफेस मार्फत नेटवर्कमा प्याकेटहरू प्रसारण गर्न कर्नेलले हार्डवेयरसँग अन्तरक्रिया गर्छ
6. हाइपरभाइजरले यसको सम्पर्कमा मेटाडाटा सर्भरमा प्याकेट समात्छ र प्रसारण गर्दछ
7. मेटाडेटा सर्भर, यसको जादूद्वारा, DNS नाम निर्धारण गर्दछ र उही विधि प्रयोग गरेर प्रतिक्रिया फर्काउँछ।

हामीले पहिले नै विचार गरिसकेका परिकल्पनाहरू मैले तपाईंलाई सम्झाउन दिनुहोस्:

परिकल्पना: टूटेको पुस्तकालयहरू

• परीक्षण 1: प्रणालीमा स्ट्रेस चलाउनुहोस्, जाँच गर्नुहोस् कि डिगले सही प्रणाली कलहरू कल गर्दछ
• नतिजा: सही प्रणाली कलहरू भनिन्छ
• परीक्षण 2: srapy प्रयोग गरेर हामीले प्रणाली पुस्तकालयहरूलाई बाइपास गरेर नामहरू निर्धारण गर्न सक्छौं कि भनेर जाँच गर्न
• परिणाम: हामी सक्छौं
• परीक्षण ३: libdns प्याकेज र md3sum पुस्तकालय फाइलहरूमा rpm –V चलाउनुहोस्
• नतिजा: पुस्तकालय कोड काम गर्ने अपरेटिङ सिस्टमको कोडसँग पूर्ण रूपमा समान छ
• परीक्षण 4: प्रयोगकर्ताको मूल प्रणाली छविलाई VM मा यो व्यवहार बिना माउन्ट गर्नुहोस्, क्रुट चलाउनुहोस्, हेर्नुहोस् कि DNS काम गर्दछ
• नतिजा: DNS सही काम गर्दछ

परीक्षणमा आधारित निष्कर्ष: समस्या पुस्तकालयहरूमा छैन

परिकल्पना: DNS सेटिङहरूमा त्रुटि छ

• परीक्षण 1: tcpdump जाँच गर्नुहोस् र हेर्नुहोस् कि DNS प्याकेटहरू पठाइएका छन् र खन्ने दौड पछि सही रूपमा फर्काइएका छन्।
• नतिजा: प्याकेटहरू सही रूपमा प्रसारित छन्
• परीक्षण २: सर्भरमा दोहोरो जाँच गर्नुहोस् /etc/nsswitch.conf и /etc/resolv.conf
• परिणाम: सबै सही छ

परीक्षणमा आधारित निष्कर्ष: समस्या DNS कन्फिगरेसनमा छैन

परिकल्पना: कोर क्षतिग्रस्त

• परीक्षण: नयाँ कर्नेल स्थापना गर्नुहोस्, हस्ताक्षर जाँच गर्नुहोस्, पुन: सुरु गर्नुहोस्
• परिणाम: समान व्यवहार

परीक्षणमा आधारित निष्कर्ष: कर्नेल क्षतिग्रस्त छैन

परिकल्पना: प्रयोगकर्ता नेटवर्कको गलत व्यवहार (वा हाइपरभाइजर नेटवर्क इन्टरफेस)

• परीक्षण १: आफ्नो फायरवाल सेटिङहरू जाँच गर्नुहोस्
• नतिजा: फायरवालले होस्ट र GCP दुवैमा DNS प्याकेटहरू पास गर्छ
• परीक्षण २: ट्राफिक रोक्नुहोस् र प्रसारणको शुद्धता र DNS अनुरोधहरूको फिर्ताको निगरानी गर्नुहोस्
• परिणाम: tcpdump ले होस्टले फिर्ता प्याकेटहरू प्राप्त गरेको पुष्टि गर्दछ

परीक्षणमा आधारित निष्कर्ष: समस्या नेटवर्कमा छैन

परिकल्पना: मेटाडाटा सर्भरले काम गरिरहेको छैन

• परीक्षण १: विसंगतिहरूका लागि मेटाडेटा सर्भर लगहरू जाँच गर्नुहोस्
• नतिजा: लगहरूमा कुनै विसंगतिहरू छैनन्
• परीक्षण २: मेटाडेटा सर्भर मार्फत बाइपास गर्नुहोस् dig @8.8.8.8
• नतिजा: मेटाडेटा सर्भर प्रयोग नगरी पनि रिजोल्युसन बिग्रिएको छ

परीक्षणमा आधारित निष्कर्ष: समस्या मेटाडेटा सर्भरमा छैन

तल लाइन: हामीले बाहेक सबै उपप्रणालीहरू परीक्षण गर्यौं रनटाइम सेटिङहरू!

कर्नेल रनटाइम सेटिङहरूमा डाइभिङ

कर्नेल कार्यान्वयन वातावरण कन्फिगर गर्न, तपाइँ कमाण्ड लाइन विकल्प (ग्रब) वा sysctl इन्टरफेस प्रयोग गर्न सक्नुहुन्छ। मैले हेरेँ /etc/sysctl.conf र सोच्नुहोस्, मैले धेरै अनुकूलन सेटिङहरू फेला पारे। मैले केहि समातेको जस्तो महसुस गर्दै, मैले पहाड सेटिङहरूमा बाँकी रहेका सबै गैर-नेटवर्क वा गैर-tcp सेटिङहरू खारेज गरें। net.core। त्यसपछि म VM मा होस्ट अनुमतिहरू भएको ठाउँमा गएँ र टुटेको VM सँग एकपछि अर्को सेटिङहरू लागू गर्न थालेँ, जबसम्म मैले अपराधी नभेटें:

net.core.rmem_default = 2147483647

यहाँ यो छ, एक DNS-ब्रेकिंग कन्फिगरेसन! हत्याको हतियार भेटियो । तर किन यस्तो भइरहेको छ ? मलाई अझै पनि मनसाय चाहिन्छ।

आधारभूत DNS प्याकेट बफर साइज मार्फत कन्फिगर गरिएको छ net.core.rmem_default। एक सामान्य मान 200KiB वरिपरि हुन्छ, तर यदि तपाइँको सर्भरले धेरै DNS प्याकेटहरू प्राप्त गर्दछ भने, तपाइँ बफर साइज बढाउन चाहनुहुन्छ। यदि नयाँ प्याकेट आइपुग्दा बफर भरिएको छ, उदाहरणका लागि किनभने अनुप्रयोगले यसलाई छिटो प्रशोधन गरिरहेको छैन, त्यसपछि तपाईंले प्याकेटहरू हराउन सुरु गर्नुहुनेछ। हाम्रो क्लाइन्टले सही रूपमा बफर साइज बढायो किनभने उसलाई डाटा हराउने डर थियो, किनकि उसले DNS प्याकेटहरू मार्फत मेट्रिक्स सङ्कलन गर्नको लागि एउटा अनुप्रयोग प्रयोग गरिरहेको थियो। उसले सेट गरेको मान अधिकतम सम्भव थियो: 231-1 (यदि 231 मा सेट गरियो भने, कर्नेलले "अमान्य तर्क" फर्काउनेछ)।

अचानक मैले थाहा पाएँ किन nmap र scapy ले सही काम गर्यो: तिनीहरूले कच्चा सकेटहरू प्रयोग गरिरहेका थिए! कच्चा सकेटहरू नियमित सकेटहरू भन्दा फरक छन्: तिनीहरूले iptables लाई बाइपास गर्छन्, र तिनीहरू बफर गरिएका छैनन्!

तर किन "बफर धेरै ठूलो" ले समस्या निम्त्याउँछ? यो स्पष्ट रूपमा इच्छित रूपमा काम गर्दैन।

यस बिन्दुमा मैले धेरै कर्नेल र बहु ​​​​वितरणहरूमा समस्या पुन: उत्पादन गर्न सक्छु। समस्या पहिले नै 3.x कर्नेलमा देखा पर्‍यो र अब यो 5.x कर्नेलमा पनि देखा पर्‍यो।

वास्तवमा, स्टार्टअपमा

sysctl -w net.core.rmem_default=$((2**31-1))

DNS ले काम गर्न छोड्यो।

मैले साधारण बाइनरी खोज एल्गोरिथ्म मार्फत काम गर्ने मानहरू खोज्न थालेँ र प्रणालीले 2147481343 सँग काम गरेको फेला पारे, तर यो संख्या मेरो लागि सङ्ख्याहरूको अर्थहीन सेट थियो। मैले ग्राहकलाई यो नम्बर प्रयोग गर्न सुझाव दिएँ, र उनले जवाफ दिए कि प्रणालीले google.com सँग काम गर्यो, तर अझै अन्य डोमेनहरूमा त्रुटि दियो, त्यसैले मैले मेरो अनुसन्धान जारी राखें।

स्थापना गरेको छु ड्रपवाच, एउटा उपकरण जुन पहिले प्रयोग गरिनु पर्ने थियो: यसले कर्नेलमा प्याकेट कहाँ समाप्त हुन्छ भनेर देखाउँछ। अपराधी समारोह थियो udp_queue_rcv_skb। मैले कर्नेल स्रोतहरू डाउनलोड गरें र केही थपे कार्यहरू printk प्याकेट कहाँ समाप्त हुन्छ ट्र्याक गर्न। मैले चाँडै सही अवस्था फेला पारे if, र केहि समयको लागि यसलाई हेरेर बस्यो, किनभने यो तब थियो कि सबै कुरा अन्ततः पूरै चित्रमा सँगै आयो: 231-1, एक अर्थहीन संख्या, एक गैर-काम गर्ने डोमेन... यो कोडको एक टुक्रा थियो। __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

कृपया ध्यान दिनुहोस्:

• rmem int प्रकारको छ
• size u16 प्रकारको छ (अनहस्ताक्षरित सोह्र-बिट int) र प्याकेट साइज भण्डारण गर्दछ
• sk->sk_rcybuf int प्रकारको छ र बफर साइज भण्डार गर्दछ जुन, परिभाषा अनुसार, मान बराबर हुन्छ net.core.rmem_default

कहिले sk_rcvbuf 231 मा पुग्छ, प्याकेट साइज संक्षेपमा परिणाम हुन सक्छ पूर्णांक ओभरफ्लो। र यो एक int भएको हुनाले, यसको मान ऋणात्मक हुन्छ, त्यसैले स्थिति सत्य हुन्छ जब यो गलत हुनुपर्छ (तपाइँ यस बारे थप पढ्न सक्नुहुन्छ लिङ्क).

त्रुटिलाई मामूली तरिकामा सच्याउन सकिन्छ: कास्ट गरेर unsigned int। मैले फिक्स लागू गरें र प्रणाली पुन: सुरु गरें र DNS फेरि काम गरे।

विजयको स्वाद

मैले मेरा खोजहरू ग्राहकलाई फर्वार्ड गरें र पठाए LKML कर्नेल प्याच। म खुसी छु: पज्जलको प्रत्येक टुक्रा सँगै फिट हुन्छ, म ठ्याक्कै व्याख्या गर्न सक्छु किन हामीले हामीले के अवलोकन गर्यौं, र सबैभन्दा महत्त्वपूर्ण कुरा, हामी हाम्रो टोली कार्यको लागि धन्यवाद समस्याको समाधान खोज्न सक्षम भयौं!

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

स्रोत: www.habr.com