🧗 🌥️ 👵🏿 शीर्ष फकापोव सियान 🛌🏿 👞 🥜

सभी को अच्छा!

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

प्रस्तावना

एक बार, जब सियान में मोनोलिथ्स शामिल थे, और अभी तक माइक्रोसेवा के कोई संकेत नहीं थे, हमने 3-5 पृष्ठों की जांच करके संसाधन की उपलब्धता को मापा।

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

साइट के मुख्य पृष्ठ, या जैसा कि हम इसे समझते हैं, नीचे से टूट गया है

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

मान लीजिए कि हमें पता चला है कि साइट के कई महत्वपूर्ण खंड हैं जो मुख्य सेवा के लिए जिम्मेदार हैं - घोषणाओं की खोज और प्रस्तुत करना। यदि अनुरोधों की संख्या 1% से अधिक है, तो यह एक महत्वपूर्ण घटना है। यदि प्राइम टाइम में 15 मिनट के भीतर त्रुटियों का प्रतिशत 0.1% से अधिक हो जाता है, तो इसे एक महत्वपूर्ण घटना भी माना जाता है। ये मानदंड अधिकांश घटनाओं को कवर करते हैं, बाकी इस लेख के दायरे से परे हैं।

शीर्ष सबसे अच्छी सियान घटनाएं

इसलिए, हमने वास्तव में इस तथ्य को निर्धारित करना सीख लिया कि यह घटना कैसे हुई।

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

यदि आप पिछले कुछ वर्षों में सभी विफलताओं को इकट्ठा करते हैं, तो नेता हैं:

mssql संबंधित घटनाएं;
बाहरी कारकों के कारण होने वाली घटनाएं;
व्यवस्थापक त्रुटियों।

आइए हम प्रवेश की गलतियों पर अधिक विस्तार से ध्यान दें, साथ ही कुछ अन्य दिलचस्प विफलताओं पर भी।

पांचवा स्थान - "DNS में ऑर्डर देना"

मंगलवार को बारिश हुई थी। हमने डीएनएस क्लस्टर को साफ करने का फैसला किया।

मैं आंतरिक डीएनएस सर्वर को बाइंड से पावरडंस में स्थानांतरित करना चाहता था, इसके लिए पूरी तरह से अलग सर्वर को उजागर करता था, जहां डीएनएस के अलावा कुछ भी नहीं है।

हमने अपने डीसी के प्रत्येक स्थान में एक डीएनएस सर्वर रखा, और पल को बाइंड से बिजलीघरों में स्थानांतरित करने और बुनियादी ढांचे को नए सर्वर पर स्विच करने के लिए आया।

इस कदम की ऊंचाई पर, सभी सर्वरों पर स्थानीय कैशिंग बाइंड में संकेत दिए गए थे, केवल एक ही था जो सेंट पीटर्सबर्ग में डेटा सेंटर में था। इस डीसी को शुरू में हमारे लिए अस्वाभाविक घोषित किया गया था, लेकिन अचानक विफलता का एक बिंदु बन गया।
स्थानांतरण के ऐसे दौर में, मॉस्को और सेंट पीटर्सबर्ग के बीच चैनल गिर गया। हम वास्तव में DNS के बिना पांच मिनट तक बने रहे और तब उठे जब हॉस्टल ने समस्याएं तय कीं।

निष्कर्ष:

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

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

चौथा स्थान - "नेग्नेक्स की सफाई"

एक दिन ठीक है, हमारी टीम ने फैसला किया कि "इसे सहन करने के लिए पर्याप्त" है, और नग्नेक्स को फिर से शुरू करने की प्रक्रिया शुरू हो गई है। एक सहज संरचना में विन्यास लाना मुख्य लक्ष्य है। पहले, सब कुछ "ऐतिहासिक रूप से स्थापित" था और अपने आप में कोई तर्क नहीं था। अब प्रत्येक server_name को उसी नाम की फ़ाइल से निकाल दिया गया है और सभी कॉन्फिगर्स को फ़ोल्डरों में वितरित कर दिया है। वैसे, कॉन्फ़िगरेशन में 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% सीपीयू से अधिक नहीं लोड किया जाना चाहिए।
क्षमता की योजना के बारे में नहीं सोचें और प्रत्येक घटक के लिए इसके बारीकियों के आधार पर सोचें।
क्लस्टर में अधिक नोड्स, बेहतर। थोड़ी मात्रा में डेटा रखने वाले सर्वर तेजी से माइग्रेट होते हैं, और इस तरह के क्लस्टर को फिर से स्थापित करना आसान होता है।

दूसरा स्थान - "कांसुल की-वैल्यू स्टोरेज से डेटा गायब हो गया है"

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

जाँच - परिणाम:

- . , ES — , , , action.destructive_requires_name: true.
. , ( , python), .

— « »

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

निष्कर्ष:

इस बग की जांच करना बहुत दिलचस्प और रोमांचक था)।

निगरानी स्थापित करें ताकि यह जल्दी से इस तरह के उतार-चढ़ाव को खोजने में मदद करे। उदाहरण के लिए, आप प्रत्येक अपस्ट्रीम के प्रत्येक बैकेंड पर रैप्स की निगरानी करने के लिए ELK का उपयोग कर सकते हैं, और नगनेक्स के दृष्टिकोण से उनकी प्रतिक्रिया समय की निगरानी कर सकते हैं। इस मामले में, इसने समस्या को पहचानने में हमारी मदद की।

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

शीर्ष फकापोव सियान