Mean time to innocence: কীভাবে প্রমাণ করবেন যে এটি WiFi এর সমস্যা নয়

ব্রিটিশ ইংরেজিতে একজন আত্মবিশ্বাসী, কর্তৃত্বপূর্ণ এবং কথোপকথনমূলক ভঙ্গিতে কথা বলুন - ঠিক যেমন একজন সিনিয়র নেটওয়ার্ক পরামর্শদাতা কফির কাপে চুমুক দিতে দিতে কোনো ক্লায়েন্টকে ব্রিফিং করছেন। একটি পরিমিত গতি, স্পষ্ট উচ্চারণ এবং মাঝে মাঝে সূক্ষ্ম রসিকতা। এটি কোনো লেকচার বা কোনো সেলস পিচ নয়। শুধু এমন একজনের সাথে সরাসরি কথা যিনি এই সমস্যাটি শতবার দেখেছেন: Purple-এর টেকনিক্যাল ব্রিফিংয়ে আপনাকে স্বাগত জানাই। আমি আজ আপনাদের সাথে এমন একটি বিষয় নিয়ে কথা বলতে যাচ্ছি যা প্রত্যেক নেটওয়ার্ক ম্যানেজার খুব ভালো করেই জানেন, এমনকি তারা যদি এর আনুষ্ঠানিক পরিভাষাটি কখনো নাও শুনে থাকেন। Mean time to innocence। বা MTTI। [সামান্য বিরতি] যে সময়টি আপনি প্রমাণ করতে ব্যয় করেন যে এটি আপনার ভুল নয়। পরিস্থিতিটি একটু ভেবে দেখুন। সকাল নয়টা বাজে। একটি বিল্ড-টু-রেন্ট ব্লকের বাসিন্দারা ফ্রন্ট ডেস্কে কল করতে শুরু করেছেন। WiFi কাজ করছে না। প্রপার্টি ম্যানেজার কল করেন ম্যানেজড WiFi প্রদানকারীকে। ম্যানেজড WiFi প্রদানকারী কল করেন ISP-কে। ISP বলে রাউটারটি পরীক্ষা করতে। রাউটার টিম বলে অ্যাক্সেস পয়েন্টগুলো পরীক্ষা করতে। অ্যাক্সেস পয়েন্ট ভেন্ডর বলে ক্লায়েন্ট ডিভাইসগুলো পরীক্ষা করতে। আর এই সবকিছুর মাঝে ৪৫ মিনিট কেটে গেছে এবং আসলে কেউই কোনো সমাধান করতে পারেনি। এটিই হলো বাস্তবে mean time to innocence-এর উদাহরণ। [সামান্য বিরতি] আর এটি আপনার ধারণার চেয়েও অনেক বেশি ব্যয়বহুল। আমাকে এটি সঠিকভাবে ব্যাখ্যা করতে দিন। Mean time to innocence হলো কোনো সমস্যা সনাক্ত করার পর থেকে যেকোনো নির্দিষ্ট টিম প্রমাণসহ এটি প্রদর্শন করতে যে গড় সময় নেয় যে, তাদের ডোমেনটি এই সমস্যার মূল কারণ নয়। এটি mean time to identify-এর মতো নয়, যা প্রকৃত মূল কারণ খুঁজে বের করার জন্য পুরো প্রতিষ্ঠান জুড়ে ব্যবহৃত একটি মেট্রিক। MTTI প্রতিটি টিমের জন্য আলাদা। এটি ব্যক্তিগত। এটি হলো নেটওয়ার্ক টিমের পক্ষ থেকে বলা যে, এই যে ডেটা দেখুন, সমস্যা আমাদের এখানে নয়, এবার অন্য কোথাও খুঁজুন। সমস্যা হলো সঠিক টুলিং ছাড়া এই প্রমাণ করতে সময় লাগে। আর MTTI-এর প্রতিটি মিনিট সরাসরি আপনার সমাধানের গড় সময় বা MTTR-এর সাথে যোগ হয়। এই দুটি একে অপরের সাথে অবিচ্ছেদ্য। তাহলে কেন সবসময় WiFi-কে প্রথমে দোষারোপ করা হয়? [সামান্য বিরতি] তিনটি কারণ রয়েছে। প্রথমত, WiFi দৃশ্যমান। যখন কোনো কিছু নষ্ট হয়, মানুষ সেই জিনিসটির দিকে তাকায় যা তারা দেখতে পায়, আর তাদের ফোনে থাকা WiFi সিগন্যাল বারগুলো হলো কানেক্টিভিটির সবচেয়ে দৃশ্যমান সূচক। দ্বিতীয়ত, WiFi হলো ডিভাইসের ঠিক আগের শেষ ধাপ, তাই কোনো ডিভাইস ইন্টারনেট অ্যাক্সেস করতে না পারলে এটিকেই প্রথম সন্দেহজনক মনে হয়। তৃতীয়ত, এবং এটি একটু অস্বস্তিকর বিষয় যে, প্রায়শই WiFi টিমগুলোর কাছে সঠিক টেলিমেট্রি না থাকার কারণে তারা দ্রুত নিজেদের নির্দোষ প্রমাণ করতে পারে না। আপনি যদি দুই মিনিটের কম সময়ের মধ্যে ওয়্যারলেস লেয়ারটি সম্পূর্ণ ত্রুটিমুক্ত তা প্রমাণ করতে না পারেন, তবে পরবর্তী এক ঘণ্টা আপনাকে কেবল নিজেকে ডিফেন্ড করতেই ব্যয় করতে হবে। এখন, একটি সিঙ্গেল-টেন্যান্ট এন্টারপ্রাইজ পরিবেশে, এটি বিরক্তিকর। একটি মাল্টি-টেন্যান্ট পরিবেশে, এটি সত্যিকার অর্থেই ক্ষতিকারক। Premier Inn এর মতো একটি হোটেল, বা একটি বিল্ড-টু-রেন্ট আবাসিক ব্লক, অথবা একের পর এক ইভেন্ট চলছে এমন একটি কনফারেন্স সেন্টারের কথা ভাবুন। আপনার এমন একজন প্রপার্টি ম্যানেজার আছেন যিনি নেটওয়ার্কটির মালিক নন। আপনার এমন বাসিন্দা বা অতিথি আছেন যারা নেটওয়ার্কটি বোঝেন না। এবং আপনার কাছে একটি ম্যানেজড WiFi প্রোভাইডার আছে যারা ওয়্যারলেস লেয়ারের জন্য দায়ী কিন্তু ISP সার্কিট, ইন-বিল্ডিং ক্যাবলিং বা ক্লায়েন্ট ডিভাইসগুলোর জন্য নয়। যখন কোনো কিছু নষ্ট হয়, তখন প্রপার্টি ম্যানেজার WiFi প্রোভাইডারকে দোষারোপ করেন কারণ এটিই সেই চুক্তি যা তারা দেখাতে পারেন। বাসিন্দা ভবনটিকে দোষারোপ করেন কারণ তারা তাদেরকেই ভাড়া দেন। এবং WiFi প্রোভাইডারকে দ্রুত নেটওয়ার্কটিকে নির্দোষ প্রমাণ করতে হয়, অন্যথায় সম্পর্কের অবনতি ঘটে। [ছোট বিরতি] এই প্রেক্ষাপটে MTTI কেবল একটি প্রযুক্তিগত মেট্রিক নয়। এটি একটি বাণিজ্যিক মেট্রিক। তাহলে চলুন এমন পদ্ধতি সম্পর্কে কথা বলি যা আসলে এটিকে সংক্ষিপ্ত করে। এখানে পাঁচটি লেয়ার রয়েছে, এবং আপনার পাঁচটিই প্রয়োজন। লেয়ার ওয়ান: কন্টিনিউয়াস সিন্থেটিক চেক। কোনো টিকিট তৈরি করার আগেই, নেটওয়ার্ক থেকেই স্বয়ংক্রিয় প্রোব চালানো উচিত, যা DNS রেজোলিউশন, HTTP রিচিবিলিটি, পরিচিত এন্ডপয়েন্টগুলোতে লেটেন্সি এবং অথেন্টিকেশন ফ্লো পরীক্ষা করবে। Juniper Mist এর Marvis এর মতো টুলস, বা ThousandEyes এর মতো প্ল্যাটফর্মে বিল্ট-ইন সিন্থেটিক টেস্টিং প্রতি কয়েক মিনিট অন্তর এই চেকগুলো চালায়। যখন কোনো ঘটনা ঘটে, তখন আপনি একটি গ্রাফ বের করে দেখাতে পারেন যে WiFi লেয়ারে সর্বশেষ কখন একটি ক্লিন সিন্থেটিক চেক হয়েছিল এবং অভিযোগের সময় এটি ক্লিন ছিল নাকি ডিগ্রেডেড ছিল। শুধুমাত্র এটিই নাটকীয়ভাবে MTTI কমিয়ে দেয়, কারণ আপনি হয় নিশ্চিত করেন যে WiFi সুস্থ ছিল, অথবা নিশ্চিত করেন যে এটি ছিল না, এবং আপনি এটি নিয়ে বিতর্ক করা বন্ধ করেন। লেয়ার টু: হপ-বাই-হপ পাথ ভিজিবিলিটি। এখানেই বেশিরভাগ টিম ব্যর্থ হয়। আপনি প্রমাণ করতে পারেন যে অ্যাক্সেস পয়েন্টটি সুস্থ। আপনি প্রমাণ করতে পারেন যে সুইচটি সুস্থ। কিন্তু আপনি কি সুইচ থেকে ISP হ্যান্ডঅফ পর্যন্ত পথটি সুস্থ তা প্রমাণ করতে পারেন? একটি মাল্টি-টেন্যান্ট ভবনে, প্রায়শই এমন কিছু হপ থাকে যা আপনার মালিকানাধীন নয়। ইন-বিল্ডিং ডিস্ট্রিবিউশন নেটওয়ার্ক, ল্যান্ডলর্ডের কোর সুইচ, ISP-এর ডিমার্কেশন পয়েন্ট। আপনার এমন পাথ ট্রেস ডেটা প্রয়োজন যা সেই সীমানাগুলো অতিক্রম করে। কেবল ৮.৮.৮.৮-এ একটি পিং করা নয়। প্রকৃত ট্র্যাকিং স্টাইলের ভিজিবিলিটি যা আপনাকে প্রতিটি হপ, এর লেটেন্সি এবং এটি প্যাকেট ড্রপ করছে কিনা তা দেখায়। যখন আপনি দেখাতে পারেন যে এক থেকে চার নম্বর হপগুলো ক্লিন এবং পাঁচ নম্বর হপ, যা হল ISP-এর এজ রাউটার, সেটি চল্লিশ শতাংশ প্যাকেট লস দেখাচ্ছে, তখন আলোচনাটি অবিলম্বে পরিবর্তিত হয়ে যায়।তৃতীয় স্তর: অন-ডিমান্ড প্যাকেট ক্যাপচার সহ ফ্লো ডেটা। NetFlow এবং IPFIX আপনাকে নেটওয়ার্কে কোনটি কার সাথে কথা বলছে তার একটি কনভারসেশন-লেভেল ভিউ প্রদান করে। যখন একজন বাসিন্দা বলেন যে স্ট্রিমিং সার্ভিসটি কাজ করছে না, তখন ফ্লো ডেটা আপনাকে বলে যে সেই সার্ভিসের IP রেঞ্জে ট্রাফিক আদৌ নেটওয়ার্ক থেকে বের হচ্ছে কিনা। যদি এটি নেটওয়ার্ক থেকে নির্বিঘ্নে বের হয় এবং সমস্যাটি ডাউনস্ট্রিমে থাকে, তবে সেটাই আপনার প্রমাণ। যদি এটি নেটওয়ার্ক থেকে একেবারেই বের না হয়, তবে আপনি জানেন কোথায় খুঁজতে হবে। Cisco Meraki এবং HPE Aruba এর মতো প্ল্যাটফর্মে উপলব্ধ অন-ডিমান্ড প্যাকেট ক্যাপচার আপনাকে হার্ডওয়্যার স্পর্শ না করেই একটি নির্দিষ্ট ক্লায়েন্ট বা VLAN এর জন্য টার্গেটেড ক্যাপচার করার সুবিধা দেয়। এটি আপনার ফরেনসিক স্তর। আপনি এটি খুব কমই ব্যবহার করবেন, তবে যখন প্রয়োজন হবে, এটিই হবে চূড়ান্ত সিদ্ধান্ত। চতুর্থ স্তর: টপোলজি এবং ডিপেন্ডেন্সি ম্যাপিং। একটি মাল্টি-টেন্যান্ট পরিবেশে আপনার একটি লাইভ ম্যাপ প্রয়োজন যা দেখায় কোন অ্যাক্সেস পয়েন্টগুলি কোন টেন্যান্টদের পরিষেবা দিচ্ছে, সেই APগুলি কোন সুইচের সাথে সংযুক্ত, সেই সুইচগুলি কোন আপলিংক ব্যবহার করছে এবং কোন ISP সার্কিট প্রতিটি আপলিংককে পরিষেবা দিচ্ছে। যখন কোনো ঘটনা ঘটে, আপনি অবিলম্বে ব্লাস্ট রেডিয়াস সনাক্ত করতে পারেন। এটি কি একজন টেন্যান্টকে নাকি সব টেন্যান্টকে প্রভাবিত করছে? একটি তলা নাকি পুরো ভবনকে? একটি VLAN নাকি সমস্ত VLAN-কে? একটি টপোলজি ম্যাপ থেকে ত্রিশ সেকেন্ডের মধ্যে উত্তর দেওয়া এই স্কোপিং প্রশ্নটি আপনাকে বলে দেয় যে সমস্যাটি 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 হলো একটি লুকানো কর। মাল্টি-টেন্যান্ট পরিবেশে, যেখানে দায়বদ্ধতা বিভিন্ন প্রোভাইডার, ল্যান্ডলর্ড এবং ISP-এর মধ্যে বিভক্ত থাকে, এটি এমন একটি মেট্রিক যা নির্ধারণ করে যে আপনি চুক্তিগুলি বজায় রাখবেন নাকি হারাবেন। এটি কমানোর পদ্ধতি জটিল নয়: সিন্থেটিক চেক, পাথ ভিজিবিলিটি, ফ্লো ডেটা, টপোলজি ম্যাপিং এবং ইভেন্ট কোরিলেশন। লক্ষ্য ব্লেম গেম বা একে অপরকে দোষারোপ করার খেলায় জয়ী হওয়া নয়। এটি হলো ব্লেম গেমের পরিবর্তে শেয়ার্ড এভিডেন্স বা যৌথ প্রমাণ ব্যবহার করা, যাতে প্রতিটি টিম নিজের এলাকা ডিফেন্ড করার চেয়ে সমস্যা সমাধানের দিকে মনোনিবেশ করতে পারে। - কারণ নির্দোষ প্রমাণ করতে ব্যয় করা প্রতিটি মিনিট আপনার বাসিন্দা, অতিথি বা ক্রেতাদের কানেক্টিভিটি ছাড়া কাটানো সময়ের সাথে যোগ হয়। আর সেটাই আসলে আসল সংখ্যা। শোনার জন্য ধন্যবাদ। Purple-এর মাল্টি-টেন্যান্ট WiFi প্ল্যাটফর্ম কীভাবে ৮০,০০০-এর বেশি লাইভ ভেন্যুতে এই ধরণের অবজারভেবিলিটি ডেটা প্রদর্শন করে তা দেখতে চাইলে purple dot ai-তে যান।