अपवाद शोर कम करें: क्लीनर प्रोडक्शन लॉग्स के लिए सिद्ध रणनीतियाँ

कोई ऐप वास्तविक उपयोगकर्ताओं के साथ पहले संपर्क में जीवित नहीं रहता। एक बार जब लोग इसका उपयोग करना शुरू करते हैं, तो वे त्रुटियों में चलने वाले हैं।

तो, एक बार प्रोडक्शन में, अधिकांश ऐप्स के पास त्रुटियों को ट्रैक और रिपोर्ट करने का एक तरीका होगा। आप exception_notification के साथ सरल जा सकते हैं या हनीबैजर या रेगन जैसे वेबऐप का उपयोग कर सकते हैं।

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

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

नेटवर्क डाउन है!

कुछ ऐप्स अकेले काम करते हैं। अधिकांश अन्य ऐप्स के साथ संवाद करते हैं। लेकिन जब आपका जियोलोकेशन API डाउन हो जाता है या ec2 में हिचकी आती है, तो आप उन हजारों अपवादों से स्पैम नहीं होना चाहते जिनके बारे में आप कुछ नहीं कर सकते।

जब आप अविश्वसनीय सेवाओं से निपटते हैं, तो सर्किट ब्रेकर पैटर्न आज़माएं, माइकल निगार्ड के Release It से:

सर्किट ब्रेकर के पीछे मूल विचार बहुत सरल है। आप एक संरक्षित फंक्शन कॉल को एक सर्किट ब्रेकर ऑब्जेक्ट में लपेटते हैं, जो विफलताओं की निगरानी करता है। एक बार जब विफलताएं एक निश्चित सीमा तक पहुंच जाती हैं, तो सर्किट ब्रेकर ट्रिप हो जाता है, और सर्किट ब्रेकर के सभी आगे के कॉल संरक्षित कॉल को बिल्कुल भी किए बिना एक त्रुटि के साथ वापस आ जाते हैं।

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

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

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

מסתבר ש-gmaaaail.com वह नहीं है जो आपका मतलब था

एक अन्य प्रकार का अपवाद जो मैं बहुत देखता हूं वह खराब उपयोगकर्ता डेटा से आता है।

उदाहरण के लिए, मान लें कि किसी ने साइन अप करते समय अपना ईमेल टाइपो किया। उन्होंने कहा, "justinweiss@gmaill.com", लेकिन उनका मतलब "justinweiss@gmail.com" था। पहला सैद्धांतिक रूप से एक वैध ईमेल पता हो सकता है, लेकिन आपके द्वारा भेजे गए सभी ईमेल बाउंस होते हैं। और आपको अपने ईमेल प्रदाता द्वारा उन बाउंस के बारे में सूचित किया जाता है।

ये सूचनाएं सिर्फ शोर हैं।

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

ईमेल के लिए, मैंने नए उपयोगकर्ताओं के रजिस्टर करते समय "gmail.com" और "yahoo.com" जैसी चीजों को स्पेलचेक करने के लिए mailcheck-js जेम का उपयोग किया है:

{% img img-responsive /images/posts/email-spellcheck.gif 477 451 ऊह, फैंसी। %}

फिर, यदि कोई ईमेल बाद में भी बाउंस होता है, तो उस उपयोगकर्ता के लिए ईमेल बंद कर दें।

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

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

404s और RoutingErrors

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

इनके लिए, और अन्य "आधे-अपेक्षित त्रुटियों" के लिए, उन्हें बैच करें और उन्हें एक साथ संभालें। आपको उनके होने पर सूचित होने की आवश्यकता नहीं है। आप पुल चाहते हैं, पुश नहीं।

RoutingErrors और 404s जैसी चीजों को Google वेबमास्टर टूल्स जैसी किसी चीज़ के साथ संभाला जा सकता है, जो आपको वे पेज दिखाएगा जिन्हें Google जानता है जो 404 फेंक रहे हैं। या आप अपने प्री-रिलीज़ प्रक्रिया के हिस्से के रूप में अपनी साइट पर लिंक्स की जांच करने के लिए link-checker जैसा कुछ चला सकते हैं।

अपवाद कार्रवाई योग्य होने चाहिए

एक अपवाद ईमेल प्राप्त करना दुर्लभ होना चाहिए। आपके एरर ट्रैकर में बहुत अधिक शोर आपको वास्तविक समस्याओं को तुरंत देखने और ठीक करने से रोकेगा।

यदि आप अपने द्वारा देखे गए अपवादों के बारे में शर्मिंदा से अधिक नाराज़ हैं, तो आपको शोर की समस्या है। यहां पैटर्न का उपयोग करके उस शोर को कम करें और अपने उपयोगकर्ताओं को एक ही समय में बेहतर अनुभव दें।

मैंने उन शोर अपवाद श्रेणियों में से कुछ के बारे में बात की है जिन्हें मैंने सबसे अधिक देखा है। लेकिन मुझे यकीन है कि मैंने उन सभी को नहीं देखा है। आपके ऐप्स में कौन से अपवाद आपको सबसे अधिक परेशान करते हैं? क्या वे इनमें से किसी श्रेणी में फिट होते हैं, या वे एक नई परिभाषा करते हैं? आप उन्हें दिन में कुछ सौ बार आपको परेशान करने से कैसे रोकते हैं?