🥇 DevOps रूपान्तरणका सात आर्केटाइपहरू

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

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

जोन विलिस — DevOps का पिताहरू मध्ये एक। जोनसँग धेरै कम्पनीहरूसँग काम गर्ने दशकौंको अनुभव छ। हालसालै, जोनले ती प्रत्येकसँग काम गर्दा हुने विशिष्ट ढाँचाहरू याद गर्न थालेका छन्। यी आर्किटाइपहरू प्रयोग गरेर, जोनले कम्पनीहरूलाई DevOps रूपान्तरणको वास्तविक मार्गमा मार्गदर्शन गर्छन्। DevOops २०१८ सम्मेलनबाट उनको रिपोर्टको अनुवादमा यी आर्किटाइपहरूको बारेमा थप पढ्नुहोस्।

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

IT व्यवस्थापनमा ३५ वर्षभन्दा बढी समय बिताए, Canonical मा OpenCloud को पूर्ववर्ती सिर्जना गर्न मद्दत गरे, १० वटा स्टार्टअपहरूमा भाग लिए, जसमध्ये दुई डेल र डकरलाई बेचे। हाल SJ Technologies मा DevOps र डिजिटल अभ्यासका उपाध्यक्ष।

यूहन्नाको दृष्टिकोणबाट भनिएको कथा निम्न छ।

मेरो नाम जोन विलिस हो र म ट्विटरमा सबैभन्दा धेरै भेटिन्छु। @बोटचागालुपे। मेरो Gmail र GitHub मा एउटै उपनाम छ। अनि यस लिङ्क द्वारा तपाईंले मेरो रिपोर्ट र प्रस्तुतीकरणहरूको भिडियो रेकर्डिङहरू फेला पार्न सक्नुहुन्छ।

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

DevOps के हो?

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

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

अन्त्यमा मैले निम्न दिएँ DevOps को परिभाषा: मानव पूँजीलाई उच्च-प्रदर्शन संगठनात्मक पूँजीमा रूपान्तरण गर्न सक्षम बनाउने अभ्यास र ढाँचाहरूको सेट हो। टोयोटाले विगत ५० वा ६० वर्षदेखि कसरी सञ्चालन गरिरहेको छ भन्ने उदाहरण हो।

(यहाँ र तल त्यस्ता रेखाचित्रहरू सन्दर्भ सामग्रीको रूपमा होइन, तर चित्रणको रूपमा प्रदान गरिएका छन्। प्रत्येक नयाँ कम्पनीको लागि तिनीहरूको सामग्री फरक हुनेछ। यद्यपि, तस्वीरलाई छुट्टाछुट्टै हेर्न र ठूलो बनाउन सकिन्छ।) यस लिङ्कमा।)

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

मलाई लाग्छ मेरा धेरै सहकर्मीहरूले गर्ने गल्ती भनेको उनीहरूले कम्पनीलाई पाँच-बुँदे गाइड दिन्छन् र त्यसपछि छ महिना पछि फर्केर के भयो भनेर हेर्छन्। मानौं, मूल्य स्ट्रिम म्यापिङ जस्तो राम्रो ढाँचामा पनि, अन्धा धब्बाहरू छन्। सयौं सीईओहरूसँग अन्तर्वार्ता लिएपछि, मैले एउटा ढाँचा विकास गरेको छु जसले समस्यालाई यसको घटकहरूमा विभाजन गर्दछ, र हामी ती प्रत्येक घटकलाई पालैपालो छलफल गर्नेछौं। कुनै पनि प्रविधि समाधानहरू लागू गर्नु अघि म यो ढाँचा प्रयोग गर्छु, र फलस्वरूप, मेरा भित्ताहरू रेखाचित्रहरूले ढाकिएका छन्। मैले हालसालै म्युचुअल फन्डसँग काम गरें र यी रेखाचित्रहरू मध्ये १००-१५० वटासँग समाप्त भएँ।

खराब संस्कृतिले ब्रेकफास्टमा राम्रो तरिकाले खान्छ

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

यो मुख्य समस्या समाधान गर्न, निम्न चरणहरू चाल्नु आवश्यक छ:

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

म एउटा संस्थासँग धेरै सरल तरिकाले काम गर्न थाल्छु: म कम्पनीमा जान्छु र कर्मचारीहरूसँग कुरा गर्छु। तपाईंले देख्न सक्नुहुन्छ, कुनै उच्च प्रविधि छैन। तपाईंलाई लेख्नको लागि केहि चाहिन्छ। म एउटा कोठामा धेरै टोलीहरू भेला गर्छु र मेरा ७ आर्केटाइपहरूको दृष्टिकोणबाट उनीहरूले मलाई के भन्छन् भनेर विश्लेषण गर्छु। र त्यसपछि म तिनीहरूलाई मार्कर दिन्छु र उनीहरूले अहिलेसम्म ठूलो स्वरमा भनेका सबै कुरा बोर्डमा लेख्न भन्छु। सामान्यतया यस्ता बैठकहरूमा एक जना व्यक्ति हुन्छ जसले सबै कुरा लेख्छ, र बढीमा उसले छलफलको १०% लेख्न व्यवस्थापन गर्छ। मेरो विधिको साथ, यो संख्या लगभग ४०% सम्म बढाउन सकिन्छ।

(यो चित्रण छुट्टै हेर्न सकिन्छ।) लिङ्क हेर्नुहोस्)

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

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

(यो चित्रण छुट्टै हेर्न सकिन्छ।) लिङ्क हेर्नुहोस्)

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

फेरि पनि, कुनै उच्च प्रविधि छैन। कालो मार्करले चीजहरू कसरी काम गर्छन् भन्ने वस्तुगत वास्तविकता देखाउँछ। रातो मार्कर मानिसहरूले हालको अवस्थाको बारेमा के मन पर्दैन भनेर संकेत गर्न प्रयोग गर्छन्। यो महत्त्वपूर्ण छ कि उनीहरूले यो लेखे, मलाई होइन। जब म बैठक पछि CIO कहाँ जान्छु, म समाधान गर्न आवश्यक पर्ने १० चीजहरूको सूची प्रदान गर्दिन। म कम्पनीका मानिसहरूले भनेको कुरा र अवस्थित प्रमाणित ढाँचाहरू बीचको सम्बन्ध खोज्ने प्रयास गर्छु। अन्तमा, समस्याको सम्भावित समाधानहरू नीलो मार्करमा सुझाव दिइन्छ।

(यो चित्रण छुट्टै हेर्न सकिन्छ।) लिङ्क हेर्नुहोस्)

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

(यो चित्रण छुट्टै हेर्न सकिन्छ।) लिङ्क हेर्नुहोस्)

अनि हामीले अन्य विभागका मानिसहरूसँग कुरा गर्यौं र थाहा भयो कि लगभग ८ वर्षअघि, सफ्टवेयर विकासकर्ताहरूले सुरक्षाकर्मीहरूलाई काम सुस्त बनाएको कारणले बर्खास्त गरेका थिए। अनि त्यसपछि यो प्रतिबन्धमा परिणत भयो जुन सामान्य रूपमा लिइयो। यद्यपि वास्तवमा कुनै प्रतिबन्ध थिएन।

हाम्रो बैठक अत्यन्तै भ्रामक थियो: लगभग तीन घण्टासम्म, पाँच फरक टोलीहरूले मलाई कोड र निर्माण बीच के हुन्छ भनेर व्याख्या गर्न सकेनन्। र यो सबैभन्दा सरल कुरा मानिन्छ। धेरैजसो DevOps सल्लाहकारहरूले यो सबैलाई पहिले नै थाहा छ भन्ने मान्छन्।

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

(यो चित्रण छुट्टै हेर्न सकिन्छ।) लिङ्क हेर्नुहोस्)

यस बैंकमा अन्तिम बैठक लगानी सफ्टवेयरमा काम गर्ने टोलीसँग थियो। उनीहरूसँगै यो कुरा स्पष्ट भयो कि कागजको पानामा मार्करले रेखाचित्र लेख्नु बोर्डमा भन्दा राम्रो छ, र स्मार्टबोर्डमा भन्दा पनि राम्रो छ।

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

त्यसैले, म कामदारहरूलाई प्रश्न सोध्छु, तिनीहरूले तीन रङका मार्करहरू (कालो, रातो र नीलो) प्रयोग गरेर उत्तरहरू लेख्छन्। म आर्केटाइपहरूको लागि तिनीहरूको उत्तरहरूको विश्लेषण गर्छु। अब सबै आर्केटाइपहरूलाई क्रमबद्ध रूपमा छलफल गरौं।

१. सबै कामलाई दृश्यात्मक बनाउनुहोस्: कामलाई दृश्यात्मक बनाउनुहोस्

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

धेरै काम प्रक्रियामा (WIP)
अज्ञात निर्भरताहरू
योजनाविहीन काम
विवादास्पद प्राथमिकताहरू
उपेक्षित काम

यो धेरै मूल्यवान विश्लेषण हो, र पुस्तक अद्भुत छ, तर यदि तपाईंले ५०% मात्र डेटा हेर्नुभयो भने यो सबै सल्लाह बेकार छ। ९०% भन्दा माथि शुद्धता प्राप्त गर्दा तपाईंले डोमिनिकाले सुझाव दिएका विधिहरू प्रयोग गर्न सक्नुहुन्छ। म त्यस्तो परिस्थितिहरूको बारेमा कुरा गर्दैछु जहाँ हाकिमले अधीनस्थलाई १५ मिनेटको काम दिन्छन्, र त्यसमा उनलाई तीन दिन लाग्छ; तर हाकिमलाई वास्तवमा थाहा हुँदैन कि यो अधीनस्थ चार वा पाँच अन्य व्यक्तिहरूमा निर्भर छ।

फिनिक्स प्रोजेक्ट तीन वर्ष ढिलो भएको परियोजनाको बारेमा एउटा उत्कृष्ट कथा हो। यसको कारणले गर्दा एक पात्रलाई बर्खास्त गर्न लागेको छ, र उसले अर्को पात्रलाई भेट्छ जसलाई एक प्रकारको सुकरातको रूपमा प्रस्तुत गरिएको छ। उसले वास्तवमा के गलत भयो भनेर पत्ता लगाउन मद्दत गर्छ। यो थाहा हुन्छ कि ब्रेन्ट नामको कम्पनीमा एक सिस्टमाडमिन छ, र सबै काम कुनै न कुनै रूपमा उसै मार्फत जान्छ। एउटा बैठकमा, एक जना अधीनस्थलाई सोधिन्छ: किन प्रत्येक आधा घण्टाको कार्यमा एक हप्ता लाग्छ? उत्तर क्युइङ सिद्धान्त र लिटिलको नियमको धेरै सरलीकृत व्याख्या हो, र यस व्याख्यामा यो पत्ता लाग्छ कि ९०% अकुपेन्सीमा, प्रत्येक घण्टाको काममा ९ घण्टा लाग्छ। प्रत्येक कार्य सात अन्य व्यक्तिहरूलाई पठाउन आवश्यक छ, त्यसैले त्यो घण्टा ६३ घण्टामा परिणत हुन्छ, ७ गुणा ९। म यो भन्छु किनभने लिटिलको नियम वा कुनै पनि प्रकारको जटिल क्युइङ सिद्धान्त प्रयोग गर्न, तपाईंसँग कम्तिमा डेटा हुनु आवश्यक छ।

त्यसैले जब म दृश्यता भन्छु, मेरो मतलब सबै कुरा स्क्रिनमा छ भन्ने होइन, मेरो मतलब कम्तिमा डेटा हुनु हो। र जब तपाईंसँग त्यो हुन्छ, तपाईंले प्रायः पाउनुहुन्छ कि धेरै अनियोजित कामहरू छन् जुन कुनै न कुनै रूपमा ब्रेन्टमा पठाइँदैछ जुन त्यहाँ हुनु आवश्यक छैन। र ब्रेन्ट एक महान मान्छे हो, उसले कहिल्यै नाइँ भन्ने छैन, तर उसले आफ्नो काम कसरी गर्छ भनेर कसैलाई बताउँदैन।

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

२. कार्य व्यवस्थापन प्रणालीहरू समेकित गर्नुहोस्: कार्य व्यवस्थापन

म जुन आर्केटाइपहरूको बारेमा कुरा गर्दैछु ती पिरामिड जस्तै हुन्। यदि पहिलो सही तरिकाले गरिएको छ भने, दोस्रो एक प्रकारको एड-अन हो। तिनीहरूमध्ये धेरै स्टार्टअपहरूको लागि काम गर्दैनन्, तर तिनीहरूलाई Fortune 5000 जस्ता ठूला कम्पनीहरूको लागि दिमागमा राख्नु आवश्यक छ। मैले काम गरेको अन्तिम कम्पनीमा १० वटा टिकटिङ प्रणालीहरू थिए। एउटा टोलीले रेमेडी प्रयोग गर्‍यो, अर्कोले आफ्नै प्रणाली लेख्यो, तेस्रोले जिरा प्रयोग गर्‍यो, र अर्को कसैले इमेलको साथ काम गर्यो। कम्पनीसँग ३० फरक पाइपलाइनहरू छन् भने पनि उही समस्या आउँछ, तर मसँग ती सबै केसहरू छलफल गर्ने समय छैन।

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

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

यो पूर्वाधार र सञ्चालन सहित सबै विभागहरूमा लागू हुन्छ। यस अवस्थामा, तपाईं के भइरहेको छ भन्ने बारे कम्तिमा केही हदसम्म प्रशंसनीय विचार बनाउन सक्नुहुन्छ। जब यो प्रक्रिया स्थापित हुन्छ, अचानक यो पत्ता लाग्छ कि तपाईं प्रत्येक आवेदनको लागि को जिम्मेवार छ भनेर सजिलै निर्धारण गर्न सक्नुहुन्छ। किनभने अब हामी ५०% होइन, तर ९८% नयाँ सेवाहरू पाउँछौं। यदि यो मुख्य प्रक्रियाले काम गर्छ भने, प्रणालीभरि शुद्धता बढ्छ।

सेवाहरूको पाइपलाइन

फेरि, यो केवल ठूला निगमहरूमा लागू हुन्छ। यदि तपाईं नयाँ क्षेत्रमा नयाँ कम्पनी हुनुहुन्छ भने, आफ्नो बाहुलाहरू बेर्नुहोस् र आफ्नो ट्राभिस CI वा CircleCI सँग काम गर्नुहोस्। Fortune 5000 कम्पनीहरूको लागि, मैले काम गरेको बैंकसँग भएको एउटा घटना उदाहरणीय छ। तिनीहरू Google बाट आएका थिए, र तिनीहरूलाई पुरानो IBM प्रणालीहरू भएका रेखाचित्रहरू देखाइयो। Google का मानिसहरूले अलमल्लमा पर्दै सोधे - यसको लागि स्रोत कोड कहाँ छ? त्यहाँ कुनै स्रोत कोड छैन, GUI पनि छैन। यो वास्तविकता हो जुन ठूला संस्थाहरूले काम गर्नुपर्छ: पुरानो मेनफ्रेममा ४० वर्ष पुरानो बैंक रेकर्डहरू। मेरो एक ग्राहकले सर्किट ब्रेकर ढाँचाहरू भएका Kubernetes कन्टेनरहरू, साथै Chaos Monkey, KeyBank अनुप्रयोगको लागि यो सबै प्रयोग गर्दछ। तर यी कन्टेनरहरू अन्ततः COBOL मा अनुप्रयोगसँग जोडिएका छन्।

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

३. बाधाहरूको सिद्धान्त: बाधाहरूको सिद्धान्त

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

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

यस प्रकारको समस्या समाधान गर्न, म उदाहरणका लागि, Slack प्रयोग गर्ने सुझाव दिन सक्छु। एक स्मार्ट सीईओले सोध्नेछ, किन? सामान्यतया, यस्ता अवस्थामा, DevOps सल्लाहकारहरूले जवाफ दिन्छन्, किनभने सबैले यो गर्छन्। यदि सीईओ साँच्चै स्मार्ट छ भने, उसले भन्नेछ, त्यसो भए के। र त्यो कुराकानीको अन्त्य हो। र त्यो म भन्छु, किनभने कम्पनीमा चार अवरोधहरू छन्, फ्रेड, लू, सुसी, र जेन। तिनीहरूको ज्ञानलाई संस्थागत गर्ने पहिलो चरण स्ल्याकलाई परिचय गराउनु हो। तपाईंका सबै विकीहरू पूर्ण रूपमा बकवास छन्, किनभने कसैलाई थाहा छैन कि तिनीहरू अवस्थित छन्। यदि इन्जिनियरहरूको टोलीले फ्रन्ट-एन्ड र ब्याक-एन्ड विकास गर्छ, र सबैलाई थाहा हुनुपर्छ कि तिनीहरू प्रश्नहरू सहित फ्रन्ट-एन्ड टोली वा पूर्वाधार टोलीमा जान सक्छन्, तब Lou वा Fred सँग विकीमा जडान गर्न समय हुनेछ। र त्यसपछि, Slack मा, कसैले सोध्न सक्छ, किन, भन्नुहोस्, चरण 5 काम गरिरहेको छैन। र त्यसपछि Lou वा Fred ले विकीमा निर्देशनहरू ठीक गर्नेछन्। यदि तपाईंले त्यो प्रक्रिया चलाउनुभयो भने, धेरै कुराहरू ठाउँमा पर्नेछन्।

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

४. सहकार्य ह्याक्स: सहकार्यका ह्याक्सहरू

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

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

५. काता कोचिङ

मैले सुरुमै चेतावनी दिएझैं, म आज यसको बारेमा कुरा गर्दिन। यदि तपाईंलाई रुचि छ भने, तपाईं हेर्न सक्नुहुन्छ मेरा केही प्रस्तुतिहरू.

यस विषयमा माइक रोथरबाट पनि राम्रो कुराकानी छ:

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

यहाँ विभिन्न समस्याहरू छन्। उदाहरणका लागि, "I" मानिसहरू, "T" मानिसहरू, र "E" मानिसहरू। "I" मानिसहरू ती हुन् जसले केवल एउटा काम गर्छन्। तिनीहरू सामान्यतया पृथक विभागहरू भएका संस्थाहरूमा अवस्थित हुन्छन्। "T" भनेको जब कुनै व्यक्ति एउटा कुरामा राम्रो हुन्छ, तर अन्य धेरै कुराहरूमा पनि उत्कृष्ट हुन्छ। "E" वा "कम्ब" भनेको जब कुनै व्यक्तिसँग धेरै सीपहरू हुन्छन्।

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

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

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

७. सिफ्ट-लेफ्ट लेखा परीक्षकहरू: चक्रको सुरुवातमा लेखा परीक्षक। सुरक्षा अनुपालन प्रदर्शनमा छ।

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

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

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

अनुसार रिपोर्टसोनाटाइपद्वारा २०१८ मा सिर्जना गरिएको, २०१७ मा ८७ अर्ब OSS डाउनलोड अनुरोधहरू थिए।

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

यस्तो अनुक्रमको उदाहरण:

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

अनि सुरक्षामा हामीले उही दृष्टिकोण लागू गर्न नसक्ने कुनै कारण छैन।

परिणाम

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