11 महत्वपूर्ण बातें जो आपको देवो के बारे में जानना है - भाग दो

(निरंतर अनुवाद, यहां पहला भाग)

8. Infosec और QA कैसे DevOps वर्कफ़्लो में एकीकृत होते हैं?

आमतौर पर DevOps से जुड़ी उच्च तैनाती दर अक्सर QA और Infosec पर भारी दबाव डालती है। उस मामले पर विचार करें जहां डेवलपर्स प्रति दिन दस तैनाती करते हैं, जबकि सुरक्षा गार्डों को चार महीने के आवेदन सुरक्षा परीक्षण की आवश्यकता होती है। पहली नज़र में, यह सब विकास और सुरक्षा परीक्षण की गति के बीच कुल विसंगति जैसा दिखता है।

अपर्याप्त रूप से सत्यापित तैनाती प्रक्रिया से जुड़े जोखिम का एक उदाहरण 2011 में अच्छी तरह से ज्ञात ड्रॉपबॉक्स समस्या है, जब प्रमाणीकरण चार घंटों के लिए अक्षम हो गया था, जिसने अनधिकृत उपयोगकर्ताओं को सभी संग्रहीत डेटा तक पहुंचने की अनुमति दी थी।

QA और Infosec के लिए अच्छी खबर यह है कि यदि विकास दल उच्च तैनाती दर बनाए रखने में सक्षम हैं, तो वे संभवतः निरंतर एकीकरण और वितरण प्रथाओं का उपयोग कर रहे हैं, जिसका अर्थ है कि वे निरंतर परीक्षण प्रथाओं का उपयोग कर रहे हैं। दूसरे शब्दों में, जब भी कोड रिपॉजिटरी को भेजता है, तो परीक्षण स्वचालित रूप से चलते हैं और त्रुटियों को तुरंत ठीक किया जाना चाहिए, जैसे कि डेवलपर ने रिपॉजिटरी को कोड भेजा है जो संकलन नहीं करता है।

डेवलपर्स की दैनिक गतिविधियों में कार्यात्मक, एकीकरण परीक्षणों और सूचना सुरक्षा परीक्षणों के उपयोग के माध्यम से दोषों का पता लगाया जाता है और पहले से कहीं अधिक तेजी से ठीक किया जाता है।

गौंटलेट और सिक्योरिटी मंकी जैसे अधिक से अधिक इन्फोसेक उपकरण हैं, जो इस कदम को विकास और वितरण प्रक्रियाओं में एकीकृत करके सुरक्षा की मदद करते हैं।

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

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

क्रैश से त्वरित पुनर्प्राप्ति को "सुविधा ध्वज" का उपयोग करके आसान बनाया जा सकता है, जो सीधे कॉन्फ़िगरेशन मापदंडों का उपयोग करके कोड में कार्यक्षमता को सक्षम और अक्षम करता है, जो पूर्ण शाखा से बचा जाता है।

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

9. मेरा पसंदीदा DevOps पैटर्न # 1:

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

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

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

एजाइल के अनुसार, हमारे पास प्रत्येक स्प्रिंट (आमतौर पर हर दो सप्ताह) के अंत में एक कामकाजी, वितरित कोड होना चाहिए। हम चुस्त नियम को बदल देंगे ताकि प्रत्येक स्प्रिंट के अंत में केवल आपूर्ति किए गए व्यवहार्य कोड होने के बजाय, आपके पास वह वातावरण भी होगा जिसमें यह तैनात किया गया है, बहुत पहले स्प्रिंट (0 या 1) से शुरू होता है।

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

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

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

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

10. मेरा पसंदीदा DevOps पैटर्न # 2:

BrowserMob के पूर्व सीईओ पैट्रिक लाइटबॉडी के मेरे पसंदीदा उद्धरणों में से एक है: “हमने पाया कि जब हम 2 बजे डेवलपर्स होंगे, तो हमें अभूतपूर्व प्रतिक्रिया मिलेगी। दोष पहले से कहीं अधिक तेजी से तय किए गए हैं। ”

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

दूसरे तरीके का एक महत्वपूर्ण तत्व फीडबैक को कम करना और मजबूत करना है ताकि डेवलपर्स क्लाइंट के करीब हो जाएं।

समरूपता पर ध्यान दें: पैटर्न नंबर 1 जितना संभव हो सके वातावरण बनाने की बात करता है और विकास में ऑप्सिंग करता है, जबकि पैटर्न # 2 डेवलपर्स को ओप्स में पेश करने की बात करता है।

देखिए, हम विकास टीम को प्रशासकों की सूचनात्मक श्रृंखला में एम्बेड करते हैं, उदाहरण के लिए, स्तर 3 के तकनीकी समर्थन के रूप में या यहां तक ​​कि उन्हें वितरण की सफलता के लिए पूरी तरह से जिम्मेदार बनाते हुए, पिछले संस्करण में रोलबैक और ग्राहक को सूचित करने सहित समस्याओं को ठीक करने के लिए।

लक्ष्य डेवलपर्स के साथ प्रवेश को प्रतिस्थापित करना नहीं है। इसके बजाय, हम विकास टीम को यह स्पष्ट करना चाहते हैं कि उनके काम में क्या कमी हो सकती है, और ऑप्स को जूते पहनने के लिए पर्याप्त समय देना चाहिए ताकि समस्याओं को जल्दी से ठीक किया जा सके और वैश्विक लक्ष्यों को प्राप्त किया जा सके।

11. मेरा पसंदीदा DevOps पैटर्न नंबर 3:

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

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

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

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

आईटी का भविष्य

पिछले दो वर्षों में, हमने इस समस्या के विभिन्न समाधानों और विकास और प्रशासन विभागों के बीच बातचीत के नए तरीके खोजने के लिए अनगिनत सुझावों को देखा है।

हम जानते हैं कि वर्तमान प्रणाली काम नहीं कर रही है। हम जानते हैं कि एक बेहतर तरीका है। हम जानते हैं कि समाधान आईटी की सही क्षमता दिखाएगा। एक सौ साल बाद, इतिहासकार इस दशक को देखेंगे और कहेंगे: "यह आईटी के लिए एक कैम्ब्रियन विस्फोट था, जब हमने आखिरकार यह पता लगा लिया कि जीतने के लिए आईटी प्रबंधन के काम को कैसे व्यवस्थित किया जाए।"

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

हम अगले 5 वर्षों में आईटी में 1 मिलियन लोगों के जीवन को सकारात्मक रूप से प्रभावित करने का प्रयास करते हैं। ऐसा करने के लिए, हम सभी प्रासंगिक क्षेत्रों में नेताओं को एक साथ लाते हैं जो हमारे लक्ष्य को प्राप्त करने और भविष्य की पीढ़ियों के लिए आईटी में सुधार करने में हमारी मदद करने के लिए सामान्य समझ रखते हैं।