छोटे वातावरण में Patching

Enterprise IT shops में, system patching एक जटिल प्रक्रिया है जिसमें बड़ी संख्या में test systems होते हैं जो production systems की नकल करते हैं, ताकि operating system और software vendors से आने वाले प्रत्येक नए patch को एक वास्तविक वातावरण में परखा जा सके कि वे संगठन में उपलब्ध hardware और software combinations के साथ कैसे काम करते हैं। एक आदर्श दुनिया में, हर shop में एक प्रबंधित patching प्रक्रिया होगी जो नए प्रकाशित patches पर तुरंत प्रतिक्रिया देती, तुरंत परीक्षण करती और जैसे ही patch सुरक्षित और लागू योग्य मानी जाती, उसे लागू कर देती। लेकिन दुनिया आदर्श नहीं है और वास्तविक जीवन में हमें सीमित संसाधनों से काम चलाना पड़ता है: भौतिक, समय और वित्तीय।

Patches सामान्यतः कुछ प्रमुख कारणों से जारी किए जाते हैं: security, stability, performance और, कभी-कभी, नई features प्रदान करने के लिए। नई features जोड़ने को छोड़कर, जिसे आमतौर पर एक अलग release process के माध्यम से संभाला जाता है, patches एक ज्ञात समस्या का समाधान होते हैं। यह “अगर टूटा नहीं है तो ठीक मत करो” वाला परिदृश्य नहीं है बल्कि “यह टूटा हुआ है और पूरी तरह विफल नहीं हुआ है अभी तक” वाला परिदृश्य है जो ध्यान मांगता है – जितनी जल्दी हो उतना बेहतर। Patches के लिए “बैठकर प्रतीक्षा करो” का दृष्टिकोण अविवेकपूर्ण है क्योंकि नए patch का अस्तित्व का मतलब है कि दुर्भावनापूर्ण hackers के पास विश्लेषण करने के लिए एक “fix” है और भले ही पहले कोई exploit नहीं था, बहुत जल्द होगा। Patch का जारी होना ही उस patch की तत्काल आवश्यकता का संकेत बन सकता है।

यह patch ecosystem एक “जल्दी patch करो” मानसिकता की आवश्यकता पैदा करता है। Patches को कभी रोककर नहीं रखना चाहिए, उन्हें जारी होते ही और परीक्षण के बाद अक्सर लागू करने की आवश्यकता होती है। Patching में देरी करने का मतलब critical security bugs के साथ चलना या systems को अनावश्यक रूप से अविश्वसनीय बनाए रखना है।

छोटे IT shops में शायद ही कभी test environments होते हैं, चाहे वे servers, networking equipment या desktops के लिए हों। आदर्श नहीं है, लेकिन वास्तविक रूप से, भले ही वे environments उपलब्ध हों, कुछ छोटे shops के पास उन tests को समय पर चलाने के लिए अतिरिक्त मानवीय IT संसाधन होते हैं।

यह उतना निराशाजनक नहीं है जितना लगता है। अधिकांश patches के लिए किया गया परीक्षण vendor द्वारा पहले से परखे गए patches के साथ redundant है। Vendors हर उस hardware और software interaction को संभवतः परख नहीं सकते जो उनके products के साथ हो सकती है, लेकिन वे आमतौर पर permutations की विस्तृत श्रृंखला का परीक्षण करते हैं और उन क्षेत्रों को देखते हैं जहां interactions सबसे अधिक होने की संभावना है। किसी प्रमुख vendor का अपने software को खराब patches से नुकसान पहुंचाना दुर्लभ है। हां, ऐसा होता है और अच्छे backups और rollback plans होना महत्वपूर्ण है, लेकिन दिन-प्रतिदिन के कार्यों में, patching एक अपेक्षाकृत सुरक्षित प्रक्रिया है जिसे तुरंत करना उन अवसरों की प्रतीक्षा करने से कहीं अधिक महत्वपूर्ण है जो हो भी सकते हैं या नहीं भी।

किसी भी system परिवर्तन की तरह, patches को बार-बार, छोटी मात्रा में लागू करना सबसे अच्छा है। यदि patches तुरंत लागू किए जाते हैं तो आमतौर पर एक ही समय में केवल एक या कुछ patches लागू करने होते हैं। Operating systems के लिए आपको अभी भी एक समय में कई patches से निपटना पड़ सकता है, विशेष रूप से यदि केवल साप्ताहिक patching की जाए, लेकिन इस तरह करने पर शायद ही कभी एक समय में दर्जनों या सैकड़ों files को patch करना पड़ता है। इस तरह करने पर patches के प्रतिकूल प्रभावों का मूल्यांकन करना और patch process के गलत होने पर rollback करना बहुत आसान है।

उचित patch testing workflow के बिना छोटे व्यवसाय के लिए सबसे खराब परिदृश्य patches में देरी करना है। प्रतीक्षा करने का मतलब है कि systems को लंबे समय तक आवश्यक देखभाल के बिना छोड़ा जाता है और जब patches अंत में लागू किए जाते हैं तो यह अक्सर बड़े, bulk patch processes में होता है। एक साथ कई patches लागू करने से कुछ गलत होने की संभावना बढ़ जाती है और जब ऐसा होता है, तो यह पहचानना कि कौन सा patch(es) दोषी है और remediation का रास्ता निकालना कहीं अधिक कठिन हो सकता है।

Delayed patching एक ऐसी प्रक्रिया है जो IT या व्यवसाय को कम या कोई फायदा नहीं देती लेकिन security, stability और performance के लिए पर्याप्त जोखिम उठाती है। छोटे वातावरण में patching के लिए best practices या तो systems को जितनी जल्दी हो सके self patch करने देना है या एक नियमित patching process निर्धारित करना है, शायद साप्ताहिक, उस समय के दौरान जब व्यवसाय patching के विफल होने और patch remediation को संभालने के लिए सबसे अधिक तैयार हो। चाहे आप स्वचालित रूप से patch करना चुनें या बस एक manual process के माध्यम से नियमित रूप से करें, सर्वोत्तम परिणामों के लिए अक्सर और तुरंत patch करें।