अराजकता व्यवस्थापित करणे: तांत्रिक नकाशाच्या मदतीने सुव्यवस्था आणणे

चित्र: Unsplash

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

बहु-उत्पादन विकासाचे समन्वय साधण्याची जटिलता, तांत्रिक नकाशा काय आहे आणि ते उपायांचे आयोजन आणि प्रतिकृती तयार करण्यास कशी मदत करते, विकास प्रक्रियेत कोणते मुख्य टप्पे आणि पायऱ्या असतात, जबाबदारीची क्षेत्रे कशी निर्धारित केली जातात याबद्दल आपण सामग्रीमधून शिकाल. आमच्या कंपनीतील DevOps आणि संघ यांच्यात.

Chaos आणि DevOps बद्दल

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

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

विशिष्टता आणि सोल्यूशन्सची क्रमिकता यांच्यातील समतोल कसा शोधायचा?

2015 पासून हे प्रश्न अधिकाधिक वेळा आपल्यासमोर येऊ लागले. उत्पादनांची संख्या वाढली, आणि आम्ही आमच्या ऑटोमेशन विभागाचा (DevOps) विस्तार करण्याचा प्रयत्न केला, ज्याने या उत्पादनांच्या असेंबली लाईन्सला समर्थन दिले, ते कमीत कमी. त्याच वेळी, मला उत्पादनांमध्ये शक्य तितक्या सोल्यूशन्सची प्रतिकृती बनवायची होती. शेवटी, दहा उत्पादनांमध्ये एकच गोष्ट वेगवेगळ्या प्रकारे का करायची?

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

आम्ही: "आम्हाला माहित नाही, आम्ही हा प्रश्न विचारला नाही, परंतु कोणत्या निर्देशकांची गणना केली पाहिजे?"

विकास संचालक: "कोणास ठाऊक! विचार करा..."

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

तर, 10 ते 200 लोकांच्या बर्‍यापैकी मोठ्या संघांसह आपण डझन उत्पादनांचे विश्लेषण कसे करू शकता आणि उपायांची प्रतिकृती तयार करताना मोजता येण्याजोगे मेट्रिक्स कसे ठरवू शकता?

1:0 Chaos च्या बाजूने, किंवा DevOps on the ब्लेड

आम्ही BPwin मालिकेतील IDEF0 आकृत्या आणि विविध व्यवसाय प्रक्रिया आकृत्या लागू करण्याचा प्रयत्न करून सुरुवात केली. पुढील प्रकल्पाच्या पुढील टप्प्यातील पाचव्या चौकोनानंतर गोंधळ सुरू झाला आणि प्रत्येक प्रकल्पासाठी हे चौरस 50+ पायऱ्यांमध्ये लांब अजगराच्या शेपटीत काढले जाऊ शकतात. मला वाईट वाटले आणि मला चंद्रावर ओरडायचे होते - ते अजिबात बसत नाही.

ठराविक उत्पादन कार्ये

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

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

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

पूर्ण आकारात उघडण्यासाठी प्रतिमेवर क्लिक करा

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

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

तांत्रिक साखळीचे सर्वात सोपे उदाहरण म्हणजे कंपनीमधील आमच्या प्रत्येक उत्पादनाचे असेंब्ली, उपयोजन आणि चाचणीचे टप्पे. या बदल्यात, उदाहरणार्थ, बिल्ड स्टेजमध्ये अनेक स्वतंत्र मानक पायऱ्यांचा समावेश आहे: GitLab वरून स्त्रोत डाउनलोड करणे, अवलंबित्व आणि तृतीय-पक्ष लायब्ररी तयार करणे, युनिट चाचणी आणि स्थिर कोड विश्लेषण, GitLab CI वर बिल्ड स्क्रिप्ट कार्यान्वित करणे, आर्टिफॅक्ट्स रिपॉजिटरीमध्ये प्रकाशित करणे. आमच्या अंतर्गत ChangelogBuilder टूलद्वारे आर्टिफॅक्टरी आणि रिलीझ नोट्स तयार करणे.

Habré वरील आमच्या इतर लेखांमध्ये तुम्ही ठराविक DevOps कार्यांबद्दल वाचू शकता: “वैयक्तिक अनुभव: आमची सतत एकत्रीकरण प्रणाली कशी दिसते"आणि"विकास प्रक्रियांचे ऑटोमेशन: आम्ही सकारात्मक तंत्रज्ञानावर DevOps कल्पना कशा लागू केल्या».

अनेक विशिष्ट उत्पादन साखळी तयार होतात उत्पादन प्रक्रिया. प्रक्रियांचे वर्णन करण्याचा मानक दृष्टीकोन म्हणजे कार्यात्मक IDEF0 मॉडेल्स वापरणे.

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

आम्ही सतत एकीकरण प्रणालीसाठी मानक प्रकल्पांच्या विकासावर विशेष लक्ष दिले. यामुळे तथाकथित हायलाइट करून प्रकल्पांचे एकीकरण साध्य करणे शक्य झाले जाहिरातींसह बिल्डचे प्रकाशन आकृती.

ते कसे कार्य करते ते येथे आहे. सर्व प्रकल्प वैशिष्ट्यपूर्ण दिसतात: त्यामध्ये आर्टिफॅक्टरीवरील स्नॅपशॉट रिपॉझिटरीमध्ये जाणार्‍या असेंब्लीचे कॉन्फिगरेशन समाविष्ट असते, त्यानंतर ते चाचणी बेंचवर तैनात केले जातात आणि त्यांची चाचणी केली जाते आणि नंतर रिलीझ रिपॉझिटरीमध्ये पदोन्नती केली जाते. आर्टिफॅक्टरी सर्व्हिस हा सर्व बिल्ड आर्टिफॅक्ट्स संघ आणि इतर सेवांमध्ये वितरीत करण्यासाठी एकच बिंदू आहे.

जर आम्ही आमची रिलीझ योजना मोठ्या प्रमाणात सरलीकृत आणि सामान्यीकृत केली, तर त्यात खालील टप्पे समाविष्ट आहेत:

• क्रॉस-प्लॅटफॉर्म उत्पादन तयार करणे,
• चाचणी बेंचवर तैनाती,
• कार्यात्मक आणि इतर चाचण्या सुरू करणे,
• आर्टिफॅक्टरीवर रेपॉजिटरीज सोडण्यासाठी चाचणी केलेल्या असेंब्लीची जाहिरात,
• प्रकाशन प्रकाशन सर्व्हर अद्यतनित करण्यासाठी तयार करते,
• बिल्डचे वितरण आणि उत्पादनासाठी अद्यतने,
• स्थापना आणि उत्पादन अद्यतने लाँच करत आहे.

उदाहरण म्हणून, या ठराविक प्रकाशन योजनेचे तांत्रिक मॉडेल (यापुढे फक्त मॉडेल म्हणून संदर्भित) फंक्शनल 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] (उदाहरणार्थ, इंटरनेटवरून असेंब्लीचे स्वातंत्र्य). आम्ही आमच्या प्रक्रियेतील डझनभर पायऱ्यांचा विचारही करणार नाही, कारण ते अतिशय विशिष्ट आहेत.

जर तुम्ही त्याची फॉर्ममध्ये कल्पना केली तर ते समजून घेणे आणि संपूर्ण उत्पादन प्रक्रिया पाहणे खूप सोपे होईल तांत्रिक नकाशा; हे एक सारणी आहे ज्यामध्ये मॉडेलचे वैयक्तिक उत्पादन टप्पे आणि विघटित चरण पंक्तींमध्ये रेकॉर्ड केले जातात आणि स्तंभांमध्ये प्रत्येक टप्प्यावर किंवा चरणावर काय केले जाते याचे वर्णन आहे. प्रत्येक टप्पा आणि जबाबदारीच्या क्षेत्रांचे सीमांकन प्रदान करणार्‍या संसाधनांवर मुख्य भर आहे.

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

आमच्‍या कंपनीमध्‍ये, नकाशा नियमित HTML फाईल म्‍हणून जिन्जा टेम्‍पलेटवरून आपोआप व्युत्पन्न केला जातो आणि नंतर GitLab Pages सर्व्हरवर अपलोड केला जातो. पूर्णतः व्युत्पन्न केलेल्या नकाशाच्या उदाहरणासह स्क्रीनशॉट पाहिला जाऊ शकतो दुवा.

पूर्ण आकारात उघडण्यासाठी प्रतिमेवर क्लिक करा

थोडक्यात, तांत्रिक नकाशा उत्पादन प्रक्रियेचे सामान्यीकृत चित्र आहे, जे मानक कार्यक्षमतेसह स्पष्टपणे वर्गीकृत ब्लॉक्स प्रतिबिंबित करते.

आमच्या तांत्रिक नकाशाची रचना

नकाशामध्ये अनेक भाग असतात:

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

तांत्रिक नकाशावर आधारित निर्णय घेणे

नकाशाचा अभ्यास केल्यानंतर, तुम्ही कंपनीतील कर्मचार्‍यांच्या भूमिकेनुसार (विकास व्यवस्थापक, उत्पादन व्यवस्थापक, विकासक किंवा परीक्षक) काही कृती करू शकता:

• वास्तविक उत्पादन किंवा प्रकल्पामध्ये कोणते टप्पे गहाळ आहेत हे समजून घ्या आणि त्यांच्या अंमलबजावणीच्या गरजेचे मूल्यांकन करा;
• जर ते वेगवेगळ्या टप्प्यांवर काम करत असतील तर अनेक विभागांमधील जबाबदारीचे क्षेत्र मर्यादित करा;
• टप्प्यांच्या इनपुट आणि आउटपुटसाठी कराराची वाटाघाटी करा;
• एकूण विकास प्रक्रियेत तुमच्या कामाचा टप्पा समाकलित करा;
• प्रत्येक टप्प्याला समर्थन देण्यासाठी संसाधनांच्या गरजेचे अधिक अचूकपणे मूल्यांकन करा.

वरील सर्व गोष्टींचा सारांश

तंत्रज्ञान नकाशा बहुमुखी, विस्तारण्यायोग्य आणि देखरेखीसाठी सोपा आहे. कठोर शैक्षणिक IDEF0 मॉडेलपेक्षा या फॉर्ममध्ये प्रक्रियेचे वर्णन विकसित करणे आणि राखणे खूप सोपे आहे. याव्यतिरिक्त, सारणीचे वर्णन कार्यात्मक मॉडेलपेक्षा सोपे, अधिक परिचित आणि चांगले संरचित आहे.

एक विशेष अंतर्गत साधन, CrossBuilder, पायऱ्यांच्या तांत्रिक अंमलबजावणीसाठी जबाबदार आहे - CI प्रणाली, सेवा आणि पायाभूत सुविधा यांच्यातील लेयरिंग साधन. विकसकाला त्याची बाईक कापण्याची गरज नाही: आमच्या सीआय सिस्टममध्ये क्रॉसबिल्डर टूलची एक स्क्रिप्ट (तथाकथित कार्य) चालवणे पुरेसे आहे, जे आमच्या पायाभूत सुविधांची वैशिष्ट्ये विचारात घेऊन ते योग्यरित्या कार्यान्वित करेल.

परिणाम

लेख बराच लांब झाला आहे, परंतु जटिल प्रक्रियेच्या मॉडेलिंगचे वर्णन करताना हे अपरिहार्य आहे. शेवटी, मी आमच्या मुख्य कल्पना थोडक्यात सांगू इच्छितो:

• आमच्या कंपनीमध्‍ये DevOps कल्पना सादर करण्‍याचे उद्दिष्ट कंपनीच्‍या उत्‍पादनांचा परिमाणवाचक अटींमध्‍ये (मॅन-अवर्स किंवा मशीन-अवर्स, vCPU, RAM, डिस्क) उत्पादन आणि देखभालीचा खर्च सातत्याने कमी करणे आहे.
• विकासाची एकूण किंमत कमी करण्याचा एक मार्ग म्हणजे मानक क्रमिक कार्ये पार पाडण्याची किंमत कमी करणे: तांत्रिक प्रक्रियेचे टप्पे आणि चरण.
• एक सामान्य कार्य म्हणजे एक कार्य ज्याचे समाधान पूर्ण किंवा अंशतः स्वयंचलित आहे, कलाकारांना अडचणी निर्माण करत नाहीत आणि महत्त्वपूर्ण श्रम खर्चाची आवश्यकता नसते.
• उत्पादन प्रक्रियेमध्ये टप्पे असतात, टप्पे अविभाज्य चरणांमध्ये विभागले जातात, जे वेगवेगळ्या स्केल आणि व्हॉल्यूमच्या विशिष्ट कार्यांचे प्रतिनिधित्व करतात.
• वेगळ्या मानक कार्यांमधून आम्ही जटिल तांत्रिक साखळी आणि उत्पादन प्रक्रियेच्या बहु-स्तरीय मॉडेल्सवर आलो आहोत, ज्याचे वर्णन कार्यात्मक IDEF0 मॉडेल किंवा सोप्या तांत्रिक नकाशाद्वारे केले जाऊ शकते.
• फ्लो चार्ट हे उत्पादन प्रक्रियेचे टप्पे आणि चरणांचे सारणीबद्ध प्रतिनिधित्व आहे. सर्वात महत्वाची गोष्ट: नकाशा आपल्याला संपूर्ण प्रक्रिया संपूर्णपणे पाहण्याची परवानगी देतो, मोठ्या तुकड्यांमध्ये तपशीलवार वर्णन करण्याच्या शक्यतेसह.
• तांत्रिक नकाशाच्या आधारे, तुम्ही विशिष्ट उत्पादनातील टप्पे अंमलात आणण्याच्या गरजेचे मूल्यांकन करू शकता, जबाबदारीचे क्षेत्र मर्यादित करू शकता, टप्प्यांच्या इनपुट आणि आउटपुटसाठी करारांवर सहमत होऊ शकता आणि संसाधनांच्या आवश्यकतेचे अधिक अचूकपणे मूल्यांकन करू शकता.

पुढील लेखांमध्ये आम्ही आमच्या नकाशावर काही तांत्रिक टप्प्यांची अंमलबजावणी करण्यासाठी कोणती तांत्रिक साधने वापरली जातात याबद्दल अधिक तपशीलवार चर्चा करू.

लेखाचे लेखक:

• अलेक्झांडर पॅझ्डनिकोव्ह — पॉझिटिव्ह टेक्नॉलॉजीज येथे ऑटोमेशन विभागाचे प्रमुख (DevOps).
• तैमूर गिलमुलिन - उप पॉझिटिव्ह टेक्नॉलॉजीज येथे ऑटोमेशन विभागाचे प्रमुख (DevOps).

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