अराजकता का प्रबंधन: तकनीकी मानचित्र की सहायता से व्यवस्था लाना

चित्र: Unsplash

नमस्ते! हम कंपनी से ऑटोमेशन इंजीनियर हैं सकारात्मक प्रौद्योगिकी और हम कंपनी के उत्पादों के विकास के लिए सहायता प्रदान करते हैं: हम डेवलपर्स द्वारा कोड की एक पंक्ति के प्रतिबद्ध होने से लेकर अपडेट सर्वर पर तैयार उत्पादों और लाइसेंस के प्रकाशन तक संपूर्ण असेंबली पाइपलाइन का समर्थन करते हैं। अनौपचारिक रूप से, हमें DevOps इंजीनियर कहा जाता है। इस लेख में हम सॉफ़्टवेयर उत्पादन प्रक्रिया के तकनीकी चरणों के बारे में बात करना चाहते हैं, हम उन्हें कैसे देखते हैं और हम उन्हें कैसे वर्गीकृत करते हैं।

सामग्री से आप बहु-उत्पाद विकास के समन्वय की जटिलता के बारे में जानेंगे, एक तकनीकी मानचित्र क्या है और यह समाधानों को व्यवस्थित करने और दोहराने में कैसे मदद करता है, विकास प्रक्रिया के मुख्य चरण और चरण क्या हैं, जिम्मेदारी के क्षेत्रों को कैसे सीमांकित किया जाता है हमारी कंपनी में DevOps और टीमों के बीच।

अराजकता और DevOps के बारे में

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

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

समाधानों की विशिष्टता और क्रमबद्धता के बीच संतुलन कैसे पाया जाए?

ये प्रश्न 2015 से हमारे सामने अधिकाधिक बार उठने लगे। उत्पादों की संख्या में वृद्धि हुई, और हमने अपने स्वचालन विभाग (डेवऑप्स) का विस्तार करने का प्रयास किया, जो इन उत्पादों की असेंबली लाइनों का न्यूनतम समर्थन करता था। साथ ही, मैं उत्पादों के बीच यथासंभव अधिक से अधिक समाधान दोहराना चाहता था। आख़िर एक ही चीज़ को दस उत्पादों में अलग-अलग तरीक़े से क्यों किया जाए?

विकास निदेशक: "दोस्तों, क्या हम किसी तरह मूल्यांकन कर सकते हैं कि DevOps उत्पादों के लिए क्या करता है?"

हम: "हम नहीं जानते, हमने यह प्रश्न नहीं पूछा है, लेकिन किन संकेतकों की गणना की जानी चाहिए?"

विकास निदेशक: "कौन जानता है! सोचना..."

जैसा कि उस प्रसिद्ध फ़िल्म में है: "मैं होटल जा रहा हूँ!.." - "उह... क्या आप मुझे रास्ता दिखा सकते हैं?" सोचने के बाद, हम इस निष्कर्ष पर पहुंचे कि हमें पहले उत्पादों की अंतिम स्थिति पर निर्णय लेने की आवश्यकता है; यह हमारा पहला लक्ष्य बन गया.

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

1:0 कैओस, या ब्लेड्स पर डेवऑप्स के पक्ष में

हमने BPwin श्रृंखला से IDEF0 आरेख और विभिन्न व्यावसायिक प्रक्रिया आरेखों को लागू करने का प्रयास करके शुरुआत की। अगले प्रोजेक्ट के अगले चरण के पांचवें वर्ग के बाद भ्रम शुरू हुआ, और प्रत्येक प्रोजेक्ट के लिए इन वर्गों को 50+ चरणों में एक लंबे अजगर की पूंछ में खींचा जा सकता है। मुझे दुःख हुआ और मैं चाँद पर चिल्लाना चाहता था - यह बिल्कुल भी उपयुक्त नहीं था।

विशिष्ट उत्पादन कार्य

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

जब हमने अपनी उत्पादन प्रक्रिया का मॉडलिंग शुरू किया, तो हमारा एक विशिष्ट लक्ष्य था - हमारी कंपनी के उत्पादों के विकास में शामिल प्रत्येक कर्मचारी और परियोजना प्रबंधकों को बताना:

• उत्पाद और उनके घटक, कोड की एक पंक्ति की प्रतिबद्धता से शुरू होकर, इंस्टॉलर और अपडेट के रूप में ग्राहक तक कैसे पहुंचते हैं,
• उत्पाद उत्पादन के प्रत्येक चरण में कौन से संसाधन उपलब्ध कराए जाते हैं,
• प्रत्येक चरण में कौन सी सेवाएँ शामिल हैं,
• प्रत्येक चरण के लिए जिम्मेदारी के क्षेत्रों का सीमांकन कैसे किया जाता है,
• प्रत्येक चरण के इनपुट और आउटपुट पर कौन से अनुबंध मौजूद हैं।

पूर्ण आकार में खोलने के लिए छवि पर क्लिक करें

कंपनी में हमारा काम कई कार्यात्मक क्षेत्रों में विभाजित है। बुनियादी ढांचा विभाग विभाग के सभी हार्डवेयर संसाधनों के संचालन को अनुकूलित करने के साथ-साथ वर्चुअल मशीनों की तैनाती और उन पर पर्यावरण को स्वचालित करने में लगा हुआ है। निगरानी दिशा 24/7 सेवाओं के प्रदर्शन पर नियंत्रण प्रदान करती है; हम डेवलपर्स के लिए एक सेवा के रूप में निगरानी भी प्रदान करते हैं। वर्कफ़्लो दिशा टीमों को विकास और परीक्षण प्रक्रियाओं के प्रबंधन, कोड स्थिति का विश्लेषण करने और परियोजनाओं पर विश्लेषण प्राप्त करने के लिए उपकरण प्रदान करती है। और अंत में, वेबडेव डायरेक्शन GUS और FLUS अपडेट सर्वर पर रिलीज़ के प्रकाशन के साथ-साथ लाइसेंसलैब सेवा का उपयोग करके उत्पादों के लाइसेंस को सुनिश्चित करता है। उत्पादन पाइपलाइन का समर्थन करने के लिए, हम डेवलपर्स के लिए कई अलग-अलग समर्थन सेवाएँ स्थापित और बनाए रखते हैं (आप उनमें से कुछ के बारे में पुरानी मीटअप में कहानियाँ सुन सकते हैं: Op!DevOps! 2016 и Op!DevOps! 2017). हम आंतरिक स्वचालन उपकरण भी विकसित करते हैं, जिनमें शामिल हैं खुला स्रोत समाधान.

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

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

आप Habré पर हमारे अन्य लेखों में विशिष्ट DevOps कार्यों के बारे में पढ़ सकते हैं: "व्यक्तिगत अनुभव: हमारी सतत एकीकरण प्रणाली कैसी दिखती है"और"विकास प्रक्रियाओं का स्वचालन: हमने सकारात्मक तकनीकों पर DevOps के विचारों को कैसे लागू किया'.

कई विशिष्ट उत्पादन शृंखलाएँ बनती हैं निर्माण प्रक्रिया. प्रक्रियाओं का वर्णन करने के लिए मानक दृष्टिकोण कार्यात्मक IDEF0 मॉडल का उपयोग करना है।

उत्पादन सीआई प्रक्रिया के मॉडलिंग का एक उदाहरण

हमने सतत एकीकरण प्रणाली के लिए मानक परियोजनाओं के विकास पर विशेष ध्यान दिया। इससे तथाकथित पर प्रकाश डालते हुए परियोजनाओं के एकीकरण को प्राप्त करना संभव हो गया प्रमोशन के साथ बिल्ड का आरेख जारी करें.

यह ऐसे काम करता है। सभी प्रोजेक्ट विशिष्ट दिखते हैं: उनमें असेंबली का कॉन्फ़िगरेशन शामिल होता है जो आर्टिफैक्टरी पर स्नैपशॉट रिपॉजिटरी में जाता है, जिसके बाद उन्हें टेस्ट बेंच पर तैनात और परीक्षण किया जाता है, और फिर रिलीज़ रिपॉजिटरी में पदोन्नत किया जाता है। आर्टिफैक्टरी सेवा टीमों और अन्य सेवाओं के बीच सभी निर्मित कलाकृतियों को वितरित करने के लिए एक एकल बिंदु है।

यदि हम अपनी रिलीज़ योजना को बहुत सरल और सामान्यीकृत करते हैं, तो इसमें निम्नलिखित चरण शामिल हैं:

• क्रॉस-प्लेटफ़ॉर्म उत्पाद निर्माण,
• परीक्षण बेंचों पर तैनाती,
• कार्यात्मक और अन्य परीक्षण लॉन्च करना,
• आर्टिफैक्टरी पर रिपॉजिटरी जारी करने के लिए परीक्षण की गई असेंबली को बढ़ावा देना,
• सर्वरों को अद्यतन करने के लिए रिलीज़ बिल्ड का प्रकाशन,
• उत्पादन के लिए बिल्ड और अपडेट की डिलीवरी,
• इंस्टॉलेशन और उत्पाद अपडेट लॉन्च करना।

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

पूर्ण आकार में खोलने के लिए छवि पर क्लिक करें

एक नियम के रूप में, कार्यात्मक मॉडल में प्रक्रियाओं के विवरण को विघटित और विस्तृत करना आसान होता है। लेकिन जैसे-जैसे तत्वों की संख्या बढ़ती है, उनके बारे में कुछ समझना अधिक कठिन होता जाता है। लेकिन वास्तविक विकास में सहायक चरण भी होते हैं: निगरानी, ​​उत्पाद प्रमाणन, कार्य प्रक्रियाओं का स्वचालन और अन्य। स्केलिंग समस्या के कारण ही हमने इस विवरण को छोड़ दिया।

आशा का जन्म

एक पुस्तक में हमें तकनीकी प्रक्रियाओं का वर्णन करने वाले पुराने सोवियत मानचित्र मिले (जो, वैसे, आज भी कई राज्य के स्वामित्व वाले उद्यमों और विश्वविद्यालयों में उपयोग किए जाते हैं)। रुको, रुको, हमारे पास भी एक तकनीकी प्रक्रिया है! .. चरण, परिणाम, मैट्रिक्स, आवश्यकताएं, संकेतक इत्यादि आदि हैं... हमारे उत्पाद कन्वेयर पर तकनीकी मानचित्र लागू करने का प्रयास क्यों न करें? एक भावना थी: “यही है! हमें सही धागा मिल गया है, इसे अच्छी तरह खींचने का समय आ गया है!”

एक साधारण तालिका में, हमने उत्पादों को स्तंभों द्वारा, और तकनीकी चरणों और उत्पाद कन्वेयर के चरणों को पंक्तियों द्वारा रिकॉर्ड करने का निर्णय लिया। चरण कुछ बड़े होते हैं, जैसे किसी उत्पाद का संयोजन चरण। और चरण कुछ छोटे और अधिक विस्तृत होते हैं, उदाहरण के लिए, स्रोत कोड को बिल्ड सर्वर पर डाउनलोड करने का चरण या कोड संकलित करने का चरण।

मानचित्र की पंक्तियों और स्तंभों के प्रतिच्छेदन पर, हम एक विशिष्ट चरण और उत्पाद के लिए स्थितियाँ डालते हैं। कई राज्यों को स्थितियों के लिए परिभाषित किया गया है:

1. कोई जानकारी नहीं - या अव्यवहारिक. उत्पाद में एक चरण की मांग का विश्लेषण करना आवश्यक है। या तो विश्लेषण पहले ही किया जा चुका है, लेकिन वर्तमान में चरण की आवश्यकता नहीं है या यह आर्थिक रूप से उचित नहीं है।
2. स्थगित - या इस समय प्रासंगिक नहीं है। पाइपलाइन में इस चरण की आवश्यकता है, लेकिन इस वर्ष इसे लागू करने के लिए कोई ऊर्जा नहीं है।
3. अनुसूचित. इस वर्ष कार्यान्वयन के लिए चरण की योजना बनाई गई है।
4. कार्यान्वित. पाइपलाइन में चरण आवश्यक सीमा तक कार्यान्वित किया जाता है।

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

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

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

हमने प्रत्येक चरण और कदम के लिए आवश्यकताओं का मानक और काफी पूर्ण विवरण पेश किया ताकि कंपनी के भीतर सभी लोग उन्हें समान रूप से समझ सकें। समय के साथ, जैसे-जैसे सुधार लागू होते हैं, एक कदम को दूसरे चरण या कदम में समाहित किया जा सकता है - फिर वे ध्वस्त हो जाएंगे। साथ ही, सभी आवश्यकताएं और तकनीकी बारीकियां सामान्यीकरण चरण या चरण की आवश्यकताओं में फिट होती हैं।

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

विकास के हिस्से पहले से ही मानचित्र पर चरणों और चरणों के रूप में प्रतिबिंबित होते हैं। हम विशिष्ट चरणों के लिए स्वचालन की शुरूआत के माध्यम से उत्पाद लागत में कमी को प्रभावित कर सकते हैं। इसके बाद, हम गुणात्मक विशेषताओं, मात्रात्मक मेट्रिक्स और टीमों द्वारा प्राप्त लाभ (मानव-घंटे या मशीन-घंटे बचाए गए) में परिवर्तन की गणना करते हैं।

उत्पादन प्रक्रिया का तकनीकी मानचित्र

यदि हम अपने सभी चरणों और चरणों को लेते हैं, उन्हें टैग के साथ एन्कोड करते हैं और उन्हें एक श्रृंखला में विस्तारित करते हैं, तो यह बहुत लंबा और समझ से बाहर हो जाएगा (बिल्कुल वही "पायथन टेल" जिसके बारे में हमने लेख की शुरुआत में बात की थी) :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

ये उत्पादों को असेंबल करने [बिल्ड करने], उन्हें टेस्ट सर्वर पर तैनात करने [तैनाती], परीक्षण [टेस्ट], परीक्षण परिणामों के आधार पर रिपॉजिटरी जारी करने के लिए असेंबली को बढ़ावा देने [प्रचार], लाइसेंस बनाने और प्रकाशित करने [लाइसेंस], प्रकाशन [प्रकाशन] के चरण हैं। GUS अपडेट सर्वर पर और सर्वर पर FLUS अपडेट की डिलीवरी, उत्पाद कॉन्फ़िगरेशन प्रबंधन [इंस्टॉल] का उपयोग करके ग्राहक के बुनियादी ढांचे पर उत्पाद घटकों की स्थापना और अद्यतन, साथ ही स्थापित उत्पादों से टेलीमेट्री [टेलीमेट्री] का संग्रह।

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

यदि आप इसकी कल्पना रूप में करें तो संपूर्ण उत्पादन प्रक्रिया को समझना और देखना बहुत आसान हो जाएगा तकनीकी मानचित्र; यह एक तालिका है जिसमें मॉडल के व्यक्तिगत उत्पादन चरणों और विघटित चरणों को पंक्तियों में दर्ज किया गया है, और कॉलम में प्रत्येक चरण या चरण में क्या किया जाता है इसका विवरण दिया गया है। मुख्य जोर उन संसाधनों पर है जो प्रत्येक चरण को प्रदान करते हैं और जिम्मेदारी के क्षेत्रों का परिसीमन करते हैं।

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

हमारी कंपनी के अंदर, नक्शा स्वचालित रूप से एक नियमित HTML फ़ाइल के रूप में जिंजा टेम्पलेट से उत्पन्न होता है, और फिर GitLab पेज सर्वर पर अपलोड किया जाता है। पूरी तरह से तैयार किए गए मानचित्र के उदाहरण के साथ एक स्क्रीनशॉट देखा जा सकता है по ссылке.

पूर्ण आकार में खोलने के लिए छवि पर क्लिक करें

संक्षेप में, एक तकनीकी मानचित्र उत्पादन प्रक्रिया की एक सामान्यीकृत तस्वीर है, जो मानक कार्यक्षमता के साथ स्पष्ट रूप से वर्गीकृत ब्लॉकों को दर्शाता है।

हमारे तकनीकी मानचित्र की संरचना

मानचित्र में कई भाग होते हैं:

1. शीर्षक क्षेत्र - यहां मानचित्र का सामान्य विवरण दिया गया है, बुनियादी अवधारणाओं का परिचय दिया गया है, और उत्पादन प्रक्रिया के मुख्य संसाधनों और परिणामों को परिभाषित किया गया है।
2. सूचना पैनल - यहां आप व्यक्तिगत उत्पादों के लिए डेटा के प्रदर्शन को नियंत्रित कर सकते हैं; सभी उत्पादों के लिए सामान्य रूप से कार्यान्वित चरणों और चरणों का सारांश प्रदान किया गया है।
3. तकनीकी मानचित्र - तकनीकी प्रक्रिया का सारणीबद्ध विवरण। नक़्शे पर:
   • सभी चरण, चरण और उनके कोड दिए गए हैं;
   • चरणों का संक्षिप्त और पूर्ण विवरण दिया गया है;
   • प्रत्येक चरण में उपयोग किए जाने वाले इनपुट संसाधनों और सेवाओं का संकेत दिया गया है;
   • प्रत्येक चरण और व्यक्तिगत चरण के परिणाम दर्शाए गए हैं;
   • प्रत्येक चरण और चरण के लिए जिम्मेदारी का क्षेत्र दर्शाया गया है;
   • तकनीकी संसाधन निर्धारित किए गए हैं, उदाहरण के लिए एचडीडी (एसएसडी), रैम, वीसीपीयू, और इस स्तर पर काम का समर्थन करने के लिए आवश्यक मानव-घंटे, दोनों वर्तमान में - तथ्य, और भविष्य में - योजना;
   • प्रत्येक उत्पाद के लिए यह इंगित किया जाता है कि इसके लिए कौन से तकनीकी चरण या कदम लागू किए गए हैं, कार्यान्वयन की योजना बनाई गई है, अप्रासंगिक हैं या लागू नहीं किए गए हैं।

तकनीकी मानचित्र के आधार पर निर्णय लेना

मानचित्र का अध्ययन करने के बाद, आप कंपनी में कर्मचारी की भूमिका (विकास प्रबंधक, उत्पाद प्रबंधक, डेवलपर या परीक्षक) के आधार पर कुछ कार्रवाई कर सकते हैं:

• समझें कि किसी वास्तविक उत्पाद या परियोजना में कौन से चरण गायब हैं और उनके कार्यान्वयन की आवश्यकता का आकलन करें;
• यदि कई विभाग विभिन्न चरणों में काम कर रहे हैं तो उनके बीच जिम्मेदारी के क्षेत्रों का परिसीमन करें;
• चरणों के इनपुट और आउटपुट के लिए अनुबंध पर बातचीत करना;
• अपने कार्य के चरण को समग्र विकास प्रक्रिया में एकीकृत करें;
• प्रत्येक चरण का समर्थन करने के लिए संसाधनों की आवश्यकता का अधिक सटीक आकलन करें।

उपरोक्त सभी का सारांश

प्रौद्योगिकी मानचित्र बहुमुखी, विस्तार योग्य और रखरखाव में आसान है। सख्त शैक्षणिक आईडीईएफ0 मॉडल की तुलना में इस फॉर्म में प्रक्रिया विवरण विकसित करना और बनाए रखना बहुत आसान है। इसके अलावा, एक सारणीबद्ध विवरण एक कार्यात्मक मॉडल की तुलना में सरल, अधिक परिचित और बेहतर संरचित है।

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

परिणाम

लेख काफी लंबा निकला, लेकिन जटिल प्रक्रियाओं के मॉडलिंग का वर्णन करते समय यह अपरिहार्य है। अंत में, मैं संक्षेप में हमारे मुख्य विचार बताना चाहूँगा:

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

निम्नलिखित लेखों में हम इस बारे में अधिक विस्तार से बात करेंगे कि हमारे मानचित्र पर कुछ तकनीकी चरणों को लागू करने के लिए किन तकनीकी उपकरणों का उपयोग किया जाता है।

लेख के लेखक:

• अलेक्जेंडर पज़्डनिकोव - पॉजिटिव टेक्नोलॉजीज में ऑटोमेशन विभाग (डेवऑप्स) के प्रमुख
• तैमूर गिलमुलिन - डिप्टी पॉजिटिव टेक्नोलॉजीज में ऑटोमेशन विभाग (डेवऑप्स) के प्रमुख

स्रोत: www.habr.com