👩‍❤️‍👨 👎🏼 🍻 सिस्टम एडमिनिस्ट्रेशन में ब्लैक बॉक्स बनाम व्हाइट बॉक्स 👨🏿‍🔬 🌏 👨🏿‍🔬

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

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

अंतर को थोड़ा और दृश्य बनाने के लिए मैं जानबूझकर थोड़ा अतिशयोक्ति करूंगा।

ब्लैक बॉक्स प्रशासन

ब्लैक बॉक्स प्रशासन द्वारा (बटन और बल्ब के साथ एक काले रंग की अपारदर्शी कसकर बंद बॉक्स के साथ सादृश्य), मैं उस स्थिति को समझता हूं जब एक निश्चित प्रणाली होती है, इसके संचालन के निर्देश, कुछ चालें, प्रश्न और उत्तर Google में होते हैं। लेकिन सिस्टम कैसे काम करता है, इस बारे में कोई जानकारी नहीं है, हम नहीं जानते (या जानना नहीं चाहते हैं) इसके अंदर क्या है, यह कैसे काम करता है, अंदर क्या है और यह कैसे इंटरैक्ट करता है। हां, यह महत्वपूर्ण नहीं है: यदि इसे सामान्य परिस्थितियों में संचालित किया जाता है, तो हम यह जानते हैं कि इसका उपयोग कैसे किया जाए और क्या उम्मीद की जाए। आदेशों / कार्यों का एक सेट जो हमें आवश्यक परिणाम देता है, पहले से वर्णित है और इससे कोई फर्क नहीं पड़ता कि सिस्टम यह कैसे करता है, हम सिर्फ "आदेश" करते हैं और परिणाम प्राप्त करते हैं। या, यदि यह अनुमानित रूप से अग्रिम में वर्णित है (या टाइप करके पाया जाता है, अर्थात् अनुभव से), बल्ब के वांछित संयोजन को हल्का करने के लिए कौन सा बटन दबाया जाना चाहिए।

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

यदि कुछ गलत हो गया और सिस्टम ने काम करना बंद कर दिया जैसा कि उसे करना चाहिए, तो पहली बात यह है - ऑपरेटिंग शर्तों के साथ क्या गलत है, इसकी खोज करें, जो इस बात से अलग है कि यह कब काम किया था और इसे वापस कैसे लौटाया जाए, "सभी लाइट बंद कैसे करें" और सिस्टम वापस करें प्रारंभिक अवस्था में। यदि यह मदद नहीं करता है, तो विशेषज्ञों से Google "गुप्त बटन संयोजन" और वर्णित स्थिति के समान समानता के अवरोही क्रम में उन सभी को आज़माएं जब तक कि क़ीमती प्रकाश हमारे पास नहीं है या सिस्टम उस स्थिति में वापस आ जाता है जिसे हम जानते हैं। यदि यह मदद नहीं करता है - एक मृत अंत। या तो बैकअप के लिए रोलबैक, या समर्थन से संपर्क करना (यदि सिस्टम में एक है) या सिस्टम को बदलना (पुनः स्थापित करना)।

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

सफेद बॉक्स

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

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

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

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

समस्या का सार

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

हम दोनों विकल्पों पर विचार करेंगे (थोड़ा सरलीकृत , ताकि असंगत लेकिन समय लेने वाले विवरणों पर समय बर्बाद न करें) जीवन उदाहरण।

एक निश्चित साइट 8GB मेमोरी के साथ 2 8-कोर मशीनों पर चलती है। Apache2 + PHP + MySQL + memcache। चरम समय पर, सिस्टम समय-समय पर बहुत धीमा पड़ने लगा और साइट पर ही 10-30 सेकंड की देरी के साथ प्रतिक्रिया करने के लिए या बिल्कुल भी जवाब नहीं देने के लिए शुरू हुआ।

शुरू करने के लिए, समस्या को ब्लैक बॉक्स दृष्टिकोण के अनुसार माना गया था।

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

वास्तव में क्या हुआ और ऐसा क्यों हुआ - शेष अज्ञात, वास्तविक समस्या थी "साइट धीमी हो जाती है और खुलती नहीं है", समस्या हल हो गई है, साइट अब धीमा नहीं होती है। डायग्नोस्टिक्स - 3 मिनट, समाधान - एक और 5 मिनट। यानी 10 मिनट से भी कम समय में यह समस्या ठीक हो जाती है, इस समस्या के प्रकट होने के बारे में लगभग कुछ भी न जानने के कारण। कोई निश्चितता नहीं है कि यह लंबे समय तक मदद करेगा और यह एक सामान्य समाधान है, लेकिन (!) 10 मिनट और वास्तव में साइट लगभग छह महीने तक समस्याओं के बिना फिर से काम करती है ।

छह महीने बाद, अपाचे के प्रति घंटा पुनरारंभ के बावजूद समस्या फिर से दिखाई देने लगी। वे पुनः आरंभ अंतराल को कम करने के लिए शुरू हुए, शिकायतें दिखाई देने लगीं कि साइट से कनेक्शन कभी-कभी समाप्त हो जाता है, पृष्ठ लोड हो गया। यानी समस्या का बहुत ही हल नई समस्याएँ पैदा करने लगा।

आगे, एक ही प्रणाली को और अधिक विस्तार से माना जाने लगा। एक सफेद बॉक्स की तरह।

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

सर्वर के लिए अलग-अलग अनुरोध मेमोरी की एक बहुत अलग राशि लेते हैं, 200 मेगाबाइट तक खाने वाले अनुरोधों की एक छोटी संख्या होती है, लेकिन थोक 5-10 से अधिक नहीं खाता है। इसी समय, php मेमोरी को मुक्त करता है, लेकिन एक बच्चे के फ्रेमवर्क के भीतर अपाचे मुक्त मेमोरी नहीं है, इसे अपने पास रखता है, इसलिए यदि इसकी आवश्यकता है तो यह पहले से मौजूद है। नतीजतन, हम जल्द ही या बाद में हर बच्चे को कम से कम एक भारी अनुरोध प्राप्त करेंगे, जिसके परिणामस्वरूप अपाचे भविष्य के लिए मेमोरी को "सेव" करेगा और बाद के अधिकांश अनुरोधों की आवश्यकता होगी।
अपाचे "बच्चों" की संख्या काफी बड़ी 250 टुकड़े है, जो कि 200 एमबी तक, उनके सुचारू रूप से "फेटनिंग" के साथ, आसानी से, लेकिन अनिवार्य रूप से स्मृति खपत की तुलना में बहुत अधिक है जो सिस्टम में उपलब्ध है। सिस्टम स्वैप करना शुरू कर देता है, सब कुछ अधिक धीरे-धीरे काम करना शुरू कर देता है, अनुरोधों को अधिक धीरे-धीरे संसाधित किया जाता है, और वे उसी तरह से पहुंचते हैं, जो अधिक युगपत अनुरोधों की ओर जाता है, जो इस तथ्य की ओर जाता है कि सभी 250 अपाचे बच्चे सक्रिय रूप से शामिल हैं और अनुरोधों की एक कतार है, और साथ में वे सक्रिय रूप से "वसा प्राप्त करते हैं" और स्वैप करते हैं ।
इसके अलावा, इस बढ़ते स्नोबॉल को कुछ हद तक पृष्ठभूमि पर लगातार लटकाए जाने वाले लंबे-लंबे अनुरोधों द्वारा त्वरित किया गया और, परिणामस्वरूप, अतिरिक्त अपाचे बच्चों को व्यस्त रखा गया, जिसने "बहुत अधिक अप्रयुक्त बच्चों" के कारण अनावश्यक अपाचे प्रक्रियाओं को समाप्त नहीं होने दिया।

समाधान इस प्रकार था (परियोजना की बारीकियों को ध्यान में रखते हुए, जो यहां वर्णित नहीं है):

वे इनपुट पर nginx डालते हैं, यह अनुरोधों और कतार की संख्या से वसा प्राप्त नहीं करता है।
Url मैच के माध्यम से Nginx ने mod-fpm के साथ एक अलग अपाचे उदाहरण के लिए भारी अनुरोधों को अग्रेषित किया, जिससे रूट में "जाम" मेमोरी की समस्या समाप्त हो गई, जिससे अधिकतम 25 समानांतर प्रक्रियाएं और केवल 5 अतिरिक्त प्रक्रियाएं (अधिकतम स्पेयर चिल्ड) हो सकती हैं।
"लाइट" अनुरोध नियमित रूप से अपाचे में चला गया, जिसने "वसा प्राप्त करना" बंद कर दिया, लेकिन बस मामले में वे अभी भी बच्चे को अधिकतम 1000 अनुरोध करते हैं, ताकि, अगर अचानक कुछ हो, तो स्मृति समय-समय पर जारी की गई थी।
प्रोग्रामर के समर्थन से लंबे समय तक मतदान, एक सर्वर को एक छोटे नोड.जेएस सर्वर पर भेजा गया, जो प्रत्येक ग्राहक के लिए एक सेकंड में एक बार एक अपाचे अनुरोध करता है, पहले मेकचे में "ताज़ा डेटा" चेकबॉक्स और "स्केन कॉन" पर नज़र रखता था, अगर कुछ भी नया नहीं दिखाई देता। ये अनुरोध बहुत हल्के हैं, अपाचे के लिए वे अब लंबे समय से मतदान नहीं कर रहे हैं और केवल तब होते हैं जब वास्तव में नया डेटा होता है - ये अनुरोध माइक्रोसेकंड में उड़ते हैं और ध्यान देने योग्य भी नहीं हैं, व्यावहारिक रूप से अपाचे-चिल्ड पर कब्जा नहीं करते हैं।
इसके अलावा, (पिनबा के लिए धन्यवाद), स्क्रिप्ट खुद को भी थोड़ा सही कर दिया, उनमें से कुछ के बाद कम खाने और तेजी से काम करना शुरू कर दिया।

नतीजतन, भीड़ के घंटे में, 25-30 से अधिक हल्के एपाचे एक साथ काम नहीं करते हैं, mod_fpm के माध्यम से 5-10 भारी व्यक्तिगत php, नोड। जेएस थोड़ा चलता है, 2-5 से अधिक अपाचे प्रक्रियाओं को एक साथ उनके माइक्रो अनुरोधों पर कब्जा कर लेता है। यदि यह अचानक बनता है, तो निगनेक्स कतार आसानी से बिना तनाव के आयोजित की जाती है, जबकि प्रोसेसर लगभग उपभोग नहीं करता है, क्योंकि यह कुछ भी नहीं करता है, यह केवल प्रॉक्सी करता है और इसकी वास्तुकला के लिए धन्यवाद, कई सौ एक साथ सत्रों का समर्थन करता है, बिल्कुल कोई कठिनाई नहीं है। इसके अलावा, नगनेक्स बफ़र्स अपाचे प्रतिक्रियाएं देता है और धीरे-धीरे उन्हें क्लाइंट को स्वयं देता है, जो एपाचे को तेजी से अनुरोध से छुटकारा पाने की अनुमति देता है।

नतीजतन, "भीड़ के घंटे" पर सर्वर पर औसत लोड औसत 0.2-0.5 के आसपास चलता है। मेमोरी की खपत - सभी प्रक्रियाओं के लिए लगभग 2-3GB। बाकी मेमोरी कैश है। स्वैप का उपयोग नहीं किया जाता है। प्रतिक्रिया समय अब जल्दी घंटे में नहीं बदलता है और शांत समय में लगभग समान हो गया है (जब साइट पर केवल 2-3 ग्राहक हैं)।
ग्राहकों की संख्या जो साइट को लोड के बिना समस्याओं के बिना सेवा कर सकती है, लगभग 10 गुना बढ़ गई है (डेटाबेस के साथ आगे की कठिनाइयां पहले से ही शुरू हो जाती हैं)।

यही है, समस्या फिर से हल हो गई है, लेकिन इस बार एक बड़े अंतर के साथ और स्पष्ट रूप से समझें कि क्या गणना करना है और कब तक यह समस्याओं के बिना काम करेगा। सब कुछ उचित, विचारशील, संतुलित है। निर्णय का समय 2 सप्ताह है ...

परिणाम

"सबूतों के कप्तान" की उपाधि मिलने के जोखिम पर, मैं ऐसे "अलगाव" के परिणामों की ओर बढ़ता हूं:

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

एक कर्मचारी या नौकरी चुनते समय, इन कुछ बिंदुओं को याद रखें और शायद आप समय, धन और तंत्रिकाओं को बचाएंगे। इस विषय पर शायद यही है। इसे पढ़ने वालों का शुक्रिया। :)