विकास दल शिथिल हो सकते हैं और विभिन्न दिशाओं में काम कर सकते हैं, न कि देवओप्स का उपयोग करने की इच्छा न जानने और न करने के लिए। आज के लेख में, हम इस बारे में बात करेंगे कि कैसे DevOps प्रथाओं को विकृत और परिवर्तित किया जा सकता है ताकि उन्हें लंबे समय से स्थापित विनियमों, नीतियों और लोगों की आदतों वाली कंपनियों में लागू किया जा सके।



अक्टूबर के देवोप्स 2017 सम्मेलन से सामग्री सर्गेई बर्डनिकोव (गोल्डन क्राउन) और आर्टेम कलिचकिन (सीएफटी) की एक संवाद रिपोर्ट पर आधारित है। रिपोर्ट के कट - वीडियो और टेक्स्ट ट्रांसक्रिप्ट के तहत।




सर्गेई: मैं हमारी कंपनी में ऑपरेशन विभाग का प्रमुख हूं। आर्टेम और मैंने एक छोटा क्रांति-विकास शुरू किया। यह सब क्रांति के साथ शुरू हुआ, अब यह विकास के चरण में पारित हो गया है।



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

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

हम अपनी कंपनी के प्रसंस्करण भाग में सर्गेई के साथ काम करते हैं। इस प्रसंस्करण में हम DevOps के साथ कहानी में कैसे आए, हम बताएंगे।

क्या था

सर्गेई: हमारी विरासत पूरी तरह से बैंकिंग थी। कंपनी ने शुरू में बैंकिंग उत्पादों को बनाया, क्रमशः, सब कुछ परिचित था: केवल SPARC के पूरे बुनियादी ढांचे, अपने स्वयं के डेटा केंद्र, पूरे कोर को ओरेकल में लिखा गया था। पीएल / एसक्यूएल कोड, बहुत सारे सामान - यह पैमाने पर करना आसान नहीं है।

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

जावा में बहुत सारे कोड भी लिखे। हम एक गर्म रिजर्व के माध्यम से आरक्षित करते हैं: एक डेटा सेंटर है, और पूरी नकल की संरचना - स्विच, सर्वर, सभी एक में, बोल्ट से बोल्ट तक।



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

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

Artem: DevOps अभी इस स्तर पर नहीं है, हमने नियमों के अनुसार काम किया, जिससे सर्गेई खुश नहीं थे।

सर्गेई: मैं लागू प्रशासकों की टीम में शामिल हो गया और मुझे याद है कि "महान समय" क्या था। हम तीन सप्ताह के लिए एक आवेदन कर सकते हैं। एक आवेदन आता है, उन्होंने इसमें किसी प्रकार की गलती पाई और इसे रद्द कर दिया, यह मानते हुए कि मूर्ख स्वयं आवेदन नहीं लिख सकते थे। और आवेदन के सही लेखन के लिए आवश्यक ज्ञान मेरे पास था।

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

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

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

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

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

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

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

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

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

हमें एहसास हुआ कि पेज इंस्ट्रक्शन के साथ कोई फर्क नहीं पड़ता, यह सब पूरी तरह से बकवास में बदल गया, चाहे वह किसी भी तरह से बना हो।

रात में लंबे समय तक डाउनटाइम के लिए महत्वपूर्ण पूर्वापेक्षाएँ थीं, जिसके कारण स्थापना के बाद खराब टेक-ऑफ, जाम, और विकास और संचालन के बीच बड़ी संख्या में संघर्ष हुए।

• परिवर्तनों को प्रसारित करने में बहुत सी मानवीय त्रुटियां;
• दोषियों की लगातार खोज;
• 3 सप्ताह तक नए मॉड्यूल की हटाने की दर;
• विफलता के एकल बिंदु (केवल ऊर्ध्वाधर स्केलिंग), संतुलन की कमी;
• 2 घंटे के अद्यतन के दौरान नियोजित डाउनटाइम।

परिवर्तन पृष्ठभूमि

सेर्गेई: बहुत सारे बदलाव हुए, हमने लगातार गड़बड़ की। हर हफ्ते हम इकट्ठा होते हैं, शापित होते हैं, शांत हो जाते हैं। इस प्रक्रिया को हमेशा के लिए दोहराया गया, उन्होंने दोषी एक की तलाश की: "ये सभी डेवलपर्स हैं जो घुमावदार कोड लिखते हैं, यहां तक ​​कि जावा मॉड्यूल भी प्रसारित नहीं किया जा सकता है।"

आर्टेम: लेकिन डेवलपर्स ने सोचा कि ये प्रारंभिक चीजें थीं: लॉग में एक त्रुटि गिर गई - इसे सुलझाएं, इसे Google करें और समझें कि कॉन्फ़िगरेशन में क्या तय किया जाना चाहिए।

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

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

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

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

आर्टेम: 2 घंटे के अपडेट समय का अनुसूचित डाउनटाइम एक महत्वपूर्ण कारक है कि हम इसका समाधान क्यों ढूंढना शुरू करते हैं, इससे कैसे दूर हो सकते हैं।

तथ्य यह है कि हम वित्तीय सेवाएं, प्रसंस्करण सेवाएं प्रदान करते हैं। हम विदेशों में काम करते हैं। फिर हमने 11 समय क्षेत्रों में काम किया, 2013 में हमारे पास केवल एक घंटे की खिड़की थी, जब सेवा का उपयोग कम से कम था, क्लाइंट कॉल की संख्या कम से कम थी, शांत हो गई, और कुछ किया जा सकता था।

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

इन सभी समस्याओं का जवाब मुझे एक विचार मिला, यह पता लगाने का प्रयास कि देवओप्स क्या है।

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

2013 में, मैंने इसके बारे में सब कुछ पढ़ा, मैंने फैसला किया कि कुछ कचरा वह नहीं था जो मुझे चाहिए था। मुझे नियंत्रित करने की आवश्यकता है, और वे कोड को वहां लिखने के लिए मजबूर करते हैं। हालांकि, स्थिति नहीं बदली, समस्याओं का संचय हुआ और मैंने खुद को घर पर बैठने के लिए मजबूर किया और चीजों को सुलझाना शुरू किया। मैंने सोचा कि इसमें कुछ था, किसी तरह का उद्धार।

और फिर मुझे पता चला कि हमारे पास समान वातावरण, समान रोल-आउट और अद्यतन स्क्रिप्ट होनी चाहिए, ताकि हमें इन परिदृश्यों की जाँच करनी चाहिए, जो परीक्षण वातावरण से शुरू होते हैं।

निर्देशों और मैनुअल क्रियाओं को कम करने और सब कुछ स्वचालित करने के लिए एक मौका था, न कि केवल अलग-अलग बैश स्क्रिप्ट के साथ, जिसमें एक और व्यवस्थापक बाद में अपना पैर तोड़ देगा।

जब मैं इस विचार के साथ आया था, तो मुझे जो भी प्राप्त करना है, उसकी पहली घोषणा के साथ। यह 2013 का दस्तावेज है, जो देवओप्स के बारे में कंपनी में बनाया गया पहला है।

सर्गेई: यहां एक महत्वपूर्ण विचार है: नए मॉड्यूल को हटाने की गति को कम करने के लिए, लड़ाई को हटाने के दौरान त्रुटियों की संख्या को कम करने के लिए। यही है, ऐसे विशिष्ट लक्ष्य थे जिन्हें हम नई रिलीज के पहले चरण में हासिल करना चाहते थे।



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

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

आर्टेम: यहां हम मूल्यों से आगे बढ़े: यह वह जगह है जहां हम पैसे खो देते हैं, यह सरल एक अस्वीकार्य है।

दोस्तों और मैं इन नुकसानों को कम करने का एक तरीका लेकर आए हैं। क्या आपके पास बेहतर विकल्प है? यदि नहीं, तो चुप रहें, यदि आप हैं, तो आलोचना करें और प्रस्ताव दें। कुछ भी नहीं देना है? फिर हम कोशिश करते हैं।

अनुनय और मजबूर करने की एक प्रक्रिया थी: हमने अपने विचारों को सीमित संख्या में प्रणालियों का उपयोग करने का सुझाव दिया।

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

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



सर्गेई: पहले पुनरावृत्तियों में, हमने अपनी कंपनी की संरचना और प्रौद्योगिकी के संदर्भ में कई महत्वपूर्ण निर्णय लिए। सबसे पहले, हमने कॉन्फ़िगरेशन प्रबंधन लागू किया। इसने हमें 10 ए 4 पृष्ठों के निर्देश के साथ गलत कॉन्फ़िगरेशन को निकालने की परेशानी से बचाया।

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

जब आप लोगों के बगल में बैठते हैं, जब आप देखते हैं कि वे कैसे काम करते हैं, जब वे देखते हैं कि हम कैसे काम करते हैं। हमें टीमों के बीच एक संवाद भी मिला: यह असली DevOps की पहली चिंगारी है। कोई नई तकनीक नहीं थी, कोई तकनीक नहीं थी। प्रौद्योगिकी के दृष्टिकोण से, हमने सोचा था कि कुछ भी बिल्कुल नहीं लगेगा, हमने अलग तरह से काम किया, दूसरी दुनिया में।

पहला विचार कॉन्फ़िगरेशन प्रबंधन को स्वयं लिखना है, कई डेवलपर्स हैं। फिर हमने वह सब कुछ याद किया जो हमने खुद लिखा था, और मना कर दिया - हम सब झगड़ते हैं।

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

इस स्तर पर, यह पता चला है कि आईटी विभाग से हमारे तकनीकी विभाग में आवेदन के प्रवेश पत्र चले गए। जैसा कि सर्गेई ने कहा, वे सभी व्यापारिक मूल्य महसूस करने लगे, व्यापारिक चीजों के कारण प्राथमिक।

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



सर्गेई: इस समय, यदि हमने एप्लिकेशन के साथ कुछ नहीं समझा, तो हमने डेवलपर को आने के लिए कहा: "चलो एक साथ निर्णय लेते हैं और लिखते हैं कि आवेदन कैसे ध्वनि चाहिए"।

आर्टेम: और इस पर, सशर्त रूप से, कमांड संरचना, हमने प्रौद्योगिकी में जाना शुरू किया।

सर्गेई: अब हम आपको बताएंगे कि हमने सिस्टम को कैसे चुना। यह काफी दिलचस्प था। सबसे पहले, हमने शेफ की कोशिश की, एक सरल कारण के लिए - हम एक गुरु को जानते थे जो शेफ को जानता है। फिर हमने कठपुतली की कोशिश की, क्योंकि उस समय ओरेकल ने कठपुतली के लिए समर्थन की घोषणा की थी।

अन्सिबल ने भी कोशिश की, लेकिन दोनों टीमों ने इसे एक प्रणाली के रूप में पसंद नहीं किया। सुरक्षा के मुद्दे भी थे: 2013 में Ansible वर्तमान से बहुत अलग था।

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

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

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

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

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

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

आर्टेम: यही कारण है कि यह अभी भी महत्वपूर्ण था: नुस्खा में, परिणाम संस्करण संख्या में परिवर्तन के रूप में प्रकट होता है, यह भंडार से आगे और आगे फैलता है और आवश्यक हो जाता है।

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

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

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

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

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

तथ्य यह है कि हमें एक ऐसा वातावरण जुटाने की जरूरत है, जो प्रदर्शन में लगभग समान हो और इसे ऐसे डेटा से भरे जो वॉल्यूम में समान हों और कोई कम महत्वपूर्ण, कार्डिनैलिटी न हो, ताकि हमारे स्टेज टेस्ट सही तरीके से पास हों।

यहाँ बहुत मुश्किल फैसले थे। सबसे पहले, हमने स्केलिंग के संदर्भ में क्या किया - हमें एहसास हुआ कि हम मंच पर समान ऊर्ध्वाधर वाहन प्रदान नहीं कर सकते हैं जैसा कि लड़ाई में है। Stage- . , , - - . .

Stage , . , , , .

Stage . , , . , bbb, , Stage .

, , , , .

, . , , , .



. , , . DevOps. — . : , , , Puppet, , . , .

: . IT .

OPS . . , . : , , .



: 200+ , 150 , 6 OPS-. , . — , , . , : -, — . .

: , git. .

: Gitlab, , . «», , .

, pdf — pdf, , . , . ops .

, . , . «».

. , , . , .

, . , , .

, , — . API Telegram, , , . .



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

, Jira. , : , . .

: , , . on call duty- . , , , .

DEV

: : , , . , . , DevOps, , CM.

, , , . CI, pipeline . .

: CI, . -, , . .

, Stage Prod . , , . , .

: , , , , . , , .



? , DevOps- , , DevOps-. ?

, , DevOps. , . , .

— , . , . .

: , , 15-20 . : , .



: . DRP- . , . , . DevOps : Git .

. , , . , . . , , .

SPARC Solaris, x86 : Sparc. Haproxy, Solaris. , . , , . .

: , . x86 . , , .

, , , . : , , , .

, , — . .



: , : git. 4-.

. - , - Oracle, , . . , - - . , - , , , .



? , . : « DevOps ». , , , , , .

: : «, DevOps?». , , Prod, .

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

: , DevOps. .



: , : .

, , — - . , , Dev Ops. , , , .

: , Merge, , . .

: . , , , , . - , - CI/CD.

OPS, CI . «». , , Docker, Kubernetes, : «, , , ».

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

: , . : — , , , . , . , .

, , , , . .

. . , . , . , , - .

, , -.

यदि आप लंबे समय से पढ़ते-पढ़ते थक गए हैं - तो हम अपने मित्रों बरूच सदोगुरस्की और व्याचेस्लाव कुज़नेत्सोव के साथ "फाइव मिनट PHP" पॉडकास्ट की रिलीज़ सुनने की सलाह देते हैं। ट्रेंड्स DevOps, DecSecOps, Kubernetes जीत और स्टेट ऑफ़ देवऑप्स 2018 DORA द्वारा रिपोर्ट।

और यदि आप अधिक शांत रिपोर्ट चाहते हैं, तो DevOops 2018 सम्मेलन में आएं। इसमें बारूक, और ग्लोरी और यहां तक ​​कि जॉन जॉनी भी होंगे! सभी वक्ताओं और कार्यक्रम साइट पर हैं ।

एक अच्छा बोनस: 1 अक्टूबर तक, DevOops 2018 का टिकट डिस्काउंट पर बुक किया जा सकता है।