10.4 बड़े और दीर्घजीवी सिस्टमों को बनाए रखना

अवलोकन और प्रेरणा

सॉफ़्टवेयर इंजीनियरिंग के बारे में अधिकांश लेखन नई चीज़ें बनाने के बारे में है। लेकिन दुनिया का अधिकांश महत्वपूर्ण सॉफ़्टवेयर पुराना, बड़ा, और अभी भी चल रहा है: टैक्स सिस्टम, लाभ (बेनिफ़िट) भुगतान, एयर-ट्रैफ़िक कंट्रोल, कोर बैंकिंग, औद्योगिक नियंत्रण, और दैनिक जीवन का इन्फ्रास्ट्रक्चर। ये सिस्टम आमतौर पर दस, बीस, या तीस साल तक चलते हैं। यह उन्हें बनाने वाले किसी भी व्यक्ति के कार्यकाल से कहीं अधिक लंबा है, और अक्सर उन्हें बनाने वाली कंपनियों और भाषाओं से भी अधिक लंबा है। ऐसे सिस्टमों को बनाए रखने का अर्थ है उन्हें दशकों तक और स्टाफ़ की कई पीढ़ियों तक विश्वसनीय, सुरक्षित, समझा हुआ, और बदलने योग्य बनाए रखना। यह इस क्षेत्र के सबसे कठिन और सबसे कम आकर्षक अनुशासनों में से एक है, और एक ऐसा अनुशासन जहाँ बड़े एंटरप्राइज़ और सरकारें सबसे भारी बोझ उठाती हैं।

यह बड़े संगठनों के लिए अधिक क्यों मायने रखता है? दायित्व की निरंतरता। एक स्टार्टअप अपने सॉफ़्टवेयर को फिर से लिख सकता है या छोड़ सकता है। एक राष्ट्रीय सरकार रीफ़ैक्टर करते समय पेंशन देना बंद नहीं कर सकती। एंटरप्राइज़ और एजेंसियाँ ऐसे सिस्टमों की मालिक होती हैं जिनकी विफलता के परिणाम आजीविका, सुरक्षा, या सार्वजनिक भरोसे में मापे जाते हैं। और वे एक साथ इनमें से कई सिस्टमों की मालिक होती हैं, जिन्हें दशकों में जुड़ने और छोड़ने वाले लोग संचालित करते हैं। केंद्रीय खतरे विचित्र नहीं हैं। वे हैं उन लोगों का धीमा क्षरण जो सिस्टम को समझते हैं (बस फ़ैक्टर, यानी कितने कम लोगों के चले जाने पर सिस्टम का ज्ञान खो जाएगा), कुछ ही सिरों में अदस्तावेज़ीकृत ज्ञान का ढेर लगना, तकनीक स्टैक का एंड ऑफ़ लाइफ़ की ओर क्षय, और वह पक्षाघात जो तब आता है जब कोई सिस्टम छूने के लिए बहुत महत्वपूर्ण और सुरक्षित रूप से बदलने के लिए बहुत कम समझा हुआ हो जाता है।

यह अध्याय स्टीवर्डशिप के बारे में है: वह सोच-समझकर किया गया, बिना आकर्षण वाला काम जो किसी सिस्टम को उसके रचयिताओं से बेहतर ढंग से आगे टिकने में मदद करता है। इसमें स्वामित्व की निरंतरता और बस-फ़ैक्टर शमन, योजनाबद्ध डेप्रिकेशन और सनसेटिंग, ज्ञान हस्तांतरण, दशकों पुराने सिस्टमों की विशिष्ट चुनौतियाँ, और नवाचार तथा उस स्थिरता को बनाए रखने के बीच निरंतर संतुलन शामिल है जिस पर नागरिक और ग्राहक निर्भर करते हैं।

प्रमुख सिद्धांत

• हर महत्वपूर्ण सिस्टम को हमेशा एक स्वामी की आवश्यकता होती है। स्वामित्व एक निरंतर असाइनमेंट है, यह याद रखना नहीं कि इसे किसने लिखा था।
• जो ज्ञान केवल एक सिर में रहता है वह एक जोखिम है, संपत्ति नहीं। व्यक्ति के जाने से पहले समझ को संस्थागत बनाएं।
• उबाऊपन एक विशेषता है। दीर्घजीवी महत्वपूर्ण सिस्टमों के लिए, स्थिरता और पूर्वानुमेयता अक्सर नवीनता से आगे निकल जाती हैं।
• अंत की योजना शुरुआत में ही बनाएं। हर सिस्टम को कभी न कभी रिटायर या प्रतिस्थापित किया जाएगा; उस दिन के लिए डिज़ाइन और दस्तावेज़ीकरण करें।
• बदलाव ही सुरक्षित रहने का तरीका है। एक सिस्टम जो छूने में बहुत डरावना है वह पहले से ही विफल हो रहा है; बदलने की क्षमता एक अस्तित्व-गुण है।
• निरंतरता व्यक्तियों से आगे टिकती है। टीमों, दस्तावेज़ीकरण, और प्रक्रियाओं को इस तरह डिज़ाइन करें कि कोई एक व्यक्ति का जाना संकट न बने।
• भरोसा ही असली उत्पाद है। नागरिक- और ग्राहक-मुखी सिस्टमों के लिए, समय के साथ बनाए रखी गई विश्वसनीयता और निष्पक्षता ही मिशन है।

सिफारिशें

स्टीवर्डशिप और स्वामित्व की निरंतरता स्थापित करें

हर महत्वपूर्ण सिस्टम के लिए स्पष्ट, वर्तमान स्वामित्व सौंपें। व्यक्तिगत स्तर पर नहीं, टीम स्तर पर स्वामित्व रखें, ताकि स्वामित्व व्यक्तियों के जाने के बाद भी बना रहे। एक सर्विस कैटलॉग बनाए रखें जो हर सिस्टम के लिए यह दर्ज करे कि उसका स्वामी कौन है, वह क्या करता है, वह किस पर निर्भर है, और वह कितना महत्वपूर्ण है। स्वामित्व की नियमित समीक्षा करें, और किसी सिस्टम को कभी अनाथ न होने दें। बिना स्वामी वाला महत्वपूर्ण सिस्टम एक आपातकाल है जो घटित होने की प्रतीक्षा कर रहा है। जब टीमें पुनर्गठित होती हैं, तो अनुमान से नहीं बल्कि एक हैंडओवर के साथ सोच-समझकर स्वामित्व स्थानांतरित करें। सबसे महत्वपूर्ण दीर्घजीवी सिस्टमों के लिए, सुनिश्चित करें कि स्वामित्व में केवल संचालन ही नहीं बल्कि सिस्टम को समझने और बदलने की क्षमता भी शामिल हो, ताकि स्टीवर्डशिप केवल देखभाल (बेबीसिटिंग) में न बदल जाए।

बस फ़ैक्टर और की-पर्सन जोखिम को कम करें

ज्ञान की सघनता को सक्रिय रूप से मापें और कम करें। यदि केवल एक ही व्यक्ति किसी सिस्टम को डिप्लॉय, डीबग, या बदल सकता है, तो यह किसी भी हार्डवेयर जितना ही वास्तविक सिंगल पॉइंट ऑफ़ फ़ेल्यर है। इसे पेयरिंग और रोटेशन, अनिवार्य कोड समीक्षा, साझा ऑन-कॉल, और इस सोच-समझे नियम के ज़रिए घटाएं कि किसी भी महत्वपूर्ण कार्य के लिए ठीक एक ही सक्षम व्यक्ति न हो। क्रॉस-ट्रेन करें ताकि कम से कम दो (आदर्श रूप से तीन) लोग हर आवश्यक कार्य कर सकें। किसी महत्वपूर्ण व्यक्ति के जाने को एक पूर्वानुमेय घटना के रूप में मानें जिसके लिए आप निरंतर तैयारी करते हैं, न कि एक झटके के रूप में जिसे आप सहन करते हैं। दस्तावेज़ीकरण मदद करता है। लेकिन वास्तविक अभ्यास के ज़रिए पूरी टीम में फैला हुआ कार्यशील ज्ञान उन दस्तावेज़ों से कहीं अधिक टिकाऊ है जिन्हें किसी ने कभी आज़माया नहीं।

ज्ञान हस्तांतरण को संस्थागत बनाएं

उस ज्ञान को संचित करें जो अन्यथा लोगों के साथ चला जाएगा। पहले उस ज्ञान पर ध्यान दें जिसे फिर से बनाना कठिन है: निर्णय क्यों लिए गए, किन विकल्पों को क्यों अस्वीकार किया गया, नुकीले किनारे और वे महत्वपूर्ण हैक्स कहाँ हैं जिन पर बाकी सिस्टम चुपचाप निर्भर करता है, और तनाव के तहत सिस्टम कैसा व्यवहार करता है। विकल्पों के पीछे के तर्क को संरक्षित करने के लिए आर्किटेक्चर डिसीज़न रिकॉर्ड का उपयोग करें, न कि केवल विकल्पों को। रनबुक और परिचालन दस्तावेज़ीकरण को सिस्टम के करीब रखें, और उन्हें सच बनाए रखने के लिए नियमित रूप से आज़माएँ। ऐसे ऑनबोर्डिंग पथ बनाएं जो नए स्टीवर्ड को वास्तविक दक्षता तक पहुँचाएँ। प्रस्थान को वास्तविक हैंडओवर समय के साथ ज्ञान-हस्तांतरण घटनाओं के रूप में मानें। याद रखें कि टेसिट नॉलेज (सिस्टम की समझ, “फ़ील”), मुख्य रूप से उस व्यक्ति के साथ काम करते हुए स्थानांतरित होता है जिसके पास वह है, इसलिए जहाँ संभव हो वहाँ जाने वाले और आने वाले स्टीवर्ड के बीच ओवरलैप रखें।

डेप्रिकेशन, सनसेटिंग, और एंड-ऑफ़-लाइफ़ का प्रबंधन करें

अंत की योजना सोच-समझकर बनाएं। जब आप किसी सिस्टम को रिटायर या प्रतिस्थापित करने का निर्णय लेते हैं, तो सनसेट को अपने आप में एक परियोजना के रूप में मानें: हर उपभोक्ता और निर्भरता की पहचान करें, एक माइग्रेशन पथ और एक यथार्थवादी समयसीमा प्रदान करें, स्पष्ट रूप से और बार-बार संवाद करें, और संक्रमण के दौरान उपभोक्ताओं का समर्थन करें। पुराने और नए सिस्टमों को हमेशा के लिए समानांतर चलाने के जाल से बचें क्योंकि कोई भी पुराने को बंद करने का कठिन काम नहीं करेगा। डीकमीशन को पूरा करने के लिए स्पष्ट जवाबदेही सौंपें। डेटा, रिकॉर्ड, और रिटायर हो चुके सिस्टम के बारे में सवालों के जवाब देने की क्षमता को लंबे समय तक संरक्षित रखें, विशेष रूप से जहाँ कानूनी प्रतिधारण (रिटेंशन) नियम लागू होते हैं। खराब ढंग से किया गया सनसेट ज़ॉम्बी सिस्टम छोड़ जाता है जो अनमेंटेन्ड हैं लेकिन फिर भी उन पर निर्भरता है: यह सभी दुनियाओं में सबसे बुरा है।

दशकों में सिस्टमों को बनाए रखें

उन सिस्टमों के लिए जिन्हें बीस या तीस साल तक चलना होता है, हर चीज़ से आगे टिकने की योजना बनाएं: मूल टीम, विक्रेता, भाषा पारिस्थितिकी तंत्र, और हार्डवेयर। प्रोप्राइटरी ब्लैक बॉक्स की तुलना में ओपन स्टैंडर्ड और दस्तावेज़ीकृत इंटरफ़ेस को प्राथमिकता दें, ताकि भविष्य के अनुरक्षकों को एक मौका मिले। मॉड्यूलराइज़ करें, ताकि हिस्सों को एक-एक करके बदला जा सके, न कि किसी ऐसे सब-कुछ-या-कुछ-नहीं रीराइट के ज़रिए जो प्रयास करने के लिए बहुत जोखिम भरा हो। सिस्टम को निरंतर मेंटेन रखें। जो सिस्टम छोटे-छोटे कदमों में अद्यतन रखा जाता है वह टिकाऊ बना रहता है। “क्योंकि यह काम करता है” के आधार पर जमाया गया सिस्टम चुपचाप अनमेंटेनेबल हो जाता है जैसे-जैसे इसका स्टैक सपोर्ट से बाहर होता जाता है। इसे संचालित करने के कौशल भी बनाए रखें: सचमुच पुरानी तकनीक के लिए, यह उम्मीद करने के बजाय कि आखिरी विशेषज्ञ कभी रिटायर नहीं होगा, जानबूझकर उत्तराधिकारियों को प्रशिक्षित करें।

नवाचार को स्थिरता और भरोसे के साथ संतुलित करें

अपने एस्टेट के उन हिस्सों को अलग पहचानें जहाँ नवीनता मूल्य पैदा करती है उन हिस्सों से जहाँ स्थिरता ही मूल्य है। जिन कोर सिस्टमों पर नागरिक और ग्राहक रोज़ाना निर्भर करते हैं वे आमतौर पर रोमांचक रीराइट के बजाय विश्वसनीयता, बैकवर्ड कम्पैटिबिलिटी, और सतर्क बदलाव को पुरस्कृत करते हैं। किनारों पर नवाचार में निवेश करें (नए चैनल, नए फ़ीचर, नए इंटरफ़ेस) जबकि टिकाऊ कोर को स्थिर और अच्छी तरह समझा हुआ बनाए रखें। कोर को बदलें, हाँ, लेकिन वीरतापूर्ण छलांगों के बजाय छोटे, प्रतिवर्तनीय, अच्छी तरह परीक्षित इंक्रीमेंट में। लक्ष्य एक ऐसा सिस्टम है जो भरोसेमंद भी हो और विकसित होने में सक्षम भी: कभी इतना जमा हुआ नहीं कि वह सड़ जाए, कभी इतना उथल-पुथल भरा नहीं कि वह अविश्वसनीय हो जाए।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

दृष्टिकोण	फ़ायदे	नुकसान
पुराने सिस्टम को बनाए रखें और मेंटेन करें	संस्थागत ज्ञान को संरक्षित करता है; कम व्यवधान; सिद्ध विश्वसनीयता	बूढ़ा होता स्टैक; दुर्लभ कौशल; अनमेंटेन्ड रहने पर बढ़ता जोखिम
बिग-बैंग रीराइट	ताज़ा स्टैक; जमा हुआ कचरा हटता है	बहुत उच्च विफलता दर; कठिनाई से अर्जित एज-केस ज्ञान खो जाता है
इंक्रीमेंटल आधुनिकीकरण	निरंतर जोखिम में कमी; चलता रहता है	धीमा; निरंतर फंडिंग और अनुशासन आवश्यक
दस्तावेज़ीकरण-भारी हस्तांतरण	स्पष्ट, खोजने योग्य रिकॉर्ड	अनमेंटेन्ड रहने पर क्षय होता है; टेसिट नॉलेज छूट जाता है
व्यक्ति-आधारित हस्तांतरण (पेयरिंग/रोटेशन)	टिकाऊ कार्यशील ज्ञान; रेज़िलिएंट टीमें	वर्तमान प्रोडक्टिविटी की लागत; सोच-समझकर शेड्यूलिंग आवश्यक
महत्वपूर्ण कोर को जमा दें	अल्पकालिक अधिकतम स्थिरता	स्टैक अनमेंटेनेबिलिटी में बूढ़ा होता है; छूने के लिए बहुत डरावना हो जाता है

परिभाषित ट्रेड-ऑफ़ है स्थिरता बनाम विकास, और दोनों भोले समाधान विफल होते हैं। किसी महत्वपूर्ण सिस्टम को बचाने के लिए उसे जमा दें, और आप गारंटी देते हैं कि वह अंततः अनमेंटेनेबल और असुरक्षित हो जाएगा। आधुनिकीकरण के लिए उसे पूरी तरह से फिर से लिखें, और आप उस उच्च विफलता दर को आमंत्रित करते हैं जिसके लिए बिग-बैंग प्रतिस्थापन कुख्यात हैं, और आप दशकों के उस एन्कोडेड एज-केस ज्ञान को त्याग देते हैं जिसके वहाँ होने को कोई याद नहीं रखता। टिकाऊ रास्ता है निरंतर, इंक्रीमेंटल बदलाव: सिस्टम को ज़िंदा रखें और छोटे-छोटे कदमों में आगे बढ़ाते रहें, ताकि यह कभी सपोर्ट से बाहर न हो और कभी किसी डरावनी छलांग की ज़रूरत न पड़े। ज्ञान हस्तांतरण एक समान ट्रेड-ऑफ़ है, दस्तावेज़ों की सरलता और अनुभवजन्य ज्ञान की टिकाऊपन के बीच। उत्तर है दोनों: अनुभवजन्य, टीम-धारित ज्ञान रीढ़ के रूप में, और दस्तावेज़ संदर्भ के रूप में।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. अभी आपके किन महत्वपूर्ण सिस्टमों का कोई वर्तमान, नामित टीम स्वामी नहीं है? स्वामित्व एक निरंतर असाइनमेंट है, यह याद रखना नहीं कि कोड किसने लिखा, और बिना स्वामी वाला महत्वपूर्ण सिस्टम एक आपातकाल है जो घटित होने की प्रतीक्षा कर रहा है, जिस पर तभी ध्यान जाता है जब वह टूटता है। अपने सर्विस कैटलॉग को देखें (या एक बनाएं) और जाँचें कि हर सिस्टम यह दर्ज करता है कि उसका स्वामी कौन है, वह किस पर निर्भर है, और वह कितना महत्वपूर्ण है। प्रमाण लाएँ: तीन महत्वपूर्ण सिस्टम चुनें और जवाबदेह टीम तथा स्वामित्व की आखिरी समीक्षा की तारीख़ बताने की कोशिश करें। जहाँ कोई सिस्टम अनाथ हो, या जहाँ किसी पुनर्गठन ने चुपचाप उसे छोड़ दिया हो, वहाँ अनुमान से नहीं बल्कि एक वास्तविक हैंडओवर के साथ सोच-समझकर स्वामित्व सौंपें। सुनिश्चित करें कि स्वामित्व में सिस्टम को समझने और बदलने की क्षमता शामिल हो, ताकि स्टीवर्डशिप केवल देखभाल में न बदल जाए।

2. जब आप किसी सिस्टम को बदलते हैं, तो पुराने को वास्तव में बंद करने के लिए कौन जवाबदेह है? अनंत समानांतर रन एक आम और महंगी विफलता है: पुराने और नए सिस्टम अनिश्चित काल तक साथ-साथ चलते हैं क्योंकि शटडाउन का कोई स्वामी नहीं है, जिससे आप दो सिस्टमों को मेंटेन करते रहते हैं और किसी की भी सुरक्षा नहीं पाते। हर सनसेट को डीकमीशन पूरा करने के लिए नामित जवाबदेही, उपभोक्ताओं की एक मैप की गई सूची, एक माइग्रेशन पथ, और एक यथार्थवादी समयसीमा वाली प्रबंधित परियोजना के रूप में मानें। प्रमाण लाएँ: आज आपके एस्टेट में कितने “अस्थायी” समानांतर रन या आधे-रिटायर सिस्टम अभी भी मेंटेनेंस खींच रहे हैं? सिस्टम के चलना बंद करने के बहुत बाद तक कानूनी प्रतिधारण नियमों को पूरा करने के लिए डेटा और रिकॉर्ड संरक्षित रखें, लेकिन प्रतिधारण को कभी न ख़त्म करने का बहाना न बनने दें। खराब ढंग से किया गया सनसेट ज़ॉम्बी सिस्टम छोड़ जाता है जो अनमेंटेन्ड हैं लेकिन फिर भी उन पर निर्भरता है, जो सबसे बुरी स्थिति है।

3. आपके दीर्घजीवी सिस्टमों के लिए कौन-से कौशल श्रम बाज़ार आपूर्ति करना बंद कर देगा, और आपकी उत्तराधिकार योजना क्या है? बीस या तीस साल तक चलने वाले सिस्टम अपनी भाषा पारिस्थितिकी तंत्र, अपने विक्रेताओं, और पुराने स्टैक को समझने वाले लोगों के करियर से भी आगे टिकते हैं, और बाज़ार आपको विश्वसनीय रूप से प्रतिस्थापन नहीं देगा। बस फ़ैक्टर को जानबूझकर घटाएं ताकि किसी भी महत्वपूर्ण कार्य के लिए ठीक एक ही सक्षम व्यक्ति न हो, और क्रॉस-ट्रेन करें ताकि कम से कम दो, आदर्श रूप से तीन, लोग हर आवश्यक कार्य कर सकें। प्रमाण लाएँ: हर बूढ़े होते महत्वपूर्ण सिस्टम के लिए, गिनें कि कितने लोग इसे सुरक्षित रूप से बदल सकते हैं और सबसे अधिक जानकार लोग रिटायरमेंट के कितने करीब हैं। उत्तर को उत्तराधिकारियों के सोच-समझे प्रशिक्षण और जाने वाले तथा आने वाले स्टीवर्ड के बीच वास्तविक ओवरलैप को गति देना चाहिए, क्योंकि टेसिट नॉलेज (सिस्टम की समझ) मुख्य रूप से उस व्यक्ति के साथ काम करते हुए स्थानांतरित होता है जिसके पास वह है। दस्तावेज़ संदर्भ हैं; अनुभवजन्य, टीम-धारित ज्ञान रीढ़ है।

4. आपने अपने सबसे महत्वपूर्ण दीर्घजीवी सिस्टम को आखिरी बार कब बदला था, और क्या कोई अभी भी ऐसा करने का साहस करता है? एक साल से जिसे किसी ने नहीं छुआ है वह सिस्टम स्थिर नहीं है, वह “छूने के लिए बहुत डरावना” जाल की ओर बह रहा है, जहाँ हर बदलाव से डर लगता है और इसलिए स्टैक चुपचाप सपोर्ट से बाहर होता जाता है। एक बड़े संगठन के लिए यह मायने रखता है क्योंकि पक्षाघात चक्रवृद्धि होता है: जितना लंबा फ़्रीज़, उतना ही अधिक ज्ञान फीका पड़ता है और अंततः अपरिहार्य बदलाव उतना ही जोखिम भरा हो जाता है। प्रमाण लाएँ: हर महत्वपूर्ण सिस्टम के लिए, आखिरी सोच-समझे बदलाव की तारीख़, आज कोई भी जो सबसे छोटा बदलाव करने की कोशिश करेगा उसका आकार, और क्या कोई नियमित निर्भरता या सुरक्षा पैच बिना किसी वीरतापूर्ण प्रयास के इस हफ़्ते शिप किया जा सकता है। प्रतिस्पर्धी विचार वास्तविक है, क्योंकि बदलाव भी जोखिम लाता है, इसलिए लक्ष्य उथल-पुथल नहीं बल्कि छोटे, प्रतिवर्तनीय, अच्छी तरह परीक्षित कदमों की एक स्थिर लय है। एंटरप्राइज़ और सरकारी एस्टेट में, जहाँ एक जमा हुआ कोर एक दशक तक किसी नागरिक सेवा के नीचे बैठा रह सकता है, “हम इसे कभी नहीं बदलते” को आश्वासन के बजाय एक चेतावनी संकेत मानें, और उस निरंतर मेंटेनेंस को फंड करें जो बदलने के विकल्प को ज़िंदा रखता है।

5. आपका कितना एस्टेट ऐसी तकनीक पर चल रहा है जो एंड ऑफ़ लाइफ़ पर या उसके नज़दीक है, और उस घड़ी को कौन ट्रैक कर रहा है? बूढ़े होते रनटाइम, अनसपोर्टेड डेटाबेस, और मेंटेनेंस से बाहर हो चुके फ़्रेमवर्क वह धीमी विफलता का तरीका है जो उस दिन अचानक संकट में बदल जाता है जिस दिन सुरक्षा पैच आना बंद हो जाता है। एक बड़ी टीम के लिए खतरा यह है कि कोई भी क्षितिज का स्वामी नहीं है: अलग-अलग टीमें जो टूटता है उसे पैच करती हैं, लेकिन कोई भी यह पोर्टफ़ोलियो दृष्टिकोण नहीं रखता कि कौन-से स्टैक कब विक्रेता सपोर्ट खो देंगे। प्रमाण लाएँ: हर महत्वपूर्ण सिस्टम की कोर तकनीकों की एक इन्वेंट्री, उनकी प्रकाशित एंड-ऑफ़-लाइफ़ या एंड-ऑफ़-सपोर्ट तारीख़ें, और आप जो चला रहे हैं और जो अभी भी सपोर्टेड है उसके बीच वर्तमान अंतर। तनाव निरंतर अपग्रेडिंग की लागत और टालमटोल के जोखिम के बीच है, और टालमटोल आमतौर पर तब तक जीतता है जब तक वह विनाशकारी रूप से हार न जाए। एंटरप्राइज़ और सरकारी परिवेश में, जहाँ खरीद और मान्यता (एक्रेडिटेशन) चक्र एक साल या उससे अधिक ले सकते हैं, दूर दिखने वाली एक एंड-ऑफ़-लाइफ़ तारीख़ अक्सर पहले से ही आपके लीड टाइम के भीतर होती है, इसलिए उत्तराधिकार और अपग्रेड का काम घड़ी के खत्म होने से काफ़ी पहले शुरू होना चाहिए।

6. आपके एस्टेट में कहाँ स्थिरता मूल्य है और नवीनता एक दायित्व, और आप उस सीमा को ईमानदार कैसे बनाए रखते हैं? हर सिस्टम एक जैसा व्यवहार नहीं चाहता: जिन कोर सिस्टमों पर नागरिक और ग्राहक रोज़ाना निर्भर करते हैं वे आमतौर पर विश्वसनीयता और सतर्क बदलाव को पुरस्कृत करते हैं, जबकि किनारे प्रयोग को पुरस्कृत करते हैं, और दोनों को गड्डमड्ड करना पैसा बर्बाद करता है या आउटेज को आमंत्रित करता है। एक बड़े संगठन के लिए जोखिम यह है कि महत्वाकांक्षा और करियर प्रोत्साहन रोमांचक रीराइट को ठीक उसी टिकाऊ कोर में धकेल देते हैं जिसे उबाऊ ही रहना चाहिए। प्रमाण लाएँ: आपके एस्टेट का एक मानचित्र जो यह चिन्हित करे कि विश्वसनीयता कहाँ मिशन है और नवीनता कहाँ मूल्य पैदा करती है, साथ ही हाल के वे बदलाव जिन्होंने उस रेखा को किसी भी दिशा में पार किया और उनकी लागत क्या थी। प्रतिस्पर्धी विचार यह है कि एक स्थिर कोर को भी अभी भी विकसित होना चाहिए, इसलिए “स्थिर” जमा देने का बहाना नहीं बन सकता। एंटरप्राइज़ और सरकारी संदर्भों में, इस सीमा को स्पष्ट क्रिटिकैलिटी स्तरों और एक नामित प्राधिकरण से जोड़ें जो किसी ऐसे सिस्टम के जोखिम भरे रीराइट को वीटो कर सके जिसे जनता विफल होते नहीं देख सकती, ताकि निर्णय इस तिमाही जो भी सबसे ज़ोर से बोल रहा हो उसके साथ न बहे।

सेक्टर लेंस

स्टार्टअप। मुट्ठी भर इंजीनियरों और कम रनवे के साथ, आपका सस्टेनमेंट जोखिम एक या दो लोगों में केंद्रित है जिन्होंने वे सिस्टम लिखे जिन्हें आप खोना अफ़ोर्ड नहीं कर सकते, जैसे बिलिंग या ऑथ। प्रक्रिया पर लगभग कुछ भी खर्च न करें, लेकिन अभी सस्ती, उच्च-मूल्य वाली चीज़ें करें: हर महत्वपूर्ण सिस्टम के लिए एक दूसरे व्यक्ति को पेयर करें, चौंकाने वाले हिस्सों के लिए एक-पृष्ठ का आर्किटेक्चर डिसीज़न रिकॉर्ड लिखें, और एक रनबुक रखें जिसे आप वास्तव में उपयोग करते हैं। किसी चीज़ को केवल इसलिए फिर से लिखने की इच्छा का विरोध करें क्योंकि वह पुरानी है, क्योंकि आपके आकार पर किसी कोर सिस्टम का विफल रीराइट कंपनी को खत्म कर सकता है।

लघु व्यवसाय। आपके पास कोई समर्पित मेंटेनेंस टीम नहीं है और एक सीमित बजट है, इसलिए किसी भी ऐसी चीज़ को बनाने के बजाय जिसे आपको खुद बनाए रखना होगा, खरीदने और होस्ट करने को प्राथमिकता दें। ऐसे विक्रेताओं और ओपन स्टैंडर्ड को प्राथमिकता दें जो आपको छोड़ने की अनुमति दें, और एक सरल रिकॉर्ड रखें कि कौन-सा बाहरी सिस्टम कौन-सा महत्वपूर्ण कार्य चलाता है और टूटने पर किसे बुलाना है। जहाँ आप स्वयं कस्टम कोड के मालिक हैं, सुनिश्चित करें कि कम से कम दो लोग (या एक विश्वसनीय कॉन्ट्रैक्टर और एक कर्मचारी) इसे समझें, ताकि एक अकेले व्यक्ति के जाने या समाप्त हो चुके सपोर्ट कॉन्ट्रैक्ट से आप फँसें नहीं।

एंटरप्राइज़। आपकी चुनौती पोर्टफ़ोलियो स्केल है: कई दीर्घजीवी सिस्टम, कई टीमें, और दशकों में घूमने वाला स्टाफ़। सर्विस कैटलॉग में टीम-स्तरीय स्वामित्व को मानकीकृत करें, पूरे एस्टेट में बस फ़ैक्टर को मापें, और बिग-बैंग रीराइट पर दांव लगाने के बजाय निरंतर इंक्रीमेंटल आधुनिकीकरण को फंड करें। एंड-ऑफ़-लाइफ़ क्षितिजों को केंद्रीय रूप से गवर्न करें ताकि कोई भी महत्वपूर्ण स्टैक चुपचाप सपोर्ट से बाहर न हो जाए, और हर सनसेट को डीकमीशन पूरा करने के लिए नामित जवाबदेही वाली एक ऑडिटेड परियोजना के रूप में चलाएं।

सरकार। दायित्व की निरंतरता निरपेक्ष है: आप रीफ़ैक्टर करते समय लाभ का भुगतान करना या एयर-ट्रैफ़िक कंट्रोल चलाना बंद नहीं कर सकते, और विफलताएँ सार्वजनिक और गंभीर परिणाम वाली होती हैं। खरीद नियम आपको ओपन स्टैंडर्ड, डेटा पोर्टेबिलिटी, और दस्तावेज़ीकृत इंटरफ़ेस की ओर धकेलते हैं ताकि भविष्य के अनुरक्षकों और भविष्य के विक्रेताओं को एक मौका मिले। श्रम बाज़ार द्वारा अब आपूर्ति न की जाने वाली पुरानी तकनीकों के लिए सोच-समझे उत्तराधिकार प्रशिक्षण को फंड करें, वैधानिक प्रतिधारण को पूरा करने के लिए रिटायर हो चुके सिस्टमों के रिकॉर्ड संरक्षित रखें, और नागरिक सेवाओं की निरंतर विश्वसनीयता को ओवरहेड के बजाय जवाबदेह मिशन के रूप में मानें।

उदाहरण

स्टार्टअप। पाँच लोगों के एक स्टार्टअप के पास पहले से ही एक ऐसा सिस्टम है जिसे वह खोना अफ़ोर्ड नहीं कर सकता: बिलिंग सर्विस जो एक संस्थापक ने पहले महीने में लिखी थी और जो अब हर ग्राहक शुल्क चलाती है। केवल वही संस्थापक इसे समझता है, इसलिए टीम बस फ़ैक्टर को एक तारीफ़ के बजाय एक वास्तविक जोखिम के रूप में मानती है। वे एक दूसरे इंजीनियर को पूरे बिलिंग चक्र में पेयर करते हैं, यह समझाते हुए एक छोटा आर्किटेक्चर डिसीज़न रिकॉर्ड लिखते हैं कि विचित्र रीट्राई लॉजिक क्यों मौजूद है, और कोड के बगल में एक रनबुक रखते हैं जिसे वे किसी घटना के दौरान वास्तव में आज़माते हैं। वे इसे केवल इसलिए फिर से लिखने का विरोध करते हैं क्योंकि यह पुराना और बिना आकर्षण वाला है, और इसके बजाय इसे छोटे प्रतिवर्तनीय कदमों में सुधारते हैं, ताकि जो सर्विस कंपनी को ज़िंदा रखती है उसे एक से अधिक सिर समझें।

एंटरप्राइज़। एक बड़ी बीमा कंपनी एक पॉलिसी-प्रशासन सिस्टम चलाती है जो पहली बार दशकों पहले लिखा गया था और अभी भी उसके व्यवसाय के केंद्र में है। एक जोखिम भरे संपूर्ण रीराइट का प्रयास करने के बजाय, इसने सिस्टम को अच्छी तरह से परिभाषित इंटरफ़ेस के पीछे मॉड्यूलराइज़ किया और अब एक बार में एक घटक बदलती है, हर बदलाव छोटा और प्रतिवर्तनीय। हर महत्वपूर्ण कार्य के लिए कम से कम तीन लोग हैं जो इसे कर सकते हैं। ऑन-कॉल साझा है। आर्किटेक्चर डिसीज़न रिकॉर्ड यह दर्ज करते हैं कि सिस्टम जिस तरह काम करता है वह क्यों करता है। एक क्यूरेटेड आंतरिक कोर्स नए इंजीनियरों को लीगेसी स्टैक पर दक्षता तक लाता है, और जाने वाले विशेषज्ञ उत्तराधिकारियों के साथ ओवरलैप करते हैं ताकि टेसिट नॉलेज काम करते हुए स्थानांतरित हो।

सरकार। एक राष्ट्रीय सामाजिक-सुरक्षा एजेंसी लाभ-भुगतान सिस्टम संचालित करती है जो तीस साल से अधिक समय से चल रहे हैं और रुक नहीं सकते। यह एक सर्विस कैटलॉग में स्पष्ट टीम स्वामित्व दर्ज करती है। यह सिस्टमों को जमाने के बजाय निरंतर मेंटेनेंस को फंड करती है। यह पुरानी तकनीकों में उत्तराधिकारियों को जानबूझकर प्रशिक्षित करती है, क्योंकि श्रम बाज़ार उन्हें आपूर्ति नहीं करेगा। जब यह किसी अप्रचलित सबसिस्टम को रिटायर करती है, तो यह सनसेट को एक प्रबंधित परियोजना के रूप में चलाती है: हर उपभोक्ता का मानचित्रण, माइग्रेशन सहायता प्रदान करना, कानूनी प्रतिधारण नियमों को पूरा करने के लिए रिकॉर्ड संरक्षित रखना, और डीकमीशन को वास्तव में पूरा करने के लिए जवाबदेही सौंपना, ताकि कोई ज़ॉम्बी सिस्टम न बचे।

व्यवसाय मामला: प्रेरणाएँ, ROI, और TCO

दीर्घजीवी सिस्टमों को बनाए रखने का रिटर्न उन दो विनाशकारी विफलता के तरीकों से बचने से आता है जो उनकी कुल स्वामित्व लागत पर हावी रहते हैं। पहला है अचानक संकट: कोई महत्वपूर्ण व्यक्ति चला जाता है, कोई अनसपोर्टेड घटक भंग हो जाता है, या कोई अनाथ सिस्टम बिना किसी समझने वाले के विफल हो जाता है। दूसरा है विफल मेगा-प्रोजेक्ट: एक जल्दबाज़ी में किया गया संपूर्ण रीराइट जो ओवररन होता है, कम डिलीवर करता है, या ध्वस्त हो जाता है। दोनों बेहद महंगे हैं, और दोनों को स्थिर स्टीवर्डशिप से काफ़ी हद तक रोका जा सकता है। एक टाले गए रीराइट विफलता, या किसी महत्वपूर्ण नागरिक सेवा के एक टाले गए विस्तारित आउटेज की लागत, आमतौर पर वर्षों के निरंतर मेंटेनेंस निवेश से अधिक होती है।

अपनाने की लागत निरंतर और बिना आकर्षण वाली है: ऐसे मेंटेनेंस को फंड करना जो कोई नया फ़ीचर उत्पन्न नहीं करता, क्रॉस-ट्रेनिंग और दस्तावेज़ीकरण के समय के लिए भुगतान करना जो अल्पकालिक आउटपुट घटाता है, और इंक्रीमेंटल आधुनिकीकरण में निवेश करना जो कभी सुर्खियाँ नहीं बनाता। इसे न अपनाने की लागत टली हुई और बड़ी है: स्टैक के बूढ़े होने के साथ बढ़ता जोखिम, बढ़ता हुआ की-पर्सन एक्सपोज़र, और अंततः आपातकालीन परिस्थितियों में एक मजबूर, उच्च-जोखिम, उच्च-लागत प्रतिस्थापन। जब आप नेतृत्व के सामने मामला रखें, तो मेंटेनेंस को “कॉस्ट सेंटर” से “उन सिस्टमों के लिए जोखिम प्रबंधन जिन्हें संगठन खोना अफ़ोर्ड नहीं कर सकता” के रूप में फिर से तैयार करें। केवल निर्माण के बजाय पूरे बहु-दशकीय जीवन (जिसमें सस्टेनमेंट और अंततः डीकमीशन शामिल है) में कुल स्वामित्व लागत प्रस्तुत करें। और इस पर ज़ोर दें: नागरिक- और ग्राहक-मुखी सिस्टमों के लिए, निरंतर विश्वसनीयता ओवरहेड नहीं है। यह वह भरोसा है जो वास्तविक उत्पाद है।

एंटी-पैटर्न और नुकसान

• हीरो मेंटेनर। एक अपूरणीय व्यक्ति जो सिस्टम को समझता है; उसका जाना एक अस्तित्व संबंधी घटना है।
• फ़्रीज़ और भूल जाओ। किसी महत्वपूर्ण सिस्टम को “पूर्ण” घोषित करना, मेंटेनेंस रोक देना, और इसके स्टैक को अनमेंटेनेबिलिटी में बूढ़ा होते देखना।
• अभिशप्त रीराइट। संगठन को एक संपूर्ण प्रतिस्थापन पर दांव पर लगाना जो एन्कोडेड ज्ञान को त्याग देता है और आमतौर पर ओवररन होता है या विफल होता है।
• अनाथ सिस्टम। बिना किसी वर्तमान स्वामी वाला महत्वपूर्ण सॉफ़्टवेयर, जिस पर तभी ध्यान जाता है जब वह टूटता है।
• दस्तावेज़ीकरण थिएटर। पुराने, कभी न आज़माए गए, और किसी के भी भरोसे के लायक न रहे दस्तावेज़ों के ढेर।
• अनंत समानांतर रन। पुराने और नए सिस्टम अनिश्चित काल तक साथ-साथ चलते हैं क्योंकि शटडाउन के लिए कोई जवाबदेह नहीं है।
• टेसिट-नॉलेज की हानि। बिना किसी ओवरलैप के विशेषज्ञों को जाने देना, जिससे सिस्टम की समझ वाष्पित हो जाती है।
• छूने के लिए बहुत डरावना। एक सिस्टम जो इतना कम समझा गया है कि किसी भी बदलाव से डर लगता है, जो उसके क्षय की गारंटी देता है।

परिपक्वता मॉडल

स्तर 1: प्रारंभ। सस्टेनमेंट तदर्थ और प्रतिक्रियात्मक है। सिस्टम व्यक्तिगत हीरो पर निर्भर करते हैं, स्वामित्व सौंपा नहीं जाता बल्कि याद रखा जाता है, और ज्ञान कुछ ही सिरों में अदस्तावेज़ीकृत रहता है। पुराने सिस्टम तब तक जमे रहते हैं जब तक वे टूट न जाएँ, बूढ़े होते स्टैक बिना ध्यान दिए एंड ऑफ़ लाइफ़ की ओर बहते हैं, और रिटायरमेंट की घोषणा की जाती है लेकिन कभी पूरी नहीं होती।

स्तर 2: विकास। बुनियादी प्रथाएँ सामने आती हैं लेकिन टीम-दर-टीम भिन्न होती हैं। सबसे स्पष्ट प्रमुख सिस्टमों के लिए स्वामित्व लिख दिया जाता है, कुछ रनबुक और दस्तावेज़ीकरण मौजूद है, और कुछ महत्वपूर्ण कार्यों के लिए एक दूसरा सक्षम व्यक्ति है। मेंटेनेंस फंडेड है लेकिन प्रतिक्रियात्मक है, क्रॉस-ट्रेनिंग तब होती है जब किसी को याद आता है, और संगठन भर में इनमें से किसी को करने का कोई साझा तरीका नहीं है।

स्तर 3: मानकीकरण। स्टीवर्डशिप प्रथाओं का दस्तावेज़ीकरण किया जाता है और संगठन भर में लागू किया जाता है। टीम-स्तरीय स्वामित्व एक सर्विस कैटलॉग में दर्ज होता है और पुनर्गठनों के बाद भी बना रहता है। रोटेशन और क्रॉस-ट्रेनिंग के ज़रिए बस-फ़ैक्टर शमन एक स्थायी नियम है, आर्किटेक्चर डिसीज़न रिकॉर्ड और आज़माए गए रनबुक अपेक्षित हैं, आधुनिकीकरण नीति के अनुसार इंक्रीमेंटल है, और हर सनसेट डीकमीशन पूरा करने के लिए नामित जवाबदेही वाली एक प्रबंधित परियोजना के रूप में चलता है।

स्तर 4: प्रबंधन। सस्टेनमेंट को बेसलाइन के विरुद्ध डेटा के साथ मापा और नियंत्रित किया जाता है। आप हर महत्वपूर्ण सिस्टम के लिए बस फ़ैक्टर, हर एक को सुरक्षित रूप से बदल सकने वाले लोगों की संख्या, हर कोर तकनीक की उम्र उसकी एंड-ऑफ़-लाइफ़ तारीख़ के विरुद्ध, निरंतर बनाम टाले गए मेंटेनेंस के तहत एस्टेट का हिस्सा, और रुके हुए समानांतर रन तथा आधे-पूर्ण डीकमीशन की संख्या को ट्रैक करते हैं। इन मेट्रिक्स के साथ ऐसे थ्रेशोल्ड जुड़े होते हैं जो कार्रवाई ट्रिगर करते हैं: जो सिस्टम बस-फ़ैक्टर फ़्लोर से नीचे गिरता है या एंड-ऑफ़-सपोर्ट क्षितिज पार करता है उसे फंडेड सुधार मिलता है, और स्टीवर्डशिप स्वास्थ्य को डिलीवरी के साथ-साथ नेतृत्व को रिपोर्ट किया जाता है।

स्तर 5: ऑर्केस्ट्रेशन। स्टीवर्डशिप को संगठन भर में लगातार सुधारा और एकीकृत किया जाता है। कोई भी महत्वपूर्ण सिस्टम मानवीय विफलता का सिंगल पॉइंट नहीं है, ओवरलैप के ज़रिए टेसिट नॉलेज सहित ज्ञान हस्तांतरण नियमित है, और सिस्टम छोटे प्रतिवर्तनीय कदमों में विकसित होते हैं ताकि कोई भी सपोर्ट से बाहर न हो। स्वामित्व, एंड-ऑफ़-लाइफ़ ट्रैकिंग, उत्तराधिकार, और सनसेट योजना को पोर्टफ़ोलियो और जोखिम योजना में बुना जाता है, तकनीकों और दायित्वों के बदलने के साथ एस्टेट को पुनर्संतुलित किया जाता है, और बहु-दशकीय सिस्टमों को उन लोगों का भरोसा बनाए रखते हुए बनाए रखा जाता है जो उन पर निर्भर हैं।

चर्चा के लिए विचार

• आप बस फ़ैक्टर को सार्थक रूप से कैसे मापते हैं, और अलग-अलग क्रिटिकैलिटी स्तरों के लिए सही लक्ष्य क्या है?
• इंक्रीमेंटल आधुनिकीकरण वास्तव में कब अव्यवहार्य होता है, जिससे रीराइट कम जोखिम भरा विकल्प बन जाता है?
• आप मेंटेनेंस काम को कैसे फंड और पुरस्कृत करते हैं ताकि स्टीवर्डशिप एक सम्मानित करियर पथ बने, न कि एक डेड एंड?
• जब आखिरी विशेषज्ञ रिटायर होने वाला हो और कोई ओवरलैप संभव न हो, तो टेसिट नॉलेज को संरक्षित करने का सही तरीका क्या है?
• रिटायर हो चुके सिस्टम के बारे में सवालों के जवाब देने की क्षमता आपको कितने समय तक बनाए रखनी चाहिए, और इसके लिए कौन भुगतान करता है?
• आपके एस्टेट में कहाँ स्थिरता मूल्य है और नवीनता एक दायित्व, और आप समय के साथ उस निर्णय को ईमानदार कैसे बनाए रखते हैं?

मुख्य निष्कर्ष

• अधिकांश महत्वपूर्ण सॉफ़्टवेयर पुराना और दीर्घजीवी है; इसे दशकों और स्टाफ़ की पीढ़ियों में बनाए रखना एक प्रथम-श्रेणी अनुशासन है।
• हर महत्वपूर्ण सिस्टम को वर्तमान, टीम-स्तरीय स्वामित्व चाहिए; अनाथ महत्वपूर्ण सिस्टम गुप्त आपातकाल हैं।
• बस फ़ैक्टर को जानबूझकर घटाएं (किसी भी महत्वपूर्ण कार्य के लिए ठीक एक ही सक्षम व्यक्ति नहीं होना चाहिए) और केवल दस्तावेज़ों के बजाय ओवरलैप के ज़रिए टेसिट नॉलेज हस्तांतरित करें।
• दीर्घजीवी सिस्टमों को निरंतर और इंक्रीमेंटल रूप से मेंटेन रखें; उन्हें जमा देना और संपूर्ण रीराइट पर दांव लगाना दोनों ही विफलता के तरीके हैं।
• अंत की योजना जवाबदेह पूर्णता वाली प्रबंधित परियोजनाओं के रूप में बनाएं, दायित्वों को पूरा करने के लिए डेटा और रिकॉर्ड संरक्षित रखते हुए।
• नागरिक- और ग्राहक-मुखी सिस्टमों के लिए, निरंतर विश्वसनीयता और निष्पक्षता ही मिशन हैं, और मेंटेनेंस उस चीज़ के लिए जोखिम प्रबंधन है जिसे आप खोना अफ़ोर्ड नहीं कर सकते।

संदर्भ और आगे पढ़ने के लिए

• Michael Feathers, Working Effectively with Legacy Code
• Titus Winters, Tom Manshreck, और Hyrum Wright, Software Engineering at Google
• Frederick P. Brooks Jr., The Mythical Man-Month
• Nat Pryce और Steve Freeman, Growing Object-Oriented Software, Guided by Tests
• Sam Newman, Monolith to Microservices
• Martin Fowler, Refactoring और Strangler Fig पैटर्न पर लेखन
• Betsy Beyer et al., Site Reliability Engineering और The Site Reliability Workbook (Google)
• Diomidis Spinellis, Code Reading: The Open Source Perspective
• U.S. Government Accountability Office, संघीय लीगेसी IT आधुनिकीकरण पर रिपोर्टें