Astrina के साथ वेबसाइट मॉनिटरिंग कैसे सेट करें

Astrina के साथ वेबसाइट निगरानी कैसे सेट करें

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

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

1. मॉनिटरिंग लक्ष्य और दायरा की पुष्टि करें

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

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

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

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

2. मॉनिटर करने के लिए सही पृष्ठों या उपयोगकर्ता यात्रा का चयन करें

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

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

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

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

3. Astrina के अंदर पहला चेक सेट करें

एक बार जब दायरा स्पष्ट हो जाए, तो एस्ट्रिना में पहला चेक बनाएं और इसे इस तरह नाम दें कि अलर्ट सूची एक नज़र में समझ में आए। “होमपेज - उत्पादन - उपलब्धता” जैसा नाम सीधा है, लेकिन यह काम करता है। “मुख्य पृष्ठ 1” नहीं करता। नामों को आपको तीन बातें बतानी चाहिए: क्या मॉनिटर किया जा रहा है, यह कहाँ चल रहा है, और यह क्यों मौजूद है।

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

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

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

4. अलर्ट की शर्तें और सूचना प्राप्तकर्ताओं को सेट करें

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

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

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

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

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

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

5. एक बुनियादी परीक्षण चलाएँ और पुष्टि करें कि जांच अपेक्षित रूप से व्यवहार करती है

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

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

सरल गलतियों पर ध्यान दें। गलत URL। गलत वातावरण। गलत प्राप्तकर्ता। गलत अलर्ट थ्रेशोल्ड। ये चार गलतियाँ अक्सर लोगों द्वारा स्वीकार की गई तुलना में अधिक होती हैं। एक अच्छा बेसलाइन परीक्षण उन्हें उपयोगकर्ताओं से पहले पकड़ लेता है। यही पूरा मुद्दा है।

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

एक और विवरण: पहले परिणाम का रिकॉर्ड रखें। एक तारीख, एक पृष्ठ का नाम, और स्थिति पर्याप्त है। बाद में, यदि कोई पूछता है कि क्या मॉनिटर पहले दिन से काम कर रहा था, तो आपके पास दिखाने के लिए कुछ ठोस होगा।

6. पर्यावरण या प्राथमिकता के अनुसार निगरानी का आयोजन करें

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

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

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

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

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

लेबल को साधारण रखें। “उत्पादन / महत्वपूर्ण,” “स्टेजिंग / परीक्षण,” और “उत्पादन / कम प्राथमिकता” अधिकांश टीमों के लिए पर्याप्त हैं। फैंसी लेबल अक्सर खराब हो जाते हैं।

7. समय के साथ निगरानी सेटअप की समीक्षा और रखरखाव करें

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

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

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

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

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

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