Mean time to innocence: WiFi चे दोषारोपण कसे टाळायचे

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