अराजकता प्रबंधन: रूटिंग के साथ सफाई करें

चित्र: अनप्लैश

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

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

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

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

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

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

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

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

हम : "हम नहीं जानते, हमने खुद से ऐसा सवाल नहीं पूछा था, लेकिन क्या संकेतक पर विचार किया जाना चाहिए?"

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

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

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

1: 0 अराजकता के पक्ष में, या कंधे के ब्लेड पर DevOps

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

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

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

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

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

चित्र पर क्लिक करने से पूर्ण आकार में खुल जाएगा

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

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



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

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

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

एक उत्पादन CI प्रक्रिया मॉडलिंग का एक उदाहरण है

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



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

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

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

उदाहरण के लिए, इस कार्यात्मक रिलीज़ स्कीम के तकनीकी मॉडल पर विचार करें (बाद में बस मॉडल के रूप में संदर्भित) एक कार्यात्मक आईडीईएफ मॉडल के रूप में। यह हमारी CI प्रक्रिया के मुख्य चरणों को दर्शाता है। 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] 

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

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

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

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

हमारी कंपनी के अंदर, नियमित HTML फ़ाइल के रूप में एक नक्शा स्वचालित रूप से एक jinja टेम्पलेट से उत्पन्न होता है, और फिर GitLab Pages सर्वर पर अपलोड किया जाता है। एक पूरी तरह से उत्पन्न नक्शे के उदाहरण के साथ एक स्क्रीनशॉट यहाँ देखा जा सकता है ।



चित्र पर क्लिक करने से पूर्ण आकार में खुल जाएगा

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

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

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

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

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

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

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

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

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

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

परिणाम

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

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

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

लेख के लेखक:

• अलेक्जेंडर पज़डनिकोव - स्वचालन के प्रमुख (DevOps), सकारात्मक प्रौद्योगिकी
• तैमूर गिल्मुलिन - डिप्टी। ऑटोमेशन (DevOps) के प्रमुख, सकारात्मक प्रौद्योगिकी