अराजकता प्रबन्ध गर्नुहोस्: प्राविधिक नक्साको मद्दतले अर्डर ल्याउने

तस्वीर: Unsplash

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

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

Chaos र DevOps को बारेमा

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

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

समाधानको विशिष्टता र क्रमिकता बीचको सन्तुलन कसरी पत्ता लगाउने?

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

विकास निर्देशक: "साथीहरू, के हामी उत्पादनहरूको लागि DevOps ले के गर्छ भनेर मूल्याङ्कन गर्न सक्छौं?"

हामी: "हामीलाई थाहा छैन, हामीले यो प्रश्न सोधेका छैनौं, तर कुन सूचकहरू गणना गर्नुपर्छ?"

विकास निर्देशक: "कसलाई थाँहा छ! सोच..."

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

त्यसोभए, तपाइँ कसरी 10 देखि 200 व्यक्तिहरूको पर्याप्त ठूलो टोलीसँग एक दर्जन उत्पादनहरू विश्लेषण गर्न सक्नुहुन्छ र समाधानहरू प्रतिकृति गर्दा मापनयोग्य मेट्रिक्स निर्धारण गर्न सक्नुहुन्छ?

1:0 Chaos को पक्षमा, वा DevOps on the ब्लेड

हामीले BPwin शृङ्खलाबाट IDEF0 रेखाचित्रहरू र विभिन्न व्यापार प्रक्रिया रेखाचित्रहरू लागू गर्ने प्रयास गरेर सुरु गर्यौं। अर्को परियोजनाको अर्को चरणको पाँचौं वर्ग पछि भ्रम सुरु भयो, र प्रत्येक परियोजनाका लागि यी वर्गहरूलाई ५०+ चरणहरूमा लामो अजगरको पुच्छरमा तान्न सकिन्छ। मलाई दुःख लाग्यो र चन्द्रमामा रुन मन लाग्यो - यो पटक्कै फिट भएन।

सामान्य उत्पादन कार्यहरू

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

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

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

पूर्ण आकारमा खोल्न छविमा क्लिक गर्नुहोस्

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

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

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

तपाईंले हाब्रेमा हाम्रा अन्य लेखहरूमा विशिष्ट DevOps कार्यहरूको बारेमा पढ्न सक्नुहुन्छ: “व्यक्तिगत अनुभव: हाम्रो निरन्तर एकीकरण प्रणाली कस्तो देखिन्छ"र"विकास प्रक्रियाहरूको स्वचालन: हामीले कसरी सकारात्मक टेक्नोलोजीहरूमा DevOps विचारहरू लागू गर्यौं"।

धेरै विशिष्ट उत्पादन चेनहरू बन्छन् निर्माण प्रक्रिया। प्रक्रियाहरू वर्णन गर्न मानक दृष्टिकोण कार्यात्मक IDEF0 मोडेलहरू प्रयोग गर्नु हो।

उत्पादन CI प्रक्रिया मोडेलिङ को एक उदाहरण

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

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

यदि हामीले हाम्रो रिलीज योजनालाई धेरै सरल र सामान्यीकरण गर्छौं भने, यसले निम्न चरणहरू समावेश गर्दछ:

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

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

पूर्ण आकारमा खोल्न छविमा क्लिक गर्नुहोस्

नियमको रूपमा, कार्यात्मक मोडेलहरूमा यो विघटन गर्न र प्रक्रियाहरूको विवरण विस्तार गर्न सजिलो छ। तर तत्वहरूको संख्या बढ्दै जाँदा, तिनीहरूको बारेमा केही बुझ्न गाह्रो हुन्छ। तर वास्तविक विकासमा त्यहाँ सहायक चरणहरू पनि छन्: अनुगमन, उत्पादन प्रमाणीकरण, कार्य प्रक्रियाहरूको स्वचालन र अन्य। यो ठ्याक्कै मापन समस्या को कारण हो कि हामीले यो विवरण त्याग्यौं।

आशाको जन्म

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

В простой таблице мы решили по столбцам фиксировать продукты, а по строкам — технологические этапы и шаги продуктового конвейера. Этапы — это нечто крупное, например этап сборки продукта. А шаги — это что-то более мелкое и детальное, например шаг скачивания исходного кода на сборочный сервер или шаг компиляции кода.

नक्साको पङ्क्ति र स्तम्भहरूको चौराहेमा, हामीले एक विशिष्ट चरण र उत्पादनको लागि स्थितिहरू राख्छौं। धेरै राज्यहरू स्थितिहरूको लागि परिभाषित गरिएको छ:

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 अद्यावधिकहरूको डेलिभरी, उत्पादन कन्फिगरेसन व्यवस्थापन [स्थापना] प्रयोग गरेर ग्राहकको पूर्वाधारमा उत्पादन घटकहरूको स्थापना र अद्यावधिक गर्ने, साथै स्थापित उत्पादनहरूबाट टेलिमेट्री [टेलीमेट्री] को सङ्कलन।

तिनीहरूका अतिरिक्त, हामी अलग-अलग चरणहरू छुट्याउन सक्छौं: पूर्वाधारको अवस्थाको निगरानी [InfMonitoring], स्रोत कोड [SourceCodeControl] को संस्करणहरू प्रबन्ध गर्ने, सम्मेलन वातावरण तयार गर्ने [तयारी], परियोजना व्यवस्थापन [कार्यप्रवाह], सञ्चार उपकरणहरू प्रदान गर्ने टोलीहरू [ संचार], उत्पादन प्रमाणीकरण [प्रमाणीकरण] र CI प्रक्रियाहरूको आत्म-पर्याप्तता सुनिश्चित गर्दै [CISelfSufficiency] (उदाहरणका लागि, इन्टरनेटबाट सम्मेलनहरूको स्वतन्त्रता)। हामी हाम्रा प्रक्रियाहरूमा दर्जनौं चरणहरू पनि विचार गर्दैनौं, किनभने तिनीहरू धेरै विशिष्ट छन्।

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

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

Внутри нашей компании карта автоматически генерируется из jinja-шаблона в виде обычного HTML-файла, а затем выкладывается на сервер GitLab Pages. Скриншот с примером полностью сгенерированной карты можно посмотреть लिङ्क.

पूर्ण आकारमा खोल्न छविमा क्लिक गर्नुहोस्

छोटकरीमा भन्नुपर्दा, प्राविधिक नक्सा उत्पादन प्रक्रियाको सामान्यीकृत तस्वीर हो, जसले मानक कार्यक्षमताका साथ स्पष्ट रूपमा वर्गीकृत ब्लकहरू प्रतिबिम्बित गर्दछ।

हाम्रो प्राविधिक नक्साको संरचना

नक्सा धेरै भागहरु मिलेर बनेको छ:

1. Область заголовков — здесь находится общее описание карты, вводятся базовые понятия, определяются основные ресурсы и результаты производственного процесса.
2. सूचना प्यानल - यहाँ तपाईले व्यक्तिगत उत्पादनहरूको लागि डेटाको प्रदर्शन नियन्त्रण गर्न सक्नुहुन्छ; लागू गरिएका चरणहरूको सारांश र सबै उत्पादनहरूको लागि सामान्य रूपमा चरणहरू प्रदान गरिएको छ।
3. प्राविधिक नक्सा - प्राविधिक प्रक्रिया को तालिका विवरण। नक्सामा:
   • सबै चरणहरू, चरणहरू र तिनीहरूका कोडहरू दिइएको छ;
   • चरणहरूको संक्षिप्त र पूर्ण विवरण दिइएको छ;
   • प्रत्येक चरणमा प्रयोग गरिएका इनपुट स्रोतहरू र सेवाहरू संकेत गरिएका छन्;
   • प्रत्येक चरण र व्यक्तिगत चरण को नतिजा संकेत गरिएको छ;
   • प्रत्येक चरण र चरणको लागि जिम्मेवारीको क्षेत्र संकेत गरिएको छ;
   • प्राविधिक स्रोतहरू निर्धारण गरिएको छ, उदाहरणका लागि HDD (SSD), RAM, vCPU, र यस चरणमा कामलाई समर्थन गर्न आवश्यक म्यान-घण्टाहरू, दुवै वर्तमान - तथ्य, र भविष्यमा - योजना;
   • प्रत्येक उत्पादनको लागि यो कुन प्राविधिक चरणहरू वा यसको लागि चरणहरू लागू गरिएको छ, कार्यान्वयनको लागि योजना गरिएको छ, अप्रासंगिक छन् वा लागू गरिएको छैन भनेर संकेत गरिएको छ।

प्राविधिक नक्साको आधारमा निर्णय लिने

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

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

माथिका सबै संक्षेप

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

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

परिणामहरू

लेख धेरै लामो भयो, तर जटिल प्रक्रियाहरूको मोडेलिङ वर्णन गर्दा यो अपरिहार्य छ। अन्तमा, म हाम्रा मुख्य विचारहरू संक्षिप्त रूपमा बताउन चाहन्छु:

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

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

लेखका लेखकहरू:

• अलेक्जेंडर Pazdnikov - सकारात्मक टेक्नोलोजीहरूमा स्वचालन विभाग (DevOps) को प्रमुख
• तैमुर गिलमुलिन - उप सकारात्मक टेक्नोलोजीहरूमा स्वचालन विभाग (DevOps) को प्रमुख

स्रोत: www.habr.com