अधिकांश त्रुटि प्रबंधन उस इंजीनियर के लिए लिखा जाता है जो पहले से ही सिस्टम को जानता है।
यह उल्टा है।
उपयोगकर्ता को इस बात से कोई फर्क नहीं पड़ता कि कोई Stripe वेबहुक टाइमआउट हो गया, किसी Supabase नीति ने पंक्ति को अस्वीकार कर दिया, या किसी मॉडल प्रदाता ने 429 लौटाया। वे तीन चीज़ों की परवाह करते हैं:
- क्या हुआ
- क्या उनका काम सुरक्षित है
- वे आगे क्या कर सकते हैं
यदि इंटरफ़ेस उन प्रश्नों का उत्तर नहीं दे सकता, तो त्रुटि संदेश मदद नहीं कर रहा है। यह केवल कार्यान्वयन विवरण लीक कर रहा है।
उपयोगकर्ता के कार्य से शुरू करें, अपवाद से नहीं
त्रुटि संदेश का पहला ड्राफ्ट आमतौर पर कोड पथ जैसा लगता है:
चेकआउट सत्र बनाने में विफल।
यह सच हो सकता है, लेकिन यह उपयोगी नहीं है। एक बेहतर संस्करण उपयोगकर्ता के इरादे से शुरू होता है:
हम चेकआउट नहीं खोल सके। आपके प्रोजेक्ट विवरण सहेज लिए गए हैं। पुनः प्रयास करें, या कॉल बुक करें और हम इसे मैन्युअल रूप से पूरा कर देंगे।
वह संदेश चार काम करता है:
- विफल कार्रवाई का नाम बताता है
- पुष्टि करता है कि डेटा सहेजा गया था या नहीं
- अगला कदम देता है
- उपयोगकर्ता को दोष देने से बचता है
आंतरिक त्रुटि को अभी भी प्रदाता, स्थिति कोड, अनुरोध आईडी और स्टैक ट्रेस के साथ लॉग किया जा सकता है। उपयोगकर्ता को इन सबकी आवश्यकता नहीं है।
उपयोगकर्ता कॉपी को इंजीनियरिंग टेलीमेट्री से अलग करें
उत्पाद सतह और अवलोकनीयता सतह को एक ही पेलोड नहीं ले जाना चाहिए।
उपयोगकर्ता एक स्पष्ट पुनर्प्राप्ति पथ देखता है। सिस्टम ऑपरेटर के लिए स्टैक ट्रेस, अनुरोध आईडी, प्रदाता प्रतिक्रिया और अलर्ट रूटिंग रखता है।
प्रोडक्शन में, मैं एक ही विफलता से दो आउटपुट चाहता हूं:
- पेज पर एक मानव-पठनीय संदेश
- लॉग, एनालिटिक्स और अलर्टिंग में एक मशीन-पठनीय घटना
उपयोगकर्ता कॉपी शांत और विशिष्ट होनी चाहिए। टेलीमेट्री घनी और यदि आवश्यक हो तो बदसूरत हो सकती है। इन दोनों को मिलाने से या तो बेकार लॉग या शत्रुतापूर्ण इंटरफ़ेस बनते हैं।
अच्छी त्रुटि स्थितियाँ पाँच प्रश्नों का उत्तर देती हैं
जब मैं किसी त्रुटि स्थिति की समीक्षा करता हूं, तो मैं इसे इस चेकलिस्ट के माध्यम से चलाता हूं।
यदि उत्तर नहीं है, तो स्थिति पूरी नहीं हुई है।
उदाहरण के लिए, एक लीड फॉर्म विफलता को 500 आंतरिक सर्वर त्रुटि नहीं कहना चाहिए। इसे कुछ इस तरह कहना चाहिए:
हम संदेश नहीं भेज सके। आपका ब्राउज़र इस पेज पर रहा, इसलिए कुछ भी नहीं खोया। पुनः प्रयास करें या प्रोजेक्ट विवरण सीधे ईमेल करें।
फिर सर्वर लॉग में वास्तविक कारण होना चाहिए: सत्यापन विफलता, Resend टाइमआउट, Supabase इन्सर्ट विफलता, या वेबहुक अस्वीकृति।
सिस्टम के विफल होने से पहले फ़ॉलबैक डिज़ाइन करें
टीमें आमतौर पर पहली प्रोडक्शन घटना के बाद फ़ॉलबैक स्थितियाँ जोड़ती हैं। यह महंगा है क्योंकि विफलता पहले से ही सार्वजनिक है।
महत्वपूर्ण प्रवाहों के लिए, मैं फीचर बनाते समय फ़ॉलबैक को परिभाषित करना पसंद करता हूं:
| प्रवाह | उपयोगकर्ता फ़ॉलबैक | ऑपरेटर संकेत |
|---|---|---|
| चेकआउट | रूट सहेजें, बुकिंग लिंक प्रदान करें | सत्र मेटाडेटा के साथ भुगतान प्रदाता त्रुटि |
| संपर्क फ़ॉर्म | संदेश स्क्रीन पर रखें, सीधा ईमेल दिखाएं | स्रोत और पेलोड आकार के साथ लीड कैप्चर त्रुटि |
| AI जनरेशन | प्रॉम्प्ट संरक्षित करें, पुनः प्रयास प्रदान करें | प्रदाता, मॉडल, विलंबता और टोकन मेटाडेटा |
| फ़ाइल अपलोड | फ़ाइल सीमा और पुनः प्रयास पथ दिखाएं | स्टोरेज त्रुटि, आकार, MIME प्रकार, org आईडी |
फ़ॉलबैक को फैंसी होने की आवश्यकता नहीं है। इसे गति बनाए रखने की आवश्यकता है।
हर त्रुटि को एक जैसा न बनाएं
सामान्य संदेश उत्पाद को लापरवाह महसूस कराते हैं:
- कुछ गलत हो गया।
- बाद में पुनः प्रयास करें।
- एक अप्रत्याशित त्रुटि हुई।
कभी-कभी ये अंतिम कैच-ऑल के रूप में स्वीकार्य होते हैं, लेकिन ये उत्पाद में एकमात्र त्रुटि भाषा नहीं होनी चाहिए।
अलग-अलग विफलताओं को अलग-अलग पुनर्प्राप्ति पथों की आवश्यकता होती है:
- सत्यापन त्रुटि: सटीक फ़ील्ड और अपेक्षित प्रारूप दिखाएं
- अनुमति त्रुटि: समझाएं कि किस भूमिका या खाते की आवश्यकता है
- दर सीमा: कब पुनः प्रयास करना है या हल्की कार्रवाई प्रदान करना है बताएं
- निर्भरता विफलता: उपयोगकर्ता का काम संरक्षित करें और वैकल्पिक पथ दिखाएं
- विनाशकारी-कार्रवाई विफलता: स्पष्ट रूप से बताएं कि क्या नहीं बदला
लक्ष्य सिस्टम को परिपूर्ण दिखाना नहीं है। लक्ष्य उपयोगकर्ता को उन्मुख महसूस कराना है जब यह परिपूर्ण नहीं है।
ऑपरेटर को एक अलग इंटरफ़ेस की आवश्यकता है
सम्मानजनक उपयोगकर्ता-मुखी कॉपी तभी काम करती है जब ऑपरेटर को अभी भी वास्तविक सबूत मिले।
इसका मतलब है लॉगिंग:
- रूट और कार्रवाई
- अनुरोध आईडी या ट्रेस आईडी
- जब उपलब्ध हो तो उपयोगकर्ता/org आईडी
- प्रदाता और स्थिति कोड
- सुरक्षित पेलोड आकार
- समय
- पुनः प्रयास गणना
इसका मतलब यह भी है कि रहस्य, कच्चे टोकन, भुगतान कार्ड विवरण, निजी दस्तावेज़, या पूर्ण प्रॉम्प्ट लॉग न करें जब उन प्रॉम्प्ट में ग्राहक डेटा हो सकता है।
अच्छा त्रुटि प्रबंधन नरम लॉगिंग नहीं है। यह तेज पृथक्करण है।
वह पैटर्न जिसे मैं शिप करने का प्रयास करता हूं
हर महत्वपूर्ण कार्रवाई के लिए, मैं यह आकार चाहता हूं:
- जल्दी सत्यापित करें और फ़ील्ड-स्तरीय मार्गदर्शन दिखाएं।
- सर्वर कार्रवाई/API रूट को संरचित त्रुटि प्रबंधन में लपेटें।
- एक स्थिर उपयोगकर्ता संदेश और एक स्थिर मशीन कोड लौटाएं।
- पूर्ण ऑपरेटर-सुरक्षित संदर्भ लॉग करें।
- यदि यह रूपांतरण को प्रभावित करता है तो विफलता को उत्पाद घटना के रूप में ट्रैक करें।
- जहां भी संभव हो उपयोगकर्ता इनपुट संरक्षित करें।
यह ग्लैमरस काम नहीं है, लेकिन यह प्रीमियम अनुभव का हिस्सा है। वह साइट जो आपका काम सहेजती है और आपको बताती है कि आगे क्या करना है, उस साइट की तुलना में अधिक भरोसेमंद लगती है जो लाल बॉक्स चमकाती है और आपको फिर से शुरू करने पर मजबूर करती है।
