कैसे वेबसाइट निगरानी को मैनुअल जांच से स्वचालित अलर्ट में स्थानांतरित करें

अपनी वर्तमान मैनुअल चेक रूटीन का ऑडिट करें

उबाऊ हिस्से से शुरू करें। हर मैनुअल चेक की सूची बनाएं जो आप अब करते हैं, यहां तक कि छोटे चेक जो कोई “सिर्फ मामले में” सोमवार को 9:00 बजे करता है, क्योंकि ये आदतें स्वचालन की ओर बढ़ने को किसी भी उपकरण के प्रदर्शन से अधिक आकार देती हैं।

हर चेक के लिए चार बातें लिखें: क्या जांचा जाता है, यह कितनी बार होता है, कौन करता है, और पिछली बार जब यह विफल हुआ तो क्या हुआ। यदि कोई चेकआउट फॉर्म 3 घंटे तक टूटा रहा जब तक किसी ने ध्यान नहीं दिया, तो यह सूची में होना चाहिए। उसी तरह वह घटना भी जो 22:15 पर एक ग्राहक ईमेल द्वारा पाई गई थी।

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

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

यह परिभाषित करें कि “अलर्ट की आवश्यकता है” बनाम “लॉग की आवश्यकता है”

हर समस्या को एक पिंग की आवश्यकता नहीं होती। एक फ़ुटर में टाइपो, 02:00 पर एक छोटी सी धीमी गति, या एक बार की CMS चेतावनी एक लॉग या डैशबोर्ड में हो सकती है, न कि एक फोन नोटिफिकेशन में जो किसी को जगाए।

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

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

यदि आप पहले से ही एक वेबसाइट एनालिटिक्स और मॉनिटरिंग प्लेटफॉर्म, यह विभाजन आसान हो जाता है क्योंकि रिपोर्टिंग और अलर्टिंग अलग-अलग लेन में रह सकती हैं। यदि आप ऐसा नहीं करते हैं, तो कुछ बनाने से पहले कागज पर विभाजन करें।

स्वचालित करने के लिए पहले निगरानी संकेतों का चयन करें

पहले दिन सब कुछ स्वचालित न करें। 3 से 5 संकेत चुनें जो परिभाषित करने में आसान और विवादित करने में कठिन हैं। अपटाइम आमतौर पर पहले होता है। SSL समाप्ति अक्सर दूसरा होता है। प्रतिक्रिया समय, टूटे हुए पृष्ठ, और फ़ॉर्म त्रुटियाँ यदि आपका स्टैक उनका समर्थन करता है तो उसके बाद आते हैं।

इनका पहले होना एक कारण है। ये दोहराने योग्य हैं। एक होमपेज या तो प्रतिक्रिया करता है या नहीं। एक प्रमाणपत्र या तो 2026-04-12 को समाप्त होता है या नहीं। एक फ़ॉर्म या तो एक सफलता संदेश लौटाता है या एक त्रुटि फेंकता है। इस प्रकार का संकेत 'साइट धीमी लग रही थी' से अधिक स्पष्ट है।

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

पहले सेट को छोटा रखें। पांच सिग्नल जो अच्छे से किए गए हैं, 20 सिग्नल से बेहतर हैं जिन पर कोई भरोसा नहीं करता।

शोर को कम करने के लिए अलर्ट नियम सेट करें

शोर तेजी से अपनाने को मारता है। यदि टीम को एक हानिरहित डिप्लॉय के लिए 17 अलर्ट मिलते हैं, तो वे शुक्रवार तक सिस्टम को म्यूट कर देंगे। यह एक तकनीकी विफलता नहीं है। यह एक विश्वास विफलता है।

संख्याओं के साथ थ्रेशोल्ड सेट करें, न कि भावना के साथ। SSL समाप्ति के लिए एक विफल जांच पर्याप्त हो सकती है। प्रतिक्रिया समय के लिए, आपको सूचित करने से पहले 3 लगातार धीमे नमूनों की आवश्यकता हो सकती है। अपटाइम के लिए, एक 2-मिनट की आउटेज बिक्री साइट पर महत्वपूर्ण हो सकती है, जबकि 10-सेकंड का ब्लिप नहीं हो सकता। उन सीमाओं को लिखें।

अलर्ट की आवृत्ति भी तय करें। एक घटना के लिए एकल अलर्ट हर मिनट एक संदेश की तुलना में संभालना आसान है। वृद्धि लॉजिक भी महत्वपूर्ण है: पहले ऑन-कॉल व्यक्ति को, फिर 10 मिनट बाद एक बैकअप को, फिर केवल एक प्रबंधक को यदि समस्या अनसुलझी रहती है। रखरखाव विंडो को अपेक्षित शोर को दबाना चाहिए, वास्तविक विफलताओं को नहीं।

झूठे सकारात्मक आमतौर पर दो स्थानों से आते हैं: थ्रेशोल्ड जो बहुत तंग होते हैं और जांच जो बहुत बार चलती हैं। यदि एक पृष्ठ 03:00 बजे एक बार टाइमआउट होता है और तुरंत ठीक हो जाता है, तो इसे एक लॉग प्रविष्टि की आवश्यकता हो सकती है, न कि एक सायरन।

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

पूर्ण रूप से स्विच करने से पहले एक समानांतर रन बनाएं

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

यह चरण परेशान करने वाला हो सकता है। अच्छा। परेशान होना एक टूटे हुए चेकआउट पृष्ठ के कारण एक दिन के ट्रैफ़िक को खोने से सस्ता है। यदि मैनुअल चेक 11:30 पर एक फॉर्म त्रुटि पाता है और अलर्ट 11:18 पर वही त्रुटि पाता है, तो यह एक जीत है। यदि उल्टा होता है, तो आपने कुछ सीखा।

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

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

स्वामित्व और प्रतिक्रिया कदम सौंपें

प्रतिक्रिया के कदमों को संक्षिप्त रखें। “एडमिन लॉग की जांच करें, त्रुटि पृष्ठ की पुष्टि करें, यदि अंतिम डिप्लॉय ने इसे कारण बनाया है तो रोल बैक करें” एक पृष्ठ के सिद्धांत से अधिक उपयोगी है। लोगों को 02:00 बजे एक घोषणापत्र की आवश्यकता नहीं है। उन्हें अगले 3 कार्यों की आवश्यकता है।

प्रतिक्रिया के चरणों को संक्षिप्त रखें। “एडमिन लॉग की जांच करें, त्रुटि पृष्ठ की पुष्टि करें, यदि अंतिम डिप्लॉय ने इसे कारण बनाया है तो वापस रोल करें” एक पृष्ठ के सिद्धांत से अधिक उपयोगी है। लोगों को 02:00 बजे एक घोषणापत्र की आवश्यकता नहीं है। उन्हें अगले 3 क्रियाओं की आवश्यकता है।

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

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

हाथ से जांच को धीरे-धीरे समाप्त करें

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

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

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

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

लॉन्च के बाद सिस्टम की समीक्षा और ट्यून करें

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

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

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

प्लेबुक को भी अपडेट करें। एक नया भुगतान प्रदाता, एक नया CMS प्लगइन, या एक redesigned चेकआउट एक सप्ताह में जोखिम मानचित्र को बदल सकता है। यदि टीम अब 15 मिनट के भीतर एक अलर्ट की जांच नहीं करती है, तो यह एक प्रक्रिया मुद्दा है, केवल एक निगरानी मुद्दा नहीं।

एक व्यावहारिक नोट: यदि आप पहले से ही लॉन्च के बाद वेबसाइट समर्थन, अलर्ट समीक्षाओं को उस दिनचर्या में शामिल करें बजाय हर छोटे सुधार के लिए एक अलग बैठक बनाने के। 4 ठोस घटनाओं के साथ एक मासिक समीक्षा चार ढीले बातचीतों और बिना निर्णयों से बेहतर है।

अंतिम मैनुअल जांचें केवल वहीं रखें जहां वे अभी भी प्रमाण जोड़ती हैं। बाकी को अपनी जगह कमानी चाहिए।