अपने बुनियादी ढांचे में विरासत सेवाओं

नमस्ते! मेरा नाम पाशा चेर्न्याक है, मैं क्यूआईडब्ल्यूआई में एक प्रमुख डेवलपर हूं, और आज मैं अपरिहार्य के बारे में बात करना चाहता हूं। विरासत के बारे में।

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



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

लेकिन मैं, किसी भी व्यक्ति की तरह, रात में सोना पसंद करता हूं, इसलिए मैंने ऑपरेशन से निपटने की कोशिश की: "दोस्तों, आप मेरे लिए क्यों हैं?" जिसके लिए उन्हें "कौन और क्या?" क्योंकि मैं सेवाओं की मरम्मत नहीं कर रहा हूं, और लोग सिर्फ यह नहीं जानते कि किसे फोन करना है।

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

किसके लिए कौन जिम्मेदार है, इसके बारे में जानकारी के अलावा, सवालों के जवाब थे: सेवा का मालिक कौन है, जो इसके विकास के लिए जिम्मेदार है, वास्तुकला और जीवन चक्र के लिए। इस सेवा के लिए जिम्मेदार लोग ऐसे लोग हैं जो कुछ होने पर इसकी मरम्मत कर सकते हैं। सेवा के स्वामी को कमिट्स में +2 छोड़ने का अधिकार है, जो जिम्मेदार इस सेवा को नई प्रतिबद्धताओं को संभालने से पहले समीक्षा में मौजूद होना चाहिए।

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

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

जैसा होता है

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

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

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

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

कहाँ से शुरू करें?

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

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

क्या करें?

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

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

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

नतीजतन, मैं एक योजना लाना चाहूंगा कि लेगेसी सेवाओं के साथ क्या करना है।

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

संदर्भ पुस्तक
अपने अनुप्रयोगों के स्रोत कोड खोदें, एक निर्देशिका बनाएं जो यह बताएगी कि यह कहाँ और कहाँ है और यह कैसे काम करती है, परियोजना विवरण में दर्ज करें (सशर्त readme.md) जल्दी से समझने के लिए कि लॉग और मैट्रिक्स कहाँ हैं। एक डेवलपर जो आपसे निपटने के बाद केवल धन्यवाद कहेगा।

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