1C विकासकर्ताको कथाहरू: प्रशासकको

सबै 1C विकासकर्ताहरूले कुनै न कुनै रूपमा IT सेवाहरू र प्रणाली प्रशासकहरूसँग प्रत्यक्ष रूपमा अन्तरक्रिया गर्छन्। तर यो अन्तरक्रिया सधैं सहज रूपमा जाँदैन। म तपाईलाई यस बारे केहि रमाईलो कथाहरू सुनाउन चाहन्छु।

उच्च गति संचार च्यानल

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

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

यो सबै सफलतापूर्वक कन्फिगर गरियो, सञ्चालनमा राखियो र सामान्यतया असफलता बिना काम गरियो।

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

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

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

शान्त हुनुहोस्, म भन्छु। हामीसँग तपाईंको राती ब्याकअप छ। जवाफमा, त्यहाँ मौनता थियो, जसबाट मैले महसुस गरें कि मैले भर्खरै एक व्यक्तिको जीवन बचाएको छु। हामी यो प्रतिलिपिलाई नयाँ, नयाँ तैनाथ गरिएको सर्भरमा कसरी स्थानान्तरण गर्ने भनेर छलफल गर्न थाल्छौं। तर यहाँ पनि समस्या आयो ।

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

जब तिनीहरू हाम्रो सर्भर कोठामा उभिरहेका थिए र फाइलहरू प्रतिलिपि गर्न पर्खिरहेका थिए, हामी पहिलो पटक भेट्यौं, त्यसैले बोल्नको लागि, "व्यक्तिगत रूपमा," एक कप कफी पिए, र अनौपचारिक सेटिङमा कुरा गर्यौं। मैले उसको दु:खप्रति सहानुभूति प्रकट गरेँ र कम्पनीको रोकिएको कामलाई हतारमा पुनर्स्थापना गर्दै ब्याकअपको पूर्ण स्क्रूसहित फिर्ता पठाएँ।

पछि, IT विभागमा हाम्रा सबै अनुरोधहरू धेरै चाँडै समाधान गरियो र कुनै थप असहमति उत्पन्न भएन।

आफ्नो प्रणाली प्रशासकलाई सम्पर्क गर्नुहोस्

एक पटक, धेरै लामो समयको लागि, मैले एक ग्राहकको लागि IIS मार्फत वेब पहुँचको लागि 1C प्रकाशित गर्न सकिन। यो सामान्य काम जस्तो देखिन्थ्यो, तर त्यहाँ सबै चीजहरू चलाउनको लागि कुनै तरिका थिएन। स्थानीय प्रणाली प्रशासकहरू संलग्न भए र विभिन्न सेटिङहरू र कन्फिगरेसन फाइलहरू प्रयास गरे। वेबमा 1C सामान्यतया कुनै पनि हिसाबले काम गर्न चाहँदैनथे। केहि गलत थियो, या त डोमेन सुरक्षा नीतिहरु संग, वा स्थानीय परिष्कृत फायरवाल संग, वा भगवान जान्नुहुन्छ अरु के हो। Nth पुनरावृत्तिमा, व्यवस्थापकले मलाई शब्दहरूसँग लिङ्क पठाउनुहुन्छ:

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

नतिजाको रूपमा, हामीले यसलाई कुनै पनि समस्या बिना Apache मा सुरु गर्यौं। IIS कहिल्यै पराजित भएको थिएन।

एक तह गहिरो

हामीसँग एक ग्राहक थियो - एउटा सानो उत्पादन उद्यम। तिनीहरूसँग सर्भर थियो, एक प्रकारको "क्लासिक" 3 मा 1: टर्मिनल सर्भर + एप्लिकेसन सर्भर + डाटाबेस सर्भर। तिनीहरूले UPP मा आधारित केही उद्योग-विशेष कन्फिगरेसनमा काम गरे, त्यहाँ लगभग 15-20 प्रयोगकर्ताहरू थिए, र प्रणालीको प्रदर्शन, सिद्धान्तमा, सबैलाई उपयुक्त थियो।

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

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

केही समय पछि, प्रशासकले मलाई नयाँ सर्भरको आईपी ठेगाना र लगइन प्रमाणहरू पठाउँछन्। उनी भन्छन् कि MS SQL र 1C सर्भर कम्पोनेन्टहरू त्यहाँ तैनाथ छन्, र डाटाबेसहरू स्थानान्तरण गर्न आवश्यक छ, तर अहिलेको लागि मात्र DBMS सर्भरमा, किनकि 1C कुञ्जीहरूमा केही समस्याहरू उत्पन्न भएका छन्।

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

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

हम्म... भर्चुअल सर्भर? यस्तो देखिन्छ कि त्यहाँ कहिल्यै भर्चुअलाइजेसन भएको छैन र त्यहाँ कहिल्यै भएको छैन... मलाई विन्डोज सर्भर 1 मा हाइपर-V मा भर्चुअल मेसिनमा 2008C सर्भर कुञ्जी फर्वार्ड गर्ने असम्भवताको साथ एक राम्रो ज्ञात समस्या याद छ। र यहाँ म मा केहि आशंकाहरु जन्मिन थाल्छन्...

म सर्भर प्रबन्धक खोल्छु - भूमिका - नयाँ भूमिका देखा पर्यो - हाइपर-V। म Hyper-V प्रबन्धकमा जान्छु, एउटा भर्चुअल मेसिन हेर्नुहोस्, जडान गर्नुहोस्... र वास्तवमा... हाम्रो नयाँ डाटाबेस सर्भर...

कै त? अख्तियारको निर्देशन र मेरा सिफारिसहरू कार्यान्वयन भएका छन्, भूमिकाहरू छुट्याएका छन्। कार्य बन्द हुन सक्छ।

केही समयपछि अहिले संकट आयो, नयाँ शाखा बन्द गर्नुपर्‍यो, लोड घट्यो र प्रणालीको कार्यसम्पादन कम वा कम सहनीय भयो।

निस्सन्देह, तिनीहरूले सर्भर कुञ्जीलाई भर्चुअल मेसिनमा फर्वार्ड गर्न सकेनन्। नतिजाको रूपमा, सबै कुरा यसरी छोडियो: भौतिक मेसिनमा टर्मिनल सर्भर + 1C क्लस्टर, भर्चुअलमा डाटाबेस सर्भर।

र यो राम्रो हुनेछ यदि यो कुनै प्रकारको sharashkin को कार्यालय थियो। त्यसैले छैन। एउटा प्रख्यात कम्पनी जसको उत्पादनहरू तपाईंले सायद थाहा पाउनुभएको छ र सबै Lentas र Auchans को सम्बन्धित विभागहरूमा देख्नुभएको छ।

हार्ड ड्राइभ छुट्टी तालिका

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

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

परियोजना सुरु भयो, सल्लाहकारहरूले नयाँ प्रणालीमा कसरी काम गर्ने भन्ने बारे तालिम प्रदान गरे, बाँकी रहेको स्थानान्तरण गरियो, केही साना साना सुधारहरू गरियो, र प्रयोगकर्ताहरूले नयाँ सूचना आधारमा काम गर्न थाले।

एक सोमबार बिहान सम्म सबै कुरा राम्ररी चलिरहेको थियो जब यो पत्ता लाग्यो कि डाटाबेस डिस्क हराइरहेको थियो। त्यहाँ सर्भरमा कुनै "D" छैन र यो हो।

थप अनुसन्धानले यो प्रकट गर्यो: यो "सर्भर" वास्तवमा स्थानीय प्रणाली प्रशासकको काम कम्प्युटर थियो। साँचो, यो अझै पनि सर्भर OS थियो। यो प्रशासकको व्यक्तिगत USB ड्राइभ सर्भरमा प्लग गरिएको थियो। र त्यसोभए प्रशासक छुट्टीमा गए, आफ्नो स्क्रू लिएर, यात्राको लागि यसमा चलचित्रहरू पम्प गर्ने लक्ष्यको साथ।

भगवानलाई धन्यवाद, उसले डाटाबेस फाइलहरू मेटाउन र उत्पादक डाटाबेस पुनर्स्थापना गर्न व्यवस्थापन गरेन।

यो उल्लेखनीय छ कि सबैजना सामान्यतया USB ड्राइभ मा स्थित प्रणाली को प्रदर्शन संग सन्तुष्ट थिए। 1C को कुनै पनि असंतोषजनक प्रदर्शनको बारेमा कसैले गुनासो गरेन। यो पछि मात्र होल्डिङले सुपर-सर्भरहरू, एक मिलियन+ रूबलको लागि भण्डारण प्रणाली, परिष्कृत हाइपरभाइजरहरू र सबै शाखाहरूमा असहनीय 1C ब्रेकहरू सहित सबै जानकारी डाटाबेसहरू एकल केन्द्रीकृत साइटमा स्थानान्तरण गर्न मेगा-प्रोजेक्ट सुरु गर्यो।

तर यो एकदम फरक कथा हो ...

स्रोत: www.habr.com