मेरी ज़िंदगी में सबसे अच्छी ops इंसान वो थी जो ज़्यादातर समय अपनी desk पर किताब पढ़ती रहती थी। Deploys — नए code को live servers पर release करना — टाइम पर होते थे। वो incidents को resolve कर देती थी इससे पहले कि किसी को पता भी चले। New hire onboarding घड़ी की तरह चलती थी।
उसके manager ने उसे almost fire कर दिया था — "काफी busy नहीं दिखती।"
वो खाली नहीं थी। उसका काम पूरा हो चुका था।
वो gap जिसके बारे में कोई बात नहीं करता
Work culture visible effort को reward करती है। जो developer ज़ोर-ज़ोर से keyboard पीट रहा है वो productive दिखता है। जो बीस मिनट छत की तरफ देख रहा है — architecture सोच रहा है — वो आलसी दिखता है। रात 11 बजे emails का जवाब देने वाला "dedicated" कहलाता है। जो शाम 5 बजे निकल जाए वो "committed नहीं है।"
2022 में Columbia, Georgetown, और Harvard के researchers की एक study ने confirm किया जो ops लोग पहले से जानते थे: managers consistently उन employees को ज़्यादा competent rate करते हैं जो "busy दिखते हैं," भले ही उनका actual output उनके शांत colleagues से कम हो। हम काम की appearance को reward करते हैं, काम को नहीं।
12 मार्च को PagerDuty ने अपना SRE Agent as a virtual responder launch किया — ऐसा software जो outages detect करता है, diagnostics run करता है, और fix procedures follow करता है बिना किसी इंसान के keyboard छुए। चार दिन बाद, 16 मार्च को GTC में, NVIDIA ने Agent Toolkit with OpenShell announce किया — autonomous operations agents को safely production में चलाने का infrastructure। 24 मार्च को YC Demo Day पर IncidentFox जैसे startups ने autonomous incident response को अपना पूरा product बनाकर pitch किया। Market से signal साफ है: अगर कोई task predictable pattern follow करता है, तो इंसान को हाथ से नहीं करना चाहिए।
जो सवाल अब हर ops team के सामने है: अगर AI agents — ऐसे programs जो खुद decisions लेते हैं और बिना constant human supervision के steps execute करते हैं — visible firefighting handle कर लें, तो ops इंसान दिनभर करे क्या?
जवाब बदला नहीं है। लेकिन इसे समझने का pressure बढ़ गया है।
Operations में पुराना incentive structure एक perverse dynamic create करता है — ऐसा system जो बिल्कुल गलत behavior को reward करता है। अगर तुम्हारी company तुम्हें आग बुझाने के लिए value करती है, तो तुम्हारे पास आग रोकने की zero motivation है। अगर तुम्हारा manager तुम्हारी worth इससे measure करता है कि तुम कितने urgent Slack messages handle करते हो, तो ऐसे systems बनाना जो उन messages को eliminate कर दें — तुम्हें dispensable बना देता है। और अब AI agents भी आग बुझाते हैं। तेज़। बिना सोए। बिना शिकायत किए।
Ops के दिल में paradox
तुम operations में जितने अच्छे हो, उतना कम लगता है कि तुम कुछ कर रहे हो। जो firefighter आग रोक दे वो बेरोज़गार दिखता है। जिस ops person के systems कभी टूटते ही नहीं वो slacker दिखता है। Visible काम इसलिए गायब हो जाता है क्योंकि किसी ने invisible काम सही किया।
मैंने ये pattern सालों से देखा है। जो ops person अपना काम automate कर ले, उससे पूछा जाता है: "तुम दिनभर करते क्या हो?" जो हर incident manually handle करता है, बारह-बारह घंटे काम करता है, उसे promote मिलता है "above and beyond" जाने के लिए।
एक ने system बनाया। दूसरे ने खुद पर dependency बनाई। खुद से पूछो — company को actually किसकी ज़रूरत है — और AI agent सबसे पहले किसकी जगह लेगा।
अच्छा ops काम असल में कैसा दिखता है
अच्छा operations काम दो phases में होता है।
Phase 1: Systems बनाओ। ये part visible है और time-limited। Runbooks लिखना — specific situations handle करने के step-by-step guides। Monitoring setup करना — automated checks जो users को पता चलने से पहले problems पकड़ लें। Repeating tasks के लिए automation बनाना। Processes document करना ताकि कोई भी follow कर सके। ये phase intense होता है: typically दो से छह महीने का focused काम।
Phase 2: Systems maintain करो। यहीं confusion शुरू होता है। Systems चलते हैं। Alerts fire होते हैं और runbooks handle करते हैं — और अब तो AI agents भी उन runbooks को बिना human intervention execute कर रहे हैं। New hires documented processes से खुद onboard हो जाते हैं। Deploys CI/CD pipelines से flow होते हैं — automated sequences जो code को developer के laptop से production servers पर बिना manual steps के पहुँचाती हैं।
Phase 2 में ops person का काम: ऐसे patterns watch करना जो बताएँ कि कोई system degrade हो रहा है। Post-mortems run करना — structured reviews कि क्या गलत हुआ और क्यों। Future capacity की planning करना। Decide करना कि कौन से नए processes agents को दिए जाएँ और किनमें अभी human judgment चाहिए। पढ़ना। सीखना। सोचना।
वो आखिरी part "कुछ नहीं कर रहा" जैसा दिखता है। लेकिन जो ops person नए tools study नहीं कर रहा, failure scenarios model नहीं कर रहा, evaluate नहीं कर रहा कि कौन सा agent framework उनके infrastructure में fit होगा, और उन situations की planning नहीं कर रहा जो अभी हुई नहीं हैं — वो जब हालात बिगड़ेंगे तो बिल्कुल तैयार नहीं मिलेगा। Google की Site Reliability Engineering handbook साफ कहती है: काम है reliability engineer करना, heroically उसकी absence से recover करना नहीं।
Busy एक bug report है
मैं वो बात बोलता हूँ जो कोई ज़ोर से नहीं बोलता: constant busyness broken systems का signal है, dedication का नहीं।
हमेशा आग बुझा रहे हो? तुम्हारे prevention systems fail हो गए। हमेशा context-switching — हर कुछ मिनट में unrelated tasks के बीच jump कर रहे हो? तुम्हारी prioritization fail हो गई। हमेशा meetings में हो? तुम्हारे communication systems fail हो गए। हमेशा new hires को हाथ पकड़कर train कर रहे हो? तुम्हारा onboarding fail हो गया।
"Busy" कोई aspirational state नहीं है। "Busy" एक bug report है।
Operations का goal — और honestly, ज़्यादातर knowledge work का — ऐसी state reach करना है जहाँ systems predictable नब्बे percent handle करें और तुम्हारे पास unpredictable दस percent के लिए bandwidth हो। वो unpredictable हिस्सा वहाँ है जहाँ human judgment matter करता है। बाकी सब खुद चलना चाहिए। March 2026 में "खुद चलना" का मतलब increasingly ये है कि AI agent चलाता है — और जिस ops person ने system बनाया वो decide करता है कि agent को क्या छूना चाहिए और क्या नहीं।
रास्ता बाहर का
अगर तुम अभी operational काम में डूब रहे हो, तो ये practical sequence follow करो।
Week 1–2: सब कुछ track करो। हर task, हर interrupt, हर recurring problem। अभी कुछ fix मत करो। बस observe करो।
Week 3–4: Categorize करो। क्या repeat होता है? क्या pattern follow करता है? क्या एक script — कोई छोटा program जो manual step automate करे — एक checklist, या AI agent handle कर सकता है? Typically साठ से सत्तर percent operational काम "predictable और automatable" category में आता है।
Week 5–8: Top ten time-consumers को automate या document करो। एक per week। जो सबसे ज़्यादा interrupt करे उससे शुरू करो। Incident response के लिए — outages detect और fix करने का process — agent-driven triage consider करो: PagerDuty के SRE Agent या open-source alternatives जैसे tools pattern-matched incidents handle करते हैं और novel ones तुम्हें escalate करते हैं।
Month 3: अब तुम्हारे पास चालीस से पचास percent ज़्यादा bandwidth है। इसे problems के next tier में invest करो।
Month 6: तुम अपनी desk पर किताब पढ़ रहे हो। तुम्हारे systems चल रहे हैं। तुम्हारे agents predictable काम handle कर रहे हैं। तुम idle दिख रहे हो। तुम idle नहीं हो। तुम्हारा काम पूरा हो चुका है।
Managers के लिए एक बात
अगर तुम्हारा सबसे अच्छा ops person bored दिख रहा है, बधाई हो। तुम्हारे systems काम कर रहे हैं। उनकी salary justify करने के लिए busywork assign मत करो। उनसे productivity theater मत करवाओ — वो performative नाटक जहाँ इंसान busy दिखने की acting करता है ताकि किसी की "hard work" वाली expectation पूरी हो।
इसके बजाय उनसे पूछो: "अगर तुम्हें तीन महीने uninterrupted मिलें, तो क्या बनाओगे?" फिर वो तीन महीने दे दो। जो वो बनाएँगे वो किसी भी visible busyness से कहीं ज़्यादा save करेगा।
तुम्हारी company का सबसे productive इंसान शायद वो है जो सबसे कम करता दिखता है। ये paradox नहीं है। "काम पूरा हो गया" — ऐसा दिखता है।
