DevOps की मूल बातें। खरोंच से परियोजना में प्रवेश

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



DevOpsConf 2019 में, आंद्रेई ने एक रिपोर्ट की, जिसमें उन्होंने लाइव उदाहरणों में दिखाया कि क्या मूल्य है और जब आप किसी प्रोजेक्ट में प्रवेश करते हैं तो क्या नहीं किया जाना चाहिए और जो आपको खराब नहीं दिखता है। कट के तहत कहानी का एक अद्यतन संस्करण है - समस्याओं की श्रेणी का ठीक से विश्लेषण कैसे करें और गतिविधि योजना कैसे बनाएं, केपीआई की सही गणना कैसे करें और समय में कब रोकें।


एंड्री युमाशेव विभिन्न क्षेत्रों (ऑनलाइन और ऑफलाइन), प्रक्रियाओं के निर्माण पर एक सलाहकार और लाइटऑन में सूचना समर्थन विभाग के प्रमुख के रूप में अपनी खुद की विकास कंपनियों के मालिक हैं।

LiteRes के बारे में थोड़ा सा। यह रूस, प्रकाशन गृह और साझेदारी परियोजनाओं के समूह में इलेक्ट्रॉनिक और ऑडियो पुस्तकों का सबसे बड़ा आपूर्तिकर्ता है। ये पर्ल, कई डेटाबेस क्लस्टर्स और रिपॉजिटरी की हजारों हजारों लाइनें हैं। यह प्रति सेकंड आउटगोइंग ट्रैफ़िक का 2 जीबी है, प्रति दिन हजारों अद्वितीय अनुरोध, विभिन्न डेटा केंद्रों में कई रैक और 100 से अधिक सर्वर। सभी के सभी, यह सिर्फ एक ई-बुकस्टोर नहीं है।

पहला कदम

मैं एक टुकड़ा दर के आधार पर LiteRes में काम करते थे। कंपनी राज्य में दूरदराज के कर्मचारियों के पंजीकरण के साथ विकास को बढ़ावा देती है।

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

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


मशरूम के लिए काम करते हैं।

सिस्टम ने मुझे अनुकूल बनाया - मैंने पर्ल प्रोग्रामिंग अनुभव का समर्थन किया, काम किया जब यह सुविधाजनक था और इस पर बहुत समय नहीं बिताया। इस मोड में, मैंने पिछले साल नवंबर तक कुछ साल बिताए और सोचा कि मैं पारिस्थितिकी तंत्र की संरचना को समझता हूं।

मैं गलत था

मुझे कंपनी में आमंत्रित किया गया और सूचित किया गया कि पर्ल डेवलपर के रूप में मेरी सेवाओं की आवश्यकता नहीं थी, और मुझे एक नए विभाग के प्रमुख की पेशकश की गई। नवंबर 2018 में, मैं सूचना विभाग का प्रमुख बन गया।

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

एक भावना थी कि मैं रसातल में देख रहा था, और रसातल मुझे देख रहा था।

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

स्वच्छता स्वास्थ्य की कुंजी है

आदेश सबसे पहले और सबसे महत्वपूर्ण है।

पहले महीने के लिए खोजने में कामयाब:

• वर्तमान कार्यों और उपयोगी जानकारी के एक चुटकी के साथ बिखरे हुए Google पत्रक;
• बिखरे हुए दस्तावेज़: वर्ड, ग्रंथ, पुराने विकी 120 पृष्ठों के स्क्रैप;
• आधा मृत पुराना नागियोस;
• कैक्टि की सशर्त निगरानी;
• जीवन के दुर्लभ संकेतों के साथ बहुत पुरानी कठपुतली।

इन सभी खंडहरों ने 400 मीट्रिक भी एकत्र किए।


पहले महीने में मुझे जो खंडहर मिले।

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

पहली गलती

जब तक आप क्षेत्र का पता नहीं लगाते हैं तब तक कोई योजना नहीं है।

योजना गर्मी और स्वास्थ्य के साथ चमकती थी, लेकिन वास्तविकता को ध्यान में नहीं रखती थी। यह सुंदर और सरल था: निगरानी को लागू करना, लॉग का विश्लेषण करना और सीआई / सीडी में तैनात करना। अंत में कहीं न कहीं "परियोजना की कमजोरियों का विश्लेषण" था। क्लासिक पहले चरण।

मैं मुख्य बात के बारे में भूल गया। मेरी पहली प्राथमिकता उपकरण के कार्यान्वयन के लिए उपकरणों को लागू करना नहीं है, लेकिन समग्र रूप से सेवा की व्यवहार्यता और स्थिरता सुनिश्चित करना है।

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

जब मैं डेटा केंद्रों के बीच यात्रा कर रहा था, तो योजना के बारे में संदेह के पहले अंकुर पैदा हुए थे।


आह-आह-आह-आह!

उसी समय, काले काम की तीव्रता इतनी अधिक थी कि मैंने एक पूर्ण चिकित्सा इतिहास एकत्र करने के लिए भी नहीं सोचा था, लेकिन आगे के अध्ययन के लिए बस कुछ तस्वीरें लीं।

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

मैंने Azure, Google, DigitalOean और बाकी सभी चीज़ों की जानकारी देनी शुरू कर दी, जो छोटी बूंद के समाधान प्रदान करती हैं। कंटेनरीकरण भीख माँगता है, तो इसे क्यों नहीं लागू किया जाए? इसके अलावा, "महान" योजना में इस बारे में एक अलग बिंदु था।

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

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

जब तक मैं समझता हूं कि मैं किसके साथ काम कर रहा हूं, सभी योजनाएं समय की बर्बादी हैं।

मैंने रैक का अध्ययन किया, सूचियों के साथ वास्तविकता की तुलना की, संपादन किया, और 20 ब्लेड के साथ एक अर्ध इकाई पर ठोकर खाई। 20 में से, केवल 4 ने काम किया। मैंने ब्लेड को झटका दिया और महसूस किया कि हमें समाधान के लिए किसी भी बूंद की आवश्यकता नहीं है। क्योंकि मुझे 340 निष्क्रिय कोर, 2 टेराबाइट्स रैम और 17 टेराबाइट्स डिस्क स्पेस में मिले! ये पुराने बैकएंड, क्लस्टर के पुराने नोड्स हैं जो बस का उपयोग करना बंद कर देते हैं, और समय ने उनके अस्तित्व की स्मृति को मिटा दिया है। मैंने इन ब्लेड्स पर कुबेरनेट्स को रोल किया और एक बड़े काम से छुटकारा पाया।

पहली त्रुटि आउटपुट

विश्लेषण और अध्ययन करें। स्थिति के प्रारंभिक विश्लेषण के बिना, ट्रेन चलती नहीं है।

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

समानांतर में, मैंने तीन नियम काटे। ये पहली गलती के परिणाम हैं।


तीन कोरोलरी।

दूसरी योजना

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

दूसरी योजना कुछ इस तरह दिखी।

निगरानी से निपटें । अपने वर्तमान स्वरूप में, यह कम से कम एक तिहाई समस्याओं को प्रतिबिंबित नहीं करता था, हालांकि यह काम करता था।

संपूर्ण लीटर के सामान्य तर्क का वर्णन करें । सर्वर नाम महान हैं, लेकिन महत्वपूर्ण बंडल महत्वपूर्ण ज्ञान हैं: क्या, कहां, कहां, क्यों और क्यों। पिछली गलती ने यह स्पष्ट कर दिया कि इसके बिना किसी भी तरह से।

स्केलिंग । लगभग अंतिम मुक्त संसाधन कुबेरनेट्स ले गए। न्यूनतम अनुमानों के अनुसार, उन्हें छह महीने में काम का पूरा पूल खत्म करना था।

उपकरणों की सूची और स्थिति । यात्रा के हिस्से के रूप में, मैंने सचमुच कई वेब सर्वरों को अपने टैग्स से डराया - "बैकअप", "सदस्यता", "bgp"। फिर, डिस्क, छोड़ने वाले डिस्क।

वास्तविकता के लिए मार्गदर्शक को अपनाना । अधिकांश निर्देश पुराने या अधूरे हैं।

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

दूसरी गलती

कम मत समझना।

मन में आने वाले किसी भी शब्द को कम करके आंका जाता है । निश्चित रूप से, आप परियोजना से जल्दी लाभ उठा सकते हैं। लेकिन रिटर्न को अधिकतम करने के लिए, नियोजित समय को कम से कम दो गुना बढ़ाएं । विशेष रूप से एक जटिल और अत्यधिक भरी हुई परियोजना पर, जो प्रति वर्ष 100% से अधिक यातायात में लगातार बढ़ रहा है।

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

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

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

समय, प्रविष्टि सीमा और परिणामों को कम मत समझो।

मूल अवधारणाएँ

बेशक, विकी में मूल अवधारणाओं के रूप में त्रुटियों का सार पहले से ही वर्णित है।

कोई भी नौकरशाही प्रक्रिया कम से कम एक महीने तक चलती है । यह खरीद के लिए लागू होता है, डेटा सेंटर या अन्य ठेकेदारों के साथ नई स्थितियों का निष्कर्ष - सब कुछ करने के लिए। इसे एक तथ्य के रूप में लें।

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

जबकि कार्यान्वयन की कोई स्पष्ट समझ नहीं है, किसी भी योजना को लागू करने की कोई योजना बनी हुई है। छोटे कदम, बेहतर है।

उदाहरण के लिए, MySQL से ClickHouse में जाने के लिए, एक विस्तृत कदम इस तरह दिखता है: "चलो कुछ सर्वर को पॉप्युलेट करते हैं, फिर पुनर्संयोजन के लिए एक टिकट खींचते हैं और उड़ते हैं!"। वास्तव में, इस मुद्दे के एक विस्तृत अध्ययन ने नए कदम उठाए: उपकरण की अतिरिक्त खरीद, उदाहरण के लिए, प्रोसेसर और डिस्क, उपयोगकर्ता व्यवहार ट्रैकर के तर्क को बदलने के लिए विस्तृत टिकट, पिछड़े एकीकरण, कतार सर्वर और कई अन्य को बनाए रखना।

योजना जितनी विस्तृत होगी, उतना बेहतर होगा। ब्रॉड ब्रशस्ट्रोक के साथ लिखने के लिए समय सीमा में 100% त्रुटि की गारंटी है।

किसी भी योजना को अधिकतम आलोचना के अधीन करें और अधिकतम जोखिम की अपेक्षा करें । योजना को व्यवसाय के दृष्टिकोण से देखना सुनिश्चित करें - प्रत्येक कदम क्या लाभ लाएगा।

हमें अनिवार्य क्रियान्वयन करना था: निगरानी करना, व्यवहार्य, लेकिन हम व्यापार घटक के बारे में नहीं भूले।

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

ऐसी स्थिति से निपटने का सबसे अच्छा तरीका है जहां आप विषय में खराब हैं, विशेषज्ञों की मदद लेना है, स्टैक ओवरफ्लो नहीं । वॉइस संपर्क लंबे पत्राचार या पढ़ने के प्रलेखन की तुलना में समस्या को कई बार तेजी से हल करता है।

छह महीने बाद

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

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

कठपुतली अब मृत और भ्रमित नहीं है । मैं त्रुटि संख्या एक से एक निष्कर्ष के साथ सशस्त्र था और उसने अन्सिबल पर जाने की कोशिश भी नहीं की, जो मेरे लिए अधिक आरामदायक है।

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

उपयोग किए गए डेटाबेस समूहों के रखरखाव को समझना ।

भारी सूजन विकी । पर्यावरण के साथ काम करने पर टिप्पणियों और निर्देशों से उसे "वसा" मिला।

तीन एचपी चेसिस जो हमने भविष्य की स्थापना के लिए खरीदा था।

एक स्पष्ट सन्निकटन में 2019 के शेष के मार्ग को समझना ।

विभाग के काम के लिए पुनर्नवीनीकरण पारिस्थितिकी तंत्र ।

इन सभी छह महीनों में मैंने लगभग अकेले काम किया। जिन कर्मचारियों को विरासत में मिली वे अधिक सिस्टम प्रशासक थे। वे वास्तव में DevOps के सार में तल्लीन होने के लिए उत्सुक नहीं थे।

बड़ी मुश्किल से मुझे टीम में दो विशेषज्ञ मिले - जूनियर और मिडिल। मैंने वर्तमान प्रशासकों से अधिकतम मात्रा में ज्ञान, दिखावे और पासवर्ड एकत्र किए और उनके साथ भारी मन से भाग लिया।

कार्य प्रणाली, पर्यावरण और उपकरण

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

सब कुछ ले लो, कुछ भी मत दो।

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

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

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

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

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

अनिवार्य साप्ताहिक बैठकें ट्रेलो के बाद अगला नवाचार हैं। हम व्यावहारिक रूप से कार्यालय में काम नहीं करते हैं। जिस समय हम सड़क पर बिता सकते थे, हम काम करने के लिए समर्पित थे। लेकिन सप्ताह में एक बार, पूरा विभाग ब्रेक के साथ 2-3 घंटों के लिए कार्यालय में इकट्ठा होता है, और स्प्रिंट के पाठ्यक्रम और उन कार्यों पर चर्चा करता है जो उत्पन्न हुए थे। तदनुसार, हर दो सप्ताह में एक बार के अलावा हम अगले स्प्रिंट की योजना बनाते हैं।

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

लागू करने और कॉन्फ़िगर करने के लिए आसान उपकरण ने प्रक्रिया को जन्म दिया, और इसे नियंत्रित करना आसान है।

समस्याओं

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

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

बढ़े हुए ट्रैफ़िक (हर कोई एक बेस्टसेलर चाहता था) परदे के पीछे से, हमने एक डीडीओएस हमले के लिए गलती की और इसके लिए कड़ी मुद्रा के साथ भुगतान किया। मुझे याद है कि हमने एक कंपनी के बिलों का भुगतान कैसे किया था जिसने हमें DDoS के खिलाफ सुरक्षा का वादा किया था। भुगतान के तुरंत बाद, मैंने DNS को उनके पते पर स्विच कर दिया, और 10 मिनट के बाद मुझे पहली त्रुटि याद आई और डीएनएस वापस फहराया। कोई कचरा यातायात नहीं था, लेकिन उनके माध्यम से गुजरने वाले यातायात के लिए एक घोड़ा मूल्य टैग था - किताबें, ऑडियो, कवर। मैं यह नहीं कहूंगा कि अन्य लोगों के पते पर हमें जीवन के 20 मिनट का कितना खर्च करना पड़ता है।

उस शाम मैंने क्लाउडफ्लेयर को फोन किया और हमारी समस्याओं के बारे में बात की। Anti-DDoS . , Cloudflare . . , DDoS' , .

. KPI.

KPI

. . , , .

KPI. — .

• . — .
• Downtime. — .
• . , --, , . , .

KPI, — . , , KPI, .

. 90%. , . — , . . , .

-Nagios -Puppet Zabbix Grafana Ansible. « ».

Prometheus , Zabbix. Zabbix, Prometheus — . — . .

, , .

• .
• .
• .
• .

. , , . — . , .

. - -, - . , . . . . .

, .


2 . 3 « », — . .

. : , , , Ansible, .

. , . . .

.

— , , . .

. — , .

. , . . 2019. , , , — . .

. .

.

, - , . .

• , , .
• , .
• , , — .
• , , , — , .

. , - . , , , .

.

— , , . , , .



, — - . , .

• .
• , .
• , , .

« , ». , — , , , .

, , .

—

Ansible? , , Puppet ? — .



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

, , . - ? , KPI? , -. - — , , .

.

:

• — .
• .
• , .

DevOpsConf . — , , . DevOps- HighLoad++ 2019 . DevOps 13 AWS, Lamoda, , Kubernetes, Kubernetes, Kubernetes . « » . HighLoad++ — , -. . — .