DevOps तत्त्वांवर आधारित सात परिवर्तन आर्केटाइप

"डेव्हॉप्स कसे अंमलात आणायचे" हा प्रश्न वर्षानुवर्षे आहे, परंतु तेथे बरेच चांगले साहित्य नाहीत. काहीवेळा तुम्ही स्मार्ट नसलेल्या सल्लागारांच्या जाहिरातींना बळी पडता ज्यांना त्यांचा वेळ विकायचा असतो, काहीही असो. काहीवेळा हे अस्पष्ट, अत्यंत सामान्य शब्द आहेत की मेगाकॉर्पोरेशन्सची जहाजे विश्वाचा विस्तार कसा नांगरतात. प्रश्न उद्भवतो: याने आपल्याला काय फरक पडतो? प्रिय लेखक, तुम्ही तुमच्या कल्पना स्पष्टपणे यादीत तयार करू शकता का?

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

जॉन विलिस - DevOps च्या वडिलांपैकी एक. जॉनला अनेक कंपन्यांमध्ये काम करण्याचा अनेक दशकांचा अनुभव आहे. अलीकडे, जॉनने त्या प्रत्येकासोबत काम करताना विशिष्ट नमुने लक्षात घेण्यास सुरुवात केली. या आर्किटाइपचा वापर करून, जॉन कंपन्यांना DevOps परिवर्तनाच्या खऱ्या मार्गावर मार्गदर्शन करतो. DevOops 2018 कॉन्फरन्समधील त्याच्या अहवालाच्या भाषांतरामध्ये या आर्किटाइपबद्दल अधिक वाचा.

स्पीकर बद्दल:

IT व्यवस्थापनात 35 वर्षांहून अधिक काळ, Canonical येथे OpenCloud च्या पूर्ववर्ती निर्मितीमध्ये भाग घेतला, 10 स्टार्टअप्समध्ये भाग घेतला, त्यापैकी दोन डेल आणि डॉकरला विकले गेले. सध्या ते SJ Technologies येथे DevOps आणि डिजिटल प्रॅक्टिसेसचे उपाध्यक्ष आहेत.

पुढे जॉनच्या दृष्टिकोनातून कथा आहे.

माझे नाव जॉन विलिस आहे आणि मला शोधण्याचे सर्वात सोपे ठिकाण म्हणजे Twitter वर, @botchagalupe. माझ्याकडे Gmail आणि GitHub वर समान उपनाव आहे. ए या दुव्याद्वारे तुम्ही माझ्या अहवालांचे व्हिडिओ रेकॉर्डिंग आणि त्यांच्यासाठी सादरीकरणे शोधू शकता.

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

DevOps म्हणजे काय?

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

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

शेवटी मी खालील गोष्टी दिल्या DevOps ची व्याख्या: हा सराव आणि नमुन्यांचा एक संच आहे जो मानवी भांडवलाचे उच्च-कार्यक्षमता संस्थात्मक भांडवलामध्ये रूपांतर करण्यास सक्षम करतो. टोयोटा गेल्या 50 किंवा 60 वर्षांपासून ज्या पद्धतीने काम करत आहे त्याचे उदाहरण आहे.

(यापुढे, अशा आकृत्या संदर्भ साहित्य म्हणून न देता, उदाहरण म्हणून दिल्या आहेत. प्रत्येक नवीन कंपनीसाठी त्यांची सामग्री वेगळी असेल. तथापि, चित्र स्वतंत्रपणे पाहिले जाऊ शकते आणि मोठे केले जाऊ शकते. या लिंकवर.)

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

मला वाटते की माझ्या अनेक सहकार्‍यांची चूक ही आहे की ते कंपनीला फक्त पाच-पॉइंट मार्गदर्शक देतात आणि नंतर सहा महिन्यांनी परत येतात आणि काय झाले ते पहा. व्हॅल्यू स्ट्रीम मॅपिंगसारख्या चांगल्या योजनेतही, ब्लाइंड स्पॉट्स आहेत. विविध कंपन्यांच्या संचालकांच्या शेकडो मुलाखतींनंतर, मी एक विशिष्ट नमुना विकसित केला आहे जो आम्हाला समस्या त्याच्या घटकांमध्ये विभाजित करण्यास अनुमती देतो आणि आता आम्ही या प्रत्येक घटकावर क्रमाने चर्चा करू. कोणतेही तांत्रिक उपाय लागू करण्यापूर्वी, मी हा नमुना वापरतो आणि परिणामी, माझ्या सर्व भिंती आकृत्यांनी झाकल्या जातात. अलीकडे मी म्युच्युअल फंडासोबत काम करत होतो आणि अशा 100-150 योजना मी संपवल्या.

वाईट संस्कृती नाश्त्यासाठी चांगला दृष्टिकोन खातो

मुख्य कल्पना ही आहे: संस्थेची संस्कृतीच खराब असल्यास लीन, एजाइल, सेफ आणि डेव्हऑप्सची कोणतीही रक्कम मदत करणार नाही. हे स्कूबा गियरशिवाय खोलवर जाण्यासारखे आहे किंवा क्ष-किरणांशिवाय काम करणे आहे. दुस-या शब्दात, ड्रकर आणि डेमिंगचा अर्थ सांगण्यासाठी: एक वाईट संघटनात्मक संस्कृती कोणत्याही चांगल्या प्रणालीला गुदमरल्याशिवाय गिळून टाकते.

या मुख्य समस्येचे निराकरण करण्यासाठी, आपण खालील चरणांचे पालन करणे आवश्यक आहे:

1. सर्व कार्य दृश्यमान करा: आपल्याला सर्व कार्य दृश्यमान करणे आवश्यक आहे. ते काही स्क्रीनवर प्रदर्शित केले जाणे आवश्यक आहे या अर्थाने नाही, परंतु ते निरीक्षण करण्यायोग्य असले पाहिजे या अर्थाने.
2. एकत्रित कार्य व्यवस्थापन प्रणाली: व्यवस्थापन प्रणाली एकत्रित करणे आवश्यक आहे. "आदिवासी" ज्ञान आणि संस्थात्मक ज्ञानाच्या समस्येमध्ये, 9 पैकी 10 प्रकरणांमध्ये अडथळे लोक आहेत. पुस्तकामध्ये "फिनिक्स प्रकल्प" समस्या ब्रेंट या एकाच व्यक्तीची होती, ज्यामुळे प्रकल्पाला तीन वर्षे उशीर झाला. आणि मी सर्वत्र या “ब्रेंट्स” मध्ये धावतो. या अडथळ्यांचे निराकरण करण्यासाठी, मी आमच्या यादीतील पुढील दोन आयटम वापरतो.
3. प्रतिबंध पद्धतीचा सिद्धांत: मर्यादांचा सिद्धांत.
4. सहयोग हॅक: सहयोग हॅक.
5. टोयोटा काटा (कोचिंग काटा): मी टोयोटा काटा बद्दल जास्त बोलणार नाही. स्वारस्य असल्यास, माझ्या github वर सादरीकरणे आहेत यापैकी जवळजवळ प्रत्येक विषयावर.
6. बाजाराभिमुख संघटना: बाजाराभिमुख संस्था.
7. शिफ्ट-डावे ऑडिटर्स: सायकलच्या सुरुवातीच्या टप्प्यावर ऑडिट.

मी एका संस्थेसोबत अगदी सहजतेने काम करायला सुरुवात करतो: मी कंपनीत जातो आणि कर्मचाऱ्यांशी बोलतो. जसे आपण पाहू शकता, उच्च तंत्रज्ञान नाही. तुम्हाला फक्त काहीतरी लिहिण्याची गरज आहे. मी एका खोलीत अनेक संघ एकत्र करतो आणि माझ्या 7 आर्किटाइपच्या दृष्टीकोनातून ते मला काय सांगतात याचे विश्लेषण करते. आणि मग मी त्यांना स्वतः एक मार्कर देतो आणि त्यांनी आतापर्यंत मोठ्याने जे काही सांगितले ते सर्व बोर्डवर लिहायला सांगतो. सहसा या प्रकारच्या मीटिंगमध्ये एक व्यक्ती असते जी सर्वकाही लिहून ठेवते आणि जास्तीत जास्त 10% चर्चा लिहू शकते. माझ्या पद्धतीसह, हा आकडा सुमारे 40% पर्यंत वाढविला जाऊ शकतो.

(हे उदाहरण स्वतंत्रपणे पाहिले जाऊ शकते लिंक पहा)

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

काहीसा चांगला पर्याय म्हणजे उच्च पातळीचे नियंत्रण आणि सक्षमता. जर अशी कंपनी फायदेशीर असेल तर कदाचित तिला DevOps ची गरज नाही. उच्च पातळीचे नियंत्रण, कमी क्षमता आणि सहकार्य असलेल्या कंपनीबरोबर काम करणे सर्वात मनोरंजक आहे, परंतु त्याच वेळी उच्च पातळीची संस्कृती (शेती). याचा अर्थ कंपनीकडे भरपूर लोक आहेत ज्यांना तिथे काम करायला आवडते आणि कामगारांची उलाढाल कमी आहे.

(हे उदाहरण स्वतंत्रपणे पाहिले जाऊ शकते लिंक पहा)

मला असे वाटते की कठोर मार्गदर्शक तत्त्वे असलेल्या पद्धती सत्याच्या प्राप्तीच्या मार्गात येतात. विशेषतः व्हॅल्यू स्ट्रीम मॅपिंगमध्ये, माहितीची रचना कशी करावी यासंबंधी अनेक नियम आहेत. कामाच्या सुरुवातीच्या टप्प्यात, ज्याबद्दल मी आता बोलत आहे, कोणालाही या नियमांची आवश्यकता नाही. जर त्याच्या हातात मार्कर असलेल्या व्यक्तीने बोर्डवर कंपनीमधील वास्तविक परिस्थितीचे वर्णन केले तर, परिस्थिती समजून घेण्याचा हा सर्वोत्तम मार्ग आहे. अशी माहिती संचालकांपर्यंत पोहोचत नाही. या क्षणी, त्या व्यक्तीला व्यत्यय आणणे आणि त्याने चुकीचा बाण काढला असे म्हणणे मूर्खपणाचे आहे. या टप्प्यावर, साधे नियम वापरणे चांगले आहे, उदाहरणार्थ: बहु-रंगीत मार्कर वापरून बहु-स्तरीय अमूर्तता तयार केली जाऊ शकते.

मी पुनरावृत्ती करतो, उच्च तंत्रज्ञान नाही. ब्लॅक मार्कर सर्वकाही कसे कार्य करते याचे वस्तुनिष्ठ वास्तव चित्रित करते. लाल मार्करसह, लोक वर्तमान स्थितीबद्दल त्यांना काय आवडत नाही ते चिन्हांकित करतात. त्यांनी हे लिहिणे महत्त्वाचे आहे, मी नाही. जेव्हा मी मीटिंगनंतर CIO कडे जातो, तेव्हा मी 10 गोष्टींची यादी देत ​​नाही ज्यांचे निराकरण करणे आवश्यक आहे. मी कंपनीतील लोक काय म्हणत आहेत आणि विद्यमान सिद्ध नमुने यांच्यात संबंध शोधण्याचा प्रयत्न करतो. शेवटी, निळा मार्कर समस्येवर संभाव्य उपाय सुचवतो.

(हे उदाहरण स्वतंत्रपणे पाहिले जाऊ शकते लिंक पहा)

या दृष्टिकोनाचे उदाहरण आता वर चित्रित केले आहे. या वर्षाच्या सुरुवातीला मी एका बँकेत काम केले. तिथल्या सिक्युरिटी लोकांना खात्री पटली की त्यांनी डिझाईन आणि आवश्यक रिव्ह्यूज करायला येऊ नये.

(हे उदाहरण स्वतंत्रपणे पाहिले जाऊ शकते लिंक पहा)

आणि मग आम्ही इतर विभागातील लोकांशी बोललो आणि असे दिसून आले की सुमारे 8 वर्षांपूर्वी, सॉफ्टवेअर डेव्हलपर्सनी सुरक्षा कर्मचार्‍यांना कामावरून काढून टाकले कारण ते काम कमी करत होते. आणि मग ते बंदीमध्ये बदलले, जे गृहित धरले गेले. प्रत्यक्षात मात्र बंदी नव्हती.

आमची बैठक अत्यंत गोंधळात पार पडली: सुमारे तीन तास, पाच वेगवेगळ्या टीम मला कोड आणि असेंब्लीमध्ये काय घडत आहे हे समजावून सांगू शकले नाहीत. आणि ही सर्वात सोपी गोष्ट वाटेल. बहुतेक DevOps सल्लागार असे गृहीत धरतात की प्रत्येकाला हे आधीच माहित आहे.

मग चार तास गप्प बसलेल्या आयटी गव्हर्नन्सचा प्रभारी व्यक्ती, जेव्हा आम्ही त्याच्या विषयावर गेलो तेव्हा अचानक जीव आला आणि त्याने बराच वेळ आमच्यावर कब्जा केला. शेवटी मी त्याला मीटिंगबद्दल काय मत विचारले, आणि मी त्याचे उत्तर कधीही विसरणार नाही. तो म्हणाला: "मला वाटायचे की आमच्या बँकेकडे सॉफ्टवेअर वितरित करण्याचे दोनच मार्ग आहेत, परंतु आता मला माहित आहे की त्यापैकी पाच आहेत आणि मला तीन बद्दल माहिती देखील नाही."

(हे उदाहरण स्वतंत्रपणे पाहिले जाऊ शकते लिंक पहा)

या बँकेत शेवटची बैठक गुंतवणूक सॉफ्टवेअर टीमसोबत झाली होती. तिच्याबरोबरच असे दिसून आले की कागदाच्या शीटवर मार्करसह आकृती लिहिणे हे बोर्डपेक्षा चांगले आहे आणि स्मार्टबोर्डपेक्षा देखील चांगले आहे.

आमच्या मीटिंगच्या चौथ्या दिवशी हॉटेल कॉन्फरन्स रूम कसा दिसत होता ते तुम्ही पाहत आहात. आणि आम्‍ही या योजनांचा वापर नमुने शोधण्‍यासाठी केला, म्हणजेच पुरातन प्रकार.

म्हणून, मी कामगारांना प्रश्न विचारतो, ते तीन रंगांच्या (काळा, लाल आणि निळा) मार्करसह उत्तरे लिहितात. मी त्यांच्या उत्तरांचे पुरातनीकरणासाठी विश्लेषण करतो. आता क्रमाने सर्व आर्किटाइपची चर्चा करूया.

1. सर्व कार्य दृश्यमान करा: कार्य दृश्यमान करा

मी ज्या कंपन्यांमध्ये काम करतो त्यांच्याकडे अज्ञात कामाची टक्केवारी खूप जास्त आहे. उदाहरणार्थ, जेव्हा एक कर्मचारी दुसर्‍याकडे येतो आणि काहीतरी करण्यास सांगतो तेव्हा असे होते. मोठ्या संस्थांमध्ये, 60% अनियोजित काम असू शकते. आणि 40% पर्यंत काम कोणत्याही प्रकारे दस्तऐवजीकरण केलेले नाही. जर ते बोईंग असते तर मी माझ्या आयुष्यात पुन्हा त्यांच्या विमानात चढू शकलो नसतो. निम्म्याच कामाचे दस्तऐवजीकरण केले तर हे काम योग्य पद्धतीने होत आहे की नाही हे कळत नाही. इतर सर्व पद्धती निरुपयोगी ठरल्या - काहीही स्वयंचलित करण्याचा प्रयत्न करण्यात काही अर्थ नाही, कारण ज्ञात 50% कामाचा सर्वात सुसंगत आणि स्पष्ट भाग असू शकतो, ज्याचे ऑटोमेशन उत्कृष्ट परिणाम देणार नाही आणि सर्व वाईट गोष्टी अदृश्य अर्ध्यामध्ये आहेत. कागदपत्रांच्या अनुपस्थितीत, सर्व प्रकारचे खाच आणि लपविलेले काम शोधणे अशक्य आहे, अडथळे शोधणे अशक्य आहे, ते "ब्रेंट्स" ज्याबद्दल मी आधीच बोललो आहे. डॉमिनिका डीग्रॅंडिस यांचे एक अप्रतिम पुस्तक आहे "कार्य दृश्यमान करणे". ती प्रकट करते पाच भिन्न "वेळ गळती" (वेळेचे चोर):

• प्रक्रियेत खूप जास्त काम (डब्ल्यूआयपी)
• अज्ञात अवलंबित्व
• अनियोजित काम
• परस्परविरोधी प्राधान्यक्रम
• दुर्लक्षित काम

हे अतिशय मौल्यवान विश्लेषण आहे आणि पुस्तक छान आहे, परंतु केवळ 50% डेटा दृश्यमान असल्यास हा सर्व सल्ला निरुपयोगी आहे. 90% पेक्षा जास्त अचूकता प्राप्त झाल्यास डॉमिनिकाने प्रस्तावित केलेल्या पद्धती वापरल्या जाऊ शकतात. मी अशा परिस्थितींबद्दल बोलत आहे जिथे बॉस अधीनस्थ व्यक्तीला 15-मिनिटांचे कार्य देतो, परंतु त्याला तीन दिवस लागतात; पण बॉसला हे कळत नाही की हा गौण चार-पाच लोकांवर अवलंबून आहे.

फिनिक्स प्रोजेक्ट ही एका प्रकल्पाची एक अद्भुत कथा आहे जी तीन वर्षे खूप उशीर झाली होती. एका पात्राला यामुळे डिसमिसला सामोरे जावे लागते आणि त्याची भेट दुसऱ्या एका पात्राशी होते ज्याला सॉक्रेटिसच्या रूपात सादर केले जाते. तो नेमका काय चुकला हे समजण्यास मदत करतो. असे दिसून आले की कंपनीकडे एक सिस्टम प्रशासक आहे, ज्याचे नाव ब्रेंट आहे आणि सर्व काम कसे तरी त्याच्याद्वारे जाते. एका मीटिंगमध्ये, अधीनस्थांपैकी एकाला विचारले जाते: प्रत्येक अर्ध्या तासाच्या कार्याला आठवडा का लागतो? उत्तर हे रांगेतील सिद्धांत आणि लिटल्स कायद्याचे एक अतिशय सोप्या पद्धतीने सादरीकरण आहे आणि या सादरीकरणात असे दिसून आले आहे की 90% व्यापामध्ये, प्रत्येक तासाला 9 तास लागतात. प्रत्येक कार्य इतर सात लोकांना पाठवणे आवश्यक आहे, जेणेकरून तो तास 63 तास, 7 गुणिले 9 होईल. मी काय म्हणतो आहे की लिटल्स लॉ किंवा कोणत्याही जटिल रांगेतील सिद्धांत वापरण्यासाठी, आपल्याकडे किमान डेटा असणे आवश्यक आहे.

म्हणून जेव्हा मी दृश्यमानतेबद्दल बोलतो, तेव्हा माझा अर्थ असा नाही की सर्व काही स्क्रीनवर आहे, परंतु आपल्याकडे किमान डेटा आहे. जेव्हा ते करतात, तेव्हा असे दिसून येते की तेथे खूप मोठ्या प्रमाणात अनियोजित काम आहे ज्याची गरज नसताना ब्रेंटला पाठवले जात आहे. आणि ब्रेंट एक चांगला माणूस आहे, तो कधीही नाही म्हणणार नाही, परंतु तो त्याचे काम कसे करतो हे तो कोणालाही सांगत नाही.

जेव्हा कार्य दृश्यमान असेल, तेव्हा डेटाचे व्यवस्थित वर्गीकरण केले जाऊ शकते (फोटोमध्ये डॉमिनिका तेच करत आहे), पाच वेळा लीकचे अमूर्तीकरण लागू केले जाऊ शकते आणि ऑटोमेशन लागू केले जाऊ शकते.

2. कार्य व्यवस्थापन प्रणाली एकत्रित करा: कार्य व्यवस्थापन

मी ज्या आर्कीटाइपबद्दल बोलत आहे ते एक प्रकारचे पिरॅमिड आहेत. जर पहिले योग्यरित्या केले असेल, तर दुसरे आधीच एक प्रकारचे अॅड-ऑन आहे. यांपैकी अनेक स्टार्टअप्ससाठी काम करत नाहीत, त्यांना फॉर्च्युन 5000 सारख्या मोठ्या कंपन्यांसाठी लक्षात ठेवण्याची गरज आहे. मी शेवटच्या कंपनीत 10 तिकीट प्रणाली होत्या. एका टीमकडे Remedy होती, दुसऱ्या टीमने काही प्रकारची स्वतःची सिस्टीम लिहिली होती, तिसऱ्याने Jira वापरला होता आणि काहींनी ईमेलद्वारे केला होता. कंपनीकडे 30 वेगवेगळ्या पाइपलाइन असल्यास समान समस्या उद्भवते, परंतु माझ्याकडे अशा सर्व प्रकरणांवर चर्चा करण्यासाठी वेळ नाही.

तिकिटे कशी तयार केली जातात, त्यांचे पुढे काय होते आणि ते कसे टाळले जातात याबद्दल मी लोकांशी चर्चा करतो. सर्वात मनोरंजक गोष्ट म्हणजे आमच्या सभांमध्ये लोक अगदी मनापासून बोलतात. मी विचारले की किती लोक तिकिटांवर "मायनर / नो इम्पॅक्ट" टाकतात ज्यांना प्रत्यक्षात "प्रमुख प्रभाव" द्यायला हवा. असे दिसून आले की जवळजवळ प्रत्येकजण हे करतो. मी निंदा करत नाही आणि लोकांना ओळखू नये यासाठी सर्व प्रकारे प्रयत्न करतो. जेव्हा ते माझ्यासमोर प्रामाणिकपणे काहीतरी कबूल करतात, तेव्हा मी त्या व्यक्तीला सोडत नाही. परंतु जेव्हा जवळजवळ प्रत्येकजण सिस्टमला बायपास करतो तेव्हा याचा अर्थ असा होतो की सर्व सुरक्षा अनिवार्यपणे विंडो ड्रेसिंग आहे. त्यामुळे या प्रणालीच्या डेटावरून कोणताही निष्कर्ष काढता येत नाही.

तिकीट समस्येचे निराकरण करण्यासाठी, तुम्हाला एक मुख्य प्रणाली निवडण्याची आवश्यकता आहे. जिरा वापरत असाल तर जिरा ठेवा. जर काही पर्याय असेल तर तो एकच असू द्या. मुख्य गोष्ट अशी आहे की तिकीटांकडे विकास प्रक्रियेतील आणखी एक पाऊल म्हणून पाहिले पाहिजे. प्रत्येक कृतीचे तिकीट असणे आवश्यक आहे, जे विकास कार्यप्रवाहातून प्रवाहित झाले पाहिजे. संघाला तिकिटे पाठवली जातात, जी त्यांना स्टोरीबोर्डवर पोस्ट करते आणि नंतर त्यांची जबाबदारी घेते.

हे पायाभूत सुविधा आणि ऑपरेशन्ससह सर्व विभागांना लागू होते. या प्रकरणात, घडामोडींच्या स्थितीची किमान काही प्रशंसनीय कल्पना तयार करणे शक्य आहे. एकदा ही प्रक्रिया स्थापित झाल्यानंतर, प्रत्येक अर्जासाठी कोण जबाबदार आहे हे ओळखणे अचानक सोपे होते. कारण आता आम्हाला 50% नाही तर 98% नवीन सेवा मिळतात. ही मुख्य प्रक्रिया कार्य करत असल्यास, संपूर्ण प्रणालीमध्ये अचूकता सुधारते.

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

हे पुन्हा फक्त मोठ्या कंपन्यांना लागू होते. जर तुम्ही नवीन क्षेत्रात नवीन कंपनी असाल, तर तुमचे आस्तीन गुंडाळा आणि तुमच्या Travis CI किंवा CircleCI सोबत काम करा. फॉर्च्युन 5000 कंपन्यांचा विचार केला तर, मी काम केलेल्या बँकेत घडलेली एक घटना. गुगल त्यांच्याकडे आले आणि त्यांना जुन्या IBM सिस्टीमचे आरेखन दाखवण्यात आले. गुगलच्या लोकांनी गोंधळात विचारले - याचा सोर्स कोड कुठे आहे? परंतु कोणताही स्त्रोत कोड नाही, अगदी GUI देखील नाही. ही वास्तविकता आहे ज्याला मोठ्या संस्थांना सामोरे जावे लागते: प्राचीन मेनफ्रेमवर 40-वर्षीय बँक रेकॉर्ड. माझा एक क्लायंट कीबँक ऍप्लिकेशनसाठी सर्किट ब्रेकर पॅटर्नसह कुबर्नेट्स कंटेनर, तसेच कॅओस मंकी वापरतो. परंतु हे कंटेनर शेवटी COBOL ऍप्लिकेशनशी जोडले जातात.

गुगलच्या लोकांना पूर्ण विश्वास होता की ते माझ्या क्लायंटच्या सर्व समस्या सोडवतील आणि मग त्यांनी प्रश्न विचारण्यास सुरुवात केली: IBM डेटापाइप म्हणजे काय? त्यांना सांगितले जाते: हा एक कनेक्टर आहे. ते कशाशी जोडते? स्पेरी प्रणालीला. आणि ते काय आहे? वगैरे. पहिल्या दृष्टीक्षेपात असे दिसते: कोणत्या प्रकारचे DevOps असू शकतात? पण खरं तर, ते शक्य आहे. डिलिव्हरी सिस्टीम आहेत ज्या तुम्हाला डिलिव्हरी टीम्सकडे वर्कफ्लो सोपवण्याची परवानगी देतात.

3. थिअरी ऑफ कंस्ट्रेंट्स: थिअरी ऑफ कंस्ट्रेंट्स

चला तिसर्‍या आर्किटाइपकडे वळू: संस्थात्मक/"आदिवासी" ज्ञान. नियमानुसार, कोणत्याही संस्थेमध्ये असे बरेच लोक असतात ज्यांना सर्वकाही माहित असते आणि सर्वकाही व्यवस्थापित करतात. हे असे लोक आहेत जे सर्वात जास्त काळ संस्थेत आहेत आणि ज्यांना सर्व उपाय माहित आहेत.

जेव्हा हे आकृतीवर येते, तेव्हा मी अशा लोकांना विशेषतः मार्करसह वर्तुळ करतो: उदाहरणार्थ, असे दिसून आले की सर्व मीटिंगमध्ये एक विशिष्ट लू उपस्थित आहे. आणि हे माझ्यासाठी स्पष्ट आहे: हे स्थानिक ब्रेंट आहे. जेव्हा सीआयओ माझ्यामध्ये टी-शर्ट आणि स्नीकर्स आणि सूट घातलेला मुलगा IBM मधून निवडतो, तेव्हा मी निवडले जाते कारण मी दिग्दर्शकाला अशा गोष्टी सांगू शकतो जे दुसरा माणूस सांगणार नाही आणि दिग्दर्शकाला ऐकायला आवडणार नाही. . मी त्यांना सांगतो की त्यांच्या कंपनीतील अडथळे कोणीतरी फ्रेड नावाचे आणि कोणीतरी लू नावाचे आहेत. ही अडचण दूर करणे आवश्यक आहे, त्यांचे ज्ञान त्यांच्याकडून एक किंवा दुसर्या मार्गाने मिळवणे आवश्यक आहे.

या प्रकारच्या समस्येचे निराकरण करण्यासाठी, मी, उदाहरणार्थ, स्लॅक वापरण्याचे सुचवू शकतो. एक हुशार दिग्दर्शक विचारेल - का? सामान्यतः, अशा प्रकरणांमध्ये, DevOps सल्लागार उत्तर देतात: कारण प्रत्येकजण ते करत आहे. जर दिग्दर्शक खरोखर हुशार असेल तर तो म्हणेल: मग काय. आणि इथेच संवाद संपतो. आणि यावर माझे उत्तर आहे: कारण कंपनीत चार अडथळे आहेत, फ्रेड, लू, सुझी आणि जेन. त्यांचे ज्ञान संस्थात्मक करण्यासाठी, प्रथम स्लॅकचा परिचय करून देणे आवश्यक आहे. तुमचे सर्व विकि पूर्णपणे मूर्खपणाचे आहेत कारण त्यांच्या अस्तित्वाबद्दल कोणालाही माहिती नाही. जर अभियांत्रिकी संघ फ्रंट-एंड आणि बॅक-एंड डेव्हलपमेंटमध्ये गुंतलेला असेल आणि प्रत्येकाला हे माहित असणे आवश्यक आहे की ते फ्रंट-एंड डेव्हलपमेंट टीम किंवा इन्फ्रास्ट्रक्चर टीमशी प्रश्नांसह संपर्क साधू शकतात. तेव्हा लू किंवा फ्रेडला विकिमध्ये सामील होण्यासाठी वेळ मिळेल. आणि मग स्लॅकमध्ये कोणीतरी विचारू शकते की, पायरी 5 का काम करत नाही. आणि मग Lou किंवा Fred विकीवरील सूचना दुरुस्त करतील. जर आपण ही प्रक्रिया स्थापित केली तर बर्‍याच गोष्टी स्वतःच घडतील.

हा माझा मुख्य मुद्दा आहे: कोणत्याही उच्च तंत्रज्ञानाची शिफारस करण्यासाठी, आपण प्रथम त्यांच्यासाठी पाया व्यवस्थित ठेवला पाहिजे आणि हे नुकतेच वर्णन केलेल्या लो-टेक सोल्यूशन्ससह केले जाऊ शकते. आपण उच्च तंत्रज्ञानासह प्रारंभ केल्यास आणि त्यांची आवश्यकता का आहे हे स्पष्ट केले नाही तर, नियमानुसार, हे चांगले समाप्त होत नाही. आमचा एक क्लायंट Azure ML वापरतो, हा एक अतिशय स्वस्त आणि सोपा उपाय आहे. त्यांच्या सुमारे 30% प्रश्नांची उत्तरे स्वयं-शिक्षण मशीनद्वारेच दिली गेली. आणि ही गोष्ट त्या ऑपरेटर्सनी लिहिली होती जे डेटा सायन्स, स्टॅटिस्टिक्स किंवा गणितात गुंतलेले नव्हते. हे लक्षणीय आहे. अशा समाधानाची किंमत किमान आहे.

4. कोलॅबोरेशन हॅक: कोलॅबोरेशन हॅक

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

एकाकीपणावर मात करण्याचे अनेक मार्ग आहेत. मला एकदा ऑस्ट्रेलियातील बँकेचा सल्ला घेण्यास सांगितले होते, परंतु मला दोन मुले आणि पत्नी असल्यामुळे मी ते करण्यास नकार दिला. त्यांना मदत करण्यासाठी मी फक्त ग्राफिकल स्टोरीटेलिंगची शिफारस करू शकलो. हे काम सिद्ध झाले आहे की काहीतरी आहे. आणखी एक मनोरंजक मार्ग म्हणजे लीन कॉफी मीटिंग्ज. मोठ्या संस्थेमध्ये, ज्ञानाचा प्रसार करण्यासाठी हा एक उत्कृष्ट पर्याय आहे. याव्यतिरिक्त, तुम्ही अंतर्गत डेव्होप्सडे, हॅकाथॉन इत्यादी आयोजित करू शकता.

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

मी अगदी सुरुवातीला चेतावणी दिल्याप्रमाणे, मी आज याबद्दल बोलणार नाही. तुम्हाला स्वारस्य असल्यास, तुम्ही एक नजर टाकू शकता माझी काही सादरीकरणे.

माईक रॉथरकडून या विषयावर एक चांगली चर्चा देखील आहे:

6. मार्केट ओरिएंटेड: मार्केट ओरिएंटेड संस्था

येथे वेगवेगळ्या समस्या आहेत. उदाहरणार्थ, "I" लोक, "T" लोक आणि "E" लोक. "मी" लोक असे असतात जे फक्त एकच काम करतात. सामान्यतः ते वेगळ्या विभाग असलेल्या संस्थांमध्ये अस्तित्वात असतात. "टी" म्हणजे जेव्हा एखादी व्यक्ती एका गोष्टीत चांगली असते परंतु इतर काही गोष्टींमध्ये देखील चांगली असते. "ई" किंवा अगदी "कंघी" म्हणजे जेव्हा एखाद्या व्यक्तीकडे अनेक कौशल्ये असतात.

कॉनवेचा कायदा येथे कार्य करतो (कॉनवेचा कायदा), ज्याला सर्वात सोप्या स्वरूपात खालीलप्रमाणे सांगितले जाऊ शकते: जर तीन संघ कंपायलरवर कार्य करतात, तर परिणाम तीन भागांचा संकलक असेल. त्यामुळे, एखाद्या संस्थेमध्ये उच्च पातळीचे अलगाव असल्यास, या संस्थेतील कुबर्नेट्स, सर्किट ब्रेकर, API एक्स्टेंसिबिलिटी आणि इतर फॅन्सी गोष्टी देखील संस्थेप्रमाणेच व्यवस्था केल्या जातील. काटेकोरपणे Conway त्यानुसार आणि आपण सर्व तरुण geeks तिरस्कार.

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

बरेच लोक या रचनेचे वेगवेगळ्या प्रकारे वर्णन करतात, मला शब्दरचना आवडते संघ तयार/चालवा, Amazon वर ते याला म्हणतात दोन पिझ्झा संघ. या संरचनेत, सर्व प्रकारचे “I” लोक एका सेवेभोवती गटबद्ध केले जातात आणि हळूहळू ते “T” टाइप करण्याच्या जवळ जातात आणि योग्य व्यवस्थापन असल्यास ते “E” देखील होऊ शकतात. येथे प्रथम प्रतिवाद असा आहे की अशा संरचनेत अनावश्यक घटक असतात. जर तुमच्याकडे परीक्षकांचा एक विशेष विभाग असेल तर तुम्हाला प्रत्येक विभागात परीक्षकाची गरज का आहे? ज्याला मी उत्तर देतो: या प्रकरणात अतिरिक्त खर्च ही संपूर्ण संस्थेसाठी भविष्यात "E" प्रकार होण्यासाठीची किंमत आहे. या संरचनेत, परीक्षक हळूहळू नेटवर्क, आर्किटेक्चर, डिझाइन इत्यादींबद्दल शिकतो. परिणामी, संस्थेतील प्रत्येक सहभागीला संस्थेमध्ये घडणाऱ्या प्रत्येक गोष्टीची पूर्ण माहिती असते. ही योजना उद्योगात कशी काम करते हे जाणून घ्यायचे असेल तर वाचा माईक रॉदर, टोयोटा काटा.

7. शिफ्ट-लेफ्ट ऑडिटर्स: सायकलमध्ये लवकर ऑडिट करा. प्रदर्शनावरील सुरक्षा नियमांचे पालन

जेव्हा तुमची कृती गंध चाचणीत उत्तीर्ण होत नाही तेव्हा असे होते. तुमच्यासाठी काम करणारे लोक मूर्ख नाहीत. जर, वरील उदाहरणाप्रमाणे, त्यांनी सर्वत्र किरकोळ/कोणताही प्रभाव पाडला नाही, तर हे तीन वर्षे चालले, आणि कोणीही काहीही लक्षात घेतले नाही, तर प्रत्येकाला चांगले माहित आहे की सिस्टम कार्य करत नाही. किंवा दुसरे उदाहरण - बदल सल्लागार मंडळ, जेथे प्रत्येक बुधवारी अहवाल सादर करणे आवश्यक आहे. तेथे काम करणार्‍या लोकांचा एक गट आहे (तसे फार चांगले पगार नाही) ज्यांना सिद्धांततः, संपूर्ण प्रणाली कशी कार्य करते हे माहित असले पाहिजे. आणि गेल्या पाच वर्षांत, तुमच्या लक्षात आले असेल की आमची प्रणाली आश्चर्यकारकपणे गुंतागुंतीची आहे. आणि पाच किंवा सहा लोकांना त्यांनी न केलेल्या बदलाबद्दल निर्णय घ्यावा लागतो आणि ज्याबद्दल त्यांना काहीच माहिती नसते.

अर्थात, हा दृष्टिकोन कार्य करत नाही. मला अशा गोष्टींपासून दूर करावे लागेल कारण हे लोक व्यवस्थेचे रक्षण करत नाहीत. निर्णय संघानेच घेतला पाहिजे, कारण त्यासाठी संघ जबाबदार असला पाहिजे. अन्यथा, एक विरोधाभासी परिस्थिती उद्भवते जेव्हा एखादा व्यवस्थापक ज्याने त्याच्या आयुष्यात कोड लिहिला नाही तो प्रोग्रामरला कोड लिहायला किती वेळ लागेल हे सांगतो. मी काम केलेल्या एका कंपनीमध्ये 7 वेगवेगळे बोर्ड होते जे प्रत्येक बदलाचे पुनरावलोकन करतात, ज्यात आर्किटेक्चर बोर्ड, उत्पादन बोर्ड इ. एक अनिवार्य प्रतीक्षा कालावधी देखील होता, जरी एका कर्मचाऱ्याने मला सांगितले की दहा वर्षांच्या कामात, या अनिवार्य कालावधीत या व्यक्तीने केलेला बदल कोणीही नाकारला नाही.

लेखापरीक्षकांना आमच्यात सामील होण्यासाठी आमंत्रित केले जाणे आवश्यक आहे, आणि त्यांची सुटका होऊ नये. त्यांना सांगा की तुम्ही अपरिवर्तनीय बायनरी कंटेनर लिहा जे, जर ते सर्व चाचण्या उत्तीर्ण झाले तर ते कायमचे अपरिवर्तनीय राहतील. त्यांना सांगा की तुमच्याकडे कोड म्हणून पाइपलाइन आहे आणि त्याचा अर्थ काय आहे ते स्पष्ट करा. त्यांना खालील योजना दर्शवा: कंटेनरमध्ये एक अपरिवर्तनीय वाचनीय बायनरी जी सर्व असुरक्षा चाचण्या उत्तीर्ण करते; आणि नंतर कोणीही त्याला स्पर्श करत नाही, तर ते पाइपलाइन तयार करणार्‍या सिस्टमला देखील स्पर्श करत नाहीत, कारण ती गतिमानपणे देखील तयार केली जाते. माझ्याकडे कॅपिटल वन क्लायंट आहेत, जे ब्लॉकचेनसारखे काहीतरी तयार करण्यासाठी व्हॉल्ट वापरत आहेत. ऑडिटरला शेफकडून "पाककृती" दर्शविण्याची आवश्यकता नाही; ब्लॉकचेन दर्शविणे पुरेसे आहे, ज्यावरून हे स्पष्ट होते की उत्पादनात जिरा तिकिटाचे काय झाले आणि त्यास कोण जबाबदार आहे.

मते अहवाल, सोनाटाइपने 2018 मध्ये तयार केले होते, 2017 मध्ये 87 अब्ज OSS डाउनलोड विनंत्या होत्या.

असुरक्षिततेमुळे होणारे नुकसान निषेधार्ह आहे. शिवाय, तुम्ही आता वर पहात असलेल्या आकड्यांमध्ये संधी खर्चाचा समावेश नाही. DevSecOps थोडक्यात काय आहे? हे नाव कितपत यशस्वी आहे याबद्दल बोलण्यात मला स्वारस्य नाही हे मी लगेच सांगू. मुद्दा असा आहे की DevOps इतके यशस्वी झाल्यामुळे, आम्ही त्या पाइपलाइनमध्ये सुरक्षा जोडण्याचा प्रयत्न केला पाहिजे.

या क्रमाचे उदाहरणः


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

आणि आम्ही सुरक्षिततेसाठी समान दृष्टीकोन का घेऊ शकलो नाही याचे कोणतेही कारण नाही.

परिणाम

निष्कर्ष म्हणून, मी DevSecOps साठी काही टिपा देईन. तुम्‍हाला तुमच्‍या सिस्‍टम तयार करण्‍याच्‍या प्रक्रियेमध्‍ये ऑडिटर्सचा समावेश करण्‍याची आवश्‍यकता आहे आणि त्‍यांना शिक्षित करण्‍यात वेळ घालवावा लागेल. आपण ऑडिटर्सना सहकार्य करणे आवश्यक आहे. पुढे, तुम्हाला खोट्या सकारात्मक गोष्टींविरुद्ध पूर्णपणे निर्दयी लढा देणे आवश्यक आहे. अगदी महागड्या भेद्यता स्कॅनिंग साधनासह, तुमचा सिग्नल-टू-आवाज गुणोत्तर काय आहे हे तुम्हाला माहीत नसेल तर तुम्ही तुमच्या विकसकांमध्ये अत्यंत वाईट सवयी निर्माण करू शकता. विकासक इव्हेंटने भारावून जातील आणि त्यांना हटवतील. जर तुम्ही इक्विफॅक्स कथेबद्दल ऐकले असेल, तर तिथे असेच घडले आहे, जिथे सर्वोच्च सतर्कता पातळीकडे दुर्लक्ष केले गेले. याव्यतिरिक्त, असुरक्षितता अशा प्रकारे स्पष्ट करणे आवश्यक आहे की ते व्यवसायावर कसा परिणाम करतात हे स्पष्ट करते. उदाहरणार्थ, तुम्ही असे म्हणू शकता की इक्विफॅक्स कथेप्रमाणेच ही असुरक्षा आहे. सुरक्षितता भेद्यता इतर सॉफ्टवेअर समस्यांप्रमाणेच हाताळली जावी, म्हणजेच, त्यांना संपूर्ण DevOps प्रक्रियेमध्ये समाविष्ट केले जावे. तुम्हाला त्यांच्यासोबत जिरा, कानबान इत्यादींद्वारे काम करण्याची गरज आहे. विकासकांनी असा विचार करू नये की कोणीतरी हे करेल - उलट, प्रत्येकाने हे केले पाहिजे. शेवटी, आपल्याला लोकांना प्रशिक्षण देण्यासाठी ऊर्जा खर्च करण्याची आवश्यकता आहे.

उपयुक्त दुवे

येथे DevOops कॉन्फरन्समधील काही चर्चा आहेत ज्या तुम्हाला कदाचित उपयुक्त वाटतील:

• सेर्गेई बर्डनिकोव्ह, आर्टिओम कालिचकिन - यशोगाथा, किंवा “देव+देवऑप्स+ऑप्स” (видео, अहवालाचा उतारा)
• बारुच सदोगुर्स्की, लिओनिड इगोल्निक - देवऑप्स ऑन स्केल: ग्रीक शोकांतिका तीन कृत्यांमध्ये (видео, अहवालाचा उतारा)
• अलेक्झांडर टिटोव्ह, किरील टोल्काचेव्ह - DevOps, अभियंते आणि समुदाय
• टिमोथी लिस्टर - वर्ण, समुदाय आणि संस्कृती: समृद्धीसाठी महत्त्वाचे घटक

चौकशी करणे कार्यक्रम DevOops 2020 मॉस्को — तेथे अनेक मनोरंजक गोष्टी देखील आहेत.

स्त्रोत: www.habr.com