जॉब टाइटल वही रहा। काम बदल गया।
अरुण नाम के एक क्लाउड एडमिनिस्ट्रेटर की कल्पना कीजिए।
कुछ साल पहले, उनका ज़्यादातर काम टिकट के ज़रिए आता था: एक वर्चुअल मशीन बनाना, स्टोरेज जोड़ना, फ़ायरवॉल रूल अपडेट करना, या किसी यूज़र को एक्सेस देना। आज, एक सेल्फ़-सर्विस पोर्टल या इंफ़्रास्ट्रक्चर-ऐज़-कोड पाइपलाइन उन अनुरोधों को संभाल सकती है।
शुरुआत में, यह नौकरी छिनने जैसा लग सकता है। लेकिन अरुण की नई क्यू एक अलग कहानी बताती है। कोई डिप्लॉयमेंट सिर्फ़ प्रोडक्शन में फेल होता है। किसी टीम को स्थायी सुरक्षा जोखिम बनाए बिना अस्थायी एक्सेस चाहिए। ट्रैफ़िक स्पाइक के बाद क्लाउड ख़र्च बढ़ जाता है। कोई सेवा अपना अपटाइम लक्ष्य पूरा करती है लेकिन यूज़र्स के लिए तकलीफ़देह रूप से धीमी बनी रहती है।
बटन दबाने वाला काम घट गया है। इंजीनियरिंग निर्णय नहीं घटे।
यही क्लाउड करियर में मुख्य बदलाव है: संगठनों को अब ऐसे कम लोग चाहिए जिनकी क़ीमत सिर्फ़ कंसोल चलाने तक सीमित हो, लेकिन उन्हें अब भी ऐसे लोग चाहिए जो क्लाउड सिस्टम को डिज़ाइन, ऑटोमेट, सुरक्षित, निरीक्षित, ट्रबलशूट, और बेहतर कर सकें।
ऑटोमेशन चरण हटाता है, जवाबदेही नहीं
क्लाउड प्लेटफ़ॉर्म इंफ़्रास्ट्रक्चर को ऑटोमेट करने के लिए बनाए गए थे। इंफ़्रास्ट्रक्चर ऐज़ कोड ने उस विचार को आगे बढ़ाया। CI/CD पाइपलाइनों ने डिलीवरी को ऑटोमेट किया। मैनेज्ड सेवाओं ने डेटाबेस, क्लस्टर, और मैसेजिंग सिस्टम चलाने के लिए ज़रूरी काम घटाया।
ये बदलाव इस तरह के मैनुअल चरण हटाते हैं:
- बार-बार मिलते-जुलते संसाधन बनाना;
- हाथ से एक जैसा कॉन्फ़िगरेशन लगाना;
- वातावरणों के बीच डिप्लॉयमेंट कमांड कॉपी करना;
- एक-एक करके डैशबोर्ड जाँचना; और
- नियमित इन्वेंटरी और लागत रिपोर्ट तैयार करना।
यह अच्छी इंजीनियरिंग है। दोहराया जाने वाला काम धीमा, असंगत, और ऑडिट करने में मुश्किल होता है।
लेकिन ऑटोमेशन यह तय नहीं करता कि संगठन को क्या मानकीकृत करना चाहिए। इसे यह नहीं पता कि बिज़नेस किस विफलता को झेल सकता है, कोई एक्सेस पॉलिसी बहुत ज़्यादा खुली है या नहीं, या कोई सस्ता डिज़ाइन कब अस्वीकार्य ऑपरेशनल जोखिम पैदा कर देता है। किसी को ऑटोमेशन बनानी होती है, उसके गार्डरेल तय करने होते हैं, उसके नतीजे मापने होते हैं, और जब हक़ीक़त योजना से मेल न खाए तो जवाब देना होता है।
ज़िम्मेदारी एक स्तर ऊपर चली जाती है।
| वह काम जो कम मैनुअल होता जा रहा है | वह ज़िम्मेदारी जो ज़्यादा अहम होती जा रही है |
|---|---|
| कंसोल में संसाधन उपलब्ध कराना | दोबारा इस्तेमाल होने लायक़ इंफ़्रास्ट्रक्चर मॉड्यूल और सुरक्षित डिफ़ॉल्ट डिज़ाइन करना |
| डिप्लॉयमेंट कमांड चलाना | टेस्ट, अप्रूवल, और रोलबैक रास्तों के साथ डिलीवरी पाइपलाइन बनाना |
| अलग-अलग सर्वर देखना | मेट्रिक्स, लॉग, ट्रेस, और यूज़र प्रभाव के ज़रिए सेवाओं की निगरानी करना |
| टिकट-दर-टिकट एक्सेस देना | पहचान, न्यूनतम-विशेषाधिकार, और ऑडिट-योग्य एक्सेस वर्कफ़्लो डिज़ाइन करना |
| महीने का क्लाउड बिल देखना | आर्किटेक्चर और इस्तेमाल के फ़ैसलों को लागत और बिज़नेस वैल्यू से जोड़ना |
एक क्लाउड सिस्टम, कई इंजीनियरिंग नज़रिए
क्लाउड इंजीनियर, प्लेटफ़ॉर्म इंजीनियर, साइट रिलायबिलिटी इंजीनियर, और DevSecOps इंजीनियर जैसे टाइटल अक्सर एक-दूसरे से मिलते-जुलते हैं। ये कोई सार्वभौमिक करियर सीढ़ी नहीं हैं, और कंपनियाँ इन्हें अलग-अलग तरह से इस्तेमाल करती हैं।
इन्हें समझने का एक उपयोगी तरीक़ा यह है कि हर भूमिका किस सवाल पर ज़ोर देती है:
- एक क्लाउड इंजीनियर पूछता है कि क्या इंफ़्रास्ट्रक्चर और मैनेज्ड सेवाएँ वर्कलोड के लिए सही हैं।
- एक प्लेटफ़ॉर्म इंजीनियर पूछता है कि क्या टीमें हर अंदरूनी बारीक़ी सीखे बिना साझा क्षमताओं का सुरक्षित इस्तेमाल कर सकती हैं।
- एक साइट रिलायबिलिटी इंजीनियर पूछता है कि क्या सेवा भरोसेमंदी के लक्ष्य पूरे कर सकती है और विफलता से उबर सकती है।
- एक DevSecOps इंजीनियर पूछता है कि क्या डिलीवरी और ऑपरेशन में शुरू से और लगातार सुरक्षा नियंत्रण शामिल हैं।
किसी छोटे संगठन में, एक ही व्यक्ति ये चारों भूमिकाएँ निभा सकता है। किसी बड़े संगठन में, अलग-अलग टीमें इन्हें संभाल सकती हैं। सीमाओं से ज़्यादा नतीजे मायने रखते हैं: दोहराई जा सकने वाली डिलीवरी, सुरक्षित एक्सेस, निगरानी-योग्य सिस्टम, नियंत्रित लागत, और भरोसेमंद सेवा।
DORA एक प्लेटफ़ॉर्म को साझा क्षमताओं के रूप में बताता है जो सॉफ़्टवेयर डिलीवरी दक्षता और उत्पादकता बेहतर करती हैं। इसका मार्गदर्शन प्लेटफ़ॉर्म के काम को डिलीवरी नतीजों से मापने की सलाह भी देता है—सिर्फ़ यह गिनने के बजाय कि किसी प्लेटफ़ॉर्म टीम ने कितने टूल या टेम्प्लेट बनाए। यह फ़र्क़ अहम है। जिस पोर्टल पर कोई भरोसा न करे, वह सफल प्लेटफ़ॉर्म नहीं है।
क्लाउड काम के इर्द-गिर्द बढ़ती पाँच ज़िम्मेदारियाँ
1. इंफ़्रास्ट्रक्चर को सॉफ़्टवेयर बनना होगा
क्लाउड कंसोल जानना अन्वेषण और निदान के लिए अब भी उपयोगी है। यह दोहराई जा सकने वाली प्रोडक्शन का काम के लिए काफ़ी नहीं है।
इंजीनियरों को इंफ़्रास्ट्रक्चर की परिभाषाएँ पढ़नी और बदलनी होंगी, उन्हें एप्लिकेशन कोड की तरह समीक्षा करनी होगी, अहम मान्यताओं की जाँच करनी होगी, और स्टेट व ड्रिफ़्ट को समझना होगा। लक्ष्य हर Terraform, OpenTofu, Bicep, या CloudFormation फ़ीचर याद करना नहीं है। लक्ष्य बदलावों को दोहराने-योग्य और समीक्षा-योग्य बनाना है।
2. डिलीवरी और ऑपरेशन जुड़े हुए हैं
कोई संसाधन सिर्फ़ मौजूद होने की वजह से मूल्यवान नहीं होता। एप्लिकेशन को उस तक सुरक्षित रूप से और बार-बार पहुँचना पड़ता है।
इससे क्लाउड का काम सोर्स कंट्रोल, बिल्ड सिस्टम, डिप्लॉयमेंट स्ट्रैटेजी, सीक्रेट्स मैनेजमेंट, और रोलबैक के क़रीब आ जाता है। किसी इंजीनियर को माहिर एप्लिकेशन डेवलपर बनने की ज़रूरत नहीं, लेकिन उसे समझना चाहिए कि कोई कोड बदलाव रिपॉज़िटरी से चल रही सेवा तक कैसे पहुँचता है—और वह सफ़र कहाँ विफल हो सकता है।
3. भरोसेमंदी एक डिज़ाइन मसला है
पारंपरिक मॉनिटरिंग अक्सर पूछती थी, “क्या सर्वर चालू है?” आधुनिक ऑपरेशन को पूछना चाहिए, “क्या यूज़र वह काम पूरा कर पा रहे हैं जिसके लिए वे आए थे?”
इसके लिए उपयोगी सेवा संकेतक, स्पष्ट अलर्ट, क्षमता की समझ, परखी हुई रिकवरी प्रक्रियाएँ, और ईमानदार इंसिडेंट समीक्षाएँ चाहिए। DORA के डिलीवरी माप भी गति को स्थिरता से जोड़ते हैं: अगर बदलाव बार-बार विफल हों या ठीक होने में बहुत समय लें, तो बार-बार डिलीवरी करना सफलता नहीं है।
4. सुरक्षा रोज़मर्रा की इंजीनियरिंग का हिस्सा है
क्लाउड सुरक्षा डिप्लॉयमेंट के बाद जोड़ी गई अंतिम मंज़ूरी नहीं है। पहचान, नेटवर्क एक्सपोज़र, सीक्रेट्स, सॉफ़्टवेयर निर्भरताएँ, लॉगिंग, एन्क्रिप्शन, और पॉलिसी — ये सब सिस्टम के डिज़ाइन का हिस्सा हैं।
NIST का NICE फ़्रेमवर्क गवर्नेंस, डिज़ाइन और डेवलपमेंट, कार्यान्वयन और ऑपरेशन, सुरक्षा, और जाँच जैसी श्रेणियों में साइबर सुरक्षा के काम को व्यवस्थित करके इसी विस्तार को दर्शाता है। किसी क्लाउड पेशेवर को पेनिट्रेशन टेस्टर बनने की ज़रूरत नहीं, लेकिन सुरक्षा को किसी और की क्यू नहीं मान सकता।
5. लागत एक ऑपरेशनल संकेत है
क्लाउड सिस्टम तकनीकी फ़ैसलों को बार-बार होने वाले ख़र्च में बदल देते हैं। ज़रूरत से बड़े संसाधन, भूले हुए वातावरण, अकुशल डेटा मूवमेंट, और ग़लत चुने गए प्राइसिंग मॉडल चुपचाप आर्किटेक्चर की समस्या बन सकते हैं।
FinOps Foundation इंजीनियरों को ऐसे भागीदारों के रूप में बताता है जो फ़ैसले लेते समय रेज़िलिएंस और उपलब्धता डेटा के साथ-साथ लागत और इस्तेमाल की जानकारी का उपयोग करते हैं। इससे हर इंजीनियर अकाउंटेंट नहीं बन जाता। इसका मतलब है कि लागत एक और सिस्टम संकेत बन जाती है—लेटेंसी, एरर रेट, या क्षमता की तरह।
क्या अभी सबको AI सीखना ज़रूरी है?
नहीं।
AI वर्कलोड GPU शेड्यूलिंग, मॉडल एंडपॉइंट, वेक्टर डेटाबेस, डेटा गवर्नेंस, और अप्रत्याशित इस्तेमाल जैसी चीज़ें ला सकते हैं। इन वर्कलोड का समर्थन करने वाली क्लाउड टीमों को इनकी ऑपरेशनल विशेषताएँ समझनी चाहिए।
लेकिन मूल ज़िम्मेदारियाँ जानी-पहचानी ही रहती हैं: क्षमता, पहचान, नेटवर्किंग, ऑब्ज़र्वेबिलिटी, भरोसेमंदी, सुरक्षा, और लागत। किसी क्लाउड इंजीनियर को सिर्फ़ इसलिए डेटा साइंटिस्ट बनने की ज़रूरत नहीं कि कोई एक एप्लिकेशन किसी मॉडल को कॉल करता है।
AI-सहायक टूल टेम्प्लेट, क्वेरी, पाइपलाइन चरण, या ट्रबलशूटिंग सुझाव भी जनरेट कर सकते हैं। ये पहले ड्राफ़्ट पर लगने वाला समय घटा सकते हैं। ये अनुमतियों, विफलता के व्यवहार, प्रोडक्शन पर असर, और लागत की जाँच करने की ज़रूरत को ख़त्म नहीं करते। जनरेट किया गया इंफ़्रास्ट्रक्चर भी मशीन की रफ़्तार से विफल हो सकता है।
AI को एक वर्कलोड और एक टूल की तरह लें—आधुनिक क्लाउड करियर की परिभाषा की तरह नहीं।
सब कुछ सीखे बिना दायरा बढ़ाने का व्यावहारिक तरीक़ा
हर क्लाउड सेवा, प्रोग्रामिंग भाषा, सुरक्षा उत्पाद, और प्लेटफ़ॉर्म टूल में महारत हासिल करने की कोशिश उथले ज्ञान और थकान का पक्का रास्ता है।
इसके बजाय तीन स्तर अपनाएँ:
जानें
उन अवधारणाओं को समझें जो हर क्लाउड सिस्टम को प्रभावित करती हैं: पहचान, नेटवर्किंग, कंप्यूट, स्टोरेज, उपलब्धता, मॉनिटरिंग, सुरक्षा सीमाएँ, और लागत। आपको ट्रेड-ऑफ़ पर बात कर पाना चाहिए, भले ही उन्हें लागू करने वाले आप न हों।
इस्तेमाल करें
किसी एक व्यावहारिक टूलचेन में काम करने की क्षमता बनाएँ। उदाहरण के लिए: एक क्लाउड प्रोवाइडर, Git, एक इंफ़्रास्ट्रक्चर-ऐज़-कोड टूल, एक CI/CD सिस्टम, कंटेनर, और एक ऑब्ज़र्वेबिलिटी स्टैक। सही उत्पाद उतने मायने नहीं रखते जितना उन्हें एक दोहराई जा सकने वाली वर्कफ़्लो में जोड़ पाना।
महारत हासिल करें
वह एक क्षेत्र चुनें जहाँ सहकर्मी आपके निर्णय पर भरोसा कर सकें। यह Kubernetes ऑपरेशन, क्लाउड नेटवर्किंग, पहचान, रिलायबिलिटी इंजीनियरिंग, प्लेटफ़ॉर्म डिज़ाइन, या कॉस्ट ऑप्टिमाइज़ेशन हो सकता है। गहराई पेशेवर मूल्य बनाती है; चौड़ाई उस गहराई को बाक़ी सिस्टम के साथ काम करने में मदद करती है।
फिर किसी छोटे प्रोजेक्ट से इस मेल को साबित करें। किसी पाइपलाइन के ज़रिए कोई सेवा डिप्लॉय करें। उसका इंफ़्रास्ट्रक्चर कोड के रूप में परिभाषित करें। न्यूनतम-विशेषाधिकार एक्सेस, उपयोगी टेलीमेट्री, एक बजट अलर्ट, और परखा हुआ रोलबैक जोड़ें। किसी एक विफलता और उसके बाद किए गए बदलाव को दर्ज करें।
यह प्रदर्शन रिज़्यूमे पर सेवाओं की लंबी सूची से कहीं ज़्यादा कहता है।
रोज़गार डेटा हमें क्या बता सकता है—और क्या नहीं
“क्लाउड इंजीनियर” नाम की कोई साफ़-सुथरी सरकारी श्रेणी नहीं है, इसलिए क्लाउड भूमिकाओं के ग़ायब होने के बारे में ठोस दावों को सावधानी से देखना चाहिए। नियोक्ताओं के बीच जॉब टाइटल बहुत अलग-अलग होते हैं।
व्यापक संकेतक टेक्नोलॉजी के काम को ग़ायब होते नहीं दिखाते। मौजूदा U.S. Bureau of Labor Statistics के अनुमान सॉफ़्टवेयर डेवलपमेंट, नेटवर्क आर्किटेक्चर, इन्फ़ॉर्मेशन सिक्योरिटी, और कंप्यूटर व इन्फ़ॉर्मेशन सिस्टम मैनेजमेंट सहित क्लाउड सिस्टम के आस-पास के कई पेशों के लिए औसत से तेज़ वृद्धि दिखाते हैं।
ये आँकड़े यह गारंटी नहीं देते कि हर मौजूदा टाइटल या काम अपरिवर्तित रहेगा। ये दिखाते हैं कि “क्लाउड नौकरियाँ ख़त्म हो रही हैं” कहना बहुत सरल है। किसी भूमिका के अंदर की स्किल्स बदलने के बावजूद, और एंट्री-लेवल या बेहद दोहराए जाने वाले काम पर ज़्यादा ऑटोमेशन आने के बावजूद, माँग बढ़ सकती है।
बेहतर करियर सवाल
किसी ख़ास कंसोल तक पहुँच के इर्द-गिर्द करियर मत बनाइए। इसे एक ऑपरेशनल नतीजे के इर्द-गिर्द बनाइए।
क्या आप इंफ़्रास्ट्रक्चर को दोहराने-योग्य बना सकते हैं? क्या आप टीमों को सुरक्षित रूप से डिलीवर करने में मदद कर सकते हैं? क्या आप बता सकते हैं कि कोई सेवा क्यों विफल हुई? क्या आप डिलीवरी रोके बिना जोखिम घटा सकते हैं? क्या आप लागत को किसी आर्किटेक्चरल फ़ैसले से जोड़ सकते हैं? क्या आप अगली घटना की संभावना कम कर सकते हैं?
क्लाउड भूमिकाएँ इसलिए व्यापक होती जा रही हैं क्योंकि क्लाउड सिस्टम अब पूरे सॉफ़्टवेयर जीवनचक्र के भीतर बैठे हैं। यह बदलाव असहज लग सकता है, ख़ासकर जब जाने-पहचाने काम ग़ायब हो जाएँ। लेकिन यह एक साफ़ रास्ता भी बनाता है।
बुनियादी बातें बनाए रखें। दोहराव को ऑटोमेट करें। एक बार में एक नज़दीकी ज़िम्मेदारी जोड़ें। जहाँ मायने रखे, वहाँ गहरी समझ विकसित करें।
टिकाऊ भूमिका वह व्यक्ति नहीं है जिसे हर बटन कहाँ है यह पता हो। यह वह इंजीनियर है जो समझता है कि बटन दबाने के बाद क्या होना चाहिए—और अगर वह न हो तो क्या करना चाहिए।
और गहराई से जानें
- Occupational Outlook Handbook: Computer and Information Technology — U.S. Bureau of Labor Statistics. सॉफ़्टवेयर डेवलपमेंट, नेटवर्क आर्किटेक्चर, और संबंधित पेशों के लिए रोज़गार अनुमान।
- Occupational Outlook Handbook: Computer and Information Systems Managers — U.S. Bureau of Labor Statistics. टेक्नोलॉजी मैनेजमेंट भूमिकाओं के लिए नौकरी का दृष्टिकोण।
- Platform Engineering capability — DORA (Google Cloud). प्लेटफ़ॉर्म क्षमताओं को एप्लिकेशन टीमों का समर्थन कैसे करना चाहिए।
- DORA Metrics guide — DORA (Google Cloud). आउटपुट नहीं, नतीजों के ज़रिए सॉफ़्टवेयर डिलीवरी परफ़ॉर्मेंस कैसे मापें।
- Engineering Persona — FinOps Foundation. आर्किटेक्चर और ऑपरेशन के फ़ैसलों में इंजीनियर लागत और इस्तेमाल डेटा का इस्तेमाल कैसे करते हैं।
- FinOps Personas — FinOps Foundation. क्लाउड लागत के फ़ैसलों पर इंजीनियरिंग, फ़ाइनेंस, प्रोडक्ट, और लीडरशिप कैसे मिलकर काम करते हैं।
- NICE Workforce Framework for Cybersecurity — NIST. साइबर सुरक्षा की ज़िम्मेदारियाँ एक जॉब टाइटल तक सीमित न होकर कई वर्क कैटेगरी में कैसे फैली हैं।