IT टीम की एक सीख देने वाली प्रतिक्रिया
- ऑस्ट्रेलिया के एक बैंक की इंटरनेट इन्फ्रास्ट्रक्चर टीम में काम करने वाले "Bruce" की कहानी.
- इंटरनेट बैंकिंग के शुरुआती दौर में टीम तेज़ी से बढ़ी और काम का बोझ भी बढ़ता गया.
- ISDN link का उपयोग आधा होने से पहले ही टीम ने अतिरिक्त link खरीदने की ज़रूरत पहचानी और CIO को प्रस्ताव भेजा.
प्रबंधन की अस्वीकृति और IT टीम की प्रतिक्रिया
- CIO ने प्रबंधन को अतिरिक्त ISDN link खरीदने का अनुरोध भेजा, लेकिन यह कहकर मना कर दिया गया कि मौजूदा link का उपयोग अभी आधे तक भी नहीं पहुँचा है.
- IT टीम ने link उपयोग 50% से ऊपर जाते ही फिर अनुरोध किया, लेकिन उन्हें 100% के करीब पहुँचने तक इंतज़ार करने को कहा गया.
IT टीम का रणनीतिक कदम
- IT टीम ने तय किया कि प्रबंधन को समस्या का एहसास कराने के लिए उनके network connection को नियंत्रित किया जाए.
- पहले हफ्ते में 10% कम किया गया, और उसके बाद हर हफ्ते 10% और कम किया गया.
- एक महीने बाद अतिरिक्त ISDN link की स्थापना को मंज़ूरी मिल गई, और प्रबंधन ने 'इंटरनेट समस्या' हल होने पर खुद को बधाई दी.
GN⁺ की राय
इस लेख की सबसे महत्वपूर्ण बात यह है कि IT टीम ने प्रबंधन के फैसले को चुनौती दी और वास्तविक user experience के ज़रिये ज़रूरी इन्फ्रास्ट्रक्चर निवेश के लिए मनाने वाली रणनीतिक प्रतिक्रिया दिखाई. यह तकनीकी समस्या और business decision के बीच की दूरी कम करने के लिए एक रचनात्मक और प्रभावी approach को दिखाता है. यह कहानी सिर्फ IT professionals के लिए ही दिलचस्प नहीं है, बल्कि गैर-तकनीकी निर्णय लेने वालों को भी तकनीकी इन्फ्रास्ट्रक्चर की अहमियत समझने में मदद करने वाला सबक देती है.
1 टिप्पणियां
Hacker News की राय
एक बार हमने एक घटिया थर्ड-पार्टी software इस्तेमाल किया था, जो ग्राहकों के लिए बड़ी समस्याएँ पैदा कर रहा था
हम अंदर ही अंदर उसका विकल्प बना रहे थे, लेकिन कुछ लोग contract renew करके उसी bug से भरे software को जारी रखना चाहते थे
ग्राहकों द्वारा खोले गए सारे tickets मैंने मौजूदा solution बनाए रखने वालों के पास जाने दिए, और आखिरकार जब हम अपने system पर शिफ्ट हुए तो समस्याएँ लगभग गायब हो गईं
काम करने वाले लोग अक्सर hero बनकर उस दर्द को ऊपर तक पहुँचने से रोकते हैं, और संगठन समस्या खत्म करने के बजाय लोगों को painkiller की तरह लगाते-लगाते उसी स्थिति का आदी हो जाता है
पुराना system जो पहले से कर रहा था, उसके अलावा बड़े पैमाने की rewiring के बिना कुछ भी नहीं कर सकता था, और उसे संभालने वाली team मानती थी कि अगर वे knowledge share नहीं करेंगे तो उनकी नौकरी जिंदगी भर पक्की रहेगी
नया system मानता था कि queries ठीक करने के बजाय और CPU लगा देना काफी है, इसलिए database latency बहुत ज्यादा थी
दोनों teams बिल्कुल बगल में बैठती थीं, लेकिन आपस में बात नहीं करती थीं, और पुराने system वाली team ने IT director की desk के नीचे पड़े parcel को bomb बताकर report तक कर दिया था
नई system team ने आखिरकार Oracle को बुलाया, और Oracle ने queries फिर से लिख दीं
जोखिम को साफ-साफ समझाना, और technical नतीजों का business पर क्या असर होगा यह बता पाना, IT पेशेवरों के लिए मुख्य कौशल है
हो सकता है इस bank की management सच में बेहद सुस्त-बुद्धि रही हो, लेकिन यह भी संभव है कि tech team ठीक से समझा नहीं पाई हो
बल्कि शायद इसलिए कि मैं IT में हूँ, मुझे लगता है कि हम काफी अच्छी तरह और सटीक communicate करते हैं
असली समस्या यह है कि middle management की politics सब कुछ धुंधला कर देती है
team से कोई कह सकता है, “मैंने गड़बड़ की है, इसे ठीक करना होगा,” लेकिन ऊपर की तरफ ऐसे लोग होते हैं जो बहुत मामूली फैसलों को भी पलटने से बचने के लिए तरह-तरह के कारण देते हैं
शायद किसी ने पहले ही अपने boss को बेच दिया हो कि वह equipment अगले 10 साल और चल सकता है
सहकर्मियों के साथ काम करते हुए दिखता है कि वे सामने वाले के स्तर के हिसाब से कई गहराइयों में समझाने की काफी कोशिश करते हैं
ज्यादा बार जो होता है, वह यह है कि top management और उनके नीचे के managers को बस परवाह नहीं होती
उनके दिमाग में पहले से एक “भव्य plan” होता है, और developers चाहे जितना कहें कि वह कल्पना reality नहीं बन सकती, कुछ बदलता नहीं
अधिकतर लोग हमारी बात पूरी तरह समझते हैं
ऐसा नहीं है कि हम सिर्फ ऊपरी दर्जे के nerds को समझ आने वाले गूढ़ jargon फेंक रहे होते हैं; बस उन्हें परवाह नहीं होती
काश कंपनियाँ MBA-style, दिमाग और दिल से खाली लोगों के कम नियंत्रण में हों और engineers ज्यादा जिम्मेदारी लेने वाले organizations बढ़ें, लेकिन जिंदगी ऐसी ही है
enterprise IT clerical support कामों से विकसित हुआ था, और fax machine या PC चल रहा है, इसके लिए strategic planning की जरूरत नहीं थी, इसलिए शुरुआत में उसे गैर-महत्वपूर्ण department माना गया
suit पहनने वालों को कंजूस या बेवकूफ मान लेना, या यह सोचना कि वे technology नहीं समझते, आसान है, लेकिन असल में कई मामलों में communication skill की कमी भी होती है
मेरी पहली नौकरी में CFO AS/400 के लिए ढंग के backup system की request बार-बार reject करता था
उस AS/400 में ERP, CRM, accounting समेत पूरी कंपनी का काम था, और 300 लोगों का काम 8-inch floppy पर backup करना शुरू से ही नामुमकिन था
एक दिन बड़ा disk failure हुआ और पूरी कंपनी कई हफ्तों तक ठप हो गई; order processing, support requests, sales proposals, customer numbers और addresses lookup सब रुक गया
मुझे याद है कि कुछ disks Kroll Ontrack को भेजे गए थे
उस disaster के बाद ही ढंग का backup equipment खरीदा गया
कुछ महीनों बाद एक student developer ने production में delete query चला दी, जिसमें
whereclause comment out था, और पूरी table उड़ गईbackup था, लेकिन एक background job ने यह detect करके 4 साल के invoices regenerate कर दिए और past के सभी customers को दोबारा payment करने का email भेज दिया
test environment ज्यादा देर बाद नहीं बना
कुछ समय पहले मैं एक दूर-दराज के 2-year college में काम करता था, जहाँ सारा data पुराने AS/400 पर था और वह हर कुछ हफ्तों में एक-दो दिन के लिए मर जाता था
backup नहीं था, tape drive खराब थी, और उस समय के हिसाब से भी पुराने 10Mbps NIC जैसे parts के replacement भी नहीं मिलते थे
मैं लगातार कहता रहा कि इसे replace करना या cloud server पर migrate करना चाहिए, लेकिन जवाब बस “budget में नहीं है” और “बहुत महँगा है” मिलता था
वास्तविक usage के हिसाब से यह महीने के कुछ सौ dollars का मामला था, जो उस risk के सामने बिल्कुल बेमानी था कि system मर गया तो पूरा college ढह सकता है और शायद हमेशा के लिए बंद हो सकता है
आखिरकार failure हुआ, और कई दिनों तक main terminal से access हो रहा था लेकिन network से कोई communication नहीं था
लोग panic करने लगे, और $100 प्रति घंटे से ज्यादा लेने वाले AS/400 repair expert को बुलाने की बात भी चली
आखिरी कोशिश के तौर पर मैंने NIC ठीक कर दिया, और उसके फिर से चलने की खबर देते हुए साफ कह दिया कि यह आखिरी boot हो सकता है, इसलिए उससे पहले इसे कहीं backup करना होगा
6 हफ्ते बाद हमारे पास चमचमाता cloud-based AS/400 था, और उस पुराने, भारी-भरकम beast को आखिरी बार बंद करके उसकी विदाई कर दी
कुल uptime लगभग 25 साल था
यह कहानी कम-से-कम संभावना वाली या पूरी तरह गढ़ी हुई कही जा सकती है, लेकिन मैं इसे ऐसे नहीं देखता
किसी बड़े संगठन में कुछ करवाना हो तो management को आपका दर्द महसूस कराना पड़ता है
यह cynicism नहीं है, दुनिया ऐसे ही चलती है
जो लोग उम्मीद करते हैं कि सामने वाला स्थिति समझने के लिए सारे mental steps खुद ही उठा लेगा, उन्हें कड़ा झटका लगने वाला है
90s की शुरुआत में भी branch office के अलावा ISDN आम नहीं रहा होगा
ऊपर से traffic shaping/QoS की बात आए तो भरोसा करना और मुश्किल हो जाता है
मेरी जानकारी में उस समय लगभग सबके इस्तेमाल वाले Cisco 2500/2600 routers ने ऐसी features काफी बाद में support की थीं
शायद उनका मतलब T1 रहा हो, और इसमें r/thathappened वाली feeling काफ़ी मजबूत है
परिभाषा के हिसाब से managers, hands-on लोगों से अलग काम करते हैं
उदाहरण के लिए खराब codebase का दर्द manager को कैसे महसूस कराया जा सकता है?
काम पर Cisco 1604 ISDN router को हमेशा connected रखने के बजाय auto-dial पर set करके cost बचाने की कोशिश की थी
लेकिन पता चला कि web browser package installed वाला IBM AIX हर घंटे Big Blue को periodic telemetry call कर रहा था, इसलिए lab network idle state में नीचे नहीं जा पा रहा था
router में firewall rule जोड़कर उस चोरी-छिपे चल रहे काम को रोक दिया
90s के आखिर में भी Microsoft, Sun, Novell telemetry के मामले में IBM जितने बेशर्म नहीं थे
यहां दिखने वाली असली समस्या यह है कि IT side को business side से कुछ हद तक स्वतंत्र होकर वे काम करने की autonomy चाहिए जिन्हें वह सही जानती है
आखिर किसी संगठन में कितनी निगरानी सहनी पड़ेगी, यह trust पर निर्भर करता है
जहां मैं हूं, अगर बात customer को affect करने वाली नहीं है तो permission मांगने की जरूरत नहीं पड़ती
machines struggling दिखें या SaaS plan limit के करीब पहुंच जाए तो बस upgrade कर देते हैं
कभी-कभी कोई नए bill या cost increase के बारे में पूछ लेता है, लेकिन काम आगे बढ़ाने के लिए कई round की पूछताछ से नहीं गुजरना पड़ता
suit पहनने वालों को सोचना चाहिए कि हर छोटी technical task के लिए permission की भीख मांगने वाले environment के नुकसान क्या हैं
10 साल से भी पहले ivory tower में बनाई गई complex change policies के कारण कितनी innovation सीधे जलते dumpster में जा रही होगी?
क्या संगठन को इस तरह फिर से सोचा नहीं जा सकता कि business को IT team का customer माना जाए?
अगर company fail होती है तो IT organization के होने का भी कोई मतलब नहीं रहता, इसलिए यह सोचने का कहीं ज्यादा सरल तरीका लगता है
इसलिए cost बनाम benefit बदलता है, और communication जरूरी है
“तुम्हारा काम hierarchy के decisions का सम्मान करना है” जैसी reaction देखकर याद आता है कि corporate organizations अब भी कितनी military-style thinking में अटकी हुई हैं
पुराने Prussian army में mission को goal-centric तरीके से communicate किया जाता था
“मैं X हासिल करने की कोशिश कर रहा हूं, तुम Y संभालो, और दूसरी unit Z करेगी” — इस तरह; execution उस local officer पर छोड़ा जाता था जिसने ground reality देखी होती थी और जिसके पास जरूरी knowledge भी होती थी
साथ ही अगर कोई officer या NCO अपने direct commander के order से असहमत हो, तो वह उसके ऊपर के level पर appeal भी कर सकता था
इसमें staff system भी था, जहां staff officers को training के दौरान command experience लेना पड़ता था और वे commander के orders को countermand भी कर सकते थे; इससे बदलती परिस्थितियों के अनुकूल एक मजबूत और flexible system बना
officers अपने superiors से बहस करने, higher-ups तक जाने, या सच में जरूरी समझें तो order refuse करने से भी नहीं हिचकते थे
ताकि lower ranks की सहमति और participation मिले
यानी decisions जितना संभव हो उतने नीचे के level पर लिए जाते थे
modern era में यह कुछ हद तक कम popular हुआ, लेकिन जहां तक मुझे पता है, कोई भी military सिर्फ “तुम्हारा काम hierarchical decision follow करना है” पर नहीं चलती
उदाहरण के लिए Extreme Ownership जैसी किताब
शायद मैं बहुत malicious सोच रहा हूं, लेकिन ऐसी leadership हो तो मैं शायद नई job ढूंढकर पूरी ship को डूबने देता
leadership perspective से simplify करें तो मान लें हर साल ऐसे 100 similar proposals आते हैं और हर एक पर 1 million dollars खर्च होते हैं
तो amortization या tax tricks हटाकर भी हर साल pure cost 100 million dollars है
bank के लिए भी यह बड़ी रकम है और इसे strategically खर्च करना चाहिए, waste नहीं
इस setup में leadership को pain महसूस कराना और instinctively समझाना कि इस बार का 1 million dollars अच्छी तरह खर्च होगा, leadership, IT और business — सभी के लिए अपनी तरह से healthy strategy है
executives वे लोग भी हैं जो company के limited time, employees, costs आदि को manage करते हैं
बेशक वे आम तौर पर यह काम खास अच्छे से नहीं करते, और company के नजरिए से purely rational choice शायद उन्हें ordinary employees जैसी कम lavish compensation देना होगा
लेकिन “company” decision नहीं लेती, लोग लेते हैं, और उनमें political games, incentives और self-interest शामिल होते हैं
executives information, decision-making, resources और money के flow को control करते हैं, इसलिए वे host company से जरूरत से ज्यादा हिस्सा चूसने वाले parasites की तरह behave करते हैं
इस problem का समाधान reader के लिए exercise के तौर पर छोड़ता हूं
अगर सिर्फ “X तारीख के आसपास line 50% saturated होने का forecast है” सुनने को मिला, तो IT ने सच में समझाया ही नहीं
हमें पता है कि इस technology में 50% saturation का मतलब customers के लिए delay या connection errors है
तो कहना चाहिए था, “X तारीख के आसपास customers को connection problems आने की आशंका है”
अगर पता है कि 100% limit केवल ideal conditions में possible theoretical value है, तो actual usable limit के आधार पर बात करनी चाहिए
लोगों को informed decisions लेने हैं तो उन्हें सही information देनी होगी, और अगर technology समझने के लिए पैसे IT को मिलते हैं, तो उसकी characteristics को suit पहनने वालों की समझ में आने लायक तरीके से communicate करना भी IT का काम है
बेशक उन्होंने पूरी कोशिश की होगी, लेकिन लेख पढ़कर लगता है कि ऐसी information के बिना बस memos भेजे गए थे
“50% उपयोग” वाली अभिव्यक्ति को ऐसे इस्तेमाल किया जाना, जैसे नल को आधा ही खोला गया हो, ठीक से समझ नहीं आता
अगर किसी एक pipeline पर load अचानक बहुत ज्यादा केंद्रित हो जाए, तो वैसे भी बीच-बीच में performance गिरावट नहीं होगी क्या?
“खराब experience” वाला समय, distribution के हिसाब से तेजी से बढ़ सकता है, इसलिए 60% पर भी इसे सहना मुश्किल लग सकता है
तुलना करें तो यह ऐसा है जैसे कोई बार औसत demand देखकर सिर्फ 1 server रखने का फैसला करे, और फिर शुक्रवार की रात आ जाए
यही बात Kingman formula कहता है
“उपयोग 50% से ऊपर जाते ही IT team ने फिर से ISDN order करने का सुझाव दिया। और फिर से उसे ठुकरा दिया गया। साथ में यह निर्देश भी कि उपयोग 100% के करीब पहुंचने तक दोबारा न पूछें।”
यह अधिकारियों की कोविड को लेकर सोच से काफी मिलता-जुलता है
ऐसा लगता है जैसे जिम्मेदार लोग मौजूदा trend देखकर किसी भी तरह का prediction नहीं कर पाते, और disaster सामने आ जाने पर ही react करते हैं