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

हम सभी अपनी सफलताओं के बारे में बात करना पसंद करते हैं और असफलताओं के बारे में बात करना पसंद नहीं करते। लेकिन गलतियों का अनुभव अक्सर सफलतापूर्वक संपन्न व्यवसाय से लाभ से अधिक मूल्यवान होता है। इसलिए, मैं आज ऐसे मामलों के बारे में बात करना चाहूंगा। तो चलिए जाने ...

बर्तन, पकाओ मत!

यह कहानी कुछ साल पहले, 1C डेवलपर के रूप में मेरे करियर की शुरुआत में आई थी।

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

इस तरह की किसी भी अन्य परियोजना की तरह, यह डेटा संग्रह के साथ शुरू हुआ। यह मान लिया गया था कि हम पहले एक महीने के भीतर विभिन्न संकेतक एकत्र करेंगे, और फिर हम स्वयं सूचना के आधार को अनुकूलित करने में लगे रहेंगे। इस नौकरशाही परिवेश में एमसीसी को स्थापित करने में कैसे और कितना समय लगा, यह एक अलग कहानी के लिए भौतिक है। लेकिन अब, कुछ बिंदु पर, यह हुआ, MCC कॉन्फ़िगर किया गया और शुरू हुआ। उसके बाद, इस परियोजना का संचालन करने वाले विशेषज्ञ (डिमा, हाय!) अपनी शानदार कार में चले गए और हमारे विशाल देश में घूमने गए, और फिर पड़ोसी देशों में गए। लेकिन तब, वास्तव में, मैं अभी भी बहुत कम जानता था और जानता था कि कैसे, लेकिन मुझे पहले से ही काफी जिम्मेदार डेवलपर माना जाता था। इसलिए, छोड़ने से पहले, दिमित्री ने मुझे एक बहुत ही महत्वपूर्ण और गंभीर कार्य सौंपा: दिन में 2 बार, पीक लोड के समय, मुझे उस गुप्त कंप्यूटर पर जाना पड़ा और एमसीसी में माप शुरू करना पड़ा, और एक घंटे के बाद उन्हें बंद कर दिया। निर्देश बेहद सरल और स्पष्ट थे:

- देखिए, आप इस छोटे हरे बटन "प्ले" को दबाएं, अलग-अलग चार्ट चलाएं, एक घंटा प्रतीक्षा करें, फिर आप इस बटन को दबाएं - "रोकें"। वह सब है।

क्या आसान हो सकता है, है ना? गणित संकाय में मैंने 5 साल तक अध्ययन किया?

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

शनिवार की सुबह एक कॉल के साथ शुरू हुई। हमें क्लाइंट पर सभी 1C-वें आधार मिले। अचतुंग और अनर्थ! हमारा विशेषज्ञ कहीं नेटवर्क एक्सेस क्षेत्र के बाहर, Dzheyrakh और Pasanauri के बीच है। क्लाइंट का मुख्य व्यवस्थापक कुछ देश के घर और दुर्गम में भी है। फोन पर पता लगाने की कोशिश की जा रही है, इसका कारण क्या है? किसी तरह यह पता चला कि डिस्क स्थान बाहर चला गया है, इसलिए 1 सी एजेंट सेवा उठ गई। यहाँ मैं पहले से ही कुछ पर शक करने लगा ...

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

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

देर रात को ही दीमा ने संपर्क किया और कहा कि आपको सिर्फ 1 सी सर्वर पर एक छोटी फाइल को डिलीट करने की जरूरत है। बाद में, कुछ हफ़्ते बाद, मैंने एक प्रसिद्ध "डेस्क" पुस्तक में उसके बारे में पढ़ा, लेकिन उस दिन, थका हुआ, सोने के लिए घर चला गया।

सोमवार की सुबह, जब तक दिमित्री छुट्टी से नहीं लौटी, तब तक हमारा खाता अवरुद्ध था, और यह मेरे खाते से काफी स्पष्ट रूप से कहा गया था: "ताकि हम उसे फिर से न देखें!"

इस तरह मेरे लिए मेरा पहला अनुकूलन प्रोजेक्ट समाप्त हो गया।

एक कीप में दो बार

बड़ी जोत। देश भर में स्थित समरूप विन्यास के साथ 18 सूचना आधार। अपडेट सप्ताह में एक बार होता है और वही अनुष्ठान होता है: डिलीवरी फ़ाइल को अग्रिम रूप से तैयार किया जाना चाहिए, क्लाउड पर अपलोड किया जाना चाहिए, सुनिश्चित करें कि यह सभी शाखाओं में डाउनलोड किया गया है (2018 में भी, कुछ क्षेत्रों में इंटरनेट 1C (ERP) की तुलना में धीमा है) जाँचें कि बैकअप हर जगह बनाए गए थे (हम इसके लिए ज़िम्मेदार नहीं लग रहे हैं, लेकिन कड़वा अनुभव ने हमें सुरक्षित रहने के लिए सिखाया है), फिर प्रत्येक शाखा में अपडेट स्क्रिप्ट को मैन्युअल रूप से चलाएं और सुनिश्चित करें कि यह त्रुटियों के बिना काम करता है। अक्सर आखिरी समय में यह पता चलता है कि डिलीवरी में एक और कार्य शामिल किया जाना है और यह एक मामूली सुधार है, क्योंकि अगला अपडेट केवल एक सप्ताह में है।

तो यह उस समय था। कई वर्षों के अनुभव के साथ एक अनुभवी डेवलपर ने एक कार्य को युद्ध सर्किट में स्थानांतरित करते समय एक पंक्ति में गलती की। त्रुटि गंभीर हो गई, यह सभी डेटाबेस को अपडेट करने के बाद पता चला।

वैसे क्या करना है? डेवलपर कोड को जल्दी ठीक करता है। किसी को भी परीक्षा नहीं देनी चाहिए:

- हां, कचरा है ... मैं एक पंक्ति में दो बार गलती नहीं कर सकता हूं?

एक घंटे बाद, 18 शाखाओं को तीसरी बार अपडेट किया गया।

डेवलपर जो कर सकता है

स्काइप पर एक सहयोगी द्वारा बताई गई कहानी।
[सहयोगी]: एक बार एक "डेवलपर जो कर सकता था!" उसके पास एक विकास पोशाक थी। वह एक परीक्षण खोलना चाहते थे, लेकिन चूक गए, और एक उत्पादक खोला ...
[सहयोगी]: लेकिन क्या यह "डेवलपर को रोक सकता है"? नहीं!
[I]: और अपडेट करते समय, वह यह नहीं समझ पाया कि वहाँ लोग बैठे थे, जैसे कि वह थे? ))
[सहकर्मी]: इसके अलावा, वह देखता है कि konf समर्थन पर है ... लेकिन क्या आपको लगता है कि यह "डेवलपर जो रोक सकता था" रोक सकता है? नहीं!
[सहयोगी]: वह समर्थन (!) से कॉन्फ़िगरेशन निकालता है और सभी रिपॉजिटरी को दरकिनार करते हुए अपने मॉड को देखता है ...
[मैं]: यह बात नहीं है! कहानी खत्म, गतिशील अद्यतन)))
[सहयोगी]: अपडेट ... सिस्टम कहता है: "डेटाबेस में 18 सक्रिय सत्र हैं!"। लेकिन यह "डेवलपर जो कर सकता था" को कैसे रोक सकता है? नहीं और फिर नहीं!
[सहकर्मी]: वह डेटाबेस को अपडेट करता है और कार्य को परीक्षण में पास करता है ...
[सहयोगी]: सलाहकार आउटफिट नहीं ढूँढ सकता ... और तभी, लंबे समय के बाद, उसे पता चलता है कि वह चूक गया।
[सहयोगी]: मुझे उसे डांटना पड़ा ...
[सहयोगी]: मैं उसे फोन कर रहा हूं ... और मैं फोन में हंस रहा हूं ...
[सहकर्मी]: मैं सिर्फ यह नहीं समझता ... कैसे ???

परिवहन ढहना

एक सहकर्मी द्वारा बताई गई कहानी और उसके शब्दों से रिकॉर्ड की गई।

यह एक बड़ी लॉजिस्टिक कंपनी में हुआ। अधिकांश व्यावसायिक प्रक्रियाएं एक सूचना आधार में केंद्रित होती हैं। 2012 के लिए प्रतिस्पर्धी उपयोगकर्ता - देश के सभी क्षेत्रों के लगभग 3,000 लोग।

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

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

उस दुर्भाग्यपूर्ण शुक्रवार की सुबह, हमने लड़ाकू बेस को अपडेट किया, और उपयोगकर्ताओं ने काम करना शुरू कर दिया। 3000 लोगों ने खुशी-खुशी दस्तावेज भरे और रजिस्टर डेटा से भरे जाने लगे। यह जांचने के बाद कि सब कुछ ठीक चल रहा था, कुछ घंटों बाद हम एक शांत आत्मा के साथ घर गए (हम सूचना के मुख्य उपयोगकर्ताओं के साथ अलग-अलग समय क्षेत्रों में काम करते हैं)।

यह ध्यान दिया जाना चाहिए कि जिन सर्वरों पर आईएस चल रहा था वे रूस में 1C के तहत उपयोग किए जाने वाले लगभग सबसे शक्तिशाली हैं। लेकिन कुछ घंटों के बाद "कुछ गलत हो गया" (ग)।

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

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

उस समय तक, कुछ उपयोगकर्ताओं के अनुसार, एक परिवहन पतन पहले ही हो चुका था, क्योंकि कारों को 1 सी से दस्तावेज़ प्राप्त नहीं हुए और अनलोडिंग अंक नहीं छोड़ सकते थे।

इसलिए, "बस" रिकॉर्डसेट में चयन करना भूल गया, मैंने रूस में 1C के सबसे बड़े डेटाबेस में से एक डाल दिया।

PS यह भी देखें:

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