पूर्ण विकसित देवता: ग्रीक त्रासदी तीन कृत्यों में

त्रासदी ( जर्मन ट्रगोडी से लैटिन ट्रोगेडिया से अन्य ग्रीक γωδίραγωδία) मंच पर मंचन के लिए बनाई गई कलाकृति की एक शैली है जिसमें कथानक पात्रों को एक भयावह परिणाम की ओर ले जाता है।

अधिकांश त्रासदी पद्य में लिखी गई हैं। इस त्रासदी को बारूच सदोगुरस्की (@jbaruch) और लियोनिद इगोलोनिक ( @ लिगोलिक ) द्वारा लिखा गया था। अगर हम बड़े पैमाने पर DevOps के बारे में बात कर रहे हैं, तो यह एक त्रासदी क्या है?

यह लेख यथार्थवाद की गंभीरता से चिह्नित है, आंतरिक अंतर्विरोधों के एक समूह की तरह, एक बड़े विकास की वास्तविकता को चित्रित करता है। यह एक कलात्मक प्रतीक के मूल्य को प्राप्त करते हुए वास्तविकता के गहन संघर्षों को अत्यंत गहन और संतृप्त रूप में प्रकट करता है।

और अब हम बेलिंस्की का खेल खत्म कर रहे हैं और कटौती में आपका स्वागत है! पाठ और वीडियो है। बंधकों को न लें!





जैसा कि आप जानते हैं, यूनानियों ने वेन आरेखों को स्वीकार किया था। और हम आपको तीन के रूप में दिखाएंगे - और सभी DevOps के बारे में।


DevOps का एक पारंपरिक विवरण है - यह संचालन, विकास और QA का प्रतिच्छेदन है। यह ऐतिहासिक रूप से दिलचस्प है कि क्यूए को बाद में वहां जोड़ा गया था।


लेकिन आज हम किसी और चीज के बारे में बात करेंगे - प्रौद्योगिकी, प्रक्रिया और लोगों का प्रतिच्छेदन। DevOps प्राप्त करने के लिए आपको इन तीनों घटकों के साथ क्या करने की आवश्यकता है।

अब दो और चार्टों की तुलना करें:



कभी-कभी ऐसा होता है।

पेंटागन इंक।

आइए कहानी शुरू करते हैं पेंटागन नामक एक पौराणिक कंपनी के साथ, जो क्रेडिट कार्ड लेनदेन से संबंधित है।

अधिनियम I - अग्निशामक

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


प्रक्रिया । जब एक टीम में तीन लोग होते हैं तो प्रक्रिया कैसी दिख सकती है? Kanban: या तो कागज या Trello के एक टुकड़े पर। लोग चतुर हैं और समझते हैं कि क्यूए को शुरुआत से ही आवश्यकता है, इसलिए टीडीडी, यूनिट और एकीकरण परीक्षण। कोई ऑप्स नहीं, सभी की जड़ें हैं।


उपकरण। तदनुसार, तीन लोगों के लिए जो केवल कुछ उठा रहे हैं: जिरा , गिटहब , ट्रैविस सीआई , आदि।


आइए बात करते हैं कि ये लोग इस खूबसूरत स्टैक पर कैसे रहते हैं। सबसे पहले, जैसे अच्छे स्टार्टअप में - हम एक उत्पाद को देख रहे हैं, देख रहे हैं और पहले ग्राहक की प्रतीक्षा कर रहे हैं।


अचानक, एक चमत्कार हुआ - सोवियत संगठन में सबसे अच्छा सम्मेलनों का आयोजन करने वाले एक संगठन ने इन लोगों पर भरोसा करने और उनके माध्यम से अपना लेनदेन करने का फैसला किया।


एक वास्तविक स्टार्टअप तब क्या करता है जब उसे अपना पहला ग्राहक मिलता है? नोट्स! और रात में लगभग तीन बजे, जब सब कुछ एक विशेष स्थिति में होता है, तो ग्राहक कॉल करता है और कहता है कि कुछ भी काम नहीं कर रहा है।


बेशक, सबसे पहले, आतंक!


अगला कदम लड़ना है! हम उदाहरण के लिए, लॉग को देखते हैं।


हमने देखा, देखा, यह पता चला कि हमारे तीन नायकों में से एक - वस्या, त्यौहार के बाद घर आया था, उसने अपने छोटे से विचार की शुरुआत की। हमें याद है कि प्रतिबद्ध और परीक्षण बीत जाने के बाद, सब कुछ उत्पादन में उड़ जाता है।

खैर, हम में से कौन उत्पादन में असफल नहीं हुआ? हम वास्या को दोष नहीं देंगे। पिछली कमिट पर वापस रोल करें। यह नहीं जा रहा है! किसी कारण से, पर्याप्त पुस्तकालय नहीं है, जिसे बाएं-पैड कहा जाता है।


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

इस प्रकार, समय के बाद, आग के खिलाफ लड़ाई जारी है। और समस्याएं हर समय एक जैसी होती हैं।

अधिनियम II - फायर अलार्म इंस्टालर

कंपनी की खबर: आटा उठाया, एक निवेशक पाया, 27 लोगों को काम पर रखा, उनमें से एक ऑप्स पृष्ठभूमि के साथ। 100 ग्राहक दिखाई दिए और तकनीकी सहायता भी।


तदनुसार, प्रक्रिया को भी अपग्रेड मिलना चाहिए। सामान्य स्क्रम, खोजपूर्ण परीक्षण, दिखाई दिया। हमने महसूस किया कि NoOps बिल्कुल भी मौजूद नहीं है, क्योंकि Ops है (यदि आर्किटेक्चर सर्वर रहित है, तो सर्वर अभी भी है, यह सिर्फ आपका नहीं है)। चूंकि रात में पूरी टीम को जगाना गलत है, इसलिए कॉल पर एक डेवलपर दिखाई दिया।


तदनुसार, उपकरणों के सेट का विस्तार हुआ है। कम से कम, नॉलेज बेस दिखाई दिया है, क्योंकि अब एक परिचर है, और उसे कहीं न कहीं जानकारी तलाशनी होगी। एक और नवीनता है जेफ्रॉग आर्टिफैक्ट : एक प्रणाली जो आपको कल स्टोर करने की अनुमति देती है ताकि आप आसानी से वापस रोल कर सकें (बाएं-पैड के साथ सबक व्यर्थ नहीं था), और फिर से इसे फिर से न बनाएं। हम लॉग इकट्ठा करने और उनके लिए खोज करने के लिए एक प्रणाली में डालते हैं। Phatt को जोड़ा गया है - करामाती निगरानी प्रणाली: आप इसे एक url देते हैं, और यह बताता है कि यह काम करता है या दुर्घटनाग्रस्त हो जाता है।


इसलिए, इस बिंदु पर उन्होंने फिर से पैसा जुटाया। तो, हम ध्यान दें। शुक्रवार, सुबह तीन बजे, ग्राहक कॉल करता है। कुछ काम नहीं करता है: वीजा और मास्टरकार्ड पास, लेकिन अमेरिकन एक्सप्रेस नहीं करता है।


और जब ग्राहक सुबह तीन बजे कॉल करता है, तो पहली प्रतिक्रिया का समर्थन कैसे करता है? आतंक!

फिर हम परिचारक को बुलाते हैं। लगता है कि कौन ड्यूटी पर है? बेशक, वासना! अंदाजा लगाइए कि वसिया किस राज्य में है। एम दा। लेकिन वास्या खुद को एक साथ खींचती है, उसे देखती है कि किस समर्थन ने उसे भेजा है, और कहती है कि वह सभी इस बात से पूरी तरह से परिचित है और वह पहले ही यह जान चुकी है। इसलिए, Vasya बस लेता है और मरम्मत करता है। सब लोग सोने जा रहे हैं। डिब्रीफिंग सोमवार से शुरू हो रही है।


यहां एक विशिष्ट दस्तावेज का एक उदाहरण है जो हम ज्ञान के आधार के लिए पैदा करते हैं, ताकि यदि कुछ फिर से दोहराता है, तो यह जल्दी से मिल सके। इसके अलावा, कभी-कभी इसे ग्राहकों को दिखाया जाता है:


दस्तावेज़ मुख्य शीर्षक, कारण, विशेषताओं, घटनाओं की एक सूची प्रदर्शित करता है। लक्षणों को इंगित किया जाना चाहिए, एक तकनीकी विवरण दिया गया है जो वास्तव में टूट गया और इसे कैसे ठीक किया जाए। दस्तावेज़ का सबसे महत्वपूर्ण हिस्सा महत्वपूर्ण कारण है कि कुछ गिर गया।

वास्या के मामले में, हम लॉग कतार अतिप्रवाह है। आपको इसे क्रेडिट कार्ड लेनदेन से साफ़ करने की आवश्यकता है, और इसके अलावा, इसका आकार बढ़ाएँ। उदाहरण के लिए, 42 पर!

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


कभी-कभी समस्या इतनी भयावह हो जाती है कि उसके बारे में बात करना उचित नहीं होता।

फरवरी 2017 में GitLab में , एक व्यक्ति ने एक उत्पादन डेटाबेस हटा दिया। यहाँ विश्लेषण है कि GitLab ने अपलोड किया है:


तो, कहीं बैकअप है, केवल कोई नहीं जानता कि कहां है। तब बैकअप मिले, लेकिन वे खाली हो गए। हां, बेस डंप है। लेकिन इसे पोस्टग्रेज के एक अलग संस्करण में बनाया गया था, इसलिए यह फिट नहीं है। हमारे पास स्नैपशॉट हैं, लेकिन उनके पास कोई डेटाबेस नहीं है। S3 से प्रतिकृति या तो डेटा की कमी के कारण काम नहीं करती थी।

इस प्रकार, डेटा बैकअप के लिए पांच अलग-अलग तकनीकों ने काम नहीं किया। हमें लगता है कि यह प्रकाशित नहीं किया जा सकता है, क्योंकि कोई और उन पर भरोसा नहीं करेगा। लेकिन, आप इसके बारे में कैसे बात करते हैं, इसके आधार पर, क्लाइंट माफ कर सकता है। सच है, केवल एक बार।


वैसे, उस लड़के ने जो किया उसे प्रमोशन मिला। इसके अलावा, उन्होंने अपने ट्विटर स्टेटस को GitLab में डेटाबेस (निष्कासन) विशेषज्ञ में बदल दिया ।

अधिनियम III - क्लाइमेक्स

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


जैसे-जैसे टीम बढ़ती है, विकास प्रक्रिया को बदलना होगा।

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

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

ऑप्स टीम के बारे में क्या? जैसा कि हमने कहा, DevOps करने के लिए दो विकल्प हैं। पहला किताब के लिए है और नेटफ्लिक्स, गूगल और ट्विटर के निर्देशों के लिए है। दूसरा वास्तविक जीवन में है, जहां सभी इंजीनियरों को उत्पादन में जड़ के साथ भरोसा नहीं किया जा सकता है।

एस्केलेशन पथ एक महत्वपूर्ण अवधारणा है जो आपको किसी भी समय किसी भी समस्या को हल करने की अनुमति देती है, क्योंकि एस्केलेशन पथ के अंत में एक सीईओ का मोबाइल फोन होता है, एक कॉल के बाद जिसमें सभी समस्याएं 5 घंटे 58 मिनट में गायब हो जाती हैं।

SOC II - मानकों का एक सेट जो विक्रेता ग्राहक को प्रदान करता है। ये मानक इस बात की पुष्टि करते हैं कि कंपनी के पास कुछ सुरक्षा समाधान हैं, जो कार्य के विभाजन के लिए दृष्टिकोण रखते हैं।

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


उपकरण, निश्चित रूप से, सुधार भी किया जा रहा है।


और भी खबर है। वासिया को पदोन्नत किया गया था। वह अब इंजीनियरिंग के वीपी हैं।

शुक्रवार, शनिवार, रविवार गुजरता है - कुछ भी नहीं आता है। सब कुछ काम करता है। हर कोई सदमे में है। सोमवार आता है, एक वकील वास्या के पास आता है और कहता है कि वह वकीलों के एक सम्मेलन में था और वहां एलजीपीएल 2.2 के बारे में सुना। अगर उनके पास एलजीपीएल 2.2 है तो वासा का कोई पता नहीं है।


लोगों ने लंबे समय तक काम किया, और फिर एलजीपीएल 2.2 पाया। काटने की जरूरत है। लेकिन यह प्रणाली के एक स्वस्थ टुकड़े द्वारा काटा जा रहा है, और किसी ने कल रिलीज को रद्द नहीं किया। खैर, कुछ नहीं, इससे निपटा।


निधि निर्देशक वसई आती हैं:

• सर्वर और उत्पादन के लिए आपको कितने पैसे की आवश्यकता है? अगले साल के लिए बजट बनाना ...
• ४२ - वसय कहते हैं।

हमने इस समस्या को भी हल किया।


वे वास्या के पास आते हैं और कहते हैं कि एक संभावित ग्राहक है, लेकिन वह डरता है कि हमारे पास इतने बड़े पैमाने पर ग्राहक कभी नहीं हैं, और यह आश्वस्त होना चाहता है कि यह अच्छा होगा। हम इतिहास से जानते हैं कि इस स्तर पर सभी की मृत्यु हो गई।


लेकिन जब से हमें एक सुखद अंत होना चाहिए, हमने इसे ग्रीक त्रासदी से जोड़ दिया।

उपसंहार - सक्रिय सुधार

अब बात करते हैं DevOps को बढ़ाने के अंतिम चरण के बारे में - प्रोएक्टिव इंप्रूवमेंट। यह आग से बचाव के बारे में है।

लोगों में कोई बदलाव नहीं हो रहा है। लेकिन प्रक्रिया के साथ - बहुत बहुत।


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

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

पदच्छेद

आइए पिछले कृत्यों से कुछ घटनाओं का विश्लेषण करें।

उस मामले को याद रखें जब वसीली ने आकाश में उंगली से बजट की योजना बनाई थी? हमारे उत्पादों में से एक पर काम करने में, हम यह पता लगाना चाहते थे कि किन संसाधनों पर खर्च किया जा रहा है। बैकलॉग में सब कुछ समूहीकृत होने के बाद, हमें यह आरेख मिला:



हमने गलती से सोचा था कि हम बिग फीचर ए पर 80% खर्च कर रहे हैं - वास्तव में, यह केवल 13% लेता है। उसी समय, जितना 34% रोशनी ऑन रखने के लिए जाता है - उन चीजों पर जो उत्पादों में किए जाने की आवश्यकता होती है: मरम्मत कीड़े, अपडेट लाइब्रेरी आदि।

वास्तव में, उत्पाद की गुणवत्ता का केवल एक उद्देश्य मीट्रिक है: ग्राहक संतुष्टि, जो समर्थन करने के लिए कॉल में व्यक्त की जाती है।

दूसरा उदाहरण। हमने सभी महत्वपूर्ण दोषों को तोड़ दिया:


65% टिकट महत्वपूर्ण स्तर के पहले स्तर के हैं। क्या यह बुरा सपना है?

अब एक ही डेटा लें और इसे अलग कोण से देखें।


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

लोगों ने अड़चनों में दस्तावेज को ठीक किया, लॉग को ठीक किया। नतीजतन, टुकड़ा, जिसमें बहुत सारे डेवलपर्स समय लगे, गायब हो गया।

निष्कर्ष

सभी चरणों में, अग्निशमन से लेकर अलार्म लगाने और प्रोएक्टिव प्रॉब्लम सॉल्व करने तक, कई प्रक्रियाएं, लोग, विशेषज्ञ, एप्रोच, टूल्स होते हैं जिन्हें इंस्टॉल करने की जरूरत होती है। यह सब एक दिन में नहीं किया जा सकता है। इसके अतिरिक्त, विकास के कुछ चरणों में कुछ चीजों की आवश्यकता नहीं होती है।

यह समझना महत्वपूर्ण है कि लोगों में, और प्रक्रियाओं में, और उपकरणों में कुछ सुधारों की लगातार आवश्यकता होती है।


वास्तव में क्या सुधार करने की आवश्यकता है, हमें उन संख्याओं का पता लगाने में मदद की जाएगी, जिनके बारे में हमने बात की थी। केवल इस डेटा के आधार पर ही हम सही निर्णय ले सकते हैं कि कहां निवेश करना है और क्या आगे बढ़ना है।

और DevOps के दो मूल सिद्धांतों को मत भूलना:

• आप इसका निर्माण करते हैं - आप इसके मालिक हैं।
  
• दर्द निर्देशात्मक है।
  

अगले रविवार, बारूक और लियोनिद सेंट पीटर्सबर्ग में देवोप्स 2018 पर एक रिपोर्ट "#DataDrivenDevOps" वितरित करेंगे। आओ, बहुत सारी दिलचस्प चीजें होंगी: यहां रिपोर्टें हैं , यहां जॉन विलिस है , और यहां BoFs और कराओके के साथ एक पार्टी है। आपका इंतजार है!