DevOpsDays 2013 माउंटेन व्यू से छापें

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

मैं अभी क्या कहना चाहता हूं - यह एक सम्मेलन था जो इंजीनियरों ने किया, इंजीनियरों के लिए, और केवल इंजीनियरों ने इस पर भी बात की। यहां तक ​​कि OpsCode या PuppetLabs जैसे विक्रेता टूल के प्रतिनिधियों के बीच, विपणन और बिक्री विभागों से कोई भी समस्या नहीं थी। यही कारण है कि उनके प्रति पर्याप्त रवैया था, उन्होंने उनके साथ बहुत और कसकर संवाद किया, और हमेशा की तरह नहीं। इसी कारण से, वहाँ कोई लड़कियों और hrs नहीं थे miniskirts में bodypainting द्वारा चित्रित किया गया था। यह सब एक थर्मल लैंप सम्मेलन का एक बहुत अच्छा माहौल बनाया। वैसे, इस पर लगभग 300 लोग थे, लेकिन यह किसी के साथ संवाद करना बंद नहीं करता था जिसे आप चाहते हैं। सामान्य तौर पर ठोस सकारात्मक।

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

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

अब रिपोर्ट पर चलते हैं। यह कार्यक्रम इस लिंक पर उपलब्ध है, और रिपोर्ट और वीडियो को थोड़ी देर के बाद केंद्र में रखा जाएगा, लेकिन वापस रिपोर्ट में।

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

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

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

शुरुआत में, मुझे चौथी रिपोर्ट मार्केटिंग बुलशिट के रूप में मिली, क्योंकि इसमें इस बारे में बात की गई थी कि वे कौन सी शांत चीज लेकर आए हैं ताकि लड़कियां आईटी में शामिल हो सकें। परियोजना को http://www.hackbrightacademy.com कहा जाता है और यह वास्तव में अच्छा है, लेकिन मैं वास्तव में इसके बारे में तब तक नहीं सुनना चाहता जब तक कि हम सामान्य रूप से कर्मचारियों को सलाह देने और नियुक्त करने जैसे विषय को नहीं उठाते। और यह वास्तव में अच्छा विषय था और इसीलिए। कई कंपनियों में, कर्मियों को काम पर रखने का मुद्दा एक गंभीर मुद्दा है, लेकिन साथ ही वे खराब सोच रहे हैं कि लोगों को मौजूदा प्रक्रिया में कैसे एकीकृत किया जाए, और सबसे महत्वपूर्ण बात, उन्हें मानों का एक ही सेट पास करें जो टीम के पास है। इसलिए, इस समस्या का समाधान मानसिक रूप से है, और औपचारिक रूप से नहीं - मैं एक संरक्षक हूं, ठीक है, लेकिन पूर्ण रूप से एक, जिसके लिए कर्मचारी का समय आवंटित किया जाता है। और एक महत्वपूर्ण घटक केवल अभ्यास में प्रशिक्षण नहीं है, बल्कि मूल्यों का स्थानांतरण, वांछित मानसिकता में समायोजन भी है। इस तरह, लोग वास्तव में टीमों में एकीकृत होते हैं। और यह भी: “अपने जूनियर से क्यों“ बोलो ” इंजीनियर ऐसा कर रहे हैं ताकि वे जान सकें कि इसे भविष्य में कैसे लागू किया जाए। ”सामान्य तौर पर, कई कंपनियों के पास एक नोट होता है।

मैंने विस्तार से इग्नाइट वार्ता के बारे में नहीं लिखा - वीडियो की प्रतीक्षा करें और देखें, वास्तव में बहुत अच्छी खबरें थीं। मस्तिष्क फट गया)

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



डेमन के बाद, यह टॉफिक बुबेज़ था, जिसने निगरानी जैसे महत्वपूर्ण चीज़ को छुआ और #monitoringsucks टैग का इतने लंबे समय तक सक्रिय रूप से उपयोग क्यों किया गया। तो, आपने खुद को एक निगरानी उपकरण सेट किया, एक गाइड लिया और उस पर सब कुछ कॉन्फ़िगर किया। क्या आपको कोई निगरानी मिली है? Hrenushki! आपके पास एक प्रणाली है जो संसाधनों का एक गुच्छा खाती है और सभी को परेशान करती है। इसलिए, रिपोर्ट का एक बहुत ही सरल विचार यह है कि यदि किसी भी मेट्रिक्स का विश्लेषण कभी नहीं किया गया है, तो उसे भट्टी पर भेजा जाना चाहिए। ऐसा होने से रोकने के लिए, सभी मैट्रिक्स को सिस्टम में होने वाली घटनाओं में जोड़ा जाना चाहिए - deploys, reconfigs, नई सुविधाओं की रिलीज़, और इसी तरह। ऐसा नहीं करेंगे - आपकी निगरानी बेकार है! दूसरा सरल विचार यह है कि दिशा-निर्देशों का नेत्रहीन पालन करने के बजाय, सिस्टम में जो कुछ भी होता है, उसके लिए 1-2 शुरुआत में कॉन्फ़िगर करें - जेवीएम, सीपीयू, डिस्क I / O और इसी तरह। और आप खुश रहेंगे।

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



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

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

माहौल को डिफ्यूज करने के लिए - कुछ सबसे ज्यादा चौंकाने वाले ट्वीट।
@ jesserobbins
बेवकूफ मत बनो। और कमाल करो। <- शब्द। # भक्ति # बादल

@ एड्रियानो
हाथी अपने कानों को जोर से फड़फड़ा कर उड़ नहीं सकते - @ jesserobbins # devopsdays

@ jonathan_thorpe
"मूल्य सह-निर्माण एक यात्रा है।" अधिक सहमत नहीं हो सका। एक सेवा के सभी पहलू चाहे कितने भी महत्वहीन क्यों न हों # devopsdays के मायने रखते हैं

@ dberkholz
QA की नई भूमिका: उत्पाद से परे समग्र उपयोगकर्ता अनुभव के बारे में सोचना। यह एक सेवा प्रदान करने के बारे में है। - @ jeffsussna # devopsdays

@ विकट
सर्वर खेत के जानवरों की तरह होते हैं, अगर आप बच्चों को उनका नाम # दिन बताने दें तो यह कठिन है

@ कल्सज <
व्यवसाय के "क्यों?" के अलावा कोई अन्य "क्यों?" नहीं है। # डेमोंडवर्ड # डेप्सडे । हाँ। शांत सामान! = व्यवसाय के लिए वितरित करना

@ लेखक
कलम और कागज की ताकत को कभी कम मत समझो। आपको हमेशा फैंसी टेक # DevOpsDays की जरूरत नहीं है

@ जोंडकैंप
"जब लोग कंप्यूटर पर काम कर सकते हैं, तो सभी कंप्यूटर देर रात को एक साथ हो जाते हैं और हम पर हंसते हैं।" # Devopsdays

@ बेंज़ोबोट
"जटिलता में आने पर पुनर्गठन या पुन: डिज़ाइन करने से डरो मत।" समझदार शब्द! # रविवार

@ vmwarecloudops
"हमें समस्याओं को हल करने की आवश्यकता है, जहां वे कम जटिल हैं और अमूर्त की परतों का निर्माण करते हैं।" # DevOpsDays

और अब वादा किए गए बोनस का समय - इस साल सितंबर में मास्को (या सेंट पीटर्सबर्ग में, अभी तक समाप्त होने का फैसला नहीं किया गया है) DevOpsDays रूस सम्मेलन की मेजबानी करेगा। मैं इसके आयोजक के रूप में काम करूंगा, इसलिए आप बने रहिए!