AI SREs की जगह नहीं ले रहा है, बल्कि उन्हें डी-स्किल कर रहा है
AI-संचालित tools Site Reliability Engineers (SREs) के लिए routine operational tasks को तेज़ी से संभाल रहे हैं—log correlation और incident triage से लेकर automated remediation तक—जिससे यह चिंता बढ़ रही है कि इंसान उन hands-on अनुभवों को खो रहे हैं जिनकी ज़रूरत novel, complex failures को debug करने में पड़ती है। कई लोग इसकी तुलना pilots के autopilot पर ज़्यादा निर्भर होने से करते हैं: automation रोज़मर्रा की safety और productivity बढ़ाती है, लेकिन जब systems अप्रत्याशित व्यवहार करते हैं या supporting AI services fail हो जाती हैं, तब ज़रूरी skills को कमज़ोर भी कर सकती है। दूसरे कहते हैं कि यह “deskilling” दरअसल emphasis का बदलाव है — low-level toil से हटकर higher-level system design, incident simulation, और AI agents को निर्देशित करने की ओर — लेकिन चिंता यह है कि deliberate practice और training के बिना, future teams के पास critical infrastructure को safely चलाने के लिए पर्याप्त deep expertise नहीं होगी.
SRE में AI का उपयोग और महसूस की गई डी-स्किलिंग
- कई लोगों को साफ़ डी-स्किलिंग दिखती है: लोग पहले Claude/ChatGPT की ओर जाते हैं, incidents के दौरान agents के बीच copy-paste करते हैं, और “अपना दिमाग इस्तेमाल करने” की आदत खो देते हैं।
- दूसरे तर्क देते हैं कि यह बस skill का केंद्र बदल रहा है: syntax लिखने से specs, tests लिखने, और observability तथा resilience के लिए systems डिज़ाइन करने की ओर।
- कुछ लोग इस “tiering” प्रभाव को नोट करते हैं: AI routine/Tier‑1 और Tier‑2 incidents संभालता है; humans केवल novel Tier‑3 failures देखते हैं, जिससे सरल मामलों को संभालकर बनी intuition कमज़ोर हो सकती है।
Skills, learning, और juniors पर असर
- कई लोगों को long-term atrophy की चिंता है: अगर शुरुआत से ही AI इस्तेमाल किया जाए, तो future engineers शायद code और infra को पढ़ना, debug करना, या गहराई से समझना कभी न सीखें।
- चिंता है कि Senior/Staff levels तक जाने की pipeline टूट सकती है अगर juniors ज़्यादातर prompt और review करें, बजाय first principles से build और debug करने के।
- दूसरे कहते हैं कि skills फिर से हासिल की जा सकती हैं, और deliberate “practice time” (coding, puzzles, simulated incidents) से deskilling कम किया जा सकता है।
SRE/DevOps क्या होना चाहिए, इस पर बहस
- इस बात पर कड़ा मतभेद है कि SRE/DevOps हैं:
- glorified sysadmins / tool jockeys जो Kubernetes, Terraform, YAML से बंधे हैं, या
- software engineers जो reliability, scalability, और cost पर केंद्रित हैं।
- कुछ ज़ोर देते हैं कि “real DevOps” का मतलब है devs अपने बनाए काम के लिए on-call की ज़िम्मेदारी लें; दूसरे तर्क देते हैं कि ops एक अलग, वैध specialization है।
- बड़े संगठनों की हकीकत: centralized SRE/infra teams बने रहते हैं ताकि platforms standardize हों, reliability लागू हो, और cross-cutting complexity संभाली जा सके।
Operations में AI के अनुभव
- कई practitioners बताते हैं कि frontier models पहले से ही इन कामों में बहुत अच्छे हैं:
- log/metric/trace correlation, incident triage, CI failure analysis, और dashboards/runbooks बनाना।
- CLI-driven tasks (जैसे AWS) और checklist का पालन करते हुए end-to-end infra changes।
- दूसरे बताते हैं कि agents alerts को गलत समझते हैं, गलत layers के पीछे भागते हैं, बहुत ज़्यादा code फिर से लिख देते हैं, या debugging को और कठिन बना देते हैं जब उनके पहले के changes सूक्ष्म रूप से गलत हों।
- सहमति: AI शक्तिशाली है, लेकिन केवल उतना ही जितना context, tooling, और human supervision हो; अक्षम लोग बेहतर tools के साथ भी अक्षम ही रहते हैं।
उपमाएँ और ऐतिहासिक समानताएँ
- Aviation का बार-बार उदाहरण दिया जाता है: autopilot safety बेहतर करता है, लेकिन manual practice और training अनिवार्य होते हैं; लोग SRE के लिए “incident simulators” / chaos exercises सुझाते हैं।
- विरोधी तर्क: software में aviation जैसी regulation और incentives नहीं हैं, इसलिए ज़्यादातर orgs अनिवार्य practice में निवेश नहीं करेंगे।
- अन्य उपमाएँ: calculators और long division, CNC बनाम manual machining, Docker/Terraform द्वारा पहले से ही infra work का “deskilling”, और इतिहास भर में mundane skills का व्यापक automation.