1C विकसकाच्या कथा: प्रशासकाच्या

सर्व 1C विकासक एका प्रकारे किंवा दुसर्‍या प्रकारे IT सेवांशी आणि थेट सिस्टम प्रशासकांशी जवळून संवाद साधतात. पण हा संवाद नेहमीच सुरळीत होत नाही. याबद्दल मी तुम्हाला काही मजेदार किस्से सांगू इच्छितो.

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

आमचे बहुतेक क्लायंट त्यांच्या स्वतःच्या मोठ्या आयटी विभागांसह मोठे होल्डिंग आहेत. आणि क्लायंट विशेषज्ञ सहसा माहिती डेटाबेसच्या बॅकअप प्रतींसाठी जबाबदार असतात. पण तुलनेने लहान संस्था देखील आहेत. विशेषत: त्यांच्यासाठी, आमच्याकडे एक सेवा आहे ज्यानुसार आम्ही प्रत्येक गोष्टी 1C च्या बॅकअपशी संबंधित सर्व समस्या स्वतःवर घेतो. ही कंपनी आहे ज्याबद्दल आपण या कथेत बोलू.

एक नवीन क्लायंट 1C ला समर्थन देण्यासाठी आला आणि इतर गोष्टींबरोबरच, करारामध्ये एक कलम समाविष्ट आहे की आम्ही बॅकअपसाठी जबाबदार आहोत, जरी त्यांचे स्वतःचे सिस्टम प्रशासक कर्मचारी होते. क्लायंट-सर्व्हर डेटाबेस, DBMS म्हणून MS SQL. बर्‍यापैकी मानक परिस्थिती, परंतु तरीही एक सूक्ष्मता होती: मुख्य आधार बराच मोठा होता, परंतु मासिक वाढ खूपच लहान होती. म्हणजेच डेटाबेसमध्ये भरपूर ऐतिहासिक डेटा होता. हे वैशिष्ट्य लक्षात घेऊन, मी खालीलप्रमाणे बॅकअप देखभाल योजना सेट केल्या: प्रत्येक महिन्याच्या पहिल्या शनिवारी संपूर्ण बॅकअप घेतला गेला, तो खूप जड होता, नंतर दररोज रात्री एक भिन्न प्रत बनविली गेली - तुलनेने लहान व्हॉल्यूम आणि एक प्रत प्रत्येक तासाच्या व्यवहाराच्या लॉगचा. शिवाय, संपूर्ण आणि विभेदक प्रती केवळ नेटवर्क संसाधनावर कॉपी केल्या गेल्या नाहीत तर आमच्या FTP सर्व्हरवर देखील अपलोड केल्या गेल्या. ही सेवा प्रदान करताना ही अनिवार्य आवश्यकता आहे.

हे सर्व यशस्वीरित्या कॉन्फिगर केले गेले, कार्यान्वित केले गेले आणि सामान्यत: अपयशाशिवाय कार्य केले गेले.

मात्र काही महिन्यांनंतर या संस्थेतील यंत्रणा प्रशासक बदलला. नवीन सिस्टम प्रशासकाने आधुनिक ट्रेंडनुसार हळूहळू कंपनीच्या आयटी पायाभूत सुविधांची पुनर्बांधणी करण्यास सुरुवात केली. विशेषतः, व्हर्च्युअलायझेशन दिसू लागले, डिस्क शेल्फ् 'चे अव रुप, प्रवेश सर्वत्र अवरोधित केला गेला आणि सर्व काही, जे सर्वसाधारणपणे, अर्थातच, आनंदी होऊ शकत नाही. परंतु त्याच्यासाठी गोष्टी नेहमी सुरळीत होत नव्हत्या; 1C च्या कार्यक्षमतेत अनेकदा समस्या होत्या, ज्यामुळे आमच्या समर्थनासह काही मतभेद आणि गैरसमज झाले. तसेच, हे लक्षात घेतले पाहिजे की त्याच्याशी आमचे संबंध सामान्यत: थंड आणि काहीसे ताणलेले होते, ज्यामुळे कोणत्याही समस्या उद्भवल्यास तणावाचे प्रमाण वाढले.

परंतु एका सकाळी असे दिसून आले की या क्लायंटचा सर्व्हर अनुपलब्ध आहे. काय झाले हे जाणून घेण्यासाठी मी सिस्टम प्रशासकाला कॉल केला आणि "आमचा सर्व्हर क्रॅश झाला आहे, आम्ही त्यावर काम करत आहोत, तुमच्यावर अवलंबून नाही" असे काहीतरी उत्तर म्हणून मिळाले. बरं, ते काम करतात हे चांगले आहे. याचा अर्थ परिस्थिती नियंत्रणात आहे. दुपारच्या जेवणानंतर, मी पुन्हा कॉल करतो आणि चिडचिड करण्याऐवजी, मला आधीच प्रशासकाच्या आवाजात थकवा आणि उदासीनता जाणवते. मी काय घडले हे शोधण्याचा प्रयत्न करत आहे आणि आम्ही मदत करण्यासाठी काही करू शकतो का? संभाषणाच्या परिणामी, खालील गोष्टी समोर आल्या:

नव्याने जमलेल्या छाप्याने त्याने सर्व्हरला नवीन स्टोरेज सिस्टममध्ये हलवले. पण काहीतरी गडबड झाली आणि काही दिवसांनी हा छापा सुरक्षितपणे कोसळला. कंट्रोलर जळून गेला किंवा डिस्कला काहीतरी झाले, मला नक्की आठवत नाही, परंतु सर्व माहिती अपरिवर्तनीयपणे गमावली गेली. आणि मुख्य गोष्ट अशी होती की बॅकअपसह नेटवर्क संसाधन देखील विविध स्थलांतर दरम्यान त्याच डिस्क अॅरेवर संपले. म्हणजेच, उत्पादक डेटाबेस स्वतः आणि त्याच्या सर्व बॅकअप प्रती गमावल्या गेल्या. आणि आता काय करावे हे स्पष्ट नाही.

शांत व्हा, मी म्हणतो. आमच्याकडे तुमचा रात्रीचा बॅकअप आहे. प्रतिसादात, शांतता होती, ज्याद्वारे मला जाणवले की मी नुकतेच एका माणसाचे प्राण वाचवले. ही प्रत नवीन, नव्याने तैनात केलेल्या सर्व्हरवर कशी हस्तांतरित करायची यावर आम्ही चर्चा करू लागतो. पण इथेही एक अडचण निर्माण झाली.

लक्षात ठेवा जेव्हा मी म्हणालो की पूर्ण बॅकअप खूप मोठा होता? मी महिन्यातून एकदा शनिवारी असे केले असे काही कारण नव्हते. वस्तुस्थिती अशी आहे की कंपनी एक लहान प्लांट होती, जी शहराच्या अगदी बाहेर स्थित होती आणि त्यांचे इंटरनेट खूप चांगले होते. सोमवारी सकाळपर्यंत, म्हणजे आठवड्याच्या शेवटी, ही प्रत आमच्या FTP सर्व्हरवर अपलोड केली जाऊ शकली नाही. पण विरुद्ध दिशेने लोड होण्यासाठी एक-दोन दिवस वाट पाहण्याचा मार्ग नव्हता. फाइल हस्तांतरित करण्याच्या अनेक अयशस्वी प्रयत्नांनंतर, प्रशासकाने नवीन सर्व्हरवरून थेट हार्ड ड्राइव्ह काढली, कुठेतरी ड्रायव्हर असलेली कार सापडली आणि पटकन आमच्या कार्यालयात धाव घेतली, सुदैवाने आम्ही अजूनही त्याच शहरात आहोत.

ते आमच्या सर्व्हर रूममध्ये उभे असताना आणि फायली कॉपी होण्याची वाट पाहत असताना, आम्ही प्रथमच भेटलो, म्हणून बोलण्यासाठी, “व्यक्तिगत”, एक कप कॉफी प्यायली आणि अनौपचारिक वातावरणात बोललो. मी त्याच्या दु:खाबद्दल सहानुभूती दाखवली आणि कंपनीचे थांबलेले काम घाईघाईने पूर्ववत करून पूर्ण बॅकअपसह त्याला परत पाठवले.

त्यानंतर, आयटी विभागाकडे आमच्या सर्व विनंत्या फार लवकर सोडवण्यात आल्या आणि कोणतेही मतभेद उद्भवले नाहीत.

तुमच्या सिस्टम प्रशासकाशी संपर्क साधा

एकदा, बर्याच काळासाठी, मी एका क्लायंटसाठी IIS द्वारे वेब प्रवेशासाठी 1C प्रकाशित करू शकलो नाही. हे एक सामान्य काम असल्यासारखे वाटत होते, परंतु सर्वकाही चालू करण्याचा कोणताही मार्ग नव्हता. स्थानिक सिस्टम प्रशासक सहभागी झाले आणि भिन्न सेटिंग्ज आणि कॉन्फिगरेशन फाइल्स वापरून पहा. वेबवरील 1C सामान्यपणे कोणत्याही प्रकारे कार्य करू इच्छित नव्हते. डोमेन सुरक्षा धोरणांमध्ये किंवा स्थानिक अत्याधुनिक फायरवॉलमध्ये काहीतरी चूक झाली होती किंवा आणखी काय देव जाणतो. Nव्या पुनरावृत्तीवर, प्रशासक मला या शब्दांसह एक लिंक पाठवतो:

- या सूचना वापरून पुन्हा प्रयत्न करा. तेथे सर्व काही तपशीलवार वर्णन केले आहे. हे कार्य करत नसल्यास, या साइटच्या लेखकास लिहा, कदाचित तो मदत करू शकेल.
"नाही," मी म्हणतो, "त्याने काही उपयोग होणार नाही."
- का?
- मी या साइटचा लेखक आहे... (

परिणामी, आम्ही ते अपाचेवर कोणत्याही समस्येशिवाय लॉन्च केले. आयआयएसचा कधीही पराभव झाला नाही.

एक पातळी खोल

आमच्याकडे एक क्लायंट होता - एक लहान उत्पादन उद्योग. त्यांच्याकडे एक सर्व्हर होता, एक प्रकारचा “क्लासिक” 3 इन 1: टर्मिनल सर्व्हर + ऍप्लिकेशन सर्व्हर + डेटाबेस सर्व्हर. त्यांनी यूपीपीवर आधारित काही उद्योग-विशिष्ट कॉन्फिगरेशनमध्ये काम केले, तेथे सुमारे 15-20 वापरकर्ते होते आणि सिस्टमची कार्यक्षमता, तत्त्वतः, प्रत्येकासाठी अनुकूल होती.

जसजसा वेळ निघून गेला तसतसे सर्व काही कमी-अधिक प्रमाणात स्थिरपणे कार्य करत होते. परंतु नंतर युरोपने रशियावर निर्बंध लादले, परिणामी रशियन लोकांनी प्रामुख्याने देशांतर्गत उत्पादित उत्पादने खरेदी करण्यास सुरवात केली आणि या कंपनीचा व्यवसाय झपाट्याने चढला. वापरकर्त्यांची संख्या 50-60 लोकांपर्यंत वाढली, एक नवीन शाखा उघडली गेली आणि त्यानुसार कागदपत्रांचा प्रवाह वाढला. आणि आता सध्याचा सर्व्हर यापुढे वेगाने वाढलेल्या भाराचा सामना करू शकत नाही आणि 1C ते म्हणतात त्याप्रमाणे “धीमे” होण्यास सुरुवात झाली. पीक अवर्स दरम्यान, दस्तऐवजांवर काही मिनिटे प्रक्रिया केली गेली, ब्लॉकिंग एरर आल्या, फॉर्म उघडण्यास बराच वेळ लागला आणि संबंधित सेवांचा संपूर्ण गुलदस्ता. स्थानिक सिस्टीम प्रशासकाने सर्व समस्या दूर केल्या, "हे तुमचे 1C आहे, तुम्ही ते शोधून काढाल." आम्ही वारंवार यंत्रणेचे परफॉर्मन्स ऑडिट करण्याचे प्रस्तावित केले आहे, परंतु ते कधीही ऑडिटमध्ये आले नाही. क्लायंटने फक्त समस्यांचे निराकरण कसे करावे याबद्दल शिफारसी विचारल्या.

बरं, मी खाली बसलो आणि टर्मिनल सर्व्हर आणि ऍप्लिकेशन सर्व्हरच्या भूमिका DBMS सह विभक्त करण्याच्या गरजेबद्दल एक लांबलचक पत्र लिहिले (जे, तत्त्वतः, आम्ही यापूर्वीही अनेकदा सांगितले आहे). मी टर्मिनल सर्व्हरवर DFSS बद्दल लिहिले, शेअर केलेल्या मेमरीबद्दल, अधिकृत स्त्रोतांना लिंक प्रदान केल्या आणि उपकरणांसाठी काही पर्याय सुचवले. हे पत्र कंपनीत सत्तेवर असलेल्यांपर्यंत पोहोचले, "अंमलबजावणी करा" असे ठराव घेऊन आयटी विभागाकडे परत गेले आणि बर्फ सामान्यतः तुटला.

काही वेळानंतर, प्रशासक मला नवीन सर्व्हरचा IP पत्ता आणि लॉगिन क्रेडेन्शियल्स पाठवतो. तो म्हणतो की MS SQL आणि 1C सर्व्हर घटक तेथे तैनात केले आहेत, आणि डेटाबेस हस्तांतरित करणे आवश्यक आहे, परंतु सध्या फक्त DBMS सर्व्हरवर, कारण 1C की सह काही समस्या उद्भवल्या आहेत.

मी आत आलो, खरंच, सर्व सेवा चालू होत्या, सर्व्हर फार शक्तिशाली नव्हता, परंतु ठीक आहे, मला वाटते की ते काहीही करण्यापेक्षा चांगले आहे. मी सध्याच्या सर्व्हरला कसा तरी आराम देण्यासाठी डेटाबेस हस्तांतरित करेन. मी मान्य केलेल्या वेळी सर्व बदल्या पूर्ण केल्या, परंतु परिस्थिती बदलली नाही - तरीही समान कार्यप्रदर्शन समस्या. हे विचित्र आहे, अर्थातच, चला, 1C क्लस्टरमध्ये डेटाबेस नोंदणी करूया आणि आपण पाहू.

बरेच दिवस उलटले तरी चाव्या हस्तांतरित झाल्या नाहीत. मला आश्चर्य वाटत आहे की समस्या काय आहे, सर्वकाही सोपे आहे असे दिसते - ते एका सर्व्हरमधून बाहेर काढा, दुसर्‍यामध्ये प्लग करा, ड्रायव्हर स्थापित करा आणि तुमचे काम पूर्ण झाले. पोर्ट फॉरवर्डिंग, व्हर्च्युअल सर्व्हर इत्यादींबद्दल गडबड करून आणि काहीतरी बोलून प्रशासक प्रतिसाद देतो.

हम्म... व्हर्च्युअल सर्व्हर? असे दिसते की कोणतेही व्हर्च्युअलायझेशन कधीही झाले नाही आणि कधीही झाले नाही... मला विंडोज सर्व्हर 1 मधील हायपर-व्ही वरील व्हर्च्युअल मशीनवर 2008C सर्व्हर की फॉरवर्ड करणे अशक्यतेसह एक सुप्रसिद्ध समस्या आठवते. आणि येथे माझ्यात काही शंका निर्माण होऊ लागतात...

मी सर्व्हर व्यवस्थापक उघडतो - भूमिका - एक नवीन भूमिका आली आहे - हायपर-व्ही. मी हायपर-व्ही मॅनेजरकडे जातो, एक व्हर्च्युअल मशीन पाहतो, कनेक्ट करतो... आणि खरंच... आमचा नवीन डेटाबेस सर्व्हर...

तर काय? अधिकाऱ्यांच्या सूचना आणि माझ्या शिफारशींची अंमलबजावणी करण्यात आली आहे, भूमिका वेगळे केल्या आहेत. कार्य बंद केले जाऊ शकते.

काही काळानंतर, आताचे संकट आले, नवीन शाखा बंद करावी लागली, भार कमी झाला आणि सिस्टमची कार्यक्षमता कमी-अधिक प्रमाणात सुसह्य झाली.

बरं, अर्थातच, ते सर्व्हर की आभासी मशीनवर अग्रेषित करू शकले नाहीत. परिणामी, सर्वकाही जसे आहे तसे राहिले: भौतिक मशीनवर टर्मिनल सर्व्हर + 1C क्लस्टर, तेथे डेटाबेस सर्व्हर आभासी.

आणि हे काही प्रकारचे शाराश्किनचे कार्यालय असल्यास छान होईल. तर नाही. एक सुप्रसिद्ध कंपनी जिची उत्पादने तुम्हाला कदाचित माहित असतील आणि सर्व Lentas आणि Auchans च्या संबंधित विभागांमध्ये पाहिली असतील.

हार्ड ड्राइव्ह सुट्टीचे वेळापत्रक

जगाचा ताबा घेण्याची महत्त्वाकांक्षी योजना असलेल्या एका मोठ्या होल्डिंग कंपनीने तिच्या मेगा-कॉर्पोरेशनमध्ये समाविष्ट करण्याच्या ध्येयाने पुन्हा एकदा एक छोटी कंपनी विकत घेतली आहे. या होल्डिंगच्या सर्व विभागांमध्ये, वापरकर्ते त्यांच्या स्वतःच्या डेटाबेसमध्ये कार्य करतात, परंतु समान कॉन्फिगरेशनसह. आणि म्हणून आम्ही या प्रणालीमध्ये नवीन युनिट समाविष्ट करण्यासाठी एक छोटा प्रकल्प सुरू केला.

सर्व प्रथम, उत्पादन आणि चाचणी डेटाबेस तैनात करणे आवश्यक आहे. विकसकाने कनेक्शन डेटा प्राप्त केला, सर्व्हरमध्ये लॉग इन केले, एमएस एसक्यूएल स्थापित केले, 1C सर्व्हर पाहिला, 2 लॉजिकल ड्राइव्हस् पहा: 250 गीगाबाइट्स क्षमतेसह ड्राइव्ह “C” आणि 1 टेराबाइट क्षमतेसह ड्राइव्ह “D”. बरं, "C" ही प्रणाली आहे, "D" डेटासाठी आहे, विकसक तार्किकपणे निर्णय घेतो आणि तेथे सर्व डेटाबेस तैनात करतो. मी बॅकअपसह देखभाल योजना देखील सेट केल्या आहेत, अगदी बाबतीत (जरी आम्ही यासाठी जबाबदार नसतो). खरे, बॅकअप येथे “D” मध्ये जोडले गेले. भविष्यात, काही वेगळ्या नेटवर्क संसाधनामध्ये ते पुन्हा कॉन्फिगर करण्याची योजना होती.

प्रकल्प सुरू झाला, सल्लागारांनी नवीन प्रणालीमध्ये कसे कार्य करावे याचे प्रशिक्षण दिले, उरलेले हस्तांतरित केले गेले, काही किरकोळ सुधारणा केल्या गेल्या आणि वापरकर्ते नवीन माहिती बेसमध्ये काम करू लागले.

एका सोमवारी सकाळी डेटाबेस डिस्क गहाळ झाल्याचे लक्षात येईपर्यंत सर्व काही ठीक चालले होते. सर्व्हरवर फक्त "डी" नाही आणि तेच आहे.

पुढील तपासात हे उघड झाले: हा “सर्व्हर” प्रत्यक्षात स्थानिक सिस्टम प्रशासकाचा संगणक होता. खरे आहे, त्यात अजूनही सर्व्हर ओएस आहे. या प्रशासकाची वैयक्तिक USB ड्राइव्ह सर्व्हरमध्ये प्लग इन केली होती. आणि म्हणून प्रशासक सुट्टीवर गेला, सोबत स्क्रू घेऊन, सहलीसाठी त्यात चित्रपट टाकण्याचे ध्येय घेऊन.

देवाचे आभार, त्याने डेटाबेस फाइल्स हटविण्यास व्यवस्थापित केले नाही आणि उत्पादक डेटाबेस पुनर्संचयित करण्यात व्यवस्थापित केले.

हे लक्षात घेण्यासारखे आहे की प्रत्येकजण यूएसबी ड्राइव्हवर असलेल्या सिस्टमच्या कार्यक्षमतेसह सामान्यतः समाधानी होता. 1C च्या असमाधानकारक कामगिरीबद्दल कोणीही तक्रार केली नाही. त्यानंतरच होल्डिंगने सुपर-सर्व्हर्स, दशलक्ष+ रूबलसाठी स्टोरेज सिस्टम, सर्व शाखांमध्ये अत्याधुनिक हायपरव्हायझर्स आणि असह्य 1C ब्रेकसह सर्व माहिती डेटाबेस एकाच केंद्रीकृत साइटवर हस्तांतरित करण्यासाठी एक मेगा-प्रोजेक्ट सुरू केला.

पण ती पूर्णपणे वेगळी कथा आहे...

स्त्रोत: www.habr.com