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

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

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

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

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

IT व्यवस्थापनमा 35 वर्ष भन्दा बढी, क्यानोनिकलमा ओपनक्लाउडको पूर्ववर्ती निर्माणमा भाग लिई, 10 स्टार्टअपहरूमा भाग लिए, जसमध्ये दुई डेल र डकरलाई बेचेका थिए। हाल उहाँ SJ Technologies मा DevOps र डिजिटल अभ्यासका उपाध्यक्ष हुनुहुन्छ।

अर्को जोनको दृष्टिकोणबाट कथा हो।

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

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

DevOps के हो?

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

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

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

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

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

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

खराब संस्कृतिले नाश्ताको लागि राम्रो दृष्टिकोण खान्छ

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

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

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

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

(यो दृष्टान्त अलग देखि हेर्न सकिन्छ लिङ्क हेर्नुहोस्)

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

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

(यो दृष्टान्त अलग देखि हेर्न सकिन्छ लिङ्क हेर्नुहोस्)

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

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

(यो दृष्टान्त अलग देखि हेर्न सकिन्छ लिङ्क हेर्नुहोस्)

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

(यो दृष्टान्त अलग देखि हेर्न सकिन्छ लिङ्क हेर्नुहोस्)

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

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

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

(यो दृष्टान्त अलग देखि हेर्न सकिन्छ लिङ्क हेर्नुहोस्)

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

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

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

1. सबै कार्य दृश्यात्मक बनाउनुहोस्: कार्य दृश्यात्मक बनाउनुहोस्

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

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

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

फीनिक्स परियोजना एक परियोजना को बारे मा एक अद्भुत कथा हो जुन तीन वर्ष धेरै ढिलो थियो। यसका कारण एउटा पात्रले बर्खास्तिको सामना गर्नुपरेको छ, र उसले अर्को पात्रसँग भेट्छ जुन एक प्रकारको सुकरातको रूपमा प्रस्तुत गरिएको छ। उसले वास्तवमा के गलत भयो भनेर पत्ता लगाउन मद्दत गर्दछ। यो बाहिर जान्छ कि कम्पनीसँग एक प्रणाली प्रशासक छ, जसको नाम ब्रेन्ट हो, र सबै काम कुनै न कुनै रूपमा उहाँ मार्फत जान्छ। एक बैठकमा, मातहतका एक जनालाई सोधिन्छ: किन प्रत्येक आधा घण्टाको कार्य एक हप्ता लाग्छ? जवाफ पङ्क्तिबद्ध सिद्धान्त र लिटिलको कानूनको एक धेरै सरल प्रस्तुतीकरण हो, र यस प्रस्तुतीकरणमा यो बाहिर जान्छ कि 90% ओकपेन्सीमा, कामको प्रत्येक घण्टा 9 घण्टा लाग्छ। प्रत्येक कार्य अन्य सात जनालाई पठाउन आवश्यक छ, त्यसैले त्यो घण्टा 63 घण्टा, 7 गुणा 9 बन्छ। म के भन्दैछु कि Little's Law वा कुनै जटिल क्युइङ सिद्धान्त प्रयोग गर्नको लागि, तपाइँसँग कम्तिमा डाटा हुनु आवश्यक छ।

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

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

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

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

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

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

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

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

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

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

3. अवरोधहरूको सिद्धान्त: अवरोधहरूको सिद्धान्त

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

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

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

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

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

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

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

5. कोचिङ काटा

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

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

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

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

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

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

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

7. शिफ्ट-बायाँ लेखा परीक्षकहरू: चक्रमा प्रारम्भिक लेखापरीक्षण। प्रदर्शनमा सुरक्षा नियमहरूको अनुपालन

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

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

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

अनुसार रिपोर्टSonatype द्वारा 2018 मा सिर्जना गरिएको, 2017 मा 87 बिलियन OSS डाउनलोड अनुरोधहरू थिए।

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

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


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

र त्यहाँ कुनै कारण छैन कि हामीले सुरक्षाको लागि समान दृष्टिकोण लिन सकेनौं।

परिणाम

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

उपयोगी लिङ्कहरू

यहाँ DevOops सम्मेलनबाट केहि कुराकानीहरू छन् जुन तपाईंलाई उपयोगी लाग्न सक्छ:

• Sergey Berdnikov, Artyom Kalichkin - सफलताको कथा, वा "Dev+DevOps+Ops" (видео, रिपोर्ट को ट्रान्सक्रिप्ट)
• Baruch Sadogursky, Leonid Igolnik - DevOps on a Scale: a Greek tragedy in three acts (видео, रिपोर्ट को ट्रान्सक्रिप्ट)
• अलेक्जेंडर टिटोभ, किरिल टोल्काचेव - DevOps, इन्जिनियरहरू र समुदाय
• तिमोथी लिस्टर - चरित्र, समुदाय र संस्कृति: समृद्धिका लागि महत्त्वपूर्ण कारकहरू

मा हेर्नुहोस कार्यक्रम DevOops २०२० मस्को - त्यहाँ धेरै रोचक चीजहरू पनि छन्।

स्रोत: www.habr.com