1C डेवलपर किस्से: व्यवस्थापक

एक तरह से या किसी अन्य तरीके से सभी 1C डेवलपर्स आईटी सेवाओं के साथ और सीधे सिस्टम प्रशासक के साथ बातचीत करते हैं। लेकिन हमेशा यह बातचीत आसानी से नहीं होती है। मैं आपको इसके बारे में कुछ मजेदार कहानियाँ बताना चाहूँगा।

हाई-स्पीड कम्युनिकेशन चैनल

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

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

यह सब सफलतापूर्वक कॉन्फ़िगर किया गया था, ऑपरेशन में डाल दिया और सामान्य रूप से बिना असफलता के काम किया।

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

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

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

शांत रूप से, मैं कहता हूं। हमारे पास आपका रात का बैकअप है। इसका उत्तर मौन है, जिसके द्वारा मैं समझता हूं कि मैंने सिर्फ एक व्यक्ति की जान बचाई है। हम चर्चा करना शुरू करते हैं कि इस प्रतिलिपि को एक नए, केवल तैनात सर्वर पर कैसे स्थानांतरित किया जाए। लेकिन यहां एक समस्या खड़ी हो गई।

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

जब हम सर्वर रूम में खड़े थे और फ़ाइलों के कॉपी होने की प्रतीक्षा कर रहे थे, तो हम पहली बार मिले, इसलिए "लाइव" बोलने के लिए, एक कप कॉफी पी गए, एक अनौपचारिक सेटिंग में बात की। मैंने उनके दुःख के प्रति सहानुभूति व्यक्त की और कंपनी के रुके हुए काम को बहाल करने के लिए जल्दबाज़ी में बैकअप के पूरे पेंच के साथ वापस भेज दिया।

इसके बाद, आईटी विभाग के लिए हमारे सभी आवेदन बहुत जल्दी हल हो गए और इससे अधिक असहमतियां नहीं हुईं।

अपने सिस्टम व्यवस्थापक से संपर्क करें

एक बार, एक ही क्लाइंट के साथ, बहुत लंबे समय तक मैं IIS के माध्यम से वेब एक्सेस के लिए 1 सी प्रकाशित नहीं कर सका। यह एक साधारण कार्य प्रतीत होता है, लेकिन यहाँ यह रास्ते से हटता नहीं है। स्थानीय सिस्टम प्रशासक जुड़े, विभिन्न सेटिंग्स और कॉन्फ़िगरेशन फ़ाइलों की कोशिश की। वेब पर 1 सी आम तौर पर किसी में काम नहीं करना चाहता था। डोमेन सुरक्षा नीतियों के साथ, या एक स्थानीय परिष्कृत फ़ायरवॉल या नरक के साथ कुछ गलत था। Nth पुनरावृत्ति पर, व्यवस्थापक शब्दों के साथ मेरे लिए एक लिंक छोड़ता है:

- इस निर्देश के साथ फिर से प्रयास करें। वहाँ सब कुछ बहुत विस्तृत है। यदि यह काम नहीं करता है, तो इस साइट के लेखक को लिखें, शायद वह मदद करेगा।
"नहीं," मैं कहता हूं, "यह मदद नहीं करेगा।"
- क्यों?
- मैं इस साइट का लेखक हूं ... (

परिणामस्वरूप, उन्होंने अपाचे को बिना किसी समस्या के लॉन्च किया। IIS नहीं जीत सका।

एक गहरे स्तर पर

हमारे पास एक ग्राहक था - एक छोटा विनिर्माण उद्यम। उनके पास एक सर्वर था, ऐसा अजीब "क्लासिक" 3 इन 1: टर्मिनल सर्वर + एप्लीकेशन सर्वर + डेटाबेस सर्वर। उन्होंने सॉफ्ट स्टार्टर्स पर आधारित कुछ उद्योग विन्यास में काम किया, सिस्टम में लगभग 15-20 उपयोगकर्ता थे, और सिस्टम का प्रदर्शन सिद्धांत रूप में सभी के लिए उपयुक्त था।

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

खैर, मैं बैठ गया और यह कहते हुए एक स्वैच्छिक पत्र लिखा कि टर्मिनल सर्वर और एप्लिकेशन सर्वर की भूमिकाओं को डीबीएमएस से अलग करना आवश्यक है (जो, सिद्धांत रूप में, हमने पहले ही बार-बार कहा है)। मैंने टर्मिनल सर्वर पर DFSS के बारे में लिखा, शेयर्ड मेमोरी के बारे में, आधिकारिक स्रोतों से लिंक फेंका और यहां तक ​​कि कुछ हार्डवेयर विकल्पों की भी पेशकश की। यह पत्र उन शक्तियों तक पहुंच गया जो कंपनी में हैं, "एक्सक्यूट" प्रस्तावों के साथ आईटी विभाग में वापस चली गईं, और आमतौर पर बर्फ टूट गई।

कुछ समय बाद, व्यवस्थापक मुझे नए सर्वर और लॉगिन क्रेडेंशियल का आईपी पता भेजता है। वह कहते हैं कि MS SQL और 1C सर्वर के घटक वहां तैनात हैं, और आपको डेटाबेस को स्थानांतरित करने की आवश्यकता है, लेकिन अभी तक केवल DBMS सर्वर पर, क्योंकि 1C कुंजियों के साथ कुछ समस्याएं थीं।

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

इसमें कई दिन लगते हैं, कुंजियों को स्थानांतरित नहीं किया गया है। मुझे इस बात में दिलचस्पी है कि समस्या क्या है, वहां सब कुछ सरल प्रतीत होता है - मैंने इसे एक सर्वर से निकाल दिया, दूसरे में अटका दिया, ड्राइवर को स्थापित किया और यह तैयार है। व्यवस्थापक प्रतिक्रिया देता है, पोर्ट फ़ॉरवर्डिंग, एक वर्चुअल सर्वर और बहुत कुछ के बारे में कहता है।

हम्म ... एक वर्चुअल सर्वर? ऐसा लगता है कि कभी कोई वर्चुअलाइजेशन नहीं हुआ है और वे नहीं थे ... मुझे Windows Server 2008 में हाइपर-वी पर वर्चुअल मशीन के लिए 1 सी सर्वर कुंजी को अक्षम करने की अक्षमता के साथ एक अच्छी तरह से ज्ञात समस्या याद है। और यहां कुछ संदेह का निर्माण शुरू हो जाता है ...

मैं सर्वर प्रबंधक खोलता हूं - भूमिकाएं - एक नई भूमिका दिखाई दी है - हाइपर-वी। मैं हाइपर- V प्रबंधक पर जाता हूं, मुझे एक वर्चुअल मशीन दिखाई दे रही है, मैं कनेक्ट कर रहा हूं ... और वास्तव में ... हमारा नया डेटाबेस सर्वर ...

खैर, क्या? अधिकारियों के निर्देश और मेरी सिफारिशें पूरी हो गई हैं, भूमिकाएं अलग हो गई हैं। कार्य बंद हो सकता है।

कुछ समय बाद, अब संकट हो गया, नई शाखा को बंद करना पड़ा, भार कम हो गया, सिस्टम प्रदर्शन कमोबेश सहनशील हो गया।

ठीक है, निश्चित रूप से, वे वर्चुअल मशीन के लिए सर्वर कुंजी को आगे नहीं बढ़ा सकते थे। नतीजतन, सब कुछ वैसा ही था जैसा कि और छोड़ दिया गया था: टर्मिनल सर्वर + 1 सी क्लस्टर भौतिक मशीन पर, डेटाबेस सर्वर वर्चुअल वर्चुअल में एक ही स्थान पर।

और ठीक है, क्या यह किसी प्रकार का शरश्कीन कार्यालय होगा। तो नहीं। एक प्रसिद्ध कंपनी, जिसके उत्पादों को आप शायद जानते हैं और सभी प्रकार के रिबन और औचनोव के संबंधित विभागों में देख चुके हैं।

हार्ड ड्राइव अवकाश अनुसूची

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

सबसे पहले, मुकाबला और परीक्षण ठिकानों को तैनात करना आवश्यक है। डेवलपर ने कनेक्शन के लिए डेटा प्राप्त किया, सर्वर पर लॉग करता है, स्थापित MS SQL, 1C सर्वर को देखता है, 2 लॉजिकल ड्राइव देखता है: एक 250 गीगाबाइट सी ड्राइव और 1 टेराबाइट डी ड्राइव। खैर, "सी" एक प्रणाली है, डेटा के लिए "डी", डेवलपर तार्किक रूप से निर्णय लेता है और वहां सभी डेटाबेस को तैनात करता है। मैंने केवल बैकअप सहित रखरखाव की योजना भी स्थापित की है (हालांकि हम इसके लिए जिम्मेदार नहीं हैं)। ट्रू बैकअप ने यहां "डी" पर आकार लिया। भविष्य में, इसे पहले से ही कुछ अलग नेटवर्क संसाधन पर फिर से कॉन्फ़िगर करने की योजना बनाई गई थी।

परियोजना शुरू की गई थी, सलाहकारों ने नई प्रणाली में काम करने के बारे में प्रशिक्षण आयोजित किया, बचे हुए हस्तांतरित किए गए, कुछ छोटे बिंदु सुधार किए गए और उपयोगकर्ता पहले से ही नए सूचना आधार में काम करना शुरू कर दिया।

सोमवार को एक सुबह तक सब कुछ ठीक रहा, यह पता चला कि डेटाबेस ड्राइव गायब हो गया था। सर्वर पर बस "डी" नहीं है और यह है।

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

भगवान का शुक्र है, उन्होंने डेटाबेस फ़ाइलों को हटाने का प्रबंधन नहीं किया और काम करने वाले डेटाबेस को पुनर्स्थापित करने में कामयाब रहे।

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

लेकिन यह पूरी तरह से अलग कहानी है ...

PS यह भी देखें:

• 1 सी डेवलपर दास्तां: महाकाव्य