Mean time to innocence: WiFi ची चूक नाही हे कसे सिद्ध करावे

ब्रिटिश इंग्रजीमध्ये एका आत्मविश्वासाने भरलेल्या, अधिकृत आणि संभाषणात्मक सुरात बोला - जसे की एखादा वरिष्ठ नेटवर्क सल्लागार कॉफी पिताना क्लायंटला माहिती देत आहे. मोजलेला वेग, स्पष्ट शब्दरचना, अधूनमधून कोरडा विनोद. हे कोणतेही व्याख्यान नाही. ही विक्रीची खेळपट्टी नाही. फक्त अशा व्यक्तीकडून थेट बोलणे ज्याने ही समस्या शेकडो वेळा पाहिली आहे: Purple च्या तांत्रिक संक्षिप्त माहितीमध्ये आपले स्वागत आहे. मी आज तुमच्याशी अशा गोष्टीबद्दल बोलणार आहे जी प्रत्येक नेटवर्क व्यवस्थापकाला त्यांच्या मनापासून ठाऊक असते, जरी त्यांनी यापूर्वी कधीही याचा औपचारिक शब्द ऐकला नसेल. मीन टाइम टू इनोसेन्स (Mean time to innocence). किंवा MTTI. [लहान विराम] तुम्ही हे सिद्ध करण्यात घालवलेला वेळ की ही तुमची चूक नाही. परिस्थिती अशी आहे. सकाळचे नऊ वाजले आहेत. बिल्ड-टू-रेंट ब्लॉक मधील रहिवासी फ्रंट डेस्कवर कॉल करू लागतात. WiFi खराब झाले आहे. प्रॉपर्टी मॅनेजर मॅनेज्ड WiFi प्रदात्याला कॉल करतो. मॅनेज्ड WiFi प्रदाता ISP ला कॉल करतो. ISP म्हणतो राउटर तपासा. राउटर टीम म्हणते ॲक्सेस पॉइंट्स तपासा. ॲक्सेस पॉइंट विक्रेता म्हणतो क्लायंट डिव्हाइसेस तपासा. आणि या सर्वांच्या मध्यभागी कुठेतरी, पंचेचाळीस मिनिटे निघून गेली आहेत आणि प्रत्यक्षात कोणीही काहीही दुरुस्त केलेले नाही. ते, अगदी तिथेच, कृतीमध्ये मीन टाइम टू इनोसेन्स आहे. [लहान विराम] आणि यामुळे तुम्हाला तुमच्या कल्पनेपेक्षा जास्त किंमत मोजावी लागत आहे. मला याची योग्य व्याख्या करू द्या. मीन टाइम टू इनोसेन्स हा समस्या आढळल्यापासून आणि कोणतीही विशिष्ट टीम पुराव्यासह हे दाखवून देऊ शकते की त्यांचे डोमेन हे मूळ कारण नाही, यामधील सरासरी लागलेला वेळ आहे. हे मीन टाइम टू आयडेंटिफाय (mean time to identify) सारखे नाही, जे वास्तविक मूळ कारण शोधण्यासाठी संस्था-व्यापी मेट्रिक आहे. MTTI हे सायलोड (siloed) आहे. हे वैयक्तिक आहे. ही नेटवर्क टीम म्हणत आहे, हा डेटा आहे, हे आम्ही नाही, आता इतरत्र पहा. समस्या अशी आहे की योग्य साधनांशिवाय, तो पुरावा मिळण्यास वेळ लागतो. आणि MTTI चा प्रत्येक मिनिट थेट तुमच्या मीन टाइम टू रिझोल्यूशन (mean time to resolution), म्हणजेच तुमच्या MTTR मध्ये जोडला जातो. हे दोन्ही अविभाज्य आहेत. तर मग WiFi ला नेहमी आधी दोष का दिला जातो? [लहान विराम] तीन कारणे. पहिले, WiFi दृश्यमान आहे. जेव्हा काहीतरी बिघडते, तेव्हा लोक त्यांना दिसणाऱ्या गोष्टीकडे पाहतात आणि त्यांच्या फोनवरील WiFi सिग्नल बार हे कनेक्टिव्हिटीचे सर्वात दृश्यमान सूचक असतात. दुसरे, WiFi हे डिव्हाइसच्या आधीचे शेवटचे हॉप आहे, त्यामुळे जेव्हा एखादे डिव्हाइस इंटरनेटवर पोहोचू शकत नाही तेव्हा सर्वात आधी संशयास्पद वाटणारी गोष्ट हीच असते. तिसरे, आणि हे थोडे अस्वस्थ करणारे आहे, WiFi टीम्स अनेकदा त्यांची निरपराधता लवकर सिद्ध करू शकत नाहीत कारण त्यांच्याकडे योग्य टेलिमेट्री नसते. जर तुम्ही वायरलेस लेयरसाठी दोन मिनिटांपेक्षा कमी वेळात क्लीन बिल ऑफ हेल्थ दाखवू शकत नसाल, तर तुम्ही पुढील तास स्वतःचा बचाव करण्यात घालवणार आहात. आता, सिंगल-टेनंट एंटरप्राइझ वातावरणात, हे त्रासदायक आहे. मल्टी-टेनंट वातावरणात, हे खरोखरच नुकसानकारक आहे. प्रीमियर इन सारख्या हॉटेलचा, किंवा बिल्ड-टू-रेंट निवासी ब्लॉकचा, किंवा लागोपाठ इव्हेंट्स चालवणाऱ्या कॉन्फरन्स सेंटरचा विचार करा. तुमच्याकडे एक प्रॉपर्टी मॅनेजर आहे ज्याच्या मालकीचे नेटवर्क नाही. तुमच्याकडे असे रहिवासी किंवा पाहुणे आहेत ज्यांना नेटवर्क समजत नाही. आणि तुमच्याकडे एक मॅनेज्ड 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 चा डिमार्केशन पॉईंट. तुम्हाला पाथ ट्रेस डेटाची आवश्यकता आहे जो या सीमा ओलांडतो. केवळ ८.८.८.८ ला पिंग करणे पुरेसे नाही. वास्तविक ट्रेसरूट-शैलीतील व्हिजिबिलिटी जी तुम्हाला प्रत्येक हॉप, त्याची लेटन्सी आणि तो पॅकेट्स ड्रॉप करत आहे की नाही हे दाखवते. जेव्हा तुम्ही दाखवू शकता की हॉप्स एक ते चार क्लीन आहेत आणि हॉप पाच, जो ISP चा एज राउटर आहे, चाळीस टक्के पॅकेट लॉस दाखवत आहे, तेव्हा संभाषण लगेच बदलते. तिसरा स्तर: ऑन-डिमांड पॅकेट कॅप्चरसह फ्लो डेटा. NetFlow आणि IPFIX तुम्हाला नेटवर्कवर कोण कशाशी बोलत आहे याचे संभाषण-स्तरीय दृश्य देतात. जेव्हा एखादा रहिवासी म्हणतो की स्ट्रीमिंग सेवा काम करत नाही आहे, तेव्हा फ्लो डेटा तुम्हाला सांगतो की त्या सेवेच्या IP श्रेणींकडील ट्रॅफिक नेटवर्कमधून बाहेर पडत आहे की नाही. जर ते नेटवर्कमधून व्यवस्थित बाहेर पडत असेल आणि समस्या डाउनस्ट्रीममध्ये असेल, तर तो तुमचा पुरावा आहे. जर ते नेटवर्कमधून अजिबात बाहेर पडत नसेल, तर तुम्हाला कुठे शोधायचे हे माहित असते. Cisco Meraki आणि HPE Aruba सारख्या प्लॅटफॉर्मवर उपलब्ध असलेले ऑन-डिमांड पॅकेट कॅप्चर, तुम्हाला हार्डवेअरला स्पर्श न करता विशिष्ट क्लायंट किंवा VLAN साठी लक्ष्यित कॅप्चर मिळवू देते. हा तुमचा फॉरेन्सिक स्तर आहे. तुम्ही याचा वापर क्वचितच करता, पण जेव्हा तुम्हाला याची गरज असते, तेव्हा हा निर्णायक ठरतो. चौथा स्तर: टोपोलॉजी आणि डिपेंडन्सी मॅपिंग. मल्टी-टेनंट वातावरणात, तुम्हाला एका थेट नकाशाची (live map) गरज असते जो दर्शवतो की कोणते ॲक्सेस पॉइंट्स कोणत्या भाडेकरूंना सेवा देतात, ते APs कोणत्या स्विचेसला जोडतात, ते स्विचेस कोणते अपलिंक्स वापरतात आणि प्रत्येक अपलिंकला कोणती ISP सर्किट सेवा देते. जेव्हा एखादी घटना घडते, तेव्हा तुम्ही तात्काळ त्याचा प्रभाव क्षेत्र (blast radius) ओळखू शकता. याचा परिणाम एका भाडेकरूवर होत आहे की सर्व भाडेकरूंवर? एका मजल्यावर की संपूर्ण इमारतीवर? एका VLAN वर की सर्व VLANs वर? टोपोलॉजी मॅपवरून तीस सेकंदात उत्तर मिळणारा हा व्याप्तीचा प्रश्न तुम्हाला सांगतो की समस्या WiFi स्तरावर आहे, इमारतीच्या नेटवर्कमध्ये आहे की WAN मध्ये आहे. हे तुम्हाला हे देखील सांगते की कोणाला यात सामील करायचे आणि कोणाला तुम्ही त्वरित वगळू शकता. पाचवा स्तर: इव्हेंट कोरिलेशन (घटना परस्परसंबंध). हा तो स्तर आहे जो सर्व गोष्टींना एकत्र बांधतो. चेंज लॉग्स, ISP मेंटेनन्स अलर्ट्स, डिव्हाइस फर्मवेअर अपडेट्स, पॉवर इव्हेंट्स आणि वापरकर्त्यांच्या तक्रारी या सर्व गोष्टी एकाच टाइमलाइनवर असणे आवश्यक आहे. जेव्हा तुम्ही क्लायंट असोसिएशन अयशस्वी होण्याच्या वाढत्या प्रमाणावर बारा मिनिटांपूर्वी झालेल्या फर्मवेअर पुशचा ओव्हरले करता, तेव्हा तुम्हाला त्याचे मूळ कारण समजते. जेव्हा तुम्ही लेटन्सी स्पाइकवर तुम्हाला न कळवलेल्या ISP मेंटेनन्स विंडोचा ओव्हरले करता, तेव्हा तुमच्याकडे एस्केलेशनसाठी पुरावा असतो. इव्हेंट कोरिलेशन हे आकर्षक वाटत नसले तरी, यामुळे पंचेचाळीस मिनिटांच्या दोषारोप खेळाचे रूपांतर चार मिनिटांच्या निर्दोषत्व सिद्धतेमध्ये होते. आता, सांस्कृतिक पैलूबद्दल थोडे बोलूया, कारण इथेच बरेच संघ चुकतात. MTTI कमी करण्याचे उद्दिष्ट दोषारोपाचा खेळ वेगाने जिंकणे हे नाही. तर तो दोषारोपाचा खेळ पूर्णपणे संपवणे हा आहे. [short pause] सामायिक पुरावा डायनॅमिक बदलतो. जेव्हा WiFi प्रदाता प्रॉपर्टी मॅनेजरला डॅशबोर्डची लिंक पाठवू शकतो ज्यामध्ये वायरलेस स्तरावर हिरवा रंग, इन-बिल्डिंग स्विचवर पिवळा रंग आणि ISP सर्किटवर लाल रंग दिसत असेल, तेव्हा संभाषण वादग्रस्त राहत नाही. ते सहयोगी बनते. प्रॉपर्टी मॅनेजर ISP ला कॉल करतो. ISP सर्किट दुरुस्त करतो. रहिवाशांना कनेक्टिव्हिटी परत मिळते. आणि WiFi प्रदात्याच्या कराराचे नूतनीकरण केले जाते कारण त्यांनीच समस्या शोधून काढली होती. ऑब्झर्व्हेबिलिटी टूल्समध्ये गुंतवणूक करण्याचा हा व्यावसायिक फायदा आहे. केवळ जलद ट्रबलशूटिंग नाही, तर तुम्हाला पैसे देणाऱ्या लोकांसोबतचे अधिक चांगले संबंध. हे अधिक स्पष्ट करण्यासाठी मी तुम्हाला काही जलद प्रसंग सांगतो. प्रसंग एक: ३५० खोल्यांचे हॉटेल. प्रीमियर इन-शैलीतील मालमत्तेमधील अतिथी खोलीतील 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 आणि मीन टाइम टू आयडेंटिफाय (mean time to identify) मध्ये काय फरक आहे? MTTI म्हणजे तुमच्या टीमचा स्वतःला निर्दोष सिद्ध करण्याचा वेळ. मीन टाइम टू आयडेंटिफाय म्हणजे संस्थेला खरा दोषी शोधण्यासाठी लागणारा वेळ. MTTI हा मीन टाइम टू आयडेंटिफाय चा एक भाग आहे. नवीन साधने न खरेदी करता मी MTTI कसा कमी करू? तुमच्याकडे जे आहे त्यापासून सुरुवात करा. Cisco Meraki, HPE Aruba, आणि Juniper Mist यांसह बहुतांश एंटरप्राइझ ॲक्सेस पॉइंट प्लॅटफॉर्म्समध्ये अंगभूत सिंथेटिक टेस्टिंग आणि क्लायंट डायग्नोस्टिक्स असतात. त्यांचा वापर करा. तुमची टोपोलॉजी दस्तऐवजीकरण (document) करा. एक सामायिक डॅशबोर्ड तयार करा जो प्रॉपर्टी मॅनेजर किंवा ऑपरेशन्स टीम पाहू शकेल. पारदर्शकता हे उपलब्ध असलेले सर्वात स्वस्त MTTI कमी करण्याचे साधन आहे. थोडक्यात सांगायचे तर. मीन टाईम टू इनोसेन्स (Mean time to innocence) हा प्रत्येक नेटवर्क घटनेवरील छुपा कर आहे. मल्टी-टेनंट वातावरणात, जिथे जबाबदारी प्रदाते, घरमालक आणि ISPs मध्ये विभागलेली असते, तिथे हा असा मेट्रिक आहे जो तुम्ही करार टिकवून ठेवता की ते गमावता हे ठरवतो. ते कमी करण्याची पद्धत गुंतागुंतीची नाही: सिंथेटिक चेक्स, पाथ व्हिजिबिलिटी, फ्लो डेटा, टोपोलॉजी मॅपिंग आणि इव्हेंट कोरिलेशन. दोषारोप करण्याच्या खेळात जिंकणे हा उद्देश नाही. दोषारोप करण्याच्या खेळाऐवजी सामायिक पुरावे आणणे हा उद्देश आहे, जेणेकरून प्रत्येक टीम स्वतःच्या क्षेत्राचा बचाव करण्याऐवजी समस्या सोडवण्यावर लक्ष केंद्रित करू शकेल. [थोडा विराम] कारण स्वतःची निर्दोषता सिद्ध करण्यात घालवलेला प्रत्येक मिनिट म्हणजे तुमचे रहिवासी, पाहुणे किंवा खरेदीदार कनेक्टिव्हिटीशिवाय घालवलेल्या वेळेत झालेली वाढ आहे. आणि तीच संख्या खरोखर महत्त्वाची आहे. ऐकल्याबद्दल धन्यवाद. Purple चे Multi-Tenant WiFi प्लॅटफॉर्म ८०,००० हून अधिक लाइव्ह ठिकाणी अशा प्रकारचा ऑब्झर्व्हेबिलिटी डेटा कसा दाखवतो हे तुम्हाला पाहायचे असल्यास, purple dot ai ला भेट द्या.