OpenShift एक IT संगठन के संगठनात्मक ढांचे को कैसे बदल रहा है। जब सास के लिए चलती है तो संगठनात्मक मॉडल का विकास

यद्यपि PaS (एक सेवा के रूप में प्लेटफ़ॉर्म) समाधान अकेले व्यक्तिगत और टीम इंटरैक्शन के तरीकों को बदलने में सक्षम नहीं हैं, लेकिन वे अक्सर आईटी प्रौद्योगिकियों के बढ़ते लचीलेपन के जवाब में संगठनात्मक परिवर्तन के उत्प्रेरक के रूप में काम करते हैं।



वास्तव में, पैस में निवेश पर अधिकतम रिटर्न अक्सर तभी संभव होता है जब संगठनात्मक भूमिकाएं, जिम्मेदारी के क्षेत्र (कार्य) और रिश्ते बदल जाते हैं। सौभाग्य से, PaS के समाधान, जैसे कि ओपनशिफ्ट कंटेनर प्लेटफ़ॉर्म, काफी लचीले हैं ताकि प्रत्येक आईटी संगठन स्वतंत्र रूप से शामिल लोगों और प्रक्रियाओं के सापेक्ष परिवर्तन की गति और सीमा को निर्धारित कर सके।

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

इस पोस्ट में, हम आवश्यक संगठनात्मक परिवर्तनों पर मार्गदर्शन प्रदान करेंगे और यह वर्णन करेंगे कि उद्यम में कंटेनर प्रौद्योगिकी की शुरुआत के साथ पारंपरिक आईटी भूमिकाएं कैसे बदल रही हैं।

नए जॉब्स को पुराने रोल्स से जोड़ना


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

एक DevOps संगठन की ओर


Paa को लॉन्च करने और आईटी सिस्टम ऑपरेशन के विशेषज्ञों और एप्लिकेशन डेवलपर्स को इसे स्थानांतरित करके, संगठन DevOps कार्यप्रणाली को लागू करना जारी रख सकता है, जो दूसरों के बीच में, निम्नलिखित बुनियादी सिद्धांत शामिल हैं:

  • प्रारंभिक अवस्था में प्रतिक्रिया प्राप्त करने, जोखिम कम करने और "विश्लेषणात्मक पक्षाघात" से बचने के लिए छोटे चरणों में काम को तोड़ दें ;
  • आवेदन की तैनाती की प्रक्रिया में बाधा या अड़चन पैदा करने के लिए पर्याप्त रूप से संचालन को स्वचालित करें ;
  • ज्ञान बांटना विश्वास बनाने की कुंजी है;
  • नियमित रूप से तकनीकी ऋण का भुगतान करें , व्यवस्थित सुधार के लिए प्रत्येक कार्य चक्र में समय की एक निश्चित राशि आवंटित करें।

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

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

OpenShift में जाने पर IT संगठनों के सामने नई चुनौतियाँ हैं


इस खंड में, हम उन भूमिकाओं और कार्यों को देखेंगे, जो संगठन खुले तौर पर स्विच करते हैं, आमतौर पर प्रौद्योगिकी और पा का उपयोग करके स्वचालन और स्व-सेवा में तेजी लाने के लिए उपयोग करते हैं।

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

तालिका 1. ओपनशिफ्ट टास्क परिभाषाएँ
कार्यआवश्यक कुशलता
(provisioning) -

:

  • -
  • Linux

OpenShift

:

  • Linux
  • (Ansible)
  • Kubernetes OpenShift

(tenant provisioning), -

:
  • RBAC

  • Kubernetes OpenShift
  • , ,



:

  • Linux
  • runtime- middleware
  • (application build frameworks)
  • , imagestream



:

  • immutable
  • – , . .
  • OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps



:

  • (cloud native)



:
  • ( )
  • -




:
  • UI ( )

  • परीक्षण ढांचे
  • आवेदन डिजाइन टेम्पलेट्स


OpenShift की ओर जाते समय IT संगठनों में नई भूमिकाएँ


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

  • आवेदन संचालन इंजीनियर या साइट विश्वसनीयता इंजीनियर। पहले, इस स्थिति को "एप्लिकेशन सर्वर प्रशासक" कहा जा सकता है।
  • एप्लिकेशन डेवलपर / सॉफ्टवेयर डेवलपर / सॉफ्टवेयर इंजीनियर।
  • क्लस्टर / अनुप्रयोग प्लेटफ़ॉर्म व्यवस्थापक। पहले, इस भूमिका को "सिस्टम प्रशासक" या "लिनक्स प्लेटफार्म प्रशासक" कहा जा सकता है।
  • सॉफ्टवेयर रिलीज मैनेजर (बिल्ड इंजीनियर)।

RACI भूमिका और कार्य मैट्रिक्स


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

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

आरएसीआई मैट्रिक्स
स्रोत में कन्वेंशन : विकिपीडिया

  • जिम्मेदार - एक निष्पादक वह है जो वह करता है जो किसी कार्य को पूरा करने के लिए आवश्यक है।
  • Accountable – – , ; , .
  • Consulted – – , , ; .
  • Informed – – , (, ); .

DevOps-


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

चित्र 1. पारंपरिक आईटी संगठन



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

चित्रा 2. DevOps IT संगठन



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

सारांश


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

All Articles