हममें से अधिकांश नियमित रूप से उन साइटों की तकनीकी पहुंच के मुद्दे का सामना करते हैं, जिन्हें हम रोजाना देखते हैं। हालांकि ऐसा लगता है कि विश्वसनीय एक्सेस चैनल और उच्च गति संचार ने लंबे समय से इस समस्या को हल किया है, मोबाइल उपकरणों के उद्भव, क्लाउड बुनियादी ढांचे और क्षेत्रों में इंटरनेट का प्रसार अभी भी हमें आश्चर्यचकित करता है कि यह साइट मेरे लिए (या मेरे उपयोगकर्ताओं के लिए) क्यों नहीं खुलती है? क्या यह गलत तरीके से काम करता है? और मेरी साइट मेरे उपयोगकर्ताओं के लिए (और आम तौर पर कैसी दिखती है) कैसे खुलती है?
इन सवालों का जवाब कैसे दें?
वेबसाइट तकनीकी उपलब्धता
मैं थोड़ी दूर से शुरू करूँगा। नेटवर्क के केवल एक बिंदु (एक इंटरनेट कनेक्शन का उपयोग करके) में स्थित होने के नाते, हम मज़बूती से यह नहीं कह सकते हैं कि जिस वेबसाइट पर हम जा रहे हैं, वह काम कर रही है अगर वह हमारे साथ नहीं खुलती है। उदाहरण के लिए, कई समस्याएं हो सकती हैं:
- हमारे नेटवर्क खंड और "मुख्य नेटवर्क" की दुर्गमता (कम डेटा विनिमय दर)। यह स्पष्ट रूप से ध्यान देने योग्य है जब आप अपने मोबाइल मेट्रो से एक वेबसाइट पर जाते हैं: आप केवल विश्वसनीय सिग्नल रिसेप्शन के क्षेत्र में खुलने का इंतजार कर सकते हैं, यदि सिग्नल कमजोर है, तो साइट अनुपलब्ध है।
- पिछली समस्या का एक और अधिक खतरनाक संशोधन है जब प्रॉक्सी सर्वर सेटिंग्स (DDoS, क्लाउड, नेटवर्क इन्फ्रास्ट्रक्चर से सुरक्षा) उपयोगकर्ताओं से शुरुआती अनुरोधों को बदल देती है, जिससे साइट का गलत कामकाज होता है। सबसे हानिरहित उदाहरण: उपयोगकर्ताओं के आधे के लिए साइट www को बिना रीडायरेक्ट के खोलती है, बाकी के लिए - एक रीडायरेक्ट के साथ।
- साइट की कम गति (या संचार चैनल जिससे सर्वर जुड़ा हुआ है)। इस मामले में, कई उपयोगकर्ताओं के लिए (जिनके पास फिर से एक धीमा चैनल या नेटवर्क का अस्थिर कनेक्शन है), साइट बहुत लंबे समय तक खुलेगी या बिल्कुल भी नहीं खुलेगी। इस स्थिति में, साइट एक्सेसिबिलिटी की वास्तविक समस्याएं उपयोगकर्ता की एक्सेसिबिलिटी समस्याओं से सुपरइम्पोज़ होती हैं।
- एक काफी नई (Runet के लिए) समस्या तब है, जब धीमी या अस्थिर कनेक्शन (पढ़ें मोबाइल या सार्वजनिक वाईफाई) पर बड़ी संख्या में ऑब्जेक्ट्स / पृष्ठ आकार के कारण, उपयोगकर्ता के पास ब्राउज़र में लोड / प्रदर्शन के लिए पृष्ठों का इंतजार करने का समय नहीं होता है।
दृश्यों के पीछे अभी भी साइट की कार्यात्मक पहुंच के प्रश्न हैं: जब, सामान्य रूप से, साइट काम कर रही होती है, लेकिन कुछ कारणों से कई उपयोगकर्ताओं के लिए साइट की पर्याप्त (कार्यक्षमता) कार्यक्षमता काम नहीं करती है। उदाहरण के लिए, नए ग्राहकों को पंजीकृत करते समय कैप्चा की जाँच करें।
एक्सेसिबिलिटी मुद्दों का पता लगाएं
दुर्भाग्य से, साइट (कार्यालय में) का विकास या समर्थन टीम स्वतंत्र रूप से वर्णित समस्याओं के केवल एक छोटे से हिस्से को ट्रैक कर सकती है, अर्थात्: मुख्य अनुरोधों के लिए सर्वर के प्रतिक्रिया समय को मापें और इस सूचक को अनुकूलित करें; सर्वर साइट त्रुटियों को खत्म करना; साइट के पृष्ठों के कुल उद्घाटन समय का निदान करें और क्लाइंट एक्सेसिबिलिटी की प्रमुख समस्याओं को समाप्त करें।
लेकिन आंतरिक टीम बाहर नेटवर्क की कनेक्टिविटी और गति से जुड़ी तकनीकी पहुंच की समस्याओं को ट्रैक करने में सक्षम नहीं होगी। नहीं, आप निश्चित रूप से, प्रत्येक कर्मचारी को घर से साइट की जांच करने के लिए कह सकते हैं, लेकिन यह हमेशा वास्तविक से दूर है और एक सामान्य समाधान नहीं हो सकता है।
वितरित नेटवर्क कनेक्टिविटी
और फिर से मैं विषय से थोड़ा दूर जाऊंगा। यदि हमारे पास रूस या दुनिया के विभिन्न हिस्सों / क्षेत्रों के उपयोगकर्ता हैं, तो हम यह सुनिश्चित नहीं कर सकते हैं कि हमारी साइट उनके लिए सुलभ है या नहीं (केवल अगर हम शारीरिक रूप से उनके बगल में नहीं बैठे हैं)। भौगोलिक पहुंच की समस्याओं की जांच करने के लिए, हमें बिंदुओं (सर्वर) के नेटवर्क की आवश्यकता होती है, जो स्वयं उपलब्ध होंगे (एक दूसरे को देखेंगे) - एक जुड़ा नेटवर्क। केवल इस मामले में, हमारे उपयोगकर्ताओं के लिए "अगला" चेकपॉइंट लगाते हैं और यह सुनिश्चित करते हैं कि बिंदु में खुद को कोई तकनीकी पहुंच समस्या नहीं है (यह अन्य बिंदुओं को देखता है, और इसमें नेटवर्क की पर्याप्त कनेक्शन गति है), हम दृढ़ता से कह सकते हैं: "हां, साइट निर्दिष्ट उपयोगकर्ताओं के लिए उपलब्ध "या" नहीं, इन उपयोगकर्ताओं के लिए साइट उपलब्ध नहीं है। "
उदाहरण: हमारे पास मॉस्को, सेंट पीटर्सबर्ग, येकातेरिनबर्ग और कज़ान से एक बैंक ऑडियंस है। यह स्पष्ट है कि बैंक की साइट हमारे दर्शकों के लिए सुलभ है (और साइट को निर्दिष्ट दर्शकों के लिए कोई समस्या नहीं है) हम केवल इन शहरों से साइट की जांच कर सकते हैं। और यही कारण है कि चौकियों को लगातार "वेब पर" होना चाहिए, अन्यथा हम उनके डेटा पर भरोसा करने में सक्षम नहीं होंगे: यदि मॉस्को और कज़ान के बीच का चैनल "गिर" जाता है, तो सभी बाहरी संसाधन कज़ान के लिए दुर्गम हो जाएंगे। और यह जानकारी कि हमारी साइट उनके लिए अनुपलब्ध हो जाएगी, मूल्यवान नहीं होगी: सुलभता के साथ समस्याएं हैं, लेकिन हम उन्हें हल नहीं कर सकते हैं, और समस्याएं प्रकृति में वैश्विक हैं।
लेकिन अगर कभी-कभी, जब संचार चैनल के साथ सब कुछ ठीक होता है, तो हमारी साइट कज़ान निवासियों के लिए दुर्गम हो जाती है - यह एक अवसर है सोचने के लिए और प्रदान की गई सेवाओं की गुणवत्ता में सुधार के लिए एक समस्या की तलाश शुरू करना।
वितरित निगरानी
बताए गए मुद्दों पर लौट रहे हैं। यह पता लगाने के लिए कि साइट मेरे (वितरित, मोबाइल, क्षेत्रीय) उपयोगकर्ताओं के लिए कैसे खुलती या दिखती है, वितरित निगरानी बिंदुओं के एक नेटवर्क का उपयोग करना आवश्यक है जो लक्षित दर्शकों के लिए जितना संभव हो उतना करीब होगा। यदि रूस के विभिन्न क्षेत्रों के लिए स्थिति कम या ज्यादा स्पष्ट है: हम सिर्फ सही शहरों से साइट की उपलब्धता की जांच करते हैं, तो मोबाइल उपयोगकर्ताओं के लिए शहर में अलग-अलग बिंदुओं से नेटवर्क के कवरेज (गति) की जांच करना दिलचस्प है - और खुशी से अभिगम समस्याओं का पता लगाएं - हालांकि यह केवल मोबाइल ऑपरेटरों के लिए प्रासंगिक है नेटवर्क और 3/4 / 5G।
इस मामले में, क्षेत्रीय उपलब्धता की जांच करने के मामले में, यह सुनिश्चित करना महत्वपूर्ण है कि सत्यापन बिंदु स्वयं सुलभ हैं, कि सत्यापन बिंदुओं के नेटवर्क में कनेक्टिविटी टूटी नहीं है।
सेवाओं की निगरानी करना
RuNet में, रूस के कई शहरों से साइट सत्यापन की पेशकश करने वाली कुछ सेवाएं हैं (यानी, वितरित भौगोलिक निगरानी):
- मेजबान ट्रैकर , रूस में 4 अंक (मास्को - 2, सेंट पीटर्सबर्ग - 2), उपलब्धता की जांच।
- पिंग एडमिन , रूस में 20 अंक (मास्को - 7, सेंट पीटर्सबर्ग - 2, निज़नी नोवगोरोड, व्लादिवोस्तोक, नोवोसिबिर्स्क, आदि), उपलब्धता जांच (कई एल्गोरिदम)
- WEBO पल्सर , रूस में 11 अंक (मास्को - 4, सेंट पीटर्सबर्ग - 2, येकातेरिनबर्ग, नोवोसिबिर्स्क, खाबरोवस्क, समारा, क्रास्नोडार, उन सभी बिंदुओं का परीक्षण करें ), एक्सेस करने की क्षमता, गति, शुरुआती पृष्ठों का समय (कई एल्गोरिदम) देखें।