एक आईटी डेटाबेस स्टैक को दस्तावेज़ करने के लिए, एक दूसरे के साथ उनके संबंध सहित, ग्राफ़ डेटाबेस में क्या करने की सिफारिश की गई है?

Question

500 से अधिक आईटी कर्मचारियों के साथ एक बड़ी कंपनी के लिए काम करना और 1,000 से अधिक सर्वरों के साथ, प्रत्येक सर्वर अपने स्वयं के व्यावसायिक अनुप्रयोगों को चलाने के साथ, हमारे पास यह जानने में एक जबरदस्त जानकारी और समन्वय चुनौती है कि किस सर्वर के लिए आईटी कर्मचारी सदस्य से संपर्क करें। तालमेल की समस्या विभिन्न आईटी कर्मचारियों के साथ जटिल होती है, जो आईटी स्टैक की विभिन्न परतों के लिए जिम्मेदार होते हैं। जैसे, अलग-अलग टीमें हैं जो हार्डवेयर, वर्चुअलाइजेशन, ऑपरेटिंग सिस्टम, एप्लिकेशन सर्वर और स्वयं एप्लिकेशन के लिए जिम्मेदार हैं।

इस चुनौती को ध्यान में रखते हुए, DevOps के भीतर, उन सभी घटकों को परिभाषित और प्रलेखित करने की आवश्यकता है, जो एक IT वातावरण में विभिन्न प्रौद्योगिकी ढेर का गठन करते हैं। परंपरागत रूप से यह एक स्वामित्व CMDB समाधान के साथ पूरा किया गया हो सकता है।

मैंने इस उद्देश्य के लिए बीएमसी Atrium और अन्य जैसे विशिष्ट सीएमडीबी समाधानों की जांच की है , समस्या यह है कि वे आईटीआईएल ढांचे के अनुसार, उच्च स्तर पर स्वयं आईटी परिसंपत्तियों के दस्तावेजीकरण के स्तर पर रुकते हैं, लेकिन प्रलेखन को संबोधित करने के लिए नहीं। आईटी प्रौद्योगिकी ढेर के बारे में विस्तार से। मैंने कठपुतली , Ansible और Salt जैसे उपकरणों की भी जांच की है , लेकिन ये उपकरण सॉफ़्टवेयर परिनियोजन और कॉन्फ़िगरेशन पर अधिक ध्यान केंद्रित करते हैं, न कि सॉफ़्टवेयर के आसपास के लोगों के समन्वय पर।

उदाहरण के लिए एक व्यावहारिक समाधान, विभिन्न अवधारणाओं को परिभाषित करेगा, साथ ही इन अवधारणाओं के लिए महत्वपूर्ण महत्वपूर्ण विशेषताएं:

• हार्डवेयर
• वर्चुअलाइजेशन
• ऑपरेटिंग सिस्टम
• अनुप्रयोग सर्वर
• अनुप्रयोग

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

इस तरह के समाधान का उद्देश्य प्रौद्योगिकी ढेर के खिलाफ विभिन्न प्रश्न करना होगा, जैसे:

• यह निर्धारित करने के लिए कि कौन से घटकों का समर्थन करता है
• कौन से घटक पुराने हैं
• किन घटकों को पैच करने की आवश्यकता है

इस बात को ध्यान में रखते हुए, एक खुला प्रौद्योगिकी उपकरण क्या मौजूद है, जो एक आईटी प्रौद्योगिकी स्टैक के सभी घटकों को परिभाषित करता है, जिसमें एक दूसरे से उनका संबंध शामिल है, जैसे कि ग्राफ डेटाबेस में Neo4J?

Comments

सिस्टम, कर्मियों, टीमों आदि के संदर्भ में संगठन का आकार क्या है?

— 030

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

— तानिबाई

यह अजीब लग सकता है, लेकिन एक अधिक सामान्य लेकिन अनुकूलन योग्य उद्यम वेयरहाउसिंग समाधान भी कर सकता है?

— पीटर मुर्सकिन

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

— तेन्सीबाई

@जे। डो एक उद्यम वेयरहाउसिंग समाधान काम कर सकता है, लेकिन क्या खुले स्रोत समाधान हैं जो इस तरह की समस्या का समाधान करेंगे। मानो या न मानो, हमारे पास बहुत सारे उपकरण हैं, जिनमें से कोई भी वास्तव में इस मुद्दे को संबोधित करने में सक्षम नहीं है। सर्वर प्रबंधन पक्ष पर हम BMC ADDM का उपयोग करते हैं, लेकिन इस टूल की महत्वपूर्ण कमी यह है कि यह अनुप्रयोग-केंद्रित होने के बजाय सर्वर-केंद्रित है। एक परिणाम के रूप में जब एक सर्वर कई अनुप्रयोगों को होस्ट करता है, तो कई एप्लिकेशन मालिकों को संबद्ध करने का कोई आसान तरीका नहीं है, क्योंकि सर्वर स्तर पर केवल एसोसिएशन के लिए पूरा किया जाता है।

— ग्रांट ड्यूर

Answer 1

आपके पहले पैराग्राफ को ध्यान में रखते हुए, आप जिस संगठन का वर्णन कर रहे हैं, वह एक अत्यधिक मौन अंग है, जो वास्तव में एक DevOps संगठन से बचने के लिए है।

इस चुनौती को ध्यान में रखते हुए, DevOps के भीतर, उन सभी घटकों को परिभाषित और प्रलेखित करने की आवश्यकता है, जो एक IT वातावरण में विभिन्न प्रौद्योगिकी ढेर का गठन करते हैं। परंपरागत रूप से यह एक स्वामित्व CMDB समाधान के साथ पूरा किया गया हो सकता है।

आप यहाँ जो वर्णन कर रहे हैं वह ITIL हो सकता है, जो एक प्रबंधन प्रणाली है जिसे दस्तावेज़ीकरण की आवश्यकता होती है और आप इसे इस तथ्य से मिलाते हैं कि एक DevOps टीम आमतौर पर कोड के रूप में अंतर्निहित परतों को परिभाषित करती है, जैसे कि यह कोड के कैविट्स के साथ किसी भी विकास प्रलेखन में वापस आ जाता है। क्या दस्तावेज़ीकरण अक्सर विकास की एक चुस्त कार्यप्रणाली के लिए स्क्रम कार्यप्रणाली में देखा जाता है (पुनरावृति के अंत में कम से कम काम करने वाले समाधान पर लक्ष्यित त्वरित और लघु पुनरावृत्तियों)

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

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

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

कहा कि, शेफ के लिए, शेफ-सर्वर भी एक CMDB के रूप में कार्य करता है जिसे आप विभिन्न उपकरणों के साथ क्वेरी कर सकते हैं (यह HTTP अनुरोधों से JSON डेटा लौटाता है), अंतर अनुप्रयोग निर्भरताएं विभिन्न तरीकों से व्यक्त की जा सकती हैं और कोई 'आउट ऑफ बॉक्स' नहीं है। विधि, प्रत्येक कंपनी के पास कॉन्फ़िगरेशन उद्देश्यों के लिए सिस्टम में उन्हें घोषित करने का अपना तरीका होगा और जैसे कि आप अपने ग्राफ़ को बनाने के लिए इसका लाभ उठा सकते हैं, लेकिन यह आपके पक्ष में है।

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

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