- Agentic coding के दौर में भी software engineer की मांग घटने के बजाय बढ़ने की संभावना है, और इसकी कुंजी code लिखना नहीं बल्कि service operations की क्षमता में है
- code लिखना हमेशा आसान हिस्सा था, असली मुश्किल लंबे समय तक system को स्थिर रूप से चलाते रहना है
- no-code और spreadsheet के उदाहरणों की तरह गैर-विशेषज्ञ भी tools बना सकते हैं, लेकिन maintenance और operations का बोझ आखिरकार professional engineering की मांग करता है
- उपयोगकर्ता software नहीं बल्कि service खरीदते हैं, और अच्छा software बिना दिखाई दिए काम करना चाहिए
- uptime, defect rate, recovery speed, security updates जैसी operational excellence भविष्य की प्रतिस्पर्धात्मक बढ़त का केंद्र है
- इन सभी जरूरतों को पूरा करने वाली भूमिका के रूप में SRE software engineering के केंद्र में आ रहा है
SRE सबसे ज्यादा hiring वाला role बनने की संभावना है
- जब code सस्ता हो जाता है, तो operational excellence जीतती है
- greenfield demo कोई भी बना सकता है, लेकिन service को स्थिर रूप से चलाने के लिए engineering capability चाहिए
- "हर कोई greenfield demo बनाना चाहता है, लेकिन कोई service चलाना नहीं चाहता"
- software engineering सिर्फ programming नहीं, बल्कि समय के साथ बदलते systems को manage करने का काम है
no-code और spreadsheet युग से मिली सीख
- accounting का काम संभालने वाले Joe ने हर हफ्ते 10 घंटे लेने वाले दोहराए जाने वाले काम को no-code tool और spreadsheet macro से 1 घंटे तक घटा दिया
- शुरुआत में नतीजे साफ़ तौर पर अच्छे थे, लेकिन समय बीतने पर complexity तेज़ी से बढ़ी
- business environment में बदलाव, accounting rules में परिवर्तन, timezone और daylight saving time की समस्याएं जमा होती गईं
- हर हफ्ते नए edge cases सामने आए और लगातार सुधार व संशोधन की जरूरत पड़ी
- आखिरकार Joe अपने बनाए system से बंधा हुआ रह गया
- छुट्टी के दौरान भी उसे system की चिंता करनी पड़ती थी, और operations किसी दूसरे को सौंपना मुश्किल था
- code चलाना और उसके परिणाम देखना ही चिंता और तनाव का कारण बन गया
Computer Disease
- Feynman द्वारा दिया गया यह विचार बताता है कि computer की समस्या यह है कि उसे बार-बार छेड़ते रहने का मन होता है
- automation अपने आप में मज़ेदार है, लेकिन जरूरत न होने वाले क्षेत्रों तक automation फैलाकर complexity बढ़ाने का जाल मौजूद है
- असली बोझ service operations में है
- उसे स्थिर रूप से काम करते रहना सुनिश्चित करना
- बड़े पैमाने के environment में बिना समस्या के scale करना
- कई वर्षों तक लगातार manage करना
- service delivery में stability, reliability और continuity सबसे अहम हैं
operational excellence ही भविष्य क्यों है
- लोग software नहीं खरीदते, बल्कि अपनी समस्या हल करने वाली service को अपनाते हैं
- किसी को iCloud के अंदरूनी कामकाज से मतलब नहीं, वे बस चाहते हैं कि photos devices के बीच हमेशा अपने-आप sync हों
- Word, Notion, gDocs कैसे बने, यह महत्वपूर्ण नहीं; महत्वपूर्ण है विचारों को लिखने और साझा करने का अनुभव
- payment network की संरचना से ज्यादा महत्वपूर्ण यह है कि 7 डॉलर का matcha latte बिना दिक्कत pay हो जाए
- अच्छा software दिखाई नहीं देता (वह बिना उपस्थिति जताए स्वाभाविक रूप से काम करता है)
असली मुश्किल engineering चुनौतियां
- काम करने वाला demo बनाने वाले पहले 90% आसान हैं, बाकी 190% ही वास्तव में महत्वपूर्ण हैं
- operations के नज़रिए से पूछे जाने वाले सवाल:
- uptime कितना है
- defect होने की दर कितनी है
- outage होने पर recover होने में कितना समय लगता है
- क्या समस्या को उपयोगकर्ता के नोटिस करने से पहले detect किया जाता है
- क्या upstream dependencies को manage किया जा सकता है
- vendor समस्या होने पर क्या उपयोगकर्ता शिकायत से पहले उसका पता चल जाता है
- उपयोगकर्ता द्वारा सुझाए गए विचार को लागू करने में कितना समय लगता है
- क्या engineers को एक-दूसरे के systems तोड़ने से रोका जाता है
- क्या ऐसा system है जिसमें engineer आगे बढ़ते रहें और app उलझे हुए ढेर में न बदल जाए
- क्या ऐसा software संभाला जा सकता है जिसका आकार एक व्यक्ति के दिमाग में समा न सके
- अगर 12 घंटे के time difference वाले timezone में engineer के सोते समय बड़ी समस्या हो जाए, तो क्या उपयोगकर्ता हार मानने से पहले उसे ठीक कर दिया जाता है
- क्या अपनी outages और upstream outages दोनों से recover किया जा सकता है, और क्या महत्वपूर्ण data खोता है
- क्या security updates लगातार लागू किए जा रहे हैं
- क्या user data leak नहीं होता
- क्या इस पर trust किया जा सकता है
- क्या इस पर depend किया जा सकता है
- क्या उस भरोसे के समर्थन में ठोस आधार है
- क्या जरूरत पड़ने पर इस बात की कानूनी रूप से बाध्यकारी guarantee पर हस्ताक्षर किए जा सकते हैं कि software काम करेगा
- यही असली मुश्किल engineering समस्याएं हैं, और code लिखना सिर्फ आसान हिस्सा है
अभी कोई टिप्पणी नहीं है.