मीन टाइम टू इनोसेंस: यह कैसे साबित करें कि समस्या WiFi की नहीं है

ब्रिटिश अंग्रेजी में एक आत्मविश्वासी, आधिकारिक और संवादात्मक लहजे में बोलें - जैसे कोई वरिष्ठ नेटवर्क सलाहकार कॉफी पर किसी क्लाइंट को जानकारी दे रहा हो। मापी गई गति, स्पष्ट उच्चारण, कभी-कभार सूखा हास्य। कोई व्याख्यान नहीं। कोई सेल्स पिच नहीं। बस उस व्यक्ति की सीधी बात जिसने इस समस्या को सैकड़ों बार देखा है: Purple तकनीकी संक्षिप्त विवरण (technical brief) में आपका स्वागत है। आज मैं आपसे एक ऐसी चीज़ के बारे में बात करने जा रहा हूँ जिसे हर नेटवर्क मैनेजर अच्छी तरह जानता है, भले ही उन्होंने इसके लिए कभी औपचारिक शब्द न सुना हो। मीन टाइम टू इनोसेंस (Mean time to innocence)। या MTTI। [छोटा ठहराव] वह समय जो आप यह साबित करने में बिताते हैं कि यह आपकी गलती नहीं है। यहाँ एक परिदृश्य है। सुबह के नौ बजे हैं। एक BTR ब्लॉक में रहने वाले लोग फ्रंट डेस्क पर कॉल करने लगते हैं। WiFi खराब है। प्रॉपर्टी मैनेजर प्रबंधित WiFi प्रदाता को कॉल करता है। प्रबंधित WiFi प्रदाता ISP को कॉल करता है। ISP कहता है कि राउटर की जांच करें। राउटर टीम कहती है कि एक्सेस पॉइंट्स की जांच करें। एक्सेस पॉइंट वेंडर कहता है कि क्लाइंट डिवाइसेस की जांच करें। और इस सब के बीच, पैंतालीस मिनट बीत चुके हैं, और वास्तव में किसी ने कुछ भी ठीक नहीं किया है। यही है मीन टाइम टू इनोसेंस। [छोटा ठहराव] और यह आपको आपकी सोच से कहीं अधिक नुकसान पहुँचा रहा है। मुझे इसे ठीक से परिभाषित करने दें। मीन टाइम टू इनोसेंस वह औसत समय है जो किसी समस्या का पता चलने और किसी भी टीम द्वारा सबूत के साथ यह प्रदर्शित करने के बीच बीतता है कि उनका डोमेन मूल कारण नहीं है। यह मीन टाइम टू आइडेंटिफाई के समान नहीं है, जो वास्तविक मूल कारण खोजने के लिए संगठन-व्यापी मीट्रिक है। MTTI अलग है। यह व्यक्तिगत है। यह नेटवर्क टीम का यह कहना है कि, 'यहाँ डेटा है, यह हमारी गलती नहीं है, अब कहीं और देखें।' समस्या यह है कि सही टूल के बिना, उस सबूत को जुटाने में समय लगता है। और MTTI का हर एक मिनट सीधे आपके मीन टाइम टू रेजोल्यूशन, यानी आपके MTTR में जुड़ जाता है। ये दोनों अविभाज्य हैं। तो WiFi को हमेशा सबसे पहले क्यों दोषी ठहराया जाता है? [छोटा ठहराव] तीन कारण हैं। पहला, WiFi दिखाई देता है। जब कुछ खराब होता है, तो लोग उस चीज़ को देखते हैं जिसे वे देख सकते हैं, और उनके फोन पर WiFi सिग्नल बार कनेक्टिविटी का सबसे दृश्यमान संकेतक होते हैं। दूसरा, WiFi डिवाइस से पहले का आखिरी हॉप है, इसलिए जब कोई डिवाइस इंटरनेट तक नहीं पहुँच पाता है तो यह सबसे पहले संदिग्ध लगता है। तीसरा, और यह थोड़ा असहज करने वाला है, WiFi टीमें अक्सर अपनी बेगुनाही जल्दी साबित नहीं कर पाती हैं क्योंकि उनके पास सही टेलीमेट्री की कमी होती है। यदि आप दो मिनट से कम समय में वायरलेस लेयर की सही स्थिति नहीं दिखा सकते हैं, तो आप अगला एक घंटा अपना बचाव करने में बिताने वाले हैं। अब, एक सिंगल-टेनेंट एंटरप्राइज वातावरण में, यह कष्टप्रद है। एक मल्टी-टेनेंट वातावरण में, यह वास्तव में नुकसानदेह है। Premier Inn जैसे होटल, या एक BTR आवासीय ब्लॉक, या लगातार इवेंट्स आयोजित करने वाले कॉन्फ्रेंस सेंटर के बारे में सोचें। आपके पास एक प्रॉपर्टी मैनेजर है जिसके पास नेटवर्क का स्वामित्व नहीं है। आपके पास ऐसे निवासी या मेहमान हैं जो नेटवर्क को नहीं समझते हैं। और आपके पास एक प्रबंधित WiFi प्रदाता है जो वायरलेस लेयर के लिए जिम्मेदार है लेकिन ISP सर्किट, इन-बिल्डिंग केबलिंग और क्लाइंट डिवाइसेस के लिए नहीं। जब कुछ खराब होता है, तो प्रॉपर्टी मैनेजर WiFi प्रदाता को दोषी ठहराता है क्योंकि वे उसी अनुबंध की ओर इशारा कर सकते हैं। निवासी बिल्डिंग को दोषी ठहराता है क्योंकि वे उन्हें किराया देते हैं। और WiFi प्रदाता को नेटवर्क को तेजी से दोषमुक्त करना होगा, अन्यथा संबंध खराब हो जाते हैं। [छोटा ठहराव] इस संदर्भ में MTTI केवल एक तकनीकी मीट्रिक नहीं है। यह एक व्यावसायिक मीट्रिक है। तो चलिए उस कार्यप्रणाली के बारे में बात करते हैं जो वास्तव में इसे कम करती है। इसके पांच स्तर हैं, और आपको इन पांचों की आवश्यकता है। पहला स्तर: निरंतर सिंथेटिक चेक (continuous synthetic checks)। कोई भी टिकट उठाए जाने से पहले, आपके पास नेटवर्क से ही चलने वाले स्वचालित प्रोब होने चाहिए, जो DNS रेजोल्यूशन, HTTP रीचेबिलिटी, ज्ञात एंडपॉइंट्स पर लेटेंसी और ऑथेंटिकेशन फ्लो का परीक्षण करते हों। Juniper Mist के Marvis जैसे टूल, या ThousandEyes जैसे प्लेटफॉर्म में निर्मित सिंथेटिक परीक्षण, हर कुछ मिनटों में ये जांच चलाते हैं। जब कोई घटना होती है, तो आप एक ग्राफ देख सकते हैं और ठीक-ठीक दिखा सकते हैं कि WiFi लेयर का आखिरी बार कब सफल सिंथेटिक चेक हुआ था, और शिकायत के समय यह सही था या खराब था। केवल यही MTTI को नाटकीय रूप से कम कर देता है, क्योंकि आप या तो पुष्टि करते हैं कि WiFi ठीक था, या आप पुष्टि करते हैं कि यह ठीक नहीं था, और आप इस पर बहस करना बंद कर देते हैं। दूसरा स्तर: हॉप-बाय-हॉप पाथ विजिबिलिटी (hop-by-hop path visibility)। यहीं पर अधिकांश टीमें मात खा जाती हैं। आप साबित कर सकते हैं कि एक्सेस पॉइंट ठीक है। आप साबित कर सकते हैं कि स्विच ठीक है। लेकिन क्या आप साबित कर सकते हैं कि स्विच से ISP हैंडऑफ तक का रास्ता ठीक है? एक मल्टी-टेनेंट बिल्डिंग में, अक्सर ऐसे हॉप्स होते हैं जिनके आप मालिक नहीं होते हैं। इन-बिल्डिंग डिस्ट्रीब्यूशन नेटवर्क, मकान मालिक का कोर स्विच, ISP का डिमार्केशन पॉइंट। आपको पाथ ट्रेस डेटा की आवश्यकता है जो उन सीमाओं को पार करे। केवल 8.8.8.8 पर पिंग करना ही काफी नहीं है। वास्तविक ट्रेसरूट-शैली की दृश्यता जो आपको हर हॉप, उसकी लेटेंसी और क्या वह पैकेट ड्रॉप कर रहा है, दिखाती है। जब आप दिखा सकते हैं कि हॉप एक से चार तक साफ हैं और हॉप पांच, जो कि ISP का एज राउटर है, चालीस प्रतिशत पैकेट लॉस दिखा रहा है, तो बातचीत तुरंत बदल जाती है। तीसरा स्तर: ऑन-डिमांड पैकेट कैप्चर के साथ फ्लो डेटा। NetFlow और IPFIX आपको नेटवर्क पर क्या किससे बात कर रहा है, इसका बातचीत-स्तर का दृश्य देते हैं। जब कोई निवासी कहता है कि स्ट्रीमिंग सेवा खराब है, तो फ्लो डेटा आपको बताता है कि उस सेवा के IP रेंज का ट्रैफ़िक नेटवर्क से बाहर जा भी रहा है या नहीं। यदि यह नेटवर्क से साफ बाहर जा रहा है और समस्या डाउनस्ट्रीम है, तो यही आपका सबूत है। यदि यह नेटवर्क से बिल्कुल बाहर नहीं जा रहा है, तो आप जानते हैं कि कहाँ देखना है। ऑन-डिमांड पैकेट कैप्चर, जो Cisco Meraki और HPE Aruba जैसे प्लेटफॉर्म पर उपलब्ध है, आपको हार्डवेयर को छुए बिना किसी विशिष्ट क्लाइंट या VLAN के लिए लक्षित कैप्चर करने की अनुमति देता है। यह आपका फोरेंसिक स्तर है। आप इसका उपयोग कम ही करते हैं, लेकिन जब आपको इसकी आवश्यकता होती, तो यह निर्णायक होता है। चौथा स्तर: टोपोलॉजी और डिपेंडेंसी मैपिंग। एक मल्टी-टेनेंट वातावरण में, आपको एक लाइव मैप की आवश्यकता होती है जो दिखाता है कि कौन से एक्सेस पॉइंट्स किन टेनेंट्स को सेवा देते हैं, वे APs किन स्विचों से जुड़ते हैं, वे स्विच किन अपलिंक्स का उपयोग करते हैं, और कौन सा ISP सर्किट प्रत्येक अपलिंक को सेवा प्रदान करता है। जब कोई घटना होती, तो आप तुरंत ब्लास्ट रेडियस की पहचान कर सकते हैं। क्या यह एक टेनेंट को प्रभावित कर रहा है या सभी टेनेंट्स को? एक मंजिल को या पूरी इमारत को? एक VLAN को या सभी VLANs को? टोपोलॉजी मैप से तीस सेकंड में मिलने वाला यह उत्तर आपको बताता है कि समस्या WiFi लेयर में है, बिल्डिंग नेटवर्क में है, या WAN में है। यह आपको यह भी बताता है कि किसे शामिल करना है, और किसे आप तुरंत बाहर कर सकते हैं। पांचवां स्तर: इवेंट कोरिलेशन (event correlation)। यह वह है जो सब कुछ एक साथ जोड़ता है। चेंज लॉग, ISP रखरखाव अलर्ट, डिवाइस फ़र्मवेयर अपडेट, पावर इवेंट और उपयोगकर्ता की शिकायतें सभी को एक ही टाइमलाइन पर होना चाहिए। जब आप क्लाइंट एसोसिएशन विफलताओं में वृद्धि को बारह मिनट पहले किए गए फ़र्मवेयर पुश के साथ मिलाकर देखते हैं, तो आपको अपना मूल कारण मिल जाता है। जब आप लेटेंसी स्पाइक को एक ISP रखरखाव विंडो के साथ मिलाकर देखते हैं जिसकी जानकारी आपको नहीं दी गई थी, तो आपके पास मामले को आगे बढ़ाने के लिए सबूत होते हैं। इवेंट कोरिलेशन कोई आकर्षक काम नहीं है, लेकिन यह पैंतालीस मिनट के दोषारोपण के खेल और चार मिनट की बेगुनाही साबित करने के बीच का अंतर है। अब, सांस्कृतिक पहलू पर एक बात, क्योंकि यहीं पर बहुत सी टीमें गलती करती हैं। MTTI को कम करने का लक्ष्य दोषारोपण के खेल को तेजी से जीतना नहीं है। इसका उद्देश्य दोषारोपण के खेल को पूरी तरह से समाप्त करना है। [छोटा ठहराव] साझा साक्ष्य स्थिति को बदल देते हैं। जब WiFi प्रदाता प्रॉपर्टी मैनेजर को एक डैशबोर्ड का लिंक भेज सकता है जो वायरलेस लेयर पर हरा, इन-बिल्डिंग स्विच पर पीला और ISP सर्किट पर लाल दिखाता है, तो बातचीत विरोधाभासी नहीं रह जाती। यह सहयोगात्मक बन जाती है। प्रॉपर्टी मैनेजर ISP को कॉल करता है। ISP सर्किट को ठीक करता है। निवासियों को कनेक्टिविटी वापस मिल जाती है। और WiFi प्रदाता के अनुबंध का नवीनीकरण किया जाता है क्योंकि वे ही थे जिन्होंने समस्या का पता लगाया था। ऑब्जर्वेबिलिटी टूलिंग में निवेश करने का यही व्यावसायिक मामला है। न केवल तेज़ समस्या निवारण, बल्कि उन लोगों के साथ बेहतर संबंध जो आपको भुगतान करते हैं। इसे स्पष्ट करने के लिए मैं आपको कुछ त्वरित परिदृश्यों के माध्यम से समझाता हूँ। परिदृश्य एक: एक 350 कमरों वाला होटल। Premier Inn-शैली की प्रॉपर्टी में मेहमान रिपोर्ट करने लगते हैं कि कमरों का WiFi धीमा है। फ्रंट डेस्क प्रबंधित WiFi प्रदाता के पास एक टिकट दर्ज करता है। सिंथेटिक चेक चलने के कारण, प्रदाता देख सकता है कि सुबह सात बजकर तैंतालीस मिनट पर DNS रेजोल्यूशन का समय बारह मिलीसेकंड से बढ़कर चार सौ मिलीसेकंड हो गया। WiFi लेयर ठीक है। पाथ ट्रेस दिखाता है कि लेटेंसी तीसरे हॉप पर उत्पन्न हुई है, जो कि ISP का एग्रीगेशन राउटर है। प्रदाता होटल मैनेजर को लाल रंग में हाइलाइट किए गए खराब हॉप के साथ पाथ ट्रेस का स्क्रीनशॉट भेजता है, साथ ही सिंथेटिक चेक ग्राफ भी भेजता है जो दिखाता है कि WiFi लेयर पूरी तरह से साफ थी। ISP को कॉल किया जाता है। ISP अपनी तरफ से राउटिंग समस्या की पुष्टि करता है। शिकायत से लेकर WiFi लेयर के दोषमुक्त होने तक का कुल समय: छह मिनट। पूरी घटना के लिए MTTR: बाईस मिनट, क्योंकि ISP को ठीक करने में सोलह मिनट लगे। ऑब्जर्वेबिलिटी टूलिंग के बिना, वह छह मिनट का दोषमुक्त होना चालीस मिनट की बहसबाजी में बदल जाता, और MTTR एक घंटे से अधिक होता। परिदृश्य दो: एक रिटेल चेन। दो सौ स्टोरों में WiFi वाला एक राष्ट्रीय रिटेलर देखता है कि एक क्षेत्र में पॉइंट-ऑफ-सेल टर्मिनल भुगतान प्रोसेसर से रुक-रुक कर कनेक्टिविटी खो रहे हैं। नेटवर्क टीम को तुरंत दोषी ठहराया जाता है। फ्लो डेटा दिखाता है कि भुगतान प्रोसेसर के IP रेंज का ट्रैफ़िक स्टोर नेटवर्क से साफ बाहर जा रहा है। समस्या नेटवर्क की नहीं है। भुगतान प्रोसेसर VLAN पर पैकेट कैप्चर से पता चलता है कि TCP रीट्रांसमिशन बढ़ रहा है, जो भुगतान प्रोसेसर पर सर्वर-साइड समस्या की ओर इशारा करता है। नेटवर्क टीम भुगतान प्रोसेसर की सहायता टीम के साथ फ्लो डेटा और कैप्चर सारांश साझा करती है। भुगतान प्रोसेसर अपनी तरफ से एक गलत कॉन्फ़िगर किए गए लोड बैलेंसर की पहचान करता है। नेटवर्क टीम का MTTI: आठ मिनट। भुगतान प्रोसेसर का ठीक करने का समय: पैंतीस मिनट। फ्लो डेटा के बिना, नेटवर्क टीम ने वे पैंतीस मिनट उन VLANs को फिर से कॉन्फ़िगर करने और स्विचों को रीबूट करने में बिताए होते जो पूरी तरह से काम कर रहे थे। ठीक है। मुझे इस विषय पर मुझसे पूछे जाने वाले मुख्य प्रश्नों का त्वरित संस्करण देने दें। क्या यह WiFi है या डिवाइस? स्वयं AP से एक सिंथेटिक चेक चलाएं। यदि AP इंटरनेट तक साफ पहुँच सकता है और डिवाइस नहीं पहुँच सकता, तो यह डिवाइस की समस्या है। यदि AP इंटरनेट तक नहीं पहुँच सकता, तो यह डिवाइस के अपस्ट्रीम की समस्या है। क्या यह WiFi है या ISP? इंटरनेट के लिए पाथ ट्रेस करें। यदि लेटेंसी या पैकेट लॉस आपके नेटवर्क की सीमा के बाहर किसी हॉप पर उत्पन्न होता है, तो यह ISP की समस्या है। MTTI और मीन टाइम टू आइडेंटिफाई के बीच क्या अंतर है? MTTI आपकी टीम द्वारा बेगुनाही साबित करने का समय है। मीन टाइम टू आइडेंटिफाई संगठन द्वारा वास्तविक दोषी का पता लगाने का समय है। MTTI मीन टाइम टू आइडेंटिफाई का एक उपसमुच्चय है। नए टूल खरीदे बिना मैं MTTI को कैसे कम करूँ? आपके पास जो है उसी से शुरुआत करें। Cisco Meraki, HPE Aruba और Juniper Mist सहित अधिकांश एंटरप्राइज एक्सेस पॉइंट प्लेटफॉर्म में सिंथेटिक परीक्षण और क्लाइंट डायग्नोस्टिक्स अंतर्निहित होते हैं। उनका उपयोग करें। अपनी टोपोलॉजी का दस्तावेजीकरण करें। एक साझा डैशबोर्ड बनाएं जिसे प्रॉपर्टी मैनेजर या ऑपरेशंस टीम देख सके। पारदर्शिता उपलब्ध सबसे सस्ता MTTI कमी उपकरण है। समापन के लिए। मीन टाइम टू इनोसेंस हर नेटवर्क घटना पर छिपा हुआ कर (hidden tax) है। मल्टी-टेनेंट वातावरण में, जहाँ जवाबदेही प्रदाताओं, मकान मालिकों और ISPs के बीच विभाजित होती है, यह वह मीट्रिक है जो यह तय करता है कि आप अनुबंधों को बनाए रखते हैं या उन्हें खो देते हैं। इसे कम करने की कार्यप्रणाली जटिल नहीं है: सिंथेटिक चेक, पाथ विजिबिलिटी, फ्लो डेटा, टोपोलॉजी मैपिंग और इवेंट कोरिलेशन। इसका लक्ष्य दोषारोपण का खेल जीतना नहीं है। इसका उद्देश्य दोषारोपण के खेल को साझा साक्ष्यों से बदलना है, ताकि प्रत्येक टीम अपने क्षेत्र का बचाव करने के बजाय समस्या को ठीक करने पर ध्यान केंद्रित कर सके। [छोटा ठहराव] क्योंकि बेगुनाही साबित करने में बिताया गया हर एक मिनट आपके निवासियों, मेहमानों या खरीदारों द्वारा बिना कनेक्टिविटी के बिताए जाने वाले समय में जुड़ जाता है। और यही वह संख्या है जो वास्तव में मायने रखती है। सुनने के लिए धन्यवाद। यदि आप देखना चाहते हैं कि Purple का मल्टी-टेनेंट WiFi प्लेटफॉर्म 80,000 लाइव वेन्यू में इस तरह के ऑब्जर्वेबिलिटी डेटा को कैसे प्रदर्शित करता है, तो purple dot ai पर जाएं।