🔵 🕧 🏥 सात DevOps परिवर्तन Archetypes 🎅🏿 🖐🏾 👻

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

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

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

स्पीकर के बारे में:

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

अगला जॉन की ओर से कथा है।

मेरा नाम जॉन विलिस है और ट्विटर पर मुझे खोजने का सबसे आसान तरीका @botchagalupe है । मेरा Gmail और GitHub पर एक ही उपनाम है। और इस लिंक पर आप मेरी रिपोर्ट और प्रस्तुतिकरण के वीडियो पा सकते हैं।

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

DevOps क्या है?

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

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

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

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

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

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

खराब संस्कृति अच्छे नाश्ते के दृष्टिकोण को खाती है

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

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

सभी कार्य दृश्यमान बनाएं: सभी कार्य दृश्यमान बनाएं। इस अर्थ में नहीं कि इसे किसी भी स्क्रीन पर प्रदर्शित किया जाना चाहिए, बल्कि इस अर्थ में कि यह अवलोकनीय होना चाहिए।
Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
Theory of Constraints Methodology: .
Collaboration hacks: .
Toyota Kata (Coaching Kata): Toyota Kata . , .
Market Oriented Organization: .
Shift-left auditors: .

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

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

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

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

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

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

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

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

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

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

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

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

माइक रोटर के इस विषय पर एक अच्छी रिपोर्ट भी है:

6. बाजार उन्मुख: एक बाजार उन्मुख संगठन

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

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

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

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

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

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

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

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

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

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

इस तरह के अनुक्रम का एक उदाहरण:

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

और कोई कारण नहीं है कि हम सुरक्षा के लिए समान दृष्टिकोण नहीं ले सके।

संपूर्ण

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

उपयोगी कड़ियाँ

यहाँ DevOops सम्मेलन से कुछ वार्ताएँ हैं जो आपको उपयोगी लग सकती हैं:

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

DevOops 2020 मास्को कार्यक्रम पर एक नज़र डालें - वहां भी बहुत सारी दिलचस्प चीजें हैं।

सात DevOps परिवर्तन Archetypes