DevOps सिद्धांतों पर आधारित सात परिवर्तन मूलरूप

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

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

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

वक्ता के बारे में:

आईटी प्रबंधन में 35 से अधिक वर्षों तक, कैनोनिकल में ओपनक्लाउड के पूर्ववर्ती के निर्माण में भाग लिया, 10 स्टार्टअप में भाग लिया, जिनमें से दो डेल और डॉकर को बेचे गए। वर्तमान में वह एसजे टेक्नोलॉजीज में डेवऑप्स और डिजिटल प्रैक्टिसेज के उपाध्यक्ष हैं।

आगे की कहानी जॉन के दृष्टिकोण से है।

मेरा नाम जॉन विलिस है और मुझे ढूंढने का सबसे आसान स्थान ट्विटर है, @botchagalupe. जीमेल और गिटहब पर मेरा उपनाम समान है। ए इस लिंक से आप उनके लिए मेरी रिपोर्ट और प्रस्तुतियों की वीडियो रिकॉर्डिंग पा सकते हैं।

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

डेवऑप्स क्या है?

दरअसल, यदि आप 10 अलग-अलग लोगों से पूछें, तो वे 10 अलग-अलग उत्तर देंगे। लेकिन दिलचस्प बात यह है: इनमें से सभी दस उत्तर सही होंगे। यहां कोई गलत उत्तर नहीं है. मैं लगभग 10 वर्षों तक DevOps में काफी गहराई तक डूबा रहा, और पहले DevOpsDay में भाग लेने वाला पहला अमेरिकी था। मैं यह नहीं कहूंगा कि मैं DevOps में शामिल सभी लोगों से अधिक स्मार्ट हूं, लेकिन शायद ही कोई ऐसा हो जिसने इस पर इतना प्रयास किया हो। मेरा मानना ​​है कि DevOps तब होता है जब मानव पूंजी और प्रौद्योगिकी एक साथ आते हैं। हम अक्सर मानवीय आयाम के बारे में भूल जाते हैं, हालाँकि हम सभी प्रकार की संस्कृतियों के बारे में बहुत बात करते हैं।

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

अंत में मैंने निम्नलिखित दिया डेवऑप्स की परिभाषा: यह प्रथाओं और पैटर्न का एक सेट है जो मानव पूंजी को उच्च-प्रदर्शन संगठनात्मक पूंजी में बदलने में सक्षम बनाता है। इसका एक उदाहरण पिछले 50 या 60 वर्षों से टोयोटा के संचालन का तरीका है।

(इसके बाद, ऐसे चित्र संदर्भ सामग्री के रूप में नहीं, बल्कि चित्रण के रूप में प्रदान किए जाते हैं। प्रत्येक नई कंपनी के लिए उनकी सामग्री अलग-अलग होगी। हालांकि, चित्र को अलग से और बड़ा करके देखा जा सकता है इस लिंक पर.)

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

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

ख़राब संस्कृति नाश्ते के अच्छे तरीकों को खा जाती है

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

इस मुख्य समस्या को हल करने के लिए, आपको निम्नलिखित कदम उठाने होंगे:

1. सभी कार्य दृश्यमान बनाएं: आपको सारा काम दृश्यमान बनाना होगा. इस अर्थ में नहीं कि इसे आवश्यक रूप से किसी स्क्रीन पर प्रदर्शित किया जाना चाहिए, बल्कि इस अर्थ में कि इसे अवश्य देखा जाना चाहिए।
2. समेकित कार्य प्रबंधन प्रणालियाँ: प्रबंधन प्रणालियों को समेकित करने की आवश्यकता है। "आदिवासी" ज्ञान और संस्थागत ज्ञान की समस्या में, 9 में से 10 मामलों में बाधा लोग हैं। किताब में "फीनिक्स प्रोजेक्ट" समस्या एक अकेले व्यक्ति, ब्रेंट के साथ थी, जिसके कारण परियोजना निर्धारित समय से तीन साल पीछे हो गई। और मैं हर जगह इन "ब्रेंट्स" से मिलता हूं। इन बाधाओं को हल करने के लिए, मैं हमारी सूची में अगली दो वस्तुओं का उपयोग करता हूँ।
3. बाधाओं का सिद्धांत पद्धति: थ्योरी ऑफ कंस्ट्रेंट्स।
4. सहयोग हैक: सहयोग हैक.
5. टोयोटा काटा (कोचिंग काटा): मैं टोयोटा काटा के बारे में ज्यादा बात नहीं करूंगा। यदि रुचि हो, तो मेरे जीथब पर प्रस्तुतियाँ हैं इनमें से लगभग हर एक विषय पर।
6. बाज़ारोन्मुखी संगठन: बाज़ारोन्मुख संगठन.
7. शिफ्ट-लेफ्ट ऑडिटर: चक्र के प्रारंभिक चरण में लेखापरीक्षा।

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

(यह चित्रण अलग से देखा जा सकता है लिंक देखें)

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

थोड़ा बेहतर विकल्प वह है जिसमें नियंत्रण और क्षमता दोनों का उच्च स्तर हो। यदि ऐसी कंपनी लाभदायक है, तो शायद उसे DevOps की आवश्यकता नहीं है। ऐसी कंपनी के साथ काम करना सबसे दिलचस्प है जिसमें उच्च स्तर का नियंत्रण, कम क्षमता और सहयोग हो, लेकिन साथ ही उच्च स्तर की संस्कृति (साधना) हो। इसका मतलब है कि कंपनी में बहुत सारे लोग हैं जो वहां काम करना पसंद करते हैं और लेबर टर्नओवर कम है।

(यह चित्रण अलग से देखा जा सकता है लिंक देखें)

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

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

(यह चित्रण अलग से देखा जा सकता है लिंक देखें)

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

(यह चित्रण अलग से देखा जा सकता है लिंक देखें)

और फिर हमने अन्य विभागों के लोगों से बात की और पता चला कि लगभग 8 साल पहले, सॉफ्टवेयर डेवलपर्स ने सुरक्षा कर्मचारियों को निकाल दिया था क्योंकि वे काम धीमा कर रहे थे। और फिर यह प्रतिबंध में बदल गया, जिसे मान लिया गया। हालांकि हकीकत में कोई रोक नहीं थी.

हमारी बैठक बेहद भ्रमित तरीके से आगे बढ़ी: लगभग तीन घंटे तक, पांच अलग-अलग टीमें मुझे यह नहीं समझा सकीं कि कोड और असेंबली के बीच क्या हो रहा था। और यह सबसे सरल चीज़ प्रतीत होगी. अधिकांश DevOps सलाहकार पहले से ही मान लेते हैं कि हर कोई यह पहले से ही जानता है।

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

(यह चित्रण अलग से देखा जा सकता है लिंक देखें)

इस बैंक में आखिरी बैठक निवेश सॉफ्टवेयर टीम के साथ थी। यह उनके साथ था कि यह पता चला कि कागज की शीट पर मार्कर के साथ आरेख लिखना बोर्ड की तुलना में बेहतर है, और स्मार्टबोर्ड की तुलना में भी बेहतर है।

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

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

1. सभी कार्यों को दृश्यमान बनाएं: कार्य को दृश्यमान बनाएं

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

• प्रक्रिया में बहुत अधिक कार्य (WIP)
• अज्ञात निर्भरताएँ
• अनियोजित कार्य
• परस्पर विरोधी प्राथमिकताएँ
• उपेक्षित कार्य

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

फीनिक्स प्रोजेक्ट एक ऐसे प्रोजेक्ट के बारे में एक अद्भुत कहानी है जो तीन साल बहुत देर हो चुकी थी। इसके कारण एक पात्र को बर्खास्तगी का सामना करना पड़ता है, और उसकी मुलाकात दूसरे पात्र से होती है जिसे एक प्रकार के सुकरात के रूप में प्रस्तुत किया जाता है। वह यह पता लगाने में मदद करता है कि वास्तव में क्या गलत हुआ। पता चला कि कंपनी के पास एक सिस्टम एडमिनिस्ट्रेटर है, जिसका नाम ब्रेंट है और सारा काम किसी न किसी तरह उसी से होता है। एक बैठक में, अधीनस्थों में से एक से पूछा जाता है: प्रत्येक आधे घंटे के कार्य में एक सप्ताह क्यों लगता है? उत्तर कतार सिद्धांत और लिटिल के नियम की एक बहुत ही सरल प्रस्तुति है, और इस प्रस्तुति में यह पता चलता है कि 90% अधिभोग पर, प्रत्येक घंटे के काम में 9 घंटे लगते हैं। प्रत्येक कार्य को सात अन्य लोगों को भेजने की आवश्यकता है, ताकि वह घंटा 63 घंटे हो जाए, 7 गुना 9। मैं जो कह रहा हूं वह यह है कि लिटिल के नियम या किसी जटिल कतार सिद्धांत का उपयोग करने के लिए, आपके पास कम से कम डेटा होना चाहिए।

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

जब काम दिखाई देता है, तो डेटा को बड़े करीने से वर्गीकृत किया जा सकता है (फोटो में डोमिनिका यही कर रही है), पांच बार लीक का अमूर्तन लागू किया जा सकता है, और स्वचालन लागू किया जा सकता है।

2. समेकित कार्य प्रबंधन प्रणाली: कार्य प्रबंधन

मैं जिन मूलरूपों की बात कर रहा हूं वे एक प्रकार के पिरामिड हैं। यदि पहला सही ढंग से किया जाता है, तो दूसरा पहले से ही एक प्रकार का ऐड-ऑन है। इनमें से कई स्टार्टअप के लिए काम नहीं करते हैं, उन्हें फॉर्च्यून 5000 जैसी बड़ी कंपनियों के लिए ध्यान में रखना होगा। पिछली कंपनी जिसके लिए मैंने काम किया था, उसमें 10 टिकटिंग सिस्टम थे। एक टीम के पास रेमेडी थी, दूसरे ने अपना खुद का सिस्टम लिखा, तीसरे ने जीरा का इस्तेमाल किया, और कुछ ने ईमेल से काम चलाया। यदि कंपनी के पास 30 अलग-अलग पाइपलाइनें हैं तो भी यही समस्या उत्पन्न होती है, लेकिन मेरे पास ऐसे सभी मामलों पर चर्चा करने का समय नहीं है।

मैं लोगों से इस बात पर चर्चा करता हूं कि टिकट कैसे बनाए जाते हैं, आगे उनका क्या होता है और उन्हें कैसे टाला जाता है। सबसे दिलचस्प बात यह है कि हमारी बैठकों में लोग काफी ईमानदारी से बात करते हैं। मैंने पूछा कि कितने लोग टिकटों पर "मामूली/कोई प्रभाव नहीं" डालते हैं जिन्हें वास्तव में "बड़ा प्रभाव" दिया जाना चाहिए। पता चला कि लगभग हर कोई ऐसा करता है। मैं निंदा में संलग्न नहीं हूं और हर संभव तरीके से लोगों की पहचान न करने का प्रयास करता हूं। जब वे ईमानदारी से मेरे सामने कुछ कबूल करते हैं, तो मैं उस व्यक्ति को छोड़ नहीं देता। लेकिन जब लगभग हर कोई सिस्टम को बायपास कर देता है, तो इसका मतलब है कि सारी सुरक्षा अनिवार्य रूप से विंडो ड्रेसिंग है। इसलिए इस सिस्टम के डेटा से कोई निष्कर्ष नहीं निकाला जा सकता.

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

यह बुनियादी ढांचे और संचालन सहित सभी विभागों पर लागू होता है। इस मामले में, मामलों की स्थिति का कम से कम कुछ प्रशंसनीय विचार बनाना संभव है। एक बार यह प्रक्रिया स्थापित हो जाने के बाद, यह पहचानना अचानक आसान हो जाता है कि प्रत्येक एप्लिकेशन के लिए कौन जिम्मेदार है। क्योंकि अब हमें 50% नहीं, बल्कि 98% नई सेवाएँ प्राप्त होती हैं। यदि यह मुख्य प्रक्रिया काम करती है, तो पूरे सिस्टम में सटीकता में सुधार होता है।

सेवा पाइपलाइन

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

Google के लोगों को पूरा विश्वास था कि वे मेरे ग्राहकों की सभी समस्याओं का समाधान कर देंगे, और फिर उन्होंने प्रश्न पूछना शुरू कर दिया: IBM डेटापाइप क्या है? उन्हें बताया जाता है: यह एक कनेक्टर है। यह किससे जुड़ता है? स्पेरी प्रणाली के लिए. और यह था कि? और इसी तरह। पहली नज़र में ऐसा लगता है: किस प्रकार के DevOps हो सकते हैं? लेकिन वास्तव में यह संभव है. ऐसी डिलीवरी प्रणालियाँ हैं जो आपको वर्कफ़्लो को डिलीवरी टीमों को सौंपने की अनुमति देती हैं।

3. बाधाओं का सिद्धांत: बाधाओं का सिद्धांत

आइए तीसरे आदर्श की ओर बढ़ें: संस्थागत/"आदिवासी" ज्ञान। एक नियम के रूप में, किसी भी संगठन में कई लोग होते हैं जो सब कुछ जानते हैं और सब कुछ प्रबंधित करते हैं। ये वे लोग हैं जो संगठन में सबसे लंबे समय से हैं और जो सभी उपाय जानते हैं।

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

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

यह मेरा मुख्य बिंदु है: किसी भी उच्च तकनीक की अनुशंसा करने के लिए, आपको पहले उनकी नींव को व्यवस्थित करना होगा, और यह अभी वर्णित निम्न-तकनीकी समाधानों के साथ किया जा सकता है। यदि आप उच्च तकनीकों से शुरुआत करते हैं और यह नहीं बताते हैं कि उनकी आवश्यकता क्यों है, तो, एक नियम के रूप में, इसका अंत अच्छा नहीं होता है। हमारा एक ग्राहक Azure ML का उपयोग करता है, जो एक बहुत ही सस्ता और सरल समाधान है। उनके लगभग 30% प्रश्नों का उत्तर स्वयं-शिक्षण मशीन द्वारा ही दिया गया। और यह बात उन ऑपरेटरों द्वारा लिखी गई थी जो डेटा विज्ञान, सांख्यिकी या गणित में शामिल नहीं थे। यह महत्वपूर्ण है. ऐसे समाधान की लागत न्यूनतम है।

4. सहयोग हैक्स: सहयोग हैक्स

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

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

5. कोचिंग काटा

जैसा कि मैंने शुरू में ही चेतावनी दी थी, मैं आज इस बारे में बात नहीं करूंगा। यदि आप रुचि रखते हैं, तो आप देख सकते हैं मेरी कुछ प्रस्तुतियाँ.

इस विषय पर माइक रॉदर की भी एक अच्छी बातचीत है:

6. बाज़ारोन्मुख: बाज़ारोन्मुख संगठन

यहां अलग-अलग समस्याएं हैं. उदाहरण के लिए, "I" लोग, "T" लोग और "E" लोग। "मैं" लोग वे हैं जो केवल एक ही काम करते हैं। आमतौर पर वे पृथक विभागों वाले संगठनों में मौजूद होते हैं। "टी" तब होता है जब कोई व्यक्ति एक चीज़ में अच्छा होता है लेकिन कुछ अन्य चीजों में भी अच्छा होता है। "ई" या "कंघी" तब होता है जब किसी व्यक्ति के पास कई कौशल होते हैं।

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

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

कई लोग इस संरचना का अलग-अलग तरीकों से वर्णन करते हैं, मुझे शब्दांकन पसंद है टीमें बनाएं/चलाएं, अमेज़न पर वे इसे कहते हैं दो पिज़्ज़ा टीमें. इस संरचना में, सभी प्रकार के "I" लोगों को एक सेवा के आसपास समूहीकृत किया जाता है, और धीरे-धीरे वे प्रकार "T" के करीब हो जाते हैं, और यदि सही प्रबंधन हो, तो वे "E" भी बन सकते हैं। यहां पहला प्रतिवाद यह है कि ऐसी संरचना में अनावश्यक तत्व होते हैं। यदि आपके पास परीक्षकों का एक विशेष विभाग हो सकता है तो आपको प्रत्येक विभाग में एक परीक्षक की आवश्यकता क्यों है? जिस पर मैं उत्तर देता हूं: इस मामले में अतिरिक्त लागत पूरे संगठन के लिए भविष्य में "ई" प्रकार बनने की कीमत है। इस संरचना में, परीक्षक धीरे-धीरे नेटवर्क, वास्तुकला, डिज़ाइन आदि के बारे में सीखता है। परिणामस्वरूप, संगठन में प्रत्येक भागीदार को संगठन में होने वाली हर चीज़ के बारे में पूरी जानकारी होती है। यदि आप जानना चाहते हैं कि यह योजना उद्योग में कैसे काम करती है, तो पढ़ें माइक रोदर, टोयोटा काटा.

7. शिफ्ट-लेफ्ट ऑडिटर: चक्र की शुरुआत में ऑडिट करें। प्रदर्शन पर सुरक्षा नियमों का अनुपालन

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

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

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

के अनुसार रिपोर्टसोनाटाइप द्वारा 2018 में बनाया गया, 2017 में 87 बिलियन ओएसएस डाउनलोड अनुरोध थे।

कमजोरियों के कारण होने वाली हानि निषेधात्मक है। इसके अलावा, जो आंकड़े अब आप ऊपर देख रहे हैं उनमें अवसर लागत शामिल नहीं है। संक्षेप में DevSecOps क्या है? मैं तुरंत कह दूं कि मुझे इस बारे में बात करने में कोई दिलचस्पी नहीं है कि यह नाम कितना सफल है। मुद्दा यह है कि चूँकि DevOps इतना सफल रहा है, हमें उस पाइपलाइन में सुरक्षा जोड़ने का प्रयास करना चाहिए।

इस क्रम का एक उदाहरण:


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

और ऐसा कोई कारण नहीं है कि हम सुरक्षा के प्रति समान दृष्टिकोण न अपना सकें।

संपूर्ण

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

उपयोगी लिंक्स

यहां DevOops कॉन्फ़्रेंस से कुछ बातचीत दी गई हैं जो आपको उपयोगी लग सकती हैं:

• सेर्गेई बर्डनिकोव, अर्टोम कालीचकिन - सफलता की कहानी, या "देव+डेवऑप्स+ऑप्स" (वीडियो, रिपोर्ट की प्रतिलेख)
• बारूक सैडोगुरस्की, लियोनिद इगोलनिक - बड़े पैमाने पर डेवऑप्स: तीन कृत्यों में एक ग्रीक त्रासदी (वीडियो, रिपोर्ट की प्रतिलेख)
• अलेक्जेंडर टिटोव, किरिल टोलकाचेव - DevOps, इंजीनियर और समुदाय
• टिमोथी लिस्टर - चरित्र, समुदाय और संस्कृति: समृद्धि के लिए महत्वपूर्ण कारक

इस पर गौर करें कार्यक्रम DevOops 2020 मॉस्को - वहां बहुत सारी दिलचस्प चीजें भी हैं।

स्रोत: www.habr.com