अगर टूटा नहीं है, तो ठीक मत करो

हम सभी ने यह बहुत सुना है, है ना? “अगर टूटा नहीं है, तो ठीक मत करो।” लोग इसे हर जगह improvements, modernization या refactoring को discourage करने के तरीके के रूप में उपयोग करते हैं। बहुत से लोग इसे कहते हैं और इस प्रकृति के कई phrases की तरह, सतह पर यह उचित लगता है। लेकिन application में, यह वास्तव में नहीं है या, कम से कम, सामान्यतः उपयोग किए जाने के तरीके में नहीं है क्योंकि इसे अच्छी तरह से समझा नहीं गया है।

यह लोगों को अपने सभी अंडे एक टोकरी में न रखने की अवधारणा के समान है, जहाँ इसे अक्सर उन स्थितियों पर लागू किया जाता है जहाँ अंडे और टोकरी का analogy लागू नहीं होता या वास्तविकता से उल्टा होता है। लेकिन क्योंकि यह एक memorized phrase है, वे भूल जाते हैं कि एक metaphor है जिसे काम करने के लिए सही होना चाहिए। यह भयानक निर्णयों की ओर ले जा सकता है क्योंकि यह किसी भी आधार के बिना एक अतार्किक डर पैदा करता है।

इसी तरह, जो चीजें टूटी नहीं हैं उन्हें ठीक न करने का विचार इस सिद्धांत से आता है कि जो चीज पूरी तरह अच्छी और functional है उसे केवल छेड़छाड़ के लिए अलग नहीं किया जाना चाहिए। यह समझ में आता है। लेकिन किसी कारण से, यह तर्क लगभग कभी भी उन चीजों पर लागू नहीं होता जहाँ यह समझ में आए (मुझे एक अच्छे उदाहरण के बारे में सोचना मुश्किल लग रहा है) बल्कि इसके बजाय complex devices पर लागू किया जाता है जिन्हें ठीक से काम करने के लिए नियमित maintenance और upkeep की आवश्यकता होती है।

अगर आपका जूता टूटा नहीं है, तो इसे अलग मत करो और फिर से glue करने की कोशिश मत करो। लेकिन आपके business infrastructure systems एक जूते की तरह कुछ भी नहीं हैं। वे जीवित systems हैं जिनमें जटिलता के enormous levels हैं और जो एक ever changing landscape में काम करते हैं। उन्हें healthy रहने के लिए constant maintenance, oversight, updating और इसी तरह की चीजों की आवश्यकता होती है। एक car की तरह, लेकिन नाटकीय रूप से अधिक।

आप कभी नहीं, हम उम्मीद करते हैं, किसी को यह कहते हुए सुनते हैं कि आपको अपनी car का oil तब तक नहीं बदलना है जब तक engine seize न हो जाए। बिल्कुल नहीं, भले ही यह अभी तक टूटी नहीं है, बात यह है कि इसे टूटने से रोकने के लिए maintenance करना है। हम जानते हैं कि car के साथ अगर हम तब तक इंतजार करें जब तक यह टूटे, यह बहुत ज्यादा टूटी होगी। इसी तरह हम tyres में हवा तब तक भरने से इनकार नहीं करेंगे जब तक flat tyres wheels से उखड़ न जाएं। यह बस कोई मतलब नहीं रखता।

किसी को systems को तब तक maintain न करने के लिए कहना जब तक बहुत देर न हो जाए, उन्हें तोड़ने के लिए कहने के समान है। एक properly maintained car शायद hundreds of thousands of miles, शायद millions तक चल सकती है। बिना oil के वह शायद ही शहर पार कर पाए। हर कुछ दिनों में एक नया engine खरीदने के बजाय जिसकी आपके पास देखभाल है, आप पूरे जीवन में बिना engine destroy किए गुजार सकते हैं।

यही बात आपके business infrastructure पर भी लागू होती है। Code पुराना होता है, systems घिसते हैं, नई technology उभरती है, नई जरूरतें होती हैं, network बाहरी दुनिया के साथ interact करता है, नई features की आवश्यकता होती है, vulnerabilities और fragility की पहचान की जाती है और ठीक की जाती है, updates आते हैं, नए attacks विकसित होते हैं और इसी तरह। भले ही नई features कभी नहीं बनाई गईं, systems को safe और reliable operation सुनिश्चित करने के लिए diligently manage और maintain करने की आवश्यकता होती है – एक car की तरह लेकिन हजार गुना अधिक complex।

IT systems के संदर्भ में, टूटे होने का अर्थ है hacking, data theft, data loss, downtime और inefficiencies के लिए अनावश्यक रूप से उजागर होना। वास्तविक दुनिया में, हमें system को उसी क्षण टूटा हुआ मानना चाहिए जब maintenance की आवश्यकता हो। कितना ransomware आज एक खतरा नहीं होता अगर systems को बस properly maintained किया जाता? IT के रूप में हमें यह समझाने के लिए आगे आना होगा कि unmaintained systems पहले से टूटे हुए हैं, disaster अभी आया नहीं है।

अगर हम IT में “अगर टूटा नहीं है, तो ठीक मत करो” के mantra का पालन करते, तो हम data चोरी होने तक vulnerabilities को patch करने का इंतजार करते, या data unrecoverable होने तक देखते कि क्या हमारे पास working backups हैं। निश्चित रूप से, यह कोई मतलब नहीं रखता। लेकिन यही अक्सर suggest किया जाता है जब लोग आपको अपने systems को तब तक ठीक न करने के लिए कहते हैं जब तक वे टूट न जाएं – वे आपको उन्हें टूटने देने के लिए कह रहे हैं! पीछे हटें, इस प्रकार की सलाह को स्वीकार न करें। समझाएं कि अच्छे IT maintenance का उद्देश्य जब भी संभव हो systems को टूटने से बचाना है। आपदा से बचना, न कि उसे आमंत्रित करना।