अनाथ सेवा: (सूक्ष्म) सेवा आर्किटेक्चरची नकारात्मक बाजू

Banki.ru पोर्टलचे संचालन संचालक आंद्रे निकोल्स्की यांनी गेल्या वर्षीच्या परिषदेत बोलले DevOpsDays मॉस्को अनाथ सेवांबद्दल: पायाभूत सुविधांमध्ये अनाथ कसे ओळखावे, अनाथ सेवा का वाईट आहेत, त्यांचे काय करावे आणि काहीही मदत न झाल्यास काय करावे.

कटच्या खाली अहवालाची मजकूर आवृत्ती आहे.

नमस्कार सहकारी! माझे नाव आंद्रे आहे, मी Banki.ru येथे ऑपरेशन करतो.

आमच्याकडे मोठ्या सेवा आहेत, या अशा मोनोलिथिक सेवा आहेत, अधिक शास्त्रीय अर्थाने सेवा आहेत आणि खूप लहान आहेत. माझ्या कामगार-शेतकरी शब्दावलीत, मी असे म्हणतो की जर एखादी सेवा साधी आणि लहान असेल तर ती सूक्ष्म असते आणि जर ती अगदी सोपी आणि लहान नसेल तर ती फक्त एक सेवा असते.

सेवांचे फायदे

मी त्वरीत सेवांच्या फायद्यांवर जाईन.

प्रथम स्केलिंग आहे. आपण सेवेवर त्वरीत काहीतरी करू शकता आणि उत्पादन सुरू करू शकता. तुम्हाला रहदारी मिळाली आहे, तुम्ही सेवा क्लोन केली आहे. आपल्याकडे अधिक रहदारी आहे, आपण ते क्लोन केले आहे आणि त्यासह जगता. हा एक चांगला बोनस आहे, आणि, तत्त्वतः, आम्ही जेव्हा सुरुवात केली तेव्हा आमच्यासाठी सर्वात महत्वाची गोष्ट मानली गेली, आम्ही हे सर्व का करत आहोत.

दुसरे म्हणजे, पृथक विकास, जेव्हा तुमच्याकडे अनेक विकास कार्यसंघ असतात, प्रत्येक संघात अनेक भिन्न विकासक असतात आणि प्रत्येक संघ स्वतःची सेवा विकसित करतो.

संघांसह एक सूक्ष्मता आहे. विकासक वेगळे आहेत. आणि आहेत, उदाहरणार्थ, स्नोफ्लेक लोक. मी हे प्रथम मॅक्सिम डोरोफीव्हसोबत पाहिले. कधीकधी स्नोफ्लेक लोक काही संघांवर असतात आणि इतरांवर नसतात. यामुळे कंपनीमध्ये वापरल्या जाणार्‍या विविध सेवा थोड्या असमान होतात.

चित्र पहा: हा एक चांगला विकासक आहे, त्याचे हात मोठे आहेत, तो बरेच काही करू शकतो. हे हात कुठून येतात ही मुख्य समस्या आहे.

सेवा विविध प्रोग्रामिंग भाषा वापरणे शक्य करतात जे भिन्न कार्यांसाठी अधिक योग्य आहेत. काही सेवा Go मध्ये आहे, काही Erlang मध्ये आहे, काही Ruby मध्ये आहे, काही PHP मध्ये आहे, काहीतरी Python मध्ये आहे. सर्वसाधारणपणे, आपण खूप विस्तृतपणे विस्तृत करू शकता. इथेही बारकावे आहेत.

सेवा-देणारं आर्किटेक्चर प्रामुख्याने डेव्हॉप्सबद्दल आहे. म्हणजेच, तुमच्याकडे ऑटोमेशन नसल्यास, कोणतीही उपयोजन प्रक्रिया नाही, जर तुम्ही ते स्वहस्ते कॉन्फिगर केले तर, तुमची कॉन्फिगरेशन सेवा उदाहरणावरून बदलू शकते आणि तुम्हाला काहीतरी करण्यासाठी तेथे जावे लागेल, तर तुम्ही नरकात आहात.

उदाहरणार्थ, तुमच्याकडे 20 सेवा आहेत आणि तुम्हाला हाताने उपयोजित करणे आवश्यक आहे, तुमच्याकडे 20 कन्सोल आहेत आणि तुम्ही एकाच वेळी निन्जाप्रमाणे “एंटर” दाबा. ते फार चांगले नाही.

जर तुमच्याकडे चाचणीनंतर सेवा असेल (अर्थात चाचणी असेल तर) आणि तरीही तुम्हाला ती फाईलसह पूर्ण करणे आवश्यक आहे जेणेकरून ते उत्पादनात कार्य करेल, माझ्याकडे तुमच्यासाठी वाईट बातमी आहे.

तुम्ही विशिष्ट Amazon सेवांवर अवलंबून राहिल्यास आणि रशियामध्ये काम करत असाल, तर दोन महिन्यांपूर्वी तुमच्याकडे "आजूबाजूचे सर्व काही आगीत आहे, मी ठीक आहे, सर्व काही छान आहे."

आम्ही तैनात स्वयंचलित करण्यासाठी Ansible, अभिसरणासाठी कठपुतळी, स्वयंचलित तैनाती करण्यासाठी बांबू आणि या सर्वांचे वर्णन करण्यासाठी Confluence वापरतो.

मी याबद्दल तपशीलवार विचार करणार नाही, कारण अहवाल परस्परसंवाद पद्धतींबद्दल आहे, तांत्रिक अंमलबजावणीबद्दल नाही.

उदाहरणार्थ, सर्व्हरवरील पपेट रुबी 2 सह कार्य करताना आम्हाला समस्या आल्या आहेत, परंतु काही अनुप्रयोग रुबी 1.8 साठी लिहिलेले आहेत आणि ते एकत्र कार्य करत नाहीत. तिथे काहीतरी गडबड होते. आणि जेव्हा तुम्हाला एका मशीनवर रुबीच्या अनेक आवृत्त्या चालवायची असतात, तेव्हा तुम्हाला सहसा समस्या येऊ लागतात.

उदाहरणार्थ, आम्ही प्रत्येक विकसकाला एक प्लॅटफॉर्म देतो ज्यावर आमच्याकडे जवळपास सर्व काही आहे, सर्व सेवा विकसित केल्या जाऊ शकतात, जेणेकरून त्याला एक वेगळे वातावरण असेल, तो तो खंडित करू शकेल आणि त्याला हवे तसे तयार करू शकेल.

असे घडते की आपल्याला तेथे एखाद्या गोष्टीसाठी समर्थनासह काही खास संकलित पॅकेजची आवश्यकता आहे. हे खूप कठीण आहे. मी एक अहवाल ऐकला जिथे डॉकर प्रतिमेचे वजन 45 जीबी आहे. लिनक्समध्ये, अर्थातच, हे सोपे आहे, तेथे सर्वकाही लहान आहे, परंतु तरीही, तेथे पुरेशी जागा नसेल.

बरं, तेथे परस्परविरोधी अवलंबित्व आहेत, जेव्हा प्रकल्पाचा एक भाग एका आवृत्तीच्या लायब्ररीवर अवलंबून असतो, तेव्हा प्रकल्पाचा दुसरा भाग दुसर्‍या आवृत्तीवर अवलंबून असतो आणि लायब्ररी एकत्र स्थापित केलेली नाहीत.

आमच्याकडे PHP 5.6 मध्ये साइट्स आणि सेवा आहेत, आम्हाला त्यांची लाज वाटते, परंतु आम्ही काय करू शकतो? ही आमची एक साइट आहे. PHP 7 वर साइट्स आणि सेवा आहेत, त्यापैकी अधिक आहेत, आम्हाला त्यांची लाज वाटत नाही. आणि प्रत्येक विकसकाचा स्वतःचा आधार असतो जिथे तो आनंदाने पाहतो.

जर तुम्ही एका कंपनीत एका भाषेत लिहित असाल, तर प्रति विकसक तीन आभासी मशीन सामान्य वाटतात. जर तुमच्याकडे वेगवेगळ्या प्रोग्रामिंग भाषा असतील तर परिस्थिती आणखी बिघडते.

तुमच्याकडे यावर साइट्स आणि सेवा आहेत, त्यावर, नंतर Go साठी दुसरी साइट, Ruby साठी एक साइट आणि बाजूला काही इतर Redis आहेत. परिणामी, हे सर्व समर्थनासाठी मोठ्या फील्डमध्ये बदलते आणि प्रत्येक वेळी त्यातील काही खंडित होऊ शकतात.

म्हणून, आम्ही प्रोग्रामिंग भाषेचे फायदे वेगवेगळ्या फ्रेमवर्कच्या वापराने बदलले, कारण PHP फ्रेमवर्क खूप भिन्न आहेत, त्यांच्या क्षमता भिन्न आहेत, भिन्न समुदाय आहेत आणि भिन्न समर्थन आहेत. आणि आपण एक सेवा लिहू शकता जेणेकरून आपल्याकडे आधीपासूनच काहीतरी तयार असेल.

प्रत्येक सेवेची स्वतःची टीम असते

आमचा मुख्य फायदा, जो अनेक वर्षांपासून स्फटिक झाला आहे, तो म्हणजे प्रत्येक सेवेची स्वतःची टीम असते. मोठ्या प्रकल्पासाठी हे सोयीस्कर आहे, आपण कागदपत्रांवर वेळ वाचवू शकता, व्यवस्थापकांना त्यांचा प्रकल्प चांगला माहित आहे.

तुम्ही सपोर्टमधून टास्क सहज सबमिट करू शकता. उदाहरणार्थ, विमा सेवा खंडित झाली. आणि ताबडतोब विम्याचा व्यवहार करणारी टीम त्याचे निराकरण करण्यासाठी जाते.

नवीन वैशिष्ट्ये त्वरीत तयार केली जात आहेत, कारण जेव्हा तुमच्याकडे एक अणु सेवा असते, तेव्हा तुम्ही त्यामध्ये त्वरीत काहीतरी स्क्रू करू शकता.

आणि जेव्हा तुम्ही तुमची सेवा खंडित करता आणि हे अपरिहार्यपणे घडते, तेव्हा तुम्ही इतर लोकांच्या सेवांवर परिणाम करत नाही आणि इतर संघातील विकासक तुमच्याकडे बिट्स घेऊन येत नाहीत आणि म्हणतात: "अय-अय, असे करू नका."

नेहमीप्रमाणे, बारकावे आहेत. आमच्याकडे स्थिर संघ आहेत, व्यवस्थापक संघाला खिळले आहेत. स्पष्ट कागदपत्रे आहेत, व्यवस्थापक सर्वकाही बारकाईने निरीक्षण करतात. व्यवस्थापक असलेल्या प्रत्येक संघाला अनेक सेवा असतात आणि विशिष्ट क्षमतेचा मुद्दा असतो.

जर संघ तरंगत असतील (आम्ही कधीकधी हे देखील वापरतो), "स्टार नकाशा" नावाची एक चांगली पद्धत आहे.

तुमच्याकडे सेवा आणि लोकांची यादी आहे. तारका म्हणजे ती व्यक्ती या सेवेतील तज्ञ आहे, पुस्तक म्हणजे ती व्यक्ती या सेवेचा अभ्यास करत आहे. तारकासाठी पुस्तिका बदलणे हे त्या व्यक्तीचे कार्य आहे. आणि जर सेवेसमोर काहीही लिहिले नाही तर समस्या सुरू होतात, ज्याबद्दल मी पुढे बोलेन.

अनाथ सेवा कशा दिसतात?

पहिली समस्या, तुमच्या पायाभूत सुविधांमध्ये अनाथ सेवा मिळवण्याचा पहिला मार्ग म्हणजे लोकांना काढून टाकणे. कार्यांचे मूल्यमापन करण्यापूर्वी कोणाला व्यवसाय पूर्ण करण्याची मुदत होती का? काहीवेळा असे घडते की मुदती घट्ट असतात आणि कागदपत्रांसाठी पुरेसा वेळ नसतो. "आम्हाला सेवा उत्पादनाकडे सोपवायची आहे, नंतर आम्ही ती जोडू."

जर संघ लहान असेल तर असे घडते की एक विकसक आहे जो सर्व काही लिहितो, बाकीचे पंखात आहेत. "मी मूलभूत आर्किटेक्चर लिहिले आहे, चला इंटरफेस जोडूया." मग एखाद्या वेळी व्यवस्थापक, उदाहरणार्थ, निघून जातो. आणि या कालावधीत, जेव्हा व्यवस्थापक निघून गेला आणि नवीन नियुक्त केले गेले नाही, तेव्हा विकासक स्वतःच ठरवतात की सेवा कोठे जात आहे आणि तेथे काय होत आहे. आणि आपल्याला माहित आहे की (काही स्लाइड्स मागे जाऊया), काही संघांमध्ये स्नोफ्लेक लोक असतात, कधीकधी स्नोफ्लेक टीम लीड असते. मग तो सोडतो आणि आम्हाला अनाथ सेवा मिळते.

त्याच वेळी, समर्थन आणि व्यवसायातील कार्ये अदृश्य होत नाहीत; ते अनुशेषात संपतात. सेवेच्या विकासादरम्यान काही स्थापत्य त्रुटी असल्यास, त्या देखील अनुशेषात जातात. सेवा हळूहळू खराब होत आहे.

अनाथ कसे ओळखावे?

ही यादी परिस्थितीचे चांगले वर्णन करते. त्यांच्या पायाभूत सुविधांबद्दल कोणी काही शिकले?

डॉक्युमेंटेड वर्क-अराउंड बद्दल: एक सेवा आहे आणि सर्वसाधारणपणे, ती कार्य करते, तिच्यासोबत कसे कार्य करायचे याचे दोन-पानांचे मॅन्युअल आहे, परंतु ते आत कसे कार्य करते हे कोणालाही माहिती नाही.

किंवा, उदाहरणार्थ, काही प्रकारचे लिंक शॉर्टनर आहे. उदाहरणार्थ, आमच्याकडे सध्या वेगवेगळ्या सेवांमध्ये वेगवेगळ्या उद्देशांसाठी तीन लिंक शॉर्टनर वापरात आहेत. हे फक्त परिणाम आहेत.

आता मी स्पष्ट कर्णधार होईन. काय केले पाहिजे? प्रथम, आम्हाला सेवा दुसर्या व्यवस्थापकाकडे, दुसर्या संघाकडे हस्तांतरित करण्याची आवश्यकता आहे. जर तुमच्या टीम लीडने अद्याप सोडले नसेल, तर या दुसऱ्या टीममध्ये, जेव्हा तुम्हाला समजते की सेवा अनाथासारखी आहे, तेव्हा तुम्हाला त्याबद्दल किमान काहीतरी समजणाऱ्या व्यक्तीचा समावेश करणे आवश्यक आहे.

मुख्य गोष्ट: तुमच्याकडे हस्तांतरण प्रक्रिया रक्तात लिहिलेली असणे आवश्यक आहे. आमच्या बाबतीत, मी सहसा याचे निरीक्षण करतो, कारण मला हे सर्व कार्य करण्याची आवश्यकता आहे. व्यवस्थापकांना ते त्वरीत वितरित करणे आवश्यक आहे आणि नंतर त्याचे काय होते ते त्यांच्यासाठी इतके महत्त्वाचे नाही.

अनाथ बनवण्याचा पुढील मार्ग म्हणजे "आम्ही ते आउटसोर्स करू, ते जलद होईल आणि नंतर आम्ही ते संघाकडे सुपूर्द करू." हे स्पष्ट आहे की प्रत्येकाच्या संघात काही योजना आहेत, एक वळण आहे. बर्‍याचदा व्यावसायिक ग्राहकाला असे वाटते की आउटसोर्सर कंपनीकडे असलेल्या तांत्रिक विभागाप्रमाणेच काम करेल. त्यांचे प्रेरक वेगळे असले तरी. आउटसोर्सिंगमध्ये विचित्र तांत्रिक उपाय आणि विचित्र अल्गोरिदमिक उपाय आहेत.

उदाहरणार्थ, आमच्याकडे विविध अनपेक्षित ठिकाणी स्फिंक्स असलेली सेवा होती. मला काय करायचे होते ते मी नंतर सांगेन.

आउटसोर्सर्सकडे स्व-लिखित फ्रेमवर्क असतात. मागील प्रोजेक्टमधील कॉपी-पेस्टसह हे फक्त बेअर पीएचपी आहे, जिथे तुम्हाला सर्व प्रकारच्या गोष्टी मिळू शकतात. डिप्लॉयमेंट स्क्रिप्ट्स ही एक मोठी कमतरता आहे जेव्हा तुम्हाला काही फाईलमधील अनेक ओळी बदलण्यासाठी काही क्लिष्ट बॅश स्क्रिप्ट वापरण्याची आवश्यकता असते आणि या डिप्लॉयमेंट स्क्रिप्ट्सना काही थर्ड स्क्रिप्ट म्हणतात. परिणामी, तुम्ही डिप्लॉयमेंट सिस्टम बदलता, दुसरे काहीतरी निवडा, हॉप करा, परंतु तुमची सेवा कार्य करत नाही. कारण तेथे वेगवेगळ्या फोल्डर्समध्ये आणखी 8 लिंक टाकणे आवश्यक होते. किंवा असे घडते की एक हजार रेकॉर्ड कार्य करतात, परंतु एक लाख यापुढे कार्य करत नाहीत.

मी कर्णधारपद कायम ठेवीन. आउटसोर्स सेवा स्वीकारणे ही एक अनिवार्य प्रक्रिया आहे. कोणाला कधी आउटसोर्स सेवा आली आहे आणि ती कुठेही स्वीकारली गेली नाही? हे अर्थातच, अनाथ सेवा म्हणून लोकप्रिय नाही, परंतु तरीही.

सेवा तपासणे आवश्यक आहे, सेवेचे पुनरावलोकन करणे आवश्यक आहे, पासवर्ड बदलणे आवश्यक आहे. जेव्हा त्यांनी आम्हाला सेवा दिली तेव्हा आमच्याकडे एक प्रकरण होते, तेथे एक प्रशासक पॅनेल आहे “जर लॉगिन == 'admin' && पासवर्ड == 'admin'...”, ते कोडमध्ये लिहिलेले आहे. आपण बसून विचार करतो आणि लोक हे 2018 मध्ये लिहितात?

साठवण क्षमता तपासणे देखील आवश्यक आहे. तुम्ही ही सेवा कुठेतरी उत्पादनात आणण्यापूर्वीच लाखभर रेकॉर्डवर काय होईल ते पाहण्याची गरज आहे.

सुधारणेसाठी सेवा पाठविण्यास लाज वाटू नये. जेव्हा तुम्ही म्हणता: "आम्ही ही सेवा स्वीकारणार नाही, आमच्याकडे 20 कार्ये आहेत, ती करा, मग आम्ही स्वीकारू," हे सामान्य आहे. तुम्ही व्यवस्थापक बसवत आहात किंवा व्यवसायात पैशाची उधळपट्टी होत आहे याने तुमचा विवेक दुखावला जाऊ नये. त्यानंतर व्यवसाय अधिक खर्च करेल.

जेव्हा आम्ही पायलट प्रोजेक्ट आउटसोर्स करण्याचा निर्णय घेतला तेव्हा आम्हाला एक केस आली.

ते वेळेवर वितरित केले गेले आणि हा एकमेव गुणवत्तेचा निकष होता. म्हणूनच आम्ही आणखी एक पायलट प्रोजेक्ट बनवला, जो आता खरोखर पायलट नव्हता. या सेवा स्वीकारल्या गेल्या, आणि प्रशासकीय माध्यमांद्वारे ते म्हणाले, हा तुमचा कोड आहे, हा आहे संघ, हा तुमचा व्यवस्थापक आहे. सेवांनी प्रत्यक्षात नफा मिळवण्यास सुरुवात केली आहे. त्याच वेळी, खरं तर, ते अद्याप अनाथ आहेत, ते कसे कार्य करतात हे कोणालाही समजत नाही आणि व्यवस्थापक त्यांची कार्ये नाकारण्याचा सर्वोत्तम प्रयत्न करतात.

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

आणि अनाथ सेवा मिळविण्याचा आणखी एक मार्ग: जेव्हा काही संघ अचानक भारलेला आढळतो, तेव्हा व्यवस्थापन म्हणतात: "चला या संघाची सेवा दुसर्‍या संघाकडे हस्तांतरित करूया, त्याचा भार कमी आहे." आणि मग आम्ही ते तिसऱ्या संघाकडे हस्तांतरित करू आणि व्यवस्थापक बदलू. आणि शेवटी आपल्याला पुन्हा एक अनाथ आहे.

अनाथांची काय अडचण आहे?

कोणास ठाऊक नाही, ही स्वीडनमधील वासा ही युद्धनौका आहे, जी प्रक्षेपणानंतर 5 मिनिटांत बुडाली म्हणून प्रसिद्ध आहे. आणि स्वीडनच्या राजाने, तसे, यासाठी कोणालाही फाशी दिली नाही. हे दोन पिढ्यांच्या अभियंत्यांनी बांधले होते ज्यांना अशी जहाजे कशी बनवायची हे माहित नव्हते. नैसर्गिक प्रभाव.

तसे, जहाज खूप वाईट मार्गाने बुडले असते, उदाहरणार्थ, जेव्हा राजा आधीच वादळात कुठेतरी त्यावर स्वार होता. आणि म्हणून, तो लगेच बुडला, चपळतेनुसार लवकर अपयशी होणे चांगले आहे.

जर आपण लवकर अयशस्वी झालो तर सहसा कोणतीही समस्या नसते. उदाहरणार्थ, स्वीकृती दरम्यान ते पुनरावृत्तीसाठी पाठवले गेले. पण जर आपण आधीच उत्पादनात अयशस्वी झालो, जेव्हा पैसे गुंतवले जातात, तेव्हा समस्या येऊ शकतात. परिणाम, जसे त्यांना व्यवसायात म्हटले जाते.

अनाथ सेवा धोकादायक का आहेत:

• सेवा अचानक खंडित होऊ शकते.
• सेवेच्या दुरुस्तीसाठी बराच वेळ लागतो किंवा दुरुस्ती केली जात नाही.
• सुरक्षा समस्या.
• सुधारणा आणि अद्यतनांसह समस्या.
• एखादी महत्त्वाची सेवा खंडित झाल्यास कंपनीच्या प्रतिष्ठेला धक्का बसतो.

अनाथ सेवांचे काय करावे?

काय करायचे ते मी पुन्हा सांगेन. प्रथम, कागदपत्रे असणे आवश्यक आहे. Banki.ru मधील 7 वर्षांनी मला शिकवले की परीक्षकांनी विकसकांचे शब्द घेऊ नयेत आणि ऑपरेशनने प्रत्येकाचे शब्द घेऊ नयेत. आम्हाला तपासण्याची गरज आहे.

दुसरे म्हणजे, परस्परसंवाद रेखाचित्रे लिहिणे आवश्यक आहे, कारण असे घडते की ज्या सेवा फार चांगल्या प्रकारे प्राप्त होत नाहीत त्यामध्ये अवलंबित्व असतात ज्याबद्दल कोणीही सांगितले नाही. उदाहरणार्थ, विकासकांनी काही Yandex.Maps किंवा Dadata वर त्यांच्या की वर सेवा स्थापित केली. तुमची विनामूल्य मर्यादा संपली आहे, सर्व काही तुटले आहे आणि तुम्हाला काय झाले हे माहित नाही. अशा सर्व रेकचे वर्णन करणे आवश्यक आहे: सेवा Dadata, SMS, इतर काहीतरी वापरते.

तिसरे म्हणजे, तांत्रिक कर्जासह काम करणे. जेव्हा तुम्ही काही प्रकारचे क्रॅच करता किंवा एखादी सेवा स्वीकारता आणि असे म्हणता की काहीतरी करणे आवश्यक आहे, तेव्हा तुम्हाला ते पूर्ण झाले आहे याची खात्री करणे आवश्यक आहे. कारण मग असे होऊ शकते की लहान छिद्र इतके लहान नाही आणि तुम्ही त्यातून पडाल.

आर्किटेक्चरल कार्यांसह, आमच्याकडे स्फिंक्सबद्दल एक कथा होती. सेवांपैकी एकाने याद्या प्रविष्ट करण्यासाठी Sphinx चा वापर केला. फक्त पृष्ठांकित यादी, परंतु ती प्रत्येक रात्री पुन्हा अनुक्रमित केली गेली. हे दोन निर्देशांकांमधून एकत्र केले गेले: एक मोठा निर्देशांक दररोज रात्री अनुक्रमित केला जातो आणि त्यात एक लहान निर्देशांक देखील होता. दररोज, एकतर बॉम्बस्फोट होण्याच्या किंवा नसण्याच्या 50% संभाव्यतेसह, गणना दरम्यान निर्देशांक क्रॅश झाला आणि आमच्या बातम्या मुख्य पृष्ठावर अपडेट करणे थांबवले. प्रथम निर्देशांक पुन्हा इंडेक्स होण्यासाठी 5 मिनिटे लागली, नंतर निर्देशांक वाढला आणि काही क्षणी तो 40 मिनिटांसाठी पुन्हा निर्देशांक करू लागला. जेव्हा आम्ही हे कापले, तेव्हा आम्ही सुटकेचा नि:श्वास सोडला, कारण हे स्पष्ट होते की आणखी थोडा वेळ जाईल आणि आमचा निर्देशांक पूर्ण वेळ पुन्हा अनुक्रमित केला जाईल. हे आमच्या पोर्टलसाठी अपयशी ठरेल, आठ तास कोणतीही बातमी नाही - तेच आहे, व्यवसाय थांबला आहे.

अनाथ सेवेसोबत काम करण्याची योजना

खरं तर, हे करणे खूप कठीण आहे, कारण डेव्हॉप्स संप्रेषणाबद्दल आहे. तुम्हाला तुमच्या सहकार्‍यांशी चांगले संबंध ठेवायचे आहेत आणि जेव्हा तुम्ही तुमच्या सहकार्‍यांना आणि व्यवस्थापकांच्या डोक्यावर नियमांचा मारा करता, तेव्हा त्यांच्यात अशा लोकांबद्दल परस्परविरोधी भावना असू शकतात.

या सर्व मुद्द्यांव्यतिरिक्त, आणखी एक महत्त्वाची गोष्ट आहे: प्रत्येक विशिष्ट सेवेसाठी, तैनाती प्रक्रियेच्या प्रत्येक विशिष्ट विभागासाठी विशिष्ट लोक जबाबदार असले पाहिजेत. जेव्हा लोक नसतात आणि तुम्हाला या संपूर्ण प्रकरणाचा अभ्यास करण्यासाठी इतर लोकांना आकर्षित करावे लागते तेव्हा ते कठीण होते.

जर या सर्वांनी मदत केली नाही आणि तुमची अनाथ सेवा अजूनही अनाथ आहे, कोणीही ती घेऊ इच्छित नाही, दस्तऐवजीकरण लिहिलेले नाही, ज्या संघाला या सेवेसाठी बोलावण्यात आले होते त्यांनी काहीही करण्यास नकार दिला, एक सोपा मार्ग आहे - पुन्हा करणे सर्व काही

म्हणजेच, तुम्ही सेवेच्या गरजा नव्याने घ्या आणि विचित्र तांत्रिक उपायांशिवाय, अधिक चांगल्या प्लॅटफॉर्मवर, नवीन सेवा लिहा. आणि तुम्ही युद्धात त्याकडे स्थलांतरित व्हा.

आमच्याकडे अशी परिस्थिती होती जेव्हा आम्ही Yii 1 वर सेवा घेतली आणि लक्षात आले की आम्ही ती आणखी विकसित करू शकत नाही, कारण आमच्याकडे Yii 1 वर चांगले लिहू शकणारे विकासक संपले आहेत. सर्व विकासक Symfony XNUMX वर चांगले लिहितात. काय करायचं? आम्ही वेळ वाटप केला, एक संघ वाटप केला, व्यवस्थापक वाटप केला, प्रकल्प पुन्हा लिहिला आणि त्याकडे रहदारी सहजतेने बदलली.

यानंतर, जुनी सेवा हटविली जाऊ शकते. ही माझी आवडती प्रक्रिया आहे, जेव्हा तुम्हाला कॉन्फिगरेशन मॅनेजमेंट सिस्टीममधून काही सेवा घ्यायची आणि साफ करायची असते आणि त्यानंतर उत्पादनात असलेल्या सर्व कार अक्षम केल्या गेल्या आहेत हे पहा, जेणेकरून विकासकांकडे कोणतेही ट्रेस शिल्लक राहणार नाहीत. रेपॉजिटरी Git मध्ये राहते.

मला एवढंच बोलायचं होतं, मी चर्चा करायला तयार आहे, विषय होलिवर आहे, अनेकजण त्यात पोहले आहेत.

स्लाइड्स म्हटल्या की तुम्ही भाषा एकत्र करा. चित्रांचे आकार बदलण्याचे उदाहरण होते. ते एका भाषेपुरतेच काटेकोरपणे मर्यादित ठेवणे खरोखर आवश्यक आहे का? कारण PHP मध्‍ये प्रतिमेचा आकार बदलणे, गोलांगमध्‍ये प्रत्यक्षात करता येऊ शकते.

खरं तर, हे सर्व पद्धतींप्रमाणेच ऐच्छिक आहे. कदाचित, काही प्रकरणांमध्ये, ते अगदी अवांछित आहे. परंतु तुम्हाला हे समजून घेणे आवश्यक आहे की जर तुमच्याकडे 50 लोकांच्या कंपनीमध्ये तांत्रिक विभाग असेल तर त्यापैकी 45 PHP विशेषज्ञ आहेत, आणखी 3 डेव्हॉप्स आहेत ज्यांना पायथन, अॅन्सिबल, पपेट आणि असे काहीतरी माहित आहे आणि त्यापैकी फक्त एकच काही मध्ये लिहितो. एक प्रकारची भाषा. काही गो इमेज रिसाइजिंग सेवा, नंतर जेव्हा ती निघून जाते, तेव्हा तज्ञ त्याच्याबरोबर जातात. आणि त्याच वेळी, तुम्हाला ही भाषा माहित असलेल्या मार्केट-विशिष्ट विकासकाची आवश्यकता असेल, विशेषतः जर ती दुर्मिळ असेल. म्हणजेच, संघटनात्मक दृष्टिकोनातून, हे समस्याप्रधान आहे. डेव्हॉप्सच्या दृष्टिकोनातून, तुम्ही सेवा उपयोजित करण्यासाठी वापरत असलेल्या काही रेडीमेड प्लेबुक्सचे क्लोन करणे आवश्यक नाही, परंतु तुम्हाला ते सर्व पुन्हा लिहावे लागेल.

आम्‍ही सध्‍या Node.js वर सेवा तयार करत आहोत आणि प्रत्येक विकसकासाठी वेगळ्या भाषेसह हे फक्त जवळचे एक प्‍लॅटफॉर्म असेल. पण आम्ही बसलो आणि विचार केला की मेणबत्तीची किंमत आहे. म्हणजेच हा तुम्हाला बसून विचार करण्यासारखा प्रश्न आहे.

तुम्ही तुमच्या सेवांचे निरीक्षण कसे करता? तुम्ही नोंदी कसे गोळा आणि निरीक्षण करता?

आम्ही इलास्टिकसर्चमध्ये लॉग गोळा करतो आणि किबानामध्ये ठेवतो आणि ते उत्पादन किंवा चाचणी वातावरण आहे की नाही यावर अवलंबून, तेथे भिन्न संग्राहक वापरले जातात. कुठेतरी लंबरजॅक, कुठेतरी आणखी काही, मला आठवत नाही. आणि अजूनही काही सेवांमध्ये काही ठिकाणे आहेत जिथे आम्ही टेलीग्राफ स्थापित करतो आणि वेगळ्या ठिकाणी शूट करतो.

एकाच वातावरणात पपेट आणि अँसिबल सोबत कसे जगायचे?

खरं तर, आता आपल्याकडे दोन वातावरण आहेत, एक कठपुतळी आहे, दुसरे उत्तरदायी आहे. त्यांचे संकर करण्याचे काम आम्ही करत आहोत. प्रारंभिक सेटअपसाठी उत्तरदायी एक चांगली फ्रेमवर्क आहे, प्रारंभिक सेटअपसाठी पपेट एक खराब फ्रेमवर्क आहे कारण त्यासाठी थेट प्लॅटफॉर्मवर हाताने काम करणे आवश्यक आहे आणि पपेट कॉन्फिगरेशन अभिसरण सुनिश्चित करते. याचा अर्थ असा आहे की प्लॅटफॉर्म स्वतःला अद्ययावत स्थितीत ठेवते आणि अॅन्सिबिलाइज्ड मशीन अद्ययावत ठेवण्यासाठी, तुम्हाला काही वारंवारतेसह सर्व वेळ प्लेबुक चालवावे लागतील. हाच फरक आहे.

तुम्ही सुसंगतता कशी राखता? तुमच्याकडे Ansible आणि Puppet या दोन्हीमध्ये कॉन्फिग आहेत का?

हीच आमची मोठी दुखणी आहे, आम्ही हाताशी सुसंगतता ठेवतो आणि आता कुठेतरी या सगळ्यातून पुढे कसे जायचे याचा विचार करतो. असे दिसून आले की पपेट पॅकेजेस रोल आउट करते आणि तेथे काही लिंक्स राखते आणि उत्तरदायी, उदाहरणार्थ, कोड रोल आउट करते आणि तेथे नवीनतम ऍप्लिकेशन कॉन्फिग्स समायोजित करते.

सादरीकरण रुबीच्या विविध आवृत्त्यांचे होते. काय उपाय?

आम्हाला हे एकाच ठिकाणी आले आहे आणि आम्हाला ते सतत आपल्या डोक्यात ठेवावे लागेल. आम्ही फक्त रुबीवर चालणारा भाग बंद केला जो अनुप्रयोगांशी विसंगत होता आणि तो वेगळा ठेवला.

यंदाची परिषद DevOpsDays मॉस्को 7 डिसेंबर रोजी टेक्नोपोलिस येथे होणार आहे. आम्ही 11 नोव्हेंबरपर्यंत अहवालांसाठी अर्ज स्वीकारत आहोत. लिहा जर तुम्हाला बोलायचे असेल तर आम्हाला.

सहभागींसाठी नोंदणी खुली आहे, आमच्यात सामील व्हा!

स्त्रोत: www.habr.com