बहुत समय पहले एक आकाशगंगा में दूर, एक कंपनी थी जो एक स्टार्टअप से कुछ ज्यादा बड़ी हो गई थी, लेकिन थोड़ी देर के लिए आईटी विभाग अभी भी कॉम्पैक्ट और बहुत कुशल था। उस कंपनी ने सैकड़ों वर्चुअल विंडोज सर्वरों को होस्ट
किया और निश्चित रूप से इन सर्वरों पर नजर रखी गई। इससे पहले कि मैं कंपनी में शामिल होता, नेटआईक्यू को एक निगरानी समाधान के रूप में चुना गया था।
मेरा एक नया काम नेटआईक्यू का समर्थन करना था। वह व्यक्ति, जिसने पहले NetIQ के साथ काम किया था, ने NetIQ के साथ अपने अनुभव के बारे में बहुत कुछ कहा, दुर्भाग्य से, अगर मैं इसे यहाँ रखने की कोशिश करता हूँ तो यह '****' वर्णों की एक लंबी कतार होगी। जल्द ही मुझे एहसास हुआ कि क्यों। स्टीव जॉब्स संभवत: अपनी कब्र में इस तरह से इंटरफ़ेस देख रहे हैं:
एक पंक्ति में चेकबॉक्स का तर्क सकारात्मक है (
ईवेंट को बढ़ाएं ), अगले एक में नकारात्मक है (
ईवेंट को न बढ़ाएं )। तो '
ईवेंट केवल i f' कैसे काम करता है? मुझे कोई पता नहीं है।
हालांकि, नेटआईक्यू के बारे में बहुत खराब बात थी: यह निगरानी एजेंट बहुत नाजुक था। विंडोज की तुलना में बहुत अधिक असुरक्षित है। कम स्मृति? एजेंट नीचे है। CPU 100% है? एजेंट गैर जिम्मेदार है। 0 मुफ्त बाइट्स डिस्क ड्राइव पर छोड़ दिया? खैर, अलर्ट संदेश भेजने के लिए एक एजेंट को पहले इसे एक डिस्क पर एक फ़ाइल में सहेजना होगा ... तो हाँ, आपको उस मामले में कोई अलर्ट नहीं मिलता है।
हालाँकि, "जो नहीं टूटा है उसे ठीक न करें", और किसी तरह, हम इसके साथ रहते थे जब तक कि हमारी कंपनी एक बहुत बड़ी खरीद नहीं हुई थी। जब एक विशाल कंपनी एक छोटा खरीदती है, तो छोटा एक समुद्र में पानी की छोटी बूंद के रूप में फैलता है। हालाँकि, हमारे मामले में हम (आईटी के नजरिए से) एक बड़ी कंपनी के आईटी से बहुत छोटे नहीं थे, और यह शुरुआत से ही स्पष्ट था कि विलय बहुत मुश्किल होगा। इतना मुश्किल है कि थोड़ी देर के लिए हम एक स्वतंत्र विभाग के रूप में अकेले रह गए और सभी व्यवसाय और आईटी प्रक्रियाओं को एक ही रखा गया - बस नए नाम की छतरी के नीचे। यह मुझे उस पल के बारे में याद दिलाता है, जब
द रिंग लावा पर
बिछ रहा था लेकिन अभी तक पिघलना शुरू नहीं हुआ है।
इस बीच, मैंने नेटआईक्यू को संस्करण 7 से 8 तक, और बाद में संस्करण 9 में अपग्रेड किया था। यह तब था जब हमारी सभी समस्याएं शुरू हुईं। हम नेटआईक्यू का उपयोग केवल कुछ बुनियादी चीजों की निगरानी के लिए कर रहे थे: सर्वर की उपलब्धता, मेमोरी, सीपीयू, डिस्क स्थान और हमारे लिए सबसे महत्वपूर्ण - घर में विकसित सेवाओं की स्थिति। जब कोई भी घरेलू सेवा स्टार्टअप प्रकार "स्वचालित" पर सेट किया गया था तो इसे हमेशा चालू होना चाहिए (अन्यथा हम इसे दुर्घटनाग्रस्त मानते हैं)। इस तरह का कोई मामला नहीं होना चाहिए:
इसलिए, नेटआईक्यू ने सेवाओं की स्थिति की निगरानी करना बंद कर दिया। एक सप्ताह के प्रयोग और नेटआईक्यू समर्थन के साथ एक और सप्ताह के बाद, हमने सीखा था कि "
यह एक बग नहीं था, यह एक विशेषता थी " और अलर्ट तभी ट्रिगर किया गया था जब एक प्रक्रिया एक विशिष्ट निकास कोड के साथ बाहर निकल गई थी। और हमारी सेवाएं किसी भी कोड के साथ क्रैश हो गईं।
उस समय वापस रोल करने के लिए बहुत देर हो चुकी थी। जैसा कि आप समझते हैं, जैसे ही हमें पता चला कि हमारे महत्वपूर्ण बुनियादी ढांचे की निगरानी नहीं की गई थी, हमने तुरंत ... एह ... कुछ नहीं किया। क्योंकि उस समय हमारी कंपनी के "पिघलने" की प्रक्रिया एक बड़े स्तर पर एक सक्रिय चरण में पहुंच गई थी, और यह इस तरह दिखता था:
मैंने ऊपर से बहुत गड़गड़ाहट की आवाज़ें सुनीं, और ऐसा लग रहा था जैसे ओलिंप पर देवता दुनिया के भाग्य का फैसला कर रहे थे, जबकि मैं अपनी छोटी तकनीकी समस्या के साथ उन्हें विचलित करने की कोशिश कर रहा था। उसी समय, मैं यह जानकर सो नहीं सका कि हमारा निगरानी तंत्र आधा अंधा था।
जब मुझे एहसास हुआ कि प्रतीक्षा करने के लिए कुछ भी नहीं है, मैंने एक त्वरित और गंदा समाधान बनाने का फैसला किया - छोटे सर्विस स्कैनर जो सेवाओं की जांच करने और सेवाओं के लिए ईमेल भेजने के लिए सभी सर्वरों पर जाना चाहिए जो नीचे थे, बिल्कुल चिह्नित के पुराने संस्करण की तरह NetIQ ने किया। आप सोच सकते हैं कि PowerShell स्क्रिप्ट ऐसा करने का सबसे अच्छा तरीका है लेकिन ... यदि आपके पास एक हथौड़ा है, तो सब कुछ एक नाखून की तरह दिखता है। यदि आप एक DBA हैं, जो SQL 6.0 संस्करण के बाद से काम कर रहे हैं ... तो यहां कोड से एक छोटा सा उद्धरण है, इसलिए आप समझ सकते हैं कि मैं किस बारे में बात कर रहा हूं:
पहला समाधान लिखने में मुझे केवल कुछ घंटे लगे। अगले कुछ दिनों के दौरान मैंने एक ऑडिट, मापदंडों और अन्य फैंसी चीजों को जोड़ा। WMIC कमांड क्या कर सकता है, इसकी जांच करने के बाद, मैं रोक नहीं पा रहा था। मुझे याद नहीं है कि अगले 2 हफ्तों के दौरान क्या हुआ था - सब कुछ थोड़े धुँधला था, लेकिन जब मैं इससे उठा तो नेट SQL की सभी विशेषताओं को शुद्ध SQL का उपयोग करके लागू किया गया।
मैंने अभी नेटआईक्यू कार्यक्षमता "जैसा है" की नकल नहीं की है, मैंने वह सब कुछ लागू किया है जो मैंने कभी सपना देखा था। LOWDISK ईमेल अलर्ट में आपको डिस्क उपयोग वृद्धि चार्ट के साथ एक पीडीएफ भी जुड़ा हुआ है जिससे आप तुरंत समझ सकते हैं कि विकास वास्तविक था या कुछ गलत था। कम मेमोरी - और आपको न केवल चार्ट मिलता है, बल्कि प्रोसेस द्वारा मेमोरी डिस्ट्रीब्यूशन भी मिलता है, साथ ही w3wp.exe के लिए आपको एक पूल जोड़ा जाता है। मैंने बाढ़ सुरक्षा और कई अन्य फैंसी चीजों के साथ स्मार्ट अनुस्मारक भी लागू किए थे। BTW, वर्चुअल सर्वर की सूची VMware रिपॉजिटरी से स्वचालित रूप से खींची गई थी। मोबाइल क्लाइंट में सतर्क विषयों को देखते हुए आप तुरंत कह सकते हैं कि क्या चल रहा था - बिना ईमेल खोले भी:
आधुनिक डेवलपर्स को एक हद तक अमूर्त स्तर बनाने की आदत हो गई कि यह एक सरल सीधा कोड लिखने की उनकी क्षमता को नुकसान पहुँचाता है। वे यह कहे बिना एक निगरानी प्रणाली नहीं बना सकते हैं: "ठीक है, इसलिए किसी भी सर्वर के लिए हम स्क्रिप्ट के किसी भी सेट को रिपॉजिटरी से नियमों से चला सकते हैं ... कितना लचीला ..."। लेकिन मेमोरी, सीपीयू, डिस्क, सेवाओं की स्थिति जैसी कुछ मूलभूत चीजों की निगरानी अद्वितीय है। अमूर्त स्तर के साथ इन बुनियादी स्थितियों के सत्यापन को लागू करने से वे एक कोड के साथ समाप्त होते हैं जो सभी मामलों के लिए समान रूप से खराब काम करता है। यह SCOM प्रणाली से एक उदाहरण है। मुझे यकीन है कि यह चश्मा द्वारा बिल्कुल लागू किया गया था:
लेकिन नई प्रणाली का प्रमुख लाभ यह था कि इसमें कोई एजेंट नहीं था। कोई एजेंट नहीं - स्थापित करने के लिए कुछ भी नहीं, कुछ भी टूटने के लिए नहीं। प्रणाली एक हथौड़ा के रूप में सरल और विश्वसनीय थी।
अगले महीने मैं काम पर आया और एक या दो घंटे बिताकर अपनी नई रचना पर काम कर रहा था - धीरे-धीरे, बिना किसी समय सीमा और ईटीए के, लगभग कोई तकनीकी ऋण नहीं छोड़ रहा था। थोड़ी देर बाद मैंने खुद को रोकने के लिए मजबूर किया।
नेटआईक्यू अभी भी उत्पादन में था, लेकिन लोग निश्चित रूप से नई प्रणाली, अधिक विश्वसनीय और सूचनात्मक से अलर्ट पसंद करते थे। धीरे-धीरे मैंने सभी सतर्क "ग्राहकों" को नई प्रणाली में स्थानांतरित कर दिया, हालांकि, पुरानी प्रणाली को जीवित रखा। इस बीच, हमारी पुरानी कंपनी के "पिघलने" की प्रक्रिया एक बड़ी स्थिति में पहुंच गई थी:
खैर, हर चीज का एक अंत होता है। मुझे और भी आश्चर्य हुआ कि मुझे एक बड़ी नौकरशाही कंपनी में ऐसी चीजों के साथ खेलने का मौका मिला। एक महीने की तैयारी के बाद, मुझे बताया गया कि "
ठीक है, एक हफ्ते में हमने नेटआईक्यू को बंद कर दिया और SCOM को एक कॉर्पोरेट मानक के रूप में स्थानांतरित कर दिया "। मैंने नेटआईक्यू को बंद कर दिया (मुझे स्वीकार करना होगा, मुझे इससे इतनी नफरत थी कि यह मेरे करियर का सबसे सुखद क्षण था) और SCOM के आने का इंतजार करने लगा। लेकिन कोई नहीं था। एक सप्ताह और महीने के बाद से कुछ भी नहीं है, और यहां तक कि एक चौथाई भी।
हमें पूरे 6 महीने के बाद ही SCOM मिला - किसी के पास भारी संख्या में सर्वर के लिए लाइसेंस की लागत के बारे में भूल गया था। इन 6 महीनों में कई विभाग नई प्रणाली के इतने भरोसेमंद हो गए, जिससे न केवल अलर्ट बल्कि प्रदर्शन मेट्रिक्स और इन्वेंट्री भी बनी रही, जो इसे बंद करने के सवाल से बाहर था। यह एक दूसरा, बैकअप सिस्टम बन गया। लेखा परीक्षकों के लिए SCOM है, वास्तव में उपयोगी चीजों के लिए - मेरी रचना है।
समय-समय पर पदानुक्रम के विभिन्न स्तरों पर प्रबंधकों ने उस प्रणाली के अलर्ट पर कदम रखा और पूछा - यह क्या है? हाल ही में मैंने इस उत्पाद के पीछे की पूरी कहानी बताई थी। वे हँसे और उस प्रणाली को जीवित रहने दिया, और मेरे लिए यह एक कोड लिखने का मौका था जब मैं एक छात्र था - ऐनक द्वारा निर्देशित नहीं, बल्कि मेरी समझ के आधार पर, एक शौक की तरह। बड़ा मजा आ रहा था।
रूसी में अनुच्छेद