चेकलिस्ट: ठेस में माइक्रोसर्विसेज शुरू करने से पहले क्या करना चाहिए था

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

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

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

अंग्रेजी संस्करण भी उपलब्ध है ।

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

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

आइए जाने…।

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

रीडमी लघु विवरण

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

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

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

डेटाडॉग, न्यूरेलिक, प्रोमेथियस और इतने पर मैट्रिक्स भेजता है।

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

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

सेवा में वे अलर्ट शामिल हैं जो सभी मानक स्थितियों और ज्ञात विशिष्ट स्थितियों को कवर करते हैं।

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

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

रनबुक बनाई

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

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

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

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

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

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

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

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

लॉग जसन हैं

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

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

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

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

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

(और आप रिक्वेस्ट-आईडी जोड़ सकते हैं और ट्रेस कर सकते हैं ...)

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

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

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

निश्चित निर्भरता संस्करण

पैकेज प्रबंधकों के लिए निर्भरताएं निश्चित हैं, जिनमें मामूली संस्करण (उदाहरण के लिए, cool_framework = 2.5.3) शामिल हैं।

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

Dockerized

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

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

पर्यावरण विन्यास

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

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

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

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

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

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

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

   
   

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

   
   

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

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

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

असेंबली और डिलीवरी स्वचालित हैं

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

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

अपनी परियोजना की असेंबली और वितरण को स्वचालित करना कितना मुश्किल है, यह इस परियोजना के उत्पादन में आने से पहले किया जाना चाहिए। इस मद में शामिल हैं, निर्माण करना और चलाने के लिए Ansible / Chef cookbooks / Salt / ..., मोबाइल उपकरणों के लिए अनुप्रयोगों का निर्माण, ऑपरेटिंग सिस्टम का एक कांटा बनाना, आभासी मशीनों की छवियों का निर्माण, जो भी हो।
स्वचालित नहीं कर सकते? इसलिए आप इसे दुनिया में नहीं चला सकते। आपके बाद, कोई भी इसे एकत्र नहीं करेगा।

सुंदर शटडाउन - सही शटडाउन

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

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

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

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

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

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

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

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

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

बढ़ते लोड के साथ, यह सुनिश्चित करने के लिए अधिक एप्लिकेशन इंस्टेंस चलाने के लिए पर्याप्त है कि सभी अनुरोध या कार्य संसाधित किए जाते हैं।

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

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

मृत पत्र की कतार और बुरा संदेश लचीलापन

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

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

इससे भी बदतर, जब एक संदेश विफलता के मामले में बस नष्ट हो जाता है।

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

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

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

आईपी ​​पते द्वारा फ़िल्टरिंग के साथ तीसरे पक्ष के एकीकरण का उपयोग नहीं करता है

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

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

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

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

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

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

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

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

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

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

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

निष्कर्ष

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