Mean time to innocence: कैसे साबित करें कि समस्या WiFi की नहीं है

एक आत्मविश्वासी, आधिकारिक और संवादात्मक शैली में ब्रिटिश इंग्लिश बोलें - जैसे कोई सीनियर नेटवर्क कंसलटेंट कॉफी पर किसी क्लाइंट को जानकारी दे रहा हो। नपी-तुली गति, स्पष्ट उच्चारण, और बीच-बीच में हल्का हास्य। यह कोई व्याख्यान नहीं है। कोई सेल्स पिच भी नहीं है। बस एक ऐसे व्यक्ति की सीधी बात जिसने इस समस्या को सैकड़ों बार देखा है: Purple के तकनीकी विवरण में आपका स्वागत है। आज मैं आपसे एक ऐसी चीज़ के बारे में बात करने जा रहा हूँ जिसे हर नेटवर्क मैनेजर अच्छी तरह समझता है, भले ही उन्होंने इसके लिए कभी कोई औपचारिक शब्द न सुना हो। मीन टाइम टू इनोसेंस (Mean time to innocence)। या MTTI। [छोटा ठहराव] वह समय जो आप यह साबित करने में बिताते हैं कि यह आपकी गलती नहीं है। यहाँ परिदृश्य इस प्रकार है। सुबह के नौ बजे हैं। बिल्ड-टू-रेंट ब्लॉक के निवासी फ्रंट डेस्क पर कॉल करना शुरू करते हैं। WiFi खराब है। प्रॉपर्टी मैनेजर मैनेज्ड WiFi प्रोवाइडर को कॉल करता है। मैनेज्ड WiFi प्रोवाइडर ISP को कॉल करता है। ISP कहता है कि राउटर की जाँच करें। राउटर टीम कहती है कि एक्सेस पॉइंट्स की जाँच करें। एक्सेस पॉइंट वेंडर कहता है कि क्लाइंट डिवाइसेस की जाँच करें। और इस सब के बीच में, पैंतालीस मिनट बीत जाते हैं, और किसी ने वास्तव में कुछ भी ठीक नहीं किया है। ठीक यही, एक्शन में मीन टाइम टू इनोसेंस है। [छोटा ठहराव] और यह आपको आपकी सोच से कहीं अधिक नुकसान पहुँचा रहा है। मुझे इसे ठीक से परिभाषित करने दें। मीन टाइम टू इनोसेंस वह औसत बीता हुआ समय है जब किसी समस्या का पता चलता है और जब कोई भी टीम साक्ष्य के साथ यह प्रदर्शित कर सकती है कि उनका डोमेन मूल कारण नहीं है। यह मीन टाइम टू आइडेंटिफाई (mean time to identify) जैसा नहीं है, जो वास्तविक मूल कारण खोजने के लिए पूरे संगठन का पैमाना होता है। MTTI साइलो में काम करता है। यह व्यक्तिगत है। यह नेटवर्क टीम द्वारा यह कहना है कि, यह रहा डेटा, यह हमारी वजह से नहीं है, अब कहीं और देखें। समस्या यह है कि सही टूलिंग के बिना, उस प्रमाण को जुटाने में समय लगता है। और MTTI का प्रत्येक मिनट सीधे आपके मीन टाइम टू रेजोल्यूशन यानी MTTR में जुड़ जाता है। ये दोनों अविभाज्य हैं। तो WiFi को ही हमेशा सबसे पहले दोषी क्यों ठहराया जाता है? [छोटा ठहराव] तीन कारण हैं। पहला, WiFi दिखाई देता है। जब कुछ खराब होता है, तो लोग उस चीज़ को देखते हैं जिसे वे देख सकते हैं, और उनके फोन पर WiFi सिग्नल बार कनेक्टिविटी का सबसे स्पष्ट संकेतक होते हैं। दूसरा, WiFi डिवाइस से पहले का आखिरी हॉप है, इसलिए जब कोई डिवाइस इंटरनेट तक नहीं पहुँच पाता है तो सबसे पहले इसी पर संदेह होता है। तीसरा, और यह थोड़ा असहज करने वाला है, कि WiFi टीमें अक्सर अपनी बेगुनाही जल्दी साबित नहीं कर पाती हैं क्योंकि उनके पास सही टेलीमेट्री की कमी होती है। यदि आप दो मिनट से कम समय में वायरलेस लेयर के बिल्कुल ठीक होने का प्रमाण नहीं दिखा सकते हैं, तो आप अगला एक घंटा अपना बचाव करने में बिताने वाले हैं। अब, एक single-tenant एंटरप्राइज वातावरण में, यह परेशान करने वाला है। एक multi-tenant वातावरण में, यह वास्तव में नुकसानदेह है। प्रीमियर इन (Premier Inn) जैसे होटल, या किराए पर रहने वाले आवासीय ब्लॉक, या लगातार इवेंट आयोजित करने वाले सम्मेलन केंद्र के बारे में सोचें। आपके पास एक प्रॉपर्टी मैनेजर है जो नेटवर्क का मालिक नहीं है। आपके पास ऐसे निवासी या मेहमान हैं जो नेटवर्क को नहीं समझते हैं। और आपके पास एक प्रबंधित WiFi प्रदाता है जो वायरलेस लेयर के लिए जिम्मेदार है लेकिन ISP सर्किट, इन-बिल्डिंग केबलिंग, और क्लाइंट डिवाइस के लिए नहीं। जब कुछ खराब होता है, तो प्रॉपर्टी मैनेजर WiFi प्रदाता को दोष देता है क्योंकि वे उसी अनुबंध की ओर इशारा कर सकते हैं। निवासी बिल्डिंग को दोष देता है क्योंकि वे उन्हें ही किराया देते हैं। और WiFi प्रदाता को नेटवर्क को तेजी से दोषमुक्त करना होता है, अन्यथा संबंध बिगड़ जाते हैं। - MTTI इस संदर्भ में केवल एक तकनीकी मीट्रिक नहीं है। यह एक व्यावसायिक मीट्रिक है। तो आइए उस कार्यप्रणाली के बारे में बात करते हैं जो वास्तव में इसे कम करती है। इसमें पांच परतें हैं, और आपको इन पांचों की आवश्यकता है। पहली परत: निरंतर सिंथेटिक जांच। कोई भी टिकट उठाए जाने से पहले, आपके पास नेटवर्क से ही चलने वाले स्वचालित प्रोब होने चाहिए, जो DNS रेजोल्यूशन, HTTP पहुंच, ज्ञात एंडपॉइंट्स तक विलंबता, और प्रमाणीकरण प्रवाह का परीक्षण करते हों। Juniper Mist के Marvis जैसे उपकरण, या ThousandEyes जैसे प्लेटफार्मों में निर्मित सिंथेटिक परीक्षण, हर कुछ मिनटों में इन जांचों को चलाते हैं। जब कोई घटना घटती है, तो आप एक ग्राफ देख सकते हैं और सटीक रूप से दिखा सकते हैं कि WiFi लेयर पर आखिरी बार कब साफ-सुथरा सिंथेटिक चेक हुआ था, और शिकायत के समय यह साफ था या खराब था। केवल यही MTTI को नाटकीय रूप से कम कर देता है, क्योंकि आप या तो पुष्टि करते हैं कि WiFi स्वस्थ था, या आप पुष्टि करते हैं कि यह नहीं था, और आप इस बारे में बहस करना बंद कर देते हैं। दूसरी परत: हॉप-बाय-हॉप पथ दृश्यता। यही वह जगह है जहां अधिकांश टीमें असफल हो जाती हैं। आप साबित कर सकते हैं कि एक्सेस पॉइंट स्वस्थ है। आप साबित कर सकते हैं कि स्विच स्वस्थ है। लेकिन क्या आप साबित कर सकते हैं कि स्विच से ISP हैंडऑफ़ तक का पथ स्वस्थ है? एक multi-tenant बिल्डिंग में, अक्सर ऐसे हॉप्स होते हैं जिनके आप मालिक नहीं होते हैं। इन-बिल्डिंग वितरण नेटवर्क, मकान मालिक का कोर स्विच, ISP के लिए सीमांकन बिंदु। आपको पथ ट्रेस डेटा की आवश्यकता है जो उन सीमाओं को पार करता हो। केवल 8.8.8.8 पर पिंग करना ही काफी नहीं है। वास्तविक ट्रेसरूट-शैली दृश्यता जो आपको हर हॉप, उसकी विलंबता, और क्या यह पैकेट छोड़ रहा है, दिखाती है। जब आप दिखा सकते हैं कि हॉप एक से चार तक साफ हैं और हॉप पांच, जो कि ISP का एज राउटर है, चालीस प्रतिशत पैकेट नुकसान दिखा रहा है, तो बातचीत तुरंत बदल जाती है।तीसरी लेयर: ऑन-डिमांड पैकेट कैप्चर के साथ फ्लो डेटा। NetFlow और IPFIX आपको एक बातचीत-स्तर का दृश्य देते हैं कि नेटवर्क पर क्या किससे बात कर रहा है। जब कोई निवासी कहता है कि स्ट्रीमिंग सेवा काम नहीं कर रही है, तो फ्लो डेटा आपको बताता है कि उस सेवा की IP रेंज का ट्रैफ़िक नेटवर्क से बाहर जा भी रहा है या नहीं। यदि यह नेटवर्क से सही तरीके से बाहर जा रहा है और समस्या डाउनस्ट्रीम में है, तो यह आपका प्रमाण है। यदि यह नेटवर्क से बिल्कुल भी बाहर नहीं जा रहा है, तो आप जानते हैं कि कहाँ देखना है। Cisco Meraki और HPE Aruba जैसे प्लेटफ़ॉर्म पर उपलब्ध ऑन-डिमांड पैकेट कैप्चर, आपको हार्डवेयर को छुए बिना किसी विशिष्ट क्लाइंट या VLAN के लिए लक्षित कैप्चर प्राप्त करने की अनुमति देता है। यह आपकी फोरेंसिक लेयर है। आप इसका उपयोग कम ही करते हैं, लेकिन जब आपको इसकी आवश्यकता होती है, तो यह निर्णायक होता है। चौथी लेयर: टोपोलॉजी और डिपेंडेंसी मैपिंग। एक मल्टी-टेनेंट वातावरण में, आपको एक लाइव मैप की आवश्यकता होती है जो दिखाता है कि कौन से एक्सेस पॉइंट किन टेनेंट्स को सेवा देते हैं, वे APs किन स्विचेस से जुड़ते हैं, वे स्विचेस किन अपलिंक्स का उपयोग करते हैं, और कौन सा ISP सर्किट प्रत्येक अपलिंक को सेवा देता है। जब कोई घटना होती है, तो आप तुरंत प्रभाव के दायरे की पहचान कर सकते हैं। क्या यह एक टेनेंट को प्रभावित कर रहा है या सभी टेनेंट्स को? एक मंजिल को या पूरी इमारत को? एक VLAN को या सभी VLANs को? टोपोलॉजी मैप से तीस सेकंड में उत्तर मिलने वाला यह स्कोपिंग प्रश्न आपको बताता है कि समस्या WiFi लेयर में है, बिल्डिंग नेटवर्क में है, या WAN में है। यह आपको यह भी बताता है कि किसे शामिल करना है, और किसे आप तुरंत बाहर कर सकते हैं। पांचवीं लेयर: इवेंट कोरिलेशन। यह वह लेयर है जो सब कुछ एक साथ जोड़ती है। चेंज लॉग्स, 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: आठ मिनट। भुगतान प्रोसेसर का समाधान समय: पैंतीस मिनट। फ्लो डेटा के बिना, नेटवर्क टीम ने वे पैंतीस मिनट उन VLAN को रीप्रोविज़निंग करने और स्विच को रीबूट करने में बिताए होते जो पूरी तरह से ठीक काम कर रहे थे। ठीक है। चलिए मैं आपको इस विषय पर मुझसे पूछे जाने वाले मुख्य प्रश्नों का त्वरित उत्तर देता हूँ। क्या यह WiFi है या डिवाइस? स्वयं AP से एक सिंथेटिक जांच चलाएं। यदि AP इंटरनेट तक आसानी से पहुँच सकता है और डिवाइस नहीं पहुँच सकता है, तो यह डिवाइस है। यदि AP इंटरनेट तक नहीं पहुँच सकता है, तो यह डिवाइस के अपस्ट्रीम में है। क्या यह WiFi है या ISP? इंटरनेट के लिए पाथ ट्रेस करें। यदि लेटेंसी या नुकसान आपके नेटवर्क की सीमा के बाहर किसी हॉप पर पेश किया जाता है, तो यह ISP है। MTTI और मीन टाइम टू आइडेंटिफाई के बीच क्या अंतर है? MTTI आपकी टीम का बेगुनाही साबित करने का समय है। मीन टाइम टू आइडेंटिफाई संगठन का वास्तविक दोषी का पता लगाने का समय है। MTTI मीन टाइम टू आइडेंटिफाई का एक उपसमुच्चय है। नए उपकरण खरीदे बिना मैं MTTI को कैसे कम करूँ? जो आपके पास है उसी से शुरुआत करें। Cisco Meraki, HPE Aruba, और Juniper Mist सहित अधिकांश एंटरप्राइज़ एक्सेस पॉइंट प्लेटफ़ॉर्म में बिल्ट-इन सिंथेटिक टेस्टिंग और क्लाइंट डायग्नोस्टिक्स होते हैं। उनका उपयोग करें। अपनी टोपोलॉजी को दस्तावेज़ीकृत करें। एक साझा डैशबोर्ड बनाएं जिसे प्रॉपर्टी मैनेजर या ऑपरेशन्स टीम देख सके। पारदर्शिता सबसे सस्ता उपलब्ध MTTI रिडक्शन टूल है। निष्कर्ष के तौर पर। मीन टाइम टू इनोसेंस (Mean time to innocence) हर नेटवर्क घटना पर लगने वाला एक छिपा हुआ टैक्स है। मल्टी-टेनेंट वातावरण में, जहाँ जवाबदेही प्रोवाइडर्स, मकान मालिकों और ISPs के बीच बंटी होती है, यह वह मीट्रिक है जो यह तय करती है कि आपके पास कॉन्ट्रैक्ट्स बने रहेंगे या चले जाएंगे। इसे कम करने की कार्यप्रणाली जटिल नहीं है: सिंथेटिक चेक, पाथ विजिबिलिटी, फ़्लो डेटा, टोपोलॉजी मैपिंग और इवेंट कोरिलेशन। इसका उद्देश्य ब्लेम गेम जीतना नहीं है। इसका उद्देश्य ब्लेम गेम को साझा सबूतों से बदलना है, ताकि हर टीम अपना बचाव करने के बजाय समस्या को ठीक करने पर ध्यान केंद्रित कर सके। [छोटा ठहराव] क्योंकि इनोसेंस साबित करने में बीता हर एक मिनट आपके निवासियों, मेहमानों या खरीदारों द्वारा बिना कनेक्टिविटी के बिताए जाने वाले समय को बढ़ा देता है। और वास्तव में यही वह संख्या है जो मायने रखती है। सुनने के लिए धन्यवाद। यदि आप यह देखना चाहते हैं कि Purple का मल्टी-टेनेंट WiFi प्लेटफ़ॉर्म किस तरह 80,000 से अधिक लाइव वेन्यू पर इस प्रकार का ऑब्ज़र्वेबिलिटी डेटा दिखाता है, तो purple dot ai पर जाएं।