शीर्ष fakapov सियान

सबैलाई राम्रो! 

मेरो नाम निकिता हो, म Cian ईन्जिनियरिङ् टोलीको टोली नेता हुँ। कम्पनीमा मेरो एक जिम्मेवारी भनेको उत्पादनमा पूर्वाधारसँग सम्बन्धित घटनाहरूको संख्यालाई शून्यमा घटाउनु हो।
तल छलफल गरिने कुराले हामीलाई धेरै पीडा ल्याएको छ, र यस लेखको उद्देश्य अरू मानिसहरूलाई हाम्रा गल्तीहरू दोहोर्याउन वा कम्तीमा उनीहरूको प्रभावलाई कम गर्नबाट रोक्नु हो। 

प्रस्तावना

धेरै समय पहिले, जब Cian मा मोनोलिथहरू थिए, र त्यहाँ माइक्रोसर्भिसेसहरूको कुनै संकेत थिएन, हामीले 3-5 पृष्ठहरू जाँच गरेर स्रोतको उपलब्धता मापन गर्यौं। 

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

साइटको मुख्य पृष्ठहरू वा हामीले कसरी बुझ्छौं कि हामीले तल हिर्कायौं

 
त्रुटिको प्राथमिकतालाई कुनै न कुनै रूपमा बुझ्नको लागि, हामीले व्यापार कार्यक्षमताका लागि सबैभन्दा महत्त्वपूर्ण साइट पृष्ठहरू पहिचान गरेका छौं। तिनीहरूलाई प्रयोग गरेर, हामी सफल/असफल अनुरोधहरू र टाइमआउटहरूको संख्या गणना गर्छौं। यसरी हामी अपटाइम मापन गर्छौं। 

मानौं हामीले पत्ता लगायौं कि साइटको धेरै महत्त्वपूर्ण खण्डहरू छन् जुन मुख्य सेवाका लागि जिम्मेवार छन् - विज्ञापनहरू खोजी र पेश गर्ने। यदि असफल अनुरोधहरूको संख्या 1% भन्दा बढी छ भने, यो एक महत्वपूर्ण घटना हो। यदि प्राइम टाइमको समयमा 15 मिनेट भित्र त्रुटि दर 0,1% नाघ्यो भने, यो पनि एक महत्वपूर्ण घटना मानिन्छ। यी मापदण्डहरूले अधिकांश घटनाहरूलाई समेट्छन्; बाँकीहरू यस लेखको दायराभन्दा बाहिर छन्।

शीर्ष सर्वश्रेष्ठ घटनाहरू सियान

त्यसोभए, हामीले घटना घटेको तथ्य निर्धारण गर्न निश्चित रूपमा सिकेका छौं। 

अब हरेक घटनालाई जिरा महाकाव्यमा विस्तृत रूपमा वर्णन गरिएको छ। वैसे: यसका लागि हामीले एउटा छुट्टै परियोजना सुरु गर्यौं, जसलाई FAIL भनिन्छ - यसमा केवल महाकाव्यहरू सिर्जना गर्न सकिन्छ। 

यदि तपाइँ विगत केही वर्षहरूमा सबै असफलताहरू सङ्कलन गर्नुहुन्छ भने, नेताहरू हुन्: 

• mssql सम्बन्धित घटनाहरू;
• बाह्य कारकहरू द्वारा उत्पन्न घटनाहरू;
• प्रशासक त्रुटिहरू।

प्रशासकहरूको गल्तीहरू, साथै केही अन्य रोचक विफलताहरूमा थप विस्तारमा हेरौं।

पाँचौं स्थान - "डीएनएसमा चीजहरू क्रमबद्ध गर्दै"

मंगलबार आँधीबेहरी थियो। हामीले DNS क्लस्टरमा अर्डर पुनर्स्थापना गर्ने निर्णय गर्यौं। 

म आन्तरिक DNS सर्भरहरू bind बाट powerdns मा स्थानान्तरण गर्न चाहन्छु, यसको लागि पूर्ण रूपमा अलग सर्भरहरू आवंटित गर्दै, जहाँ DNS बाहेक केही छैन। 

हामीले हाम्रो DCs को प्रत्येक स्थानमा एउटा DNS सर्भर राख्यौं, र समय आएको छ जोनहरू बाँईडबाट पावरडन्समा सार्ने र पूर्वाधारलाई नयाँ सर्भरहरूमा स्विच गर्ने। 

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

निष्कर्ष:

यदि पहिले हामीले कामको तयारीको क्रममा बाह्य कारकहरूलाई बेवास्ता गर्यौं भने, अब तिनीहरू पनि हामीले तयारीको सूचीमा समावेश गरेका छन्। र अब हामी सबै घटकहरू n-2 आरक्षित छन् भनेर सुनिश्चित गर्न प्रयास गर्छौं, र कामको क्रममा हामी यो स्तरलाई n-1 मा कम गर्न सक्छौं।

• कार्य योजना बनाउँदा, सेवा असफल हुन सक्ने बिन्दुहरूलाई चिन्ह लगाउनुहोस्, र सबै कुरा "खराबबाट नराम्रोमा" पहिले नै गएको परिदृश्य मार्फत सोच्नुहोस्।
• विभिन्न भौगोलिक स्थानहरू/डेटा केन्द्रहरू/र्याकहरू/स्विचहरू/इनपुटहरूमा आन्तरिक DNS सर्भरहरू वितरण गर्नुहोस्।
• प्रत्येक सर्भरमा, स्थानीय क्यासिङ DNS सर्भर स्थापना गर्नुहोस्, जसले अनुरोधहरूलाई मुख्य DNS सर्भरहरूमा रिडिरेक्ट गर्छ, र यदि यो उपलब्ध छैन भने, यसले क्यासबाट प्रतिक्रिया दिनेछ। 

चौथो स्थान - "Nginx मा चीजहरू सफा गर्दै"

एक राम्रो दिन, हाम्रो टोलीले निर्णय गर्‍यो कि "हामीसँग यो पर्याप्त छ," र nginx कन्फिगहरू रिफ्याक्टर गर्ने प्रक्रिया सुरु भयो। मुख्य लक्ष्य एक सहज संरचनामा कन्फिगहरू ल्याउनु हो। पहिले, सबै कुरा "ऐतिहासिक रूपमा स्थापित" थियो र कुनै तर्क बोक्दैन। अब प्रत्येक सर्भर_नाम एउटै नामको फाइलमा सारिएको छ र सबै कन्फिगहरू फोल्डरहरूमा वितरण गरिएको छ। वैसे, कन्फिगरेसनले 253949 रेखाहरू वा 7836520 क्यारेक्टरहरू समावेश गर्दछ र लगभग 7 मेगाबाइटहरू लिन्छ। संरचना को शीर्ष स्तर: 

Nginx संरचना

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

यो धेरै राम्रो भयो, तर कन्फिगहरू पुन: नामाकरण र वितरण गर्ने प्रक्रियामा, तिनीहरूमध्ये केहीको गलत विस्तार थियो र समावेश *.conf निर्देशनमा समावेश गरिएको थिएन। नतिजाको रूपमा, केही होस्टहरू अनुपलब्ध भए र मुख्य पृष्ठमा 301 फर्किए। प्रतिक्रिया कोड 5xx/4xx थिएन भन्ने तथ्यको कारण, यो तुरुन्तै याद गरिएको थिएन, तर बिहान मात्र। त्यस पछि, हामीले पूर्वाधार घटकहरू जाँच गर्न परीक्षणहरू लेख्न थाल्यौं।

निष्कर्ष: 

• तपाईंको कन्फिगहरू सही रूपमा संरचना गर्नुहोस् (नजिनक्स मात्र होइन) र परियोजनाको प्रारम्भिक चरणमा संरचना मार्फत सोच्नुहोस्। यस तरिकाले तपाईंले तिनीहरूलाई टोलीका लागि अझ बुझ्ने बनाउनुहुनेछ, जसले TTM कम गर्नेछ।
• केही पूर्वाधार घटकहरूको लागि परीक्षणहरू लेख्नुहोस्। उदाहरणका लागि: जाँच गर्दै कि सबै कुञ्जी सर्भर_नामहरूले सही स्थिति + प्रतिक्रिया शरीर दिन्छ। कम्पोनेन्टको आधारभूत प्रकार्यहरू जाँच गर्ने हातमा केही स्क्रिप्टहरू हुनु पर्याप्त हुनेछ, ताकि बिहान 3 बजे अन्य के जाँच गर्न आवश्यक छ भनी याद नगर्नुहोस्। 

तेस्रो स्थान - "कसान्ड्रामा अचानक ठाउँ सकियो"

डाटा स्थिर रूपमा बढ्दै गयो, र ठूला केसस्पेसहरूको मर्मत क्यासान्ड्रा क्लस्टरमा असफल हुन थालेको क्षण सम्म सबै ठीक थियो, किनकि कम्प्याक्शनले उनीहरूमा काम गर्न सकेन। 

एक तूफानी दिन क्लस्टर लगभग कद्दूमा परिणत भयो, अर्थात्:

• त्यहाँ क्लस्टरमा बाँकी कुल ठाउँको लगभग 20% थियो;
• नोडहरू पूर्ण रूपमा थप्न असम्भव छ, किनभने विभाजनहरूमा खाली ठाउँको कमीको कारणले नोड थपेपछि सफा गर्न सकिँदैन;
• कम्प्याक्सनले काम नगर्दा उत्पादकता बिस्तारै घट्दै जान्छ; 
• क्लस्टर आपतकालीन मोडमा छ।

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

निष्कर्ष:

• सबै क्यासान्ड्रा सर्भरहरूमा, प्रत्येक विभाजनमा 60% भन्दा बढी ठाउँ ओगट्नु हुँदैन। 
• तिनीहरू 50% cpu भन्दा बढीमा लोड हुनुपर्छ।
• तपाईंले क्षमता योजनाको बारेमा बिर्सनु हुँदैन र यसको विवरणहरूमा आधारित प्रत्येक घटकको लागि यसलाई सोच्न आवश्यक छ।
• क्लस्टरमा धेरै नोडहरू, राम्रो। थोरै मात्रामा डाटा समावेश गर्ने सर्भरहरू छिटो ओभरलोड हुन्छन्, र यस्तो क्लस्टर पुनरुत्थान गर्न सजिलो हुन्छ। 

दोस्रो स्थान - "डाटा कन्सुल कुञ्जी-मान भण्डारणबाट गायब भयो"

सेवा खोजको लागि, हामी, धेरै जस्तै, कन्सुल प्रयोग गर्दछौं। तर हामी मोनोलिथको नीलो-हरियो लेआउटको लागि यसको मुख्य-मान पनि प्रयोग गर्छौं। यसले सक्रिय र निष्क्रिय अपस्ट्रिमहरूको बारेमा जानकारी भण्डारण गर्दछ, जसले तैनातीको समयमा ठाउँहरू परिवर्तन गर्दछ। यस उद्देश्यको लागि, एक तैनाती सेवा लेखिएको थियो जसले KV सँग अन्तरक्रिया गर्यो। केहि बिन्दुमा, KV बाट डाटा गायब भयो। मेमोरीबाट पुनर्स्थापित गरियो, तर धेरै त्रुटिहरूको साथ। नतिजाको रूपमा, अपलोडको क्रममा, अपस्ट्रिमहरूमा लोड असमान रूपमा वितरण गरिएको थियो, र हामीले धेरै 502 त्रुटिहरू प्राप्त गर्यौं किनभने ब्याकइन्डहरू CPU मा ओभरलोड भएको थियो। नतिजाको रूपमा, हामी कन्सुल KV बाट postgres मा सारियो, जहाँबाट तिनीहरूलाई हटाउन त्यति सजिलो छैन।  

निष्कर्ष:

• कुनै पनि प्राधिकरण बिना सेवाहरूले साइटको सञ्चालनको लागि महत्वपूर्ण डेटा समावेश गर्नु हुँदैन। उदाहरणका लागि, यदि तपाईंसँग ES मा प्राधिकरण छैन भने, यो आवश्यक नभएको सबै ठाउँबाट नेटवर्क स्तरमा पहुँच अस्वीकार गर्नु राम्रो हुन्छ, आवश्यक मात्र छोड्नुहोस्, र action.destructive_requires_name: true पनि सेट गर्नुहोस्।
• अग्रिम आफ्नो ब्याकअप र रिकभरी संयन्त्र अभ्यास गर्नुहोस्। उदाहरणका लागि, पहिले नै स्क्रिप्ट बनाउनुहोस् (उदाहरणका लागि, पाइथनमा) जसले ब्याकअप र रिस्टोर गर्न सक्छ।

पहिलो स्थान - "कप्तान अस्पष्ट" 

केहि बिन्दुमा, हामीले ब्याकइन्डमा 10+ सर्भरहरू भएको अवस्थामा nginx अपस्ट्रिमहरूमा लोडको असमान वितरण देख्यौं। राउन्ड-रोबिनले 1st देखि अन्तिम अपस्ट्रिममा क्रमबद्ध रूपमा अनुरोधहरू पठाएको र प्रत्येक nginx पुन: लोड सुरु भएको तथ्यका कारण, पहिलो अपस्ट्रिमहरूले सधैं बाँकी भन्दा बढी अनुरोधहरू प्राप्त गरे। परिणाम स्वरूप, तिनीहरूले ढिलो काम गरे र सम्पूर्ण साइटले क्षति बेहोर्नुपर्यो। ट्राफिकको संख्या बढ्दै जाँदा यो झन्झटिलो देखिन थाल्यो। अनियमित सक्षम गर्नको लागि केवल nginx अद्यावधिक गर्दा काम भएन - हामीले संस्करण 1.15 (त्यस समयमा) मा टेक अफ नभएको लुआ कोडको गुच्छा पुन: गर्न आवश्यक छ। हामीले हाम्रो nginx 1.14.2 प्याच गर्नुपर्‍यो, यसमा अनियमित समर्थनको परिचय दिँदै। यसले समस्या समाधान गर्यो। यो बग "कप्तान गैर-स्पष्टता" श्रेणी जित्छ।

निष्कर्ष:

यो बग अन्वेषण गर्न धेरै रोचक र रोमाञ्चक थियो)। 

• आफ्नो निगरानी व्यवस्थित गर्नुहोस् ताकि यसले तपाईंलाई त्यस्ता उतार चढावहरू छिट्टै फेला पार्न मद्दत गर्दछ। उदाहरणका लागि, तपाईंले ELK प्रयोग गर्न सक्नुहुन्छ प्रत्येक अपस्ट्रीमको प्रत्येक ब्याकइन्डमा rps निगरानी गर्न, nginx को दृष्टिकोणबाट तिनीहरूको प्रतिक्रिया समय निगरानी गर्नुहोस्। यस अवस्थामा, यसले हामीलाई समस्या पहिचान गर्न मद्दत गर्‍यो। 

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

स्रोत: www.habr.com