शीर्ष fakapov निळसर

सर्वांना चांगले! 

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

प्रस्तावना

खूप पूर्वी, जेव्हा Cian मध्ये मोनोलिथ्सचा समावेश होता, आणि अद्याप मायक्रोसर्व्हिसेसचे कोणतेही संकेत नव्हते, तेव्हा आम्ही 3-5 पृष्ठे तपासून संसाधनाची उपलब्धता मोजली. 

ते उत्तर देतात - सर्वकाही ठीक आहे, जर त्यांनी बराच वेळ उत्तर दिले नाही तर - सावधान. त्यांना किती दिवस कामावर राहावे लागेल, ही घटना मानली जावी, हे लोक सभांमध्ये ठरवत. या घटनेच्या तपासात अभियंत्यांचे पथक नेहमीच गुंतले होते. तपास पूर्ण झाल्यावर, त्यांनी पोस्टमॉर्टम लिहिले - एक प्रकारचा अहवाल ईमेलद्वारे स्वरूपात: काय झाले, ते किती काळ टिकले, आम्ही क्षणात काय केले, भविष्यात आम्ही काय करू. 

साइटची मुख्य पृष्ठे किंवा आम्ही कसे समजतो की आम्ही तळाशी मारले आहे

 
त्रुटीचे प्राधान्य कसे तरी समजून घेण्यासाठी, आम्ही व्यवसाय कार्यक्षमतेसाठी सर्वात गंभीर साइट पृष्ठे ओळखली आहेत. त्यांचा वापर करून, आम्ही यशस्वी/अयशस्वी विनंत्या आणि कालबाह्यांची संख्या मोजतो. अशा प्रकारे आम्ही अपटाइम मोजतो. 

चला असे म्हणूया की आम्हाला आढळले की साइटचे अनेक अति-महत्त्वाचे विभाग आहेत जे मुख्य सेवेसाठी जबाबदार आहेत - जाहिराती शोधणे आणि सबमिट करणे. अयशस्वी झालेल्या विनंत्यांची संख्या 1% पेक्षा जास्त असल्यास, ही एक गंभीर घटना आहे. प्राइम टाइम दरम्यान 15 मिनिटांच्या आत त्रुटी दर 0,1% पेक्षा जास्त असल्यास, ही देखील एक गंभीर घटना मानली जाते. हे निकष बहुतेक घटनांचा समावेश करतात; बाकीच्या या लेखाच्या व्याप्तीच्या बाहेर आहेत.

शीर्ष सर्वोत्तम घटना निळसर

त्यामुळे एखादी घटना घडली हे निश्चितपणे ठरवायला शिकलो आहोत. 

आता प्रत्येक घटनेचे तपशीलवार वर्णन केले आहे आणि जिरा महाकाव्यात प्रतिबिंबित केले आहे. तसे: यासाठी आम्ही एक वेगळा प्रकल्प सुरू केला, त्याला FAIL म्हणतात - त्यात केवळ महाकाव्ये तयार केली जाऊ शकतात. 

आपण गेल्या काही वर्षांतील सर्व अपयश एकत्रित केल्यास, नेते आहेत: 

• mssql संबंधित घटना;
• बाह्य घटकांमुळे झालेल्या घटना;
• प्रशासकीय त्रुटी.

प्रशासकांच्या चुका तसेच इतर काही मनोरंजक अपयशांबद्दल अधिक तपशीलवार पाहू या.

पाचवे स्थान - "DNS मध्ये गोष्टी व्यवस्थित ठेवणे"

तो मंगळवार वादळी होता. आम्ही DNS क्लस्टरमध्ये सुव्यवस्था पुनर्संचयित करण्याचा निर्णय घेतला. 

मला अंतर्गत डीएनएस सर्व्हर बाइंडवरून पॉवरडीएनएसवर हस्तांतरित करायचे होते, यासाठी पूर्णपणे स्वतंत्र सर्व्हर वाटप करून, जेथे डीएनएसशिवाय काहीही नाही. 

आम्ही आमच्या DCs च्या प्रत्येक स्थानावर एक DNS सर्व्हर ठेवला, आणि झोनला बाइंडवरून पॉवरडीएनएसवर हलवण्याचा आणि पायाभूत सुविधा नवीन सर्व्हरवर स्विच करण्याचा क्षण आला. 

हलविण्याच्या दरम्यान, सर्व सर्व्हरवर स्थानिक कॅशिंग बाइंडमध्ये निर्दिष्ट केलेल्या सर्व सर्व्हरपैकी, फक्त एकच राहिला, जो सेंट पीटर्सबर्गमधील डेटा सेंटरमध्ये होता. हा DC सुरुवातीला आमच्यासाठी नॉन-क्रिटिकल म्हणून घोषित करण्यात आला होता, परंतु अचानक अपयशाचा एकच मुद्दा बनला.
स्थलांतराच्या या काळातच मॉस्को आणि सेंट पीटर्सबर्ग दरम्यानचा कालवा खाली पडला. आम्हाला प्रत्यक्षात पाच मिनिटे DNS शिवाय सोडण्यात आले आणि जेव्हा होस्टने समस्या सोडवली तेव्हा आम्ही परत आलो. 

निष्कर्ष:

पूर्वी जर आपण कामाच्या तयारीच्या वेळी बाह्य घटकांकडे दुर्लक्ष केले असेल, तर आता आपण ज्यासाठी तयारी करत आहोत त्या यादीमध्ये ते देखील समाविष्ट केले आहेत. आणि आता आम्ही हे सुनिश्चित करण्याचा प्रयत्न करतो की सर्व घटक n-2 राखीव आहेत आणि कामाच्या दरम्यान आम्ही ही पातळी n-1 पर्यंत कमी करू शकतो.

• कृती आराखडा तयार करताना, जेथे सेवा अयशस्वी होऊ शकते ते बिंदू चिन्हांकित करा आणि सर्व काही "वाईट ते वाईट" अगोदरच घडत असलेल्या परिस्थितीचा विचार करा.
• अंतर्गत DNS सर्व्हर विविध भौगोलिक स्थाने/डेटा केंद्रे/रॅक/स्विच/इनपुटवर वितरित करा.
• प्रत्येक सर्व्हरवर, स्थानिक कॅशिंग DNS सर्व्हर स्थापित करा, जो मुख्य DNS सर्व्हरवर विनंत्या पुनर्निर्देशित करतो आणि तो अनुपलब्ध असल्यास, तो कॅशेमधून प्रतिसाद देईल. 

चौथे स्थान - "नगिनक्समध्ये गोष्टी व्यवस्थित ठेवणे"

एका चांगल्या दिवशी, आमच्या कार्यसंघाने ठरवले की "आमच्याकडे हे पुरेसे आहे," आणि 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 नसल्यामुळे, हे लगेच लक्षात आले नाही, परंतु फक्त सकाळीच. त्यानंतर, आम्ही पायाभूत सुविधांचे घटक तपासण्यासाठी चाचण्या लिहिण्यास सुरुवात केली.

निष्कर्ष: 

• तुमच्या कॉन्फिगची योग्य रचना करा (फक्त nginx नाही) आणि प्रकल्पाच्या सुरुवातीच्या टप्प्यावर संरचनेचा विचार करा. अशा प्रकारे तुम्ही त्यांना संघासाठी अधिक समजण्यायोग्य बनवाल, ज्यामुळे TTM कमी होईल.
• काही पायाभूत घटकांसाठी चाचण्या लिहा. उदाहरणार्थ: सर्व की सर्व्हर_नावे योग्य स्थिती + प्रतिसाद मुख्य भाग देतात हे तपासणे. घटकाची मूलभूत कार्ये तपासणार्‍या काही स्क्रिप्ट्स हातात असणे पुरेसे आहे, जेणेकरुन पहाटे 3 वाजता आणखी काय तपासण्याची आवश्यकता आहे हे वेडसरपणे लक्षात येऊ नये. 

तिसरे स्थान - "कॅसांड्रामध्ये अचानक जागा संपली"

डेटा हळूहळू वाढला आणि कॅसॅंड्रा क्लस्टरमध्ये मोठ्या केसस्पेसची दुरुस्ती अयशस्वी होण्यापर्यंत सर्व काही ठीक होते, कारण कॉम्पॅक्शन त्यांच्यावर कार्य करू शकत नाही. 

एका वादळी दिवशी क्लस्टर जवळजवळ भोपळ्यात बदलले, म्हणजे:

• क्लस्टरमध्ये एकूण जागेपैकी सुमारे 20% जागा शिल्लक होती;
• नोड्स पूर्णपणे जोडणे अशक्य आहे, कारण विभाजनांवर जागेच्या कमतरतेमुळे नोड जोडल्यानंतर साफसफाई होत नाही;
• उत्पादकता हळूहळू कमी होत आहे कारण कॉम्पॅक्शन कार्य करत नाही; 
• क्लस्टर आपत्कालीन मोडमध्ये आहे.

बाहेर पडा - आम्ही साफ न करता आणखी 5 नोड जोडले, त्यानंतर आम्ही त्यांना क्लस्टरमधून पद्धतशीरपणे काढून टाकण्यास सुरुवात केली आणि रिक्त नोड्स प्रमाणे त्यांना पुन्हा एंटर करण्यास सुरुवात केली, जसे की जागा संपली होती. आमच्या इच्छेपेक्षा कितीतरी जास्त वेळ गेला. क्लस्टरच्या आंशिक किंवा पूर्ण अनुपलब्धतेचा धोका होता. 

निष्कर्ष:

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

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

सेवा शोधासाठी, आम्ही, अनेकांप्रमाणे, सल्लागार वापरतो. परंतु आम्ही मोनोलिथच्या निळ्या-हिरव्या लेआउटसाठी त्याचे की-व्हॅल्यू देखील वापरतो. हे सक्रिय आणि निष्क्रिय अपस्ट्रीमबद्दल माहिती संग्रहित करते, जे तैनाती दरम्यान ठिकाणे बदलतात. या उद्देशासाठी, केव्हीशी संवाद साधणारी उपयोजन सेवा लिहिली गेली. काही क्षणी, KV मधील डेटा गायब झाला. मेमरीमधून पुनर्संचयित केले, परंतु बर्याच त्रुटींसह. परिणामी, अपलोड दरम्यान, अपस्ट्रीमवरील भार असमानपणे वितरीत केला गेला आणि CPU वर बॅकएंड ओव्हरलोड झाल्यामुळे आम्हाला अनेक 502 त्रुटी मिळाल्या. परिणामी, आम्ही कॉन्सुल केव्ही वरून पोस्टग्रेसवर गेलो, जिथून त्यांना काढणे आता इतके सोपे नाही.  

निष्कर्ष:

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

प्रथम स्थान - "कॅप्टन अनोब्वियस" 

काही ठिकाणी, बॅकएंडमध्ये 10+ सर्व्हर असणा-या प्रकरणांमध्ये nginx अपस्ट्रीमवर लोडचे असमान वितरण आमच्या लक्षात आले. राऊंड-रॉबिनने क्रमाने 1 पासून शेवटच्या अपस्ट्रीमपर्यंत विनंत्या पाठवल्या आणि प्रत्येक nginx रीलोड सुरू झाल्यामुळे, पहिल्या अपस्ट्रीमला नेहमी बाकीच्यांपेक्षा जास्त विनंत्या मिळाल्या. परिणामी, त्यांनी हळू काम केले आणि संपूर्ण साइटला त्याचा फटका बसला. वाहतुकीचे प्रमाण वाढल्याने ही बाब अधिकच लक्षात येऊ लागली. यादृच्छिक सक्षम करण्यासाठी फक्त nginx अद्यतनित करणे कार्य करत नाही - आम्हाला लुआ कोडचा एक समूह पुन्हा करणे आवश्यक आहे जे आवृत्ती 1.15 (त्या क्षणी) वर टेक ऑफ झाले नाही. आम्हाला आमचे nginx 1.14.2 पॅच करावे लागले, त्यात यादृच्छिक समर्थन सादर केले. यामुळे समस्या सुटली. हा बग "कॅप्टन नॉन-ऑब्वियसनेस" श्रेणी जिंकतो.

निष्कर्ष:

हा बग एक्सप्लोर करणे खूप मनोरंजक आणि रोमांचक होते). 

• तुमचे निरीक्षण व्यवस्थापित करा जेणेकरून ते तुम्हाला असे चढउतार पटकन शोधण्यात मदत करेल. उदाहरणार्थ, आपण प्रत्येक अपस्ट्रीमच्या प्रत्येक बॅकएंडवर आरपीएसचे निरीक्षण करण्यासाठी ELK वापरू शकता, nginx च्या दृष्टिकोनातून त्यांच्या प्रतिसाद वेळेचे निरीक्षण करू शकता. या प्रकरणात, यामुळे आम्हाला समस्या ओळखण्यात मदत झाली. 

परिणामी, तुम्ही जे करत आहात त्याबद्दल अधिक नीट विचार करून बहुतेक अपयश टाळता आले असते. मर्फीचा नियम आपण नेहमी लक्षात ठेवला पाहिजे: जे काही चुकीचे होऊ शकते ते चुकीचे होईल, आणि त्यावर आधारित घटक तयार करा. 

स्त्रोत: www.habr.com