एंटोन वीस के साथ एक बड़ा साक्षात्कार: "बिना सोचे समझे प्रौद्योगिकियों का निर्माण करना जो उनका उपयोग करता है, पूरी तरह से व्यर्थ है"

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

हम निम्नलिखित विषयों के बारे में बात करेंगे:

• रूस और इजरायल के बीच काम में अंतर;
• स्टार्टअप्स और दिग्गजों के बीच का अंतर, विशेष रूप से DevOps के संदर्भ में;
• प्रवृत्ति जटिलता बढ़ाना है, और इसके बारे में क्या करना है;
• तकनीकी और गैर-तकनीकी कौशल का संयोजन;
• त्वरित प्रशिक्षण और कार्यान्वयन;
• DevOps की दुनिया से सबसे उपयोगी प्रथाओं और प्रौद्योगिकियों;
• क्या रिपोर्ट जाने लायक हैं।

रूस और इज़राइल के बीच अंतर

ओलेग: कृपया मुझे बताएं कि आप कौन हैं और आप क्या करते हैं।

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

ओलेग: क्या काम के मामले में रूस और इज़राइल के बीच अंतर है?

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

- अच्छा, कैसे?

- अच्छा तो। यह कठिन है, वे कहते हैं, हम यह कर रहे हैं, अब कुछ होने लगा है।

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

स्टार्टअप्स और दिग्गजों के बीच का अंतर

ओलेग: मैं समझ गया। वैसे, आपके लिए काम करना अधिक दिलचस्प और सुखद कहां है: स्टार्टअप्स में या बड़े संगठनों में?

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

ओलेग: और छोटी और बड़ी कंपनियों में DevOps के दृष्टिकोण में अंतर के बारे में क्या? यही है, यदि आप, उदाहरण के लिए, दो लोगों के लिए काम करते हैं, तो आप अपने स्वयं के सीआई / सीडी को कॉन्फ़िगर नहीं कर सकते हैं, लेकिन एससीपी से कलाकृतियों को कॉपी कर सकते हैं।

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

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

प्रवृत्ति जटिलता बढ़ रही है, और इसके बारे में क्या करना है

ओलेग: ठीक है, साथ ही तकनीकी हिस्सा: जब आपके पास कम लोग होते हैं, सरल प्रौद्योगिकियां होती हैं, तो आपको कुछ बुनियादी लिनक्स और यह जानना आवश्यक है। और थोड़ी सी स्केलिंग के साथ, आपको कुछ कुबेरनेट्स सीखने की जरूरत है, और यह समस्या प्रतीत होती है।

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

ओलेग: एक साल पहले था?

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

ओलेग: और क्या जवाब है? इस जटिलता का प्रबंधन कैसे करें?

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

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

बादल मूल निवासी

ओलेग: क्या आप थोड़ा बता सकते हैं कि क्लाउड नेटिव क्या है? क्योंकि यह किसी तरह का बज़ट बन गया है, अब हर कोई इसे हर दीवार पर लिखता है। आप इसे कैसे देखते हैं?

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

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

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

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

ओलेग: संभवतः, संगठन को किसी भी तरह यह सब सामान के साथ जीना सीखना चाहिए।

एंटोन: स्वाभाविक रूप से, स्वाभाविक रूप से! यह सब अपनी छाप छोड़ता है। माइक्रोसर्विसेज भी इसी से संबंधित हैं। द्वारा और बड़े तौर पर, यह विचार है कि हमारे पास छोटी सेवाएं, छोटे अनुप्रयोग हैं जो बादल में बिखरे हुए हैं और किसी भी समय कहीं भी हो सकते हैं, और अब 10 प्रतिकृतियां हो सकती हैं, और कल - 1,500, यह भी क्लाउड का हिस्सा है मूल निवासी। यह विचार कि हम डेटा सेंटर की भौतिक सीमाओं से सीमित नहीं हैं। द्वारा और बड़े, पूरी दुनिया मेरा बादल है, यह एक पूरी तरह से अद्भुत दृष्टि है, एक अद्भुत खोज है, लेकिन इसकी एक कीमत है, और यह कीमत जटिलता है, कीमत यह है कि बड़े और कोई भी सिर में फिट नहीं हो सकता है जो होगा, जब हमारा आवेदन अचानक 10 उदाहरणों से बढ़कर 1500 हो जाता है। कोई भी इसकी कल्पना नहीं कर सकता है, और सभी स्केलिंग कलाकृतियां दिखाई देने लगती हैं। मनुष्य के रूप में, ऑपरेटर के रूप में, हम इसके साथ कुछ भी नहीं कर सकते हैं सिवाय अराजकता के लिए जो हो रहा है। और इसलिए हम यह सोचना शुरू करते हैं: “लेकिन हम अपने आवेदन और बुनियादी ढांचे का निर्माण कैसे कर सकते हैं ताकि जब ये कलाकृतियां उत्पन्न हों, तो सबसे पहले, वे पूर्वाभास कर सकें, और दूसरी बात, किसी तरह हम इन कलाकृतियों का सामना कर सकें और जारी रख सकें कार्य करने के लिए? "

तकनीकी और गैर-तकनीकी कौशल का संयोजन

ओलेग: क्या आपके पास तकनीकी चीजों के बारे में रिपोर्ट है, उदाहरण के लिए, एक सेवा छलनी के बारे में और नेतृत्व के बारे में, प्रबंधन के बारे में सभी रिपोर्टें हैं। क्या आप एक तकनीकी व्यक्ति के अधिक हैं, या आप एक प्रबंधक हैं, या आपका काम किसी तरह अलग है?

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

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

कैसे जल्दी से पता लगाने के लिए DevOps

ओलेग: सुनो, क्या आप कुछ लोगों को सलाह दे सकते हैं जो अब इंजीनियरिंग में लगे हुए हैं और एक ही समय में DevOps प्रथाओं का अध्ययन कर रहे हैं? यह सब कैसे और किस क्रम में करना है? सापेक्ष रूप से, कैसे योजना बनायें, शायद, कम समय में अधिक सफल बनने के लिए आपका करियर?

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

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

. DevOps — . , , . , , , , - , - , , - . , . , , , , , , , . , . . ? — , , . , , . , . कुछ इस तरह। .

: , , DevOps', , . , , . , -, , … , . - , ? . , , : « ». , ?

: -, , , : « ». - , , , , . , , : « ».

: ?

: , , , , , . , — . , , «, , », - . , - , . - , - . , Agile: , , , , , .

, . . , — , - — , , — , , , , , . : « — , . , , . , . , , , -, , , ». , , , .

, - , , continuous integration … , , , . , , . , 10 : , , - , , , , , , , , . — . : , , , , . E - , , .

: . , - , , - , , , , DevOps -. ?

: , , , , . , , , , ? , , . . - , , .

, , . , , .

DevOps

: , : Google, Netflix, . , ?

: , , ( ) , — , , , . , , lean management — value stream mapping. . , , , - : , , , , , , , , . , , , .

: ? - — - , , — . , , , , . , , , Java, , , . , :

— , .
— , ? ?
— , , .

, , , , — , . — , .

, :
— .

:
— , , . .

, , :
— .

:
— . ?

:
— , .

, — , , . . . , CI/CD — . , . , , . , , .

: , ? , CI/CD . ?

: -, , . - , , , , . Kubernetes: , — Kubernetes. VMware , Kubernetes . , Google . , , .

: Google ?

: , , Swarm Kubernetes, Docker. Docker , . , Microsoft, Amazon — « Docker». Docker! Docker . , , , , Google, Microsoft, Amazon? , . , , , . , . और इसलिए यह हुआ।

तो यहाँ है। . — . — « Kubernetes , ». . Kubernetes . Kubernetes — - API, , . API . — , , , , : « API, , Kubernetes, Kubernetes , ».

— , Continuous Delivery Foundation, - , , Google, CloudBees, GitLab. Tekton, — API continuous delivery-. , continuous integration / continuous delivery- Kubernetes, , , . , . Microsoft , , SMI Spec. , , - .

Kubernetes . , , - , , Kubernetes — .

ओलेग: आप खुद क्या रिपोर्ट करते हैं, आप क्या दिलचस्प पाते हैं?

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

ओलेग: और किस तरह का तकनीकी शिक्षण? क्या कर रहे हो

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

ओलेग: क्या आप मुख्य रूप से एक रिपोर्ट में, किसी विषय पर या किसी व्यक्ति के पास जाते हैं?

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

ओलेग: क्या यह कॉमरेड है जिसके पास मध्यम पुस्तक है ? उन्होंने इसे पदों के रूप में बनाया। असामान्य प्रारूप।

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

ओलेग: लेकिन हमारे पास ऐसा नहीं है - मैं यह भी नहीं समझ पा रहा हूं कि आप अभी क्या बात कर रहे हैं।

एंटोन: तो मैं वास्तव में या तो समझ में नहीं आया, या तो इजरायल में ऐसा नहीं है। और वहां वे इसके बारे में बात करते हैं। अगर आप DORA की तरह इन सभी साथियों को सुनते हैं, जो State of DevOps Report बनाते हैं , तो वे इसके बारे में भी बहुत कुछ लिखते हैं। सामान्य तौर पर, मेरा मतलब है कि लोग किसी तरह की समस्या के बारे में बात कर रहे हैं जो केवल उनके पास है, और आप इसमें बिल्कुल भी दिलचस्पी नहीं रखते हैं।

ओलेग: आप पिछले DevOops में थे, क्या रिपोर्ट करने और रिकॉर्डिंग की समीक्षा करने के लायक हैं?

एंटोन: सभी को देखें। विषय में थोड़ा रुचि - जाओ।

ओलेग: मेरी राय में, कुछ एंटोन वीस हैं। शायद यह देखने लायक है।

एंटोन: नहीं, इसके लिए मत जाओ, कुछ उबाऊ बातें :-)

ओलेग: ठीक है, बहुत बहुत धन्यवाद। यह बहुत बढ़िया था! मैं देख रहा हूं कि आपने पहले ही अगले सम्मेलन के लिए एक रिपोर्ट प्रस्तुत कर दी है, इसलिए - अगले देवो में आपको देखें!

मॉस्को में इस बार DevOops 2020 मास्को सम्मेलन 29-30 अप्रैल को आयोजित किया जाएगा। हमने घोषणा में हेब्रे पर सम्मेलन के सार का वर्णन किया "देवो-इंजीनियरों का अस्तित्व नहीं है । " कार्यक्रम सक्रिय रूप से बन रहा है (सम्मेलन के कई महीने पहले भी हैं), लेकिन पहले वक्ताओं को पहले ही साइट पर देखा जा सकता है । आप वहां टिकट खरीद सकते हैं।