चेकलिस्ट: उत्पादन के लिए माइक्रोसर्विस को तैनात करने से पहले क्या करना चाहिए था

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

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

अगर आपको लगता है कि कुबेरनेट्स / ईसीएस / जो भी हो, में एक और ऐप लॉन्च करने का समय आ गया है, तो मुझे कुछ आपत्ति है।

अस्वीकरण: यह मेरी मूल पोस्ट का अनुवाद है। अंग्रेजी मेरी आम भाषा नहीं है। कृपया, मुझे खुद को सुधारने में मदद करें। यदि आपको कोई त्रुटि दिखाई देती है, तो मुझे इसे दिखाने के लिए स्वतंत्र महसूस करें, मैं आभारी रहूंगा।

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

यदि आपका माइक्रोसर्विस कम से कम एक मापदंड को पूरा नहीं करता है, तो मैं आपको गर्म फर्श (हाँ, यह गर्म होगा) और एक बंद स्व के साथ जमीन के नीचे 2000 मीटर की दूरी पर बंकर में बनाए गए अपने आदर्श क्लस्टर में डालने की अनुमति नहीं देगा। -विशेष इंटरनेट प्रणाली।

यहाँ जाता है!

नोट: वस्तुओं का क्रम मायने नहीं रखता। कम से कम मेरे लिए।

Readme में एक संक्षिप्त विवरण

यह अपने गिट रिपॉजिटरी में Readme.md की शुरुआत में खुद का एक छोटा विवरण शामिल है।

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

एक निगरानी प्रणाली के साथ एकीकरण

DataDog, NewRelic, Prometheus, आदि को मेट्रिक्स भेजें

संसाधन खपत, स्मृति लीक, स्टैकट्रैक, सेवा अन्योन्याश्रयता, त्रुटि दर और इतने पर विश्लेषण ... यह सब समझने के बिना एक बड़े वितरित आवेदन में क्या होता है, इसे नियंत्रित करना बेहद मुश्किल है।

अलर्ट कॉन्फ़िगर किए गए हैं

ने ऐसे अलर्ट कॉन्फ़िगर किए हैं जो सभी मानक स्थितियों को कवर करते हैं, साथ ही ज्ञात विशिष्ट स्थितियों को भी।

मेट्रिक्स अच्छे हैं, लेकिन कोई भी उन्हें मैन्युअल रूप से पालन नहीं करेगा। इसलिए, हम स्वचालित रूप से कॉल / पुश / टेक्स्ट प्राप्त करते हैं:

• सीपीयू / मेमोरी की खपत में नाटकीय रूप से वृद्धि हुई है।
• आवागमन में नाटकीय रूप से वृद्धि हुई है।
• प्रति सेकंड संसाधित किए गए लेनदेन की संख्या किसी भी दिशा में उज्ज्वल रूप से बदल गई है।
• एक तैनात विरूपण साक्ष्य के आकार को विशेष रूप से बदल दिया गया है (उदाहरण, एप्लिकेशन, जार, ...)।
• त्रुटियों का प्रतिशत या उनकी आवृत्ति अनुमेय सीमा से अधिक थी।
• सेवा ने मैट्रिक्स भेजना बंद कर दिया (एक स्थिति अक्सर अनदेखी की गई)।
• कुछ अपेक्षित घटनाओं की नियमितता टूट जाती है (क्रॉन जॉब काम नहीं करता है, सभी घटनाओं को संसाधित नहीं किया जाता है, आदि)
• ...

रनबुक बनाई

ज्ञात या अपेक्षित असामान्य स्थितियों का वर्णन करने वाली सेवा के लिए एक दस्तावेज़ बनाया गया है।

• यह सुनिश्चित करने के लिए कि त्रुटि आंतरिक है और किसी तृतीय-पक्ष पर निर्भर नहीं है;
• अगर यह निर्भर करता है: कहाँ, किससे और क्या लिखना है;
• इसे सुरक्षित रूप से कैसे पुनः आरंभ करें;
• बैकअप से कैसे पुनर्स्थापित करें और वे कहाँ हैं, बैकअप;
• इस सेवा की निगरानी के लिए क्या विशेष डैशबोर्ड / खोज क्वेरी बनाई गई थी;
• सेवा का अपना स्वयं का व्यवस्थापक पैनल है और वहां कैसे पहुंचा जाए;
• एक एपीआई / सीएलआई है और ज्ञात समस्याओं को ठीक करने के लिए इसका उपयोग कैसे करें;
• और इसी तरह।

विभिन्न संगठनों में सूची बहुत अलग हो सकती है, लेकिन कम से कम बुनियादी चीजें होनी चाहिए।

सभी लॉग STDOUT / STDERR को लिखे गए हैं

सेवा उत्पादन मोड में किसी भी लॉग फ़ाइल का उत्पादन नहीं करती है, उन्हें किसी भी बाहरी सेवाओं को नहीं भेजती है, इसमें कोई निरर्थक सार जैसे लॉग रोटेशन, आदि शामिल नहीं है।

जब कोई एप्लिकेशन लॉग के साथ फाइल बनाता है - ये लॉग बेकार हैं। आप समानांतर में चल रहे 5 कंटेनरों में नहीं कूदेंगे, "पूंछ-एफ" से आवश्यक त्रुटि को पकड़ने की उम्मीद करेंगे (हाँ, आप करेंगे, भागते हुए रोते हुए ...)। एक कंटेनर को फिर से शुरू करने से इसके लॉग का पूर्ण नुकसान होगा।

यदि कोई एप्लिकेशन थर्ड-पार्टी सिस्टम में लॉग लिखता है, उदाहरण के लिए लॉगस्टैश में, तो यह बेकार अतिरेक पैदा करता है। पड़ोसी सेवा ऐसा नहीं कर सकती क्योंकि यह दूसरे ढांचे पर आधारित है? आपको एक चिड़ियाघर मिलेगा।

एप्लिकेशन फ़ाइलों में इसके लॉग का एक भाग और STDOUT में एक और भाग लिखता है क्योंकि डेवलपर INFO को कंसोल में लेकिन DEBUG को फाइलों में देखना चाहता है? यह आमतौर पर सबसे खराब विकल्प है। किसी को भी इस जटिलता की आवश्यकता नहीं है और अतिरिक्त कोड और कॉन्फ़िगरेशन को बनाए रखना है जो पहले सीखना होगा।

लॉग का मतलब होता है json

लॉग की प्रत्येक पंक्ति को Json प्रारूप में लिखा गया है और इसमें फ़ील्ड का एक सहमत सेट शामिल है।

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

जसन एक वरदान है, यह स्वर्ग से दी गई अग्नि है। बस वहां जोड़ें:

• RFC 3339 के अनुसार मिलीसेकंड के साथ टाइमस्टैम्प;
• स्तर: जानकारी, चेतावनी, त्रुटि, डीबग
• user_id;
• app_name,
• और अन्य क्षेत्र।

उन्हें किसी भी उपयुक्त सिस्टम पर अपलोड करें (उदाहरण के लिए, ठीक से कॉन्फ़िगर की गई लोचदारस्टिक) कई microservices के लॉग कनेक्ट करें और फिर से महसूस करें कि अखंड अनुप्रयोगों में क्या अच्छा था।

(आप एक अनुरोध-आईडी भी जोड़ सकते हैं और एक अनुरेखण प्राप्त कर सकते हैं ...)

वर्बोसिटी के स्तर के साथ लॉग

एप्लिकेशन को कम से कम दो विकल्पों के साथ, LOG_LEVEL के लिए, पर्यावरण चर का समर्थन करना चाहिए: ERRORS और DEBUG।

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

निर्भरता के बंद संस्करण

पैकेज प्रबंधकों के लिए निर्भरताएँ निश्चित हैं, जिनमें लघु संस्करण (उदाहरण के लिए, cool_framework = 2.5.3) शामिल हैं। कमिटेड लॉकफाइल्स भी ऐसा करने का अच्छा तरीका है।

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

Dockerized

रिपॉजिटरी में एक प्रोडक्शन-रेडी डॉकरफाइल और डॉकटर-कंपोज.इमल शामिल हैं

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

पर्यावरण के माध्यम से विन्यास

सभी महत्वपूर्ण कॉन्फ़िगरेशन विकल्प पर्यावरण से पढ़े जाते हैं और कॉन्फ़िगरेशन फ़ाइलों पर पर्यावरण की उच्च प्राथमिकता होती है (लेकिन कमांड लाइन तर्कों की तुलना में कम)।

कोई भी कभी भी आपकी कॉन्फ़िगरेशन फ़ाइलों को पढ़ना और उनके प्रारूप का अध्ययन नहीं करना चाहेगा। बस इसे स्वीकार करो।

अधिक विवरण यहां: https://12factor.net/config

तत्परता और आलूबुखारा जांच

स्टार्टअप पर और जीवनचक्र के दौरान अनुरोधों को पूरा करने के लिए तत्परता का परीक्षण करने के लिए उपयुक्त समापन बिंदु या cli कमांड शामिल हैं

यदि कोई एप्लिकेशन HTTP अनुरोधों को पूरा करता है, तो उसे डिफ़ॉल्ट रूप से दो इंटरफेस होने चाहिए (CLI जांच भी संभव है):

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

   
   

2. यह सत्यापित करने के लिए कि आवेदन अभी शुरू नहीं हुआ है, लेकिन अनुरोध स्वीकार करने के लिए तैयार है, एक तत्परता जांच की जा सकती है। यदि किसी एप्लिकेशन ने एक डेटाबेस, एक कतार प्रणाली, और इसी तरह से कनेक्शन स्थापित किया है, तो उसे 200 से 400 (कुबेरनेट के लिए) की स्थिति के साथ जवाब देना होगा।

   
   

संसाधन की सीमा

स्मृति, सीपीयू, डिस्क स्थान और किसी अन्य उपलब्ध संसाधनों के लिए सहमत प्रारूप में सीमाएं शामिल हैं।

इस बिंदु का ठोस कार्यान्वयन विभिन्न संगठनों में और विभिन्न ऑर्केस्ट्रेटर के लिए बहुत भिन्न होगा। हालांकि, उन्हें विशेष रूप से सभी उपलब्ध वातावरणों (ठेस, देव, परीक्षण, ...) के लिए कॉन्फ़िगर किया जाना चाहिए और आवेदन कोड के साथ गिट रेपो से बाहर संग्रहीत किया जाना चाहिए।

स्वचालित बनाता है और वितरण

आपके संगठन या परियोजना में उपयोग की जाने वाली CI / CD प्रणाली को कॉन्फ़िगर किया गया है और स्वीकृत वर्कफ़्लो के अनुसार वांछित वातावरण में आवेदन देने में सक्षम है।

मैन्युअल रूप से उत्पादन करने के लिए कुछ भी नहीं दिया जाता है।

कोई फर्क नहीं पड़ता कि आपके आवेदन का निर्माण और वितरण स्वचालित करना कितना मुश्किल है, यह इस परियोजना के उत्पादन में आने से पहले किया जाना चाहिए। इस मद में मोबाइल उपकरणों के लिए बिल्डिंग बिल्डिंग, एंसेबल / शेफ कुकबुक / सॉल्ट / ... का निर्माण और अनुप्रयोग शामिल हैं; ऑपरेटिंग सिस्टम के कांटे; आभासी मशीनों की छवियाँ, जो भी हो।
इसे स्वचालित करना मुश्किल है? आप इसे फिर दुनिया में नहीं ला सकते। आपके जाने के बाद कोई भी इसे मैन्युअल रूप से फिर से नहीं बना सकेगा।

ग्रेसफुल शटडाउन

आवेदन SIGTERM और अन्य संकेतों को समझता है और वर्तमान कार्य को संसाधित करने के बाद अपने आप बंद हो जाएगा।

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

यदि आप तृतीय-पक्ष निर्भरता में से कुछ को नियंत्रित करने में सक्षम नहीं हैं और यह गारंटी नहीं दे सकते कि आपका कोड SIGTERM को सही ढंग से संभालेगा, तो डंब -इन जैसा कुछ उपयोग करें।

अधिक जानकारी यहाँ:

• https://12factor.net/disposability
• https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods

डेटाबेस कनेक्शन को नियमित रूप से जांचा जाता है

एप्लिकेशन लगातार डेटाबेस को पिंग करता है और स्वचालित रूप से एक पिंग से या किसी अन्य प्रश्न से दिखाई देने वाले "कनेक्शन खो गए" अपवाद पर प्रतिक्रिया करता है, इसे अपने आप से बहाल करने या अपने काम को सही ढंग से पूरा करने की कोशिश करता है।

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

क्षैतिज रूप से स्केल किया गया

जैसे ही लोड बढ़ता है, यह सुनिश्चित करने के लिए आवेदन के अधिक उदाहरणों को चलाने के लिए पर्याप्त है कि सभी अनुरोधों या कार्यों को संसाधित किया जाए।

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

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

मृत पत्र की कतारें और "खराब" संदेशों का प्रतिरोध

यदि सेवा कतारों को सुनती है या घटनाओं पर प्रतिक्रिया देती है, तो संदेशों के प्रारूप या सामग्री को बदलने से यह गिरने का कारण नहीं बनता है। कार्य को संसाधित करने के असफल प्रयास को N बार दोहराया जाता है, जिसके बाद संदेश को डेड लेटर क्यू में भेज दिया जाता है।

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

और बहुत बुरा जब विफलता के मामले में संदेश बस नष्ट हो जाता है।

एक उदाहरण द्वारा संसाधित संदेशों और कार्यों की सीमित संख्या

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

लगातार बढ़ती मेमोरी खपत और अंत में "ओओएम किल्ड" आधुनिक कुबेरनेटिक दिमागों के लिए जीवन का आदर्श है। एक आदिम जांच को लागू करना जो आपको इन सभी मेमोरी लीक की जांच करने की बहुत आवश्यकता होगी, जिससे जीवन आसान हो जाएगा। मैंने अक्सर देखा है कि लोग इन लीक को रोकने के लिए बहुत समय और प्रयास (और पैसा) खर्च करते हैं, लेकिन इस बात की कोई गारंटी नहीं है कि आपके वर्कमेट के अगले कमिट से चीजें खराब नहीं होंगी। यदि आवेदन एक सप्ताह तक जीवित रह सकता है, तो यह एक उत्कृष्ट संकेतक है। फिर इसे बस खुद को रोक दें और इसे फिर से शुरू किया जाएगा। यह SIGKILL (SIGTERM के बारे में, ऊपर देखें) या "मेमोरी से बाहर" अपवाद से बेहतर है। कुछ दशकों के लिए, यह वर्कअराउंड अधिकांश मामलों के लिए पर्याप्त है।

IP पते श्वेतसूची के साथ तीसरे पक्ष के एकीकरण द्वारा लॉक नहीं किया गया

यदि कोई एप्लिकेशन तृतीय-पक्ष सेवा के लिए अनुरोध करता है जो केवल सीमित आईपी पते से अनुरोध करता है, तो सेवा इन अनुरोधों को अप्रत्यक्ष रूप से (उदाहरण के लिए, एक रिवर्स प्रॉक्सी के माध्यम से) बनाती है।

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

स्पष्ट HTTP उपयोगकर्ता-एजेंट

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

जब आपके पास 100 अलग-अलग एप्लिकेशन एक-दूसरे के साथ संवाद करते हैं, तो आप पागल हो सकते हैं, लॉग में कुछ "गो-http-क्लाइंट / 1.1" और कुबेरनेट कंटेनर के गतिशील आईपी पते को देखकर। हमेशा अपने एप्लिकेशन और उसके संस्करण को स्पष्ट रूप से पहचानें।

किसी लाइसेंस का उल्लंघन नहीं करता है

इसमें निर्भरताएं नहीं हैं जो एप्लिकेशन को सीमित करती हैं और यह किसी और के कोड की कॉपी नहीं है, और इसी तरह।

यह एक स्व-स्पष्ट मामला है, लेकिन मैंने चीजों को देखा है कि एनडीए को लिखने वाले एक वकील को भी अब हिचकी मिली है।

असमर्थित निर्भरता का उपयोग नहीं करता है।

जब आप पहली बार सेवा शुरू करते हैं, तो इसमें निर्भरताएं शामिल नहीं होती हैं जो पहले से ही पुरानी हैं।

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

निष्कर्ष

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