IT में बड़े पैमाने के अध्ययनों की कमी को समझाना

IT practitioners हर दिन इनके लिए पूछते हैं और फिर भी, कोई नहीं है – IT hardware और software के लिए बड़े पैमाने के risk और performance अध्ययन। यह संभावनाओं की एक विस्तृत श्रृंखला को कवर करता है, लेकिन सामान्य उदाहरण हैं विभिन्न server models, hard drives, operating systems, RAID array types, desktops, laptops के बीच failure rates। और फिर भी, ऐसे data की उच्च मांग के बावजूद कोई उपलब्ध नहीं है। यह कैसे हो सकता है।

सभी मामले एक जैसे नहीं हैं, निश्चित रूप से, लेकिन बड़े पैमाने पर तीन वास्तव में महत्वपूर्ण कारक हैं जो इस प्रकार के data को क्षेत्र में आने से रोकते हैं। ये हैं अध्ययन करने की उच्च लागत, अध्ययन के लिए आवश्यक लंबा समय और इस data को उत्पन्न करने और/या अन्य कंपनियों के साथ साझा करने का प्रोत्साहन नहीं होना।

लागत अब तक सबसे बड़ा कारक है। यदि बड़े पैमाने के अध्ययनों की लागत को दूर किया जा सकता, तो सभी अन्य कारकों के लिए समाधान मिल सकते थे। लेकिन दुर्भाग्य से बड़े पैमाने के अध्ययन की प्रकृति यह है कि यह महंगा होगा। उदाहरण के रूप में हम server reliability rates को देख सकते हैं।

एक server पर failure rates निर्धारित करने के लिए हमें यह data collect करने के लिए बड़ी संख्या में servers की आवश्यकता है। यह एक चरम उदाहरण लग सकता है लेकिन server failure rates सबसे अधिक अनुरोध किए जाने वाले बड़े पैमाने के अध्ययन आँकड़ों में से एक है और इसलिए उदाहरण महत्वपूर्ण है। एक बहुत छोटे अध्ययन के लिए हमें शायद कुछ सौ servers की आवश्यकता होगी लेकिन सांख्यिकीय रूप से महत्वपूर्ण data प्राप्त करने के लिए हमें संभवतः हज़ारों servers की आवश्यकता होगी। यदि हम मान लें कि एक server पाँच हज़ार dollar है, जो एक अपेक्षाकृत entry level server होगा, तो हम आसानी से पच्चीस मिलियन dollar के equipment को देख रहे हैं! और यह केवल एक कुछ छोटे पैमाने के test (केवल पाँच हज़ार servers) के लिए काफी है जो एक बजाय कम लागत वाले device का है। यदि हम enterprise servers के बारे में बात करें तो प्रति server आसानी से तीस या यहाँ तक कि पचास हज़ार dollar हो जाएंगे जिससे लागत एक चौथाई अरब dollar तक पहुँच जाएगी।

वह लागत, निश्चित रूप से, एक single server model के एक single configuration का परीक्षण करने के लिए है। संभवतः एक अध्ययन को सार्थक बनाने के लिए हमें कई अलग-अलग models के servers की आवश्यकता होगी। शायद विभिन्न lines और features की तुलना करने के लिए प्रत्येक vendor के कई। शायद कई vendors। यह देखना आसान है कि एक अध्ययन की लागत कितनी जल्दी असंभव रूप से बड़ी हो जाती है।

यह लागत की शुरुआत भर है, हालाँकि। एक अच्छा अध्ययन करने के लिए पर्यावरणीय मुद्दों को जितना संभव हो सके अलग करने के लिए सर्वश्रेष्ठ datacenters के बराबर सावधानीपूर्वक नियंत्रित वातावरण की आवश्यकता होगी। इसका मतलब है अत्यधिक विश्वसनीय बिजली, cooling, airflow, humidity control, vibration और dust control। इस तरह की अच्छी सुविधाएँ बहुत महंगी हैं और यही कारण है कि कई कंपनियाँ उनके लिए भुगतान नहीं करतीं, यहाँ तक कि मूल्यवान production workloads के लिए भी। एक बड़े अध्ययन में यह लागत अध्ययन के दौरान equipment की लागत से भी आसानी से अधिक हो सकती है।

फिर, निश्चित रूप से, हमें विशेष sensors और testing की ज़रूरतों को संबोधित करना होगा। वास्तव में failure क्या है? Production systems में भी अक्सर इस पर विवाद होता है। क्या किसी array में hard drive का fail होना एक failure है, यहाँ तक कि अगर array fail नहीं होती? क्या predictive failure एक failure है? यदि किसी अध्ययन में drive failure से निपट रहे हैं, तो आप human components जैसे drive replacement को कैसे factor में लेते हैं जो एक समान तरीके से नहीं किया जा सकता? इसे handle करने के तरीके हैं, लेकिन वे जटिलता जोड़ते हैं और अध्ययनों को real world data से contrived data की ओर ले जाते हैं। अध्ययन दिशानिर्देश स्थापित करना जो end users के लिए लागू और उपयोगी हों, उससे कहीं अधिक कठिन है जितना लगता है।

और सबसे बड़ी लागत, manual labor। एक बड़े अध्ययन के लिए एक वातावरण बनाए रखने में मानव पूंजी लगेगी जो अध्ययन की लागत के बराबर हो सकती है। एक अध्ययन वातावरण बनाए रखने, अध्ययन स्वयं चलाने, उसकी निगरानी करने और data collect करने के लिए बड़ी संख्या में लोगों की ज़रूरत है। कुल मिलाकर, लागत आम तौर पर, सरल रूप से करना असंभव है।

निश्चित रूप से हम test को बहुत कम कर सकते हैं, केवल कुछ servers और केवल दो या तीन models चला सकते हैं, लेकिन test का मूल्य तेज़ी से गिरता है और ऐसे परिणामों के साथ समाप्त होने का जोखिम उठाता है जिन्हें कोई उपयोग नहीं कर सकता जबकि अभी भी बड़ी राशि खर्च कर दी गई है।

दूसरी अजेय समस्या समय है। अधिकांश चीजों को समय के साथ failure rates के लिए परीक्षण करने की आवश्यकता होती है और जैसा कि IT में equipment आम तौर पर दशकों तक विश्वसनीय रूप से काम करने के लिए डिज़ाइन किया जाता है, failure rates पर data collect करने के लिए कई वर्षों की आवश्यकता होती है। Mean Time to Failure numbers केवल इतने मूल्यवान हैं, Mean Time Between Failures और failure types, modes और उस failure पर statistics एक अध्ययन के उपयोगी होने के लिए बहुत महत्वपूर्ण हैं। इसका मतलब यह है कि एक अध्ययन को वास्तव में उपयोगी होने के लिए बहुत लंबे समय तक चलना होगा जिससे अधिक से अधिक लागत बढ़ती जाएगी।

लेकिन यह सबसे बड़ी समस्या नहीं है। बहुत बड़ा मुद्दा यह है कि उपयोगी failure numbers उत्पन्न करने के लिए एक अध्ययन के पास पर्याप्त समय होने के लिए, यहाँ तक कि अगर वे numbers “live” आ रहे होते जैसे वे होते तो पहले से ही बहुत देर हो जाती। प्रश्न में equipment पहले से ही aging हो रहा होता और अध्ययन के वास्तव में उपयोगी शुरुआती परिणाम उत्पन्न करने के समय तक production marketplace में replacement के करीब पहुँच रहा होता। अक्सर production equipment केवल तीन से पाँच साल की कुल lifespan के लिए खरीदी जाती है। इस span में एक वर्ष में भी परिणाम प्राप्त करने का बहुत कम मूल्य होगा। और नए products उन अध्ययन में शामिल products को products के naturally aging होने से भी अधिक तेज़ी से replace कर सकते हैं जिससे अध्ययन केवल एक historic context से मूल्यवान हो जाता है बिना production decision role में choices निर्धारित करने में किसी उपयोग के – परिणाम उपलब्ध होने के समय तक उपयोगी होने के लिए बहुत पुराने हो जाते।

अंतिम प्रमुख कारक उन लोगों को मौजूदा data प्रदान करने के लिए प्रोत्साहन की कमी है जिन्हें इसकी आवश्यकता है। जबकि data के कुछ स्रोत मौजूद हैं, कुछ करते हैं, लेकिन लगभग सभी अधूरे हैं और बड़े vendors के लिए अपने equipment की quality, failure rates और इस तरह की चीज़ों को मापने के लिए मौजूद हैं। ये शायद ही कभी नियंत्रित वातावरण में किए जाते हैं और अक्सर field से collect किए गए data को involve करते हैं। कई मामलों में यह data customers के लिए भी private हो सकता है और legally share नहीं किया जा सकता।

लेकिन data collect करने वाले vendors इसे एक समान, monitored तरीके से collect नहीं करते इसलिए उस data को share करना उनके लिए बहुत हानिकारक हो सकता है क्योंकि इसकी कोई assurance नहीं है कि उनके competitors से समान data मौजूद होगा। ऐसे uncontrolled statistics market को कोई वास्तविक लाभ नहीं देंगे और न ही उन vendors को जिनके पास वे हैं इसलिए vendors ऐसे data को कड़ी निगरानी में रखने के लिए भारी रूप से प्रोत्साहित हैं।

दुर्लभ अपवाद Google और BackBlaze जैसे vendors के कुछ hardware अध्ययन हैं जिनके पास अपेक्षाकृत नियंत्रित वातावरण में बड़ी संख्या में consumer class hard drives हैं और अपने स्वयं के उद्देश्यों के लिए failure rates collect करते हैं लेकिन उनके अपने competitors से उस data का लाभ उठाने का बहुत कम या कोई जोखिम नहीं है लेकिन ऐसा करने में public relations मूल्य है और इसलिए, कभी-कभी, सीमित पैमाने पर hardware reliability का एक अध्ययन जारी करेंगे। ये अध्ययन उद्योग द्वारा भूखे मन से पढ़े जाते हैं, भले ही उनमें आम तौर पर अपेक्षाकृत कम मूल्य होता है क्योंकि उनका data पुराना है और अज्ञात conditions और thresholds के तहत है, और अक्सर product comparison के लिए सांख्यिकीय रूप से meaningful data नहीं होता और, सबसे अच्छे में, कुछ हद तक उपयोगी उद्योग-व्यापी सांख्यिकीय trends होते हैं जो भविष्य की reliability paths की भविष्यवाणी करने के लिए सबसे अच्छे में कुछ हद तक उपयोगी होते हैं।

अधिकांश अन्य कंपनियाँ जो internal reliability statistics रखने के लिए पर्याप्त बड़ी हैं, उनके पास equipment की एक संकीर्ण range पर ये हैं और उस जानकारी को proprietary मानती हैं, यदि यह प्रकट होती है तो एक संभावित जोखिम (यह architectural implementations के महत्वपूर्ण विवरण देगी) और एक competitive advantage। इसलिए इन कारणों से वे share नहीं किए जाते।

मैं वास्तव में एक बड़े पैमाने के storage reliability test में शामिल होने और उसे चलाने के लिए भाग्यशाली रहा हूँ जो कुछ हद तक अनौपचारिक रूप से, लेकिन बहुत मूल्यवान रूप से आठ वर्षों में दस हज़ार से अधिक enterprise servers पर किया गया जिसके परिणामस्वरूप अस्सी हज़ार server years का अध्ययन हुआ, एक दुर्लभ अवसर। लेकिन उस अध्ययन में जो निष्कर्ष निकाला गया वह यह था कि हालाँकि यह अत्यधिक मूल्यवान था, जो यह मुख्य रूप से दिखाता है वह यह है कि इतने बड़े set पर हम एक भी failure नहीं देख सके! Failures की कमी अपने आप में बहुत मूल्यवान थी। लेकिन हम Mean Time to Failure जैसे किसी मानक आँकड़े को produce करने में असमर्थ रहे। जिस प्रकार के data की लोग अपेक्षा करते हैं उसे produce करने के लिए हम जानते हैं कि हमें किसी भी सांख्यिकीय महत्व के लिए न्यूनतम सैकड़ों हज़ारों server years की आवश्यकता होती, लेकिन हम यह विश्वसनीय रूप से नहीं कह सकते कि वह भी पर्याप्त होता। शायद लाखों servers years आवश्यक होते। वास्तव में जानने का कोई तरीका नहीं है।

यह हमें जहाँ छोड़ता है वह यह है कि IT में बड़े पैमाने के अध्ययन बस मौजूद नहीं हैं और संभवतः कभी मौजूद नहीं होंगे। जब वे होंगे तो वे isolated होंगे और लगभग निश्चित रूप से वास्तविकता की आवश्यकताओं से अपंग होंगे। उपयोगी होने के लिए आवश्यक पैमाने पर अध्ययनों को monetize करने का कोई साधन नहीं है, अधिकतर इसलिए कि enterprise gear की failure rates इतनी कम है जबकि equipment इतना महंगा है, इसलिए third party firms इस research प्रदान करने की लागत को कभी cover नहीं कर सकते। एक उद्योग के रूप में हमें यह स्वीकार करना होगा कि इस प्रकार का data मौजूद नहीं है और ऐसे data तक पहुँच होने के विकल्पों को सक्रिय रूप से pursue करना होगा। यह आश्चर्यजनक है कि क्षेत्र में बहुत से लोग इस प्रकार के data के उपलब्ध होने की उम्मीद करते हैं जब यह ऐतिहासिक रूप से कभी नहीं रहा है।

हमारे पास वास्तविक विकल्प, इस vacuum को देखते हुए, मौजूद anecdotal evidence को collect करना हैं (यह एक बहुत खतरनाक बात है जिसके लिए context पर सावधानीपूर्वक विचार की आवश्यकता है) और reliability approaches और techniques का आकलन करने के लिए logic का application। यह एक व्यापक स्थिति है जहाँ observation ज़रूरी रूप से हमें विफल करता है और ज्ञान की परिणामी कमी को भरने के लिए केवल logic और intuition का उपयोग किया जा सकता है।