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

Speak in British English with a confident, authoritative, and conversational tone - like a senior network consultant briefing a client over a coffee. Measured pace, clear diction, occasional dry wit. Not a lecture. Not a sales pitch. Just straight talk from someone who has seen this problem a hundred times: Purple तकनीकी ब्रीफ में स्वागत है। आज मैं आपसे एक ऐसी चीज़ के बारे में बात करने जा रहा हूँ जिसे हर नेटवर्क मैनेजर अच्छी तरह से जानता है, भले ही उन्होंने इसके लिए कभी औपचारिक शब्द न सुना हो। मीन टाइम टू इनोसेंस (Mean time to innocence)। या MTTI। [short pause] वह समय जो आप यह साबित करने में बिताते हैं कि यह आपकी गलती नहीं है। यहाँ एक परिदृश्य है। सुबह के नौ बजे हैं। एक BTR ब्लॉक में रहने वाले लोग फ्रंट डेस्क पर कॉल करने लगते हैं। WiFi खराब है। प्रॉपर्टी मैनेजर प्रबंधित WiFi प्रदाता को कॉल करता है। प्रबंधित WiFi प्रदाता ISP को कॉल करता है। ISP कहता है कि राउटर की जांच करें। राउटर टीम कहती है कि एक्सेस पॉइंट्स की जांच करें। एक्सेस पॉइंट वेंडर कहता है कि क्लाइंट डिवाइसेस की जांच करें। और इस सब के बीच, पैंतालीस मिनट बीत चुके हैं, और वास्तव में किसी ने कुछ भी ठीक नहीं किया है। ठीक यही मीन टाइम टू इनोसेंस का उदाहरण है। [short pause] और यह आपको आपकी सोच से कहीं अधिक नुकसान पहुँचा रहा है। मुझे इसे ठीक से परिभाषित करने दें। मीन टाइम टू इनोसेंस वह औसत बीता हुआ समय है जब किसी समस्या का पता चलता है और जब कोई भी टीम सबूत के साथ यह प्रदर्शित कर सकती है कि उनका डोमेन मूल कारण नहीं है। यह मीन टाइम टू आइडेंटिफाई के समान नहीं है, जो वास्तविक मूल कारण खोजने के लिए संगठन-व्यापी मीट्रिक है। MTTI अलग है। यह व्यक्तिगत है। यह नेटवर्क टीम का यह कहना है कि, 'यहाँ डेटा है, यह हमारी गलती नहीं है, अब कहीं और देखें।' समस्या यह है कि सही टूल्स के बिना, उस सबूत को जुटाने में समय लगता है। और MTTI का हर एक मिनट सीधे आपके मीन टाइम टू रेजोल्यूशन, यानी आपके MTTR में जुड़ जाता है। ये दोनों अविभाज्य हैं। तो हमेशा सबसे पहले WiFi को ही क्यों दोषी ठहराया जाता है? [short pause] इसके तीन कारण हैं। पहला, WiFi दिखाई देता है। जब कुछ खराब होता है, तो लोग उस चीज़ को देखते हैं जिसे वे देख सकते हैं, और उनके फोन पर WiFi सिग्नल बार कनेक्टिविटी का सबसे दृश्यमान संकेतक होते हैं। दूसरा, WiFi डिवाइस से पहले का आखिरी हॉप है, इसलिए जब कोई डिवाइस इंटरनेट तक नहीं पहुँच पाता है तो यह सबसे पहले संदिग्ध लगता है। तीसरा, और यह थोड़ा असहज करने वाला है, WiFi टीमें अक्सर अपनी बेगुनाही जल्दी साबित नहीं कर पाती हैं क्योंकि उनके पास सही टेलीमेट्री की कमी होती है। यदि आप दो मिनट से कम समय में वायरलेस लेयर के ठीक होने का प्रमाण नहीं दिखा सकते हैं, तो आप अगला एक घंटा अपना बचाव करने में बिताने वाले हैं। अब, एक सिंगल-टेनेंट एंटरप्राइज वातावरण में, यह कष्टप्रद है। लेकिन एक मल्टी-टेनेंट वातावरण में, यह वास्तव में नुकसानदेह है। Premier Inn जैसे होटल, या एक BTR आवासीय ब्लॉक, या लगातार इवेंट आयोजित करने वाले कॉन्फ्रेंस सेंटर के बारे में सोचें। आपके पास एक प्रॉपर्टी मैनेजर है जिसके पास नेटवर्क का स्वामित्व नहीं है। आपके पास ऐसे निवासी या मेहमान हैं जो नेटवर्क को नहीं समझते हैं। और आपके पास एक प्रबंधित WiFi प्रदाता है जो वायरलेस लेयर के लिए जिम्मेदार है लेकिन ISP सर्किट, इन-बिल्डिंग केबलिंग और क्लाइंट डिवाइसेस के लिए नहीं। जब कुछ खराब होता है, तो प्रॉपर्टी मैनेजर WiFi प्रदाता को दोषी ठहराता है क्योंकि वे उसी अनुबंध की ओर इशारा कर सकते हैं। निवासी बिल्डिंग को दोषी ठहराता है क्योंकि वे उन्हें किराया देते हैं। और WiFi प्रदाता को नेटवर्क को तेजी से दोषमुक्त करना होता है, अन्यथा संबंध खराब हो जाते हैं। [short pause] इस संदर्भ में 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 का एज राउटर है, चालीस प्रतिशत पैकेट लॉस दिखा रहा है, तो बातचीत तुरंत बदल जाती है। तीसरा स्तर: ऑन-डिमांड पैकेट कैप्चर के साथ फ्लो डेटा (flow data with on-demand packet capture)। NetFlow और IPFIX आपको नेटवर्क पर क्या किससे बात कर रहा है, इसका बातचीत-स्तरीय दृश्य प्रदान करते हैं। जब कोई निवासी कहता है कि स्ट्रीमिंग सेवा खराब है, तो फ्लो डेटा आपको बताता है कि उस सेवा के IP रेंज का ट्रैफ़िक नेटवर्क से बाहर जा भी रहा है या नहीं। यदि यह नेटवर्क से सुचारू रूप से बाहर जा रहा है और समस्या डाउनस्ट्रीम में है, तो यही आपका सबूत है। यदि यह नेटवर्क से बिल्कुल भी बाहर नहीं जा रहा है, तो आप जानते हैं कि कहाँ देखना है। Cisco Meraki और HPE Aruba जैसे प्लेटफॉर्म पर उपलब्ध ऑन-डिमांड पैकेट कैप्चर आपको हार्डवेयर को छुए बिना किसी विशिष्ट क्लाइंट या VLAN के लिए लक्षित कैप्चर करने की अनुमति देता है। यह आपकी फोरेंसिक लेयर है। आप इसका उपयोग कम ही करते हैं, लेकिन जब आपको इसकी आवश्यकता होती है, तो यह निर्णायक होता है। चौथा स्तर: टोपोलॉजी और डिपेंडेंसी मैपिंग (topology and dependency mapping)। मल्टी-टेनेंट वातावरण में, आपको एक लाइव मैप की आवश्यकता होती है जो दिखाता है कि कौन से एक्सेस पॉइंट किस टेनेंट को सेवा देते हैं, वे APs किन स्विचों से जुड़ते हैं, वे स्विच किन अपलिंक्स का उपयोग करते हैं, और कौन सा ISP सर्किट प्रत्येक अपलिंक को सेवा प्रदान करता है। जब कोई घटना होती है, तो आप तुरंत ब्लास्ट रेडियस की पहचान कर सकते हैं। क्या यह एक टेनेंट को प्रभावित कर रहा है या सभी टेनेंट्स को? एक मंजिल को या पूरी इमारत को? एक VLAN को या सभी VLANs को? टोपोलॉजी मैप से तीस सेकंड में मिलने वाला यह उत्तर आपको बताता है कि समस्या WiFi लेयर में है, बिल्डिंग नेटवर्क में है, या WAN में है। यह आपको यह भी बताता है कि किसे शामिल करना है, और किसे आप तुरंत बाहर कर सकते हैं। पांचवां स्तर: इवेंट कोरिलेशन (event correlation)। यह वह स्तर है जो सब कुछ एक साथ जोड़ता है। चेंज लॉग, ISP रखरखाव अलर्ट, डिवाइस फ़र्मवेयर अपडेट, पावर इवेंट और उपयोगकर्ता शिकायतों को एक ही टाइमलाइन पर होना चाहिए। जब आप क्लाइंट एसोसिएशन विफलताओं में वृद्धि को बारह मिनट पहले किए गए फ़र्मवेयर पुश के साथ ओवरले करते हैं, तो आपको अपना मूल कारण मिल जाता है। जब आप लेटेंसी स्पाइक को एक ISP रखरखाव विंडो के साथ ओवरले करते जिसके बारे में आपको सूचित नहीं किया गया था, तो आपके पास एस्केलेशन के लिए सबूत होता है। इवेंट कोरिलेशन आकर्षक नहीं लग सकता है, लेकिन यह पैंतालीस मिनट के दोषारोपण के खेल और चार मिनट की बेगुनाही साबित करने के बीच का अंतर है। अब, सांस्कृतिक आयाम पर एक बात, क्योंकि यहीं पर बहुत सी टीमें गलती करती हैं। MTTI को कम करने का लक्ष्य दोषारोपण के खेल को तेजी से जीतना नहीं है। यह दोषारोपण के खेल को पूरी तरह से समाप्त करना है। [short pause] साझा साक्ष्य इस स्थिति को बदल देते हैं। जब 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 शमन टूल है। समापन के लिए। मीन टाइम टू इनोसेंस हर नेटवर्क घटना पर लगने वाला एक छिपा हुआ कर (tax) है। मल्टी-टेनेंट वातावरण में, जहाँ जवाबदेही प्रदाताओं, मकान मालिकों और ISPs के बीच विभाजित होती है, यह वह मीट्रिक है जो यह तय करता है कि आप अनुबंधों को बनाए रखते हैं या उन्हें खो देते हैं। इसे कम करने की पद्धति जटिल नहीं है: सिंथेटिक जांच, पाथ विजिबिलिटी, फ्लो डेटा, टोपोलॉजी मैपिंग और इवेंट कोरिलेशन। लक्ष्य दोषारोपण के खेल को जीतना नहीं है। यह दोषारोपण के खेल को साझा साक्ष्यों से बदलना है, ताकि हर टीम अपने क्षेत्र का बचाव करने के बजाय समस्या को ठीक करने पर ध्यान केंद्रित कर सके। [short pause] क्योंकि बेगुनाही साबित करने में बिताया गया हर एक मिनट उस समय में जुड़ जाता है जो आपके निवासी, मेहमान या खरीदार बिना कनेक्टिविटी के बिताते हैं। और यही वह संख्या है जो वास्तव में मायने रखती है। सुनने के लिए धन्यवाद। यदि आप देखना चाहते हैं कि Purple का मल्टी-टेनेंट WiFi प्लेटफॉर्म 80,000 लाइव वेन्यू में इस तरह के ऑब्जर्वेबिलिटी डेटा को कैसे प्रदर्शित करता है, तो purple dot ai पर जाएं।