मार्च 2024 में मैंने vacation लेने की कोशिश की। चार दिन चला।
दूसरे दिन तक मैंने Slack पर "बस एक quick question" का जवाब दे दिया। तीसरे दिन hotel lobby में बैठकर production issue debug कर रहा था — हमारे live, customer-facing servers में problem थी। चौथे दिन मेरी partner ने कहा: "वापस काम पर चला जा। ये vacation नहीं है।" वो सही कह रही थीं।
Problem मेरी team नहीं थी। वो capable थे। Problem ये था कि company के आधे operations की एकमात्र copy मेरे दिमाग में थी। Deploy procedure? मेरे head में। Client escalation flow? मेरे head में। Billing service freeze होने पर restart कैसे करें? वो भी मेरे head में। मैं indispensable इसलिए नहीं था क्योंकि मैं brilliant था। मैं indispensable इसलिए था क्योंकि मैंने कुछ भी लिखा ही नहीं था।
छह महीने बाद, September 2024 में, मैंने पूरे दो हफ्ते की छुट्टी ली। No laptop. No Slack. No "quick calls." कुछ नहीं टूटा।
यहाँ बताता हूँ उन छह महीनों में मैंने क्या किया।
Step 1: अपना bus factor ढूंढो
"Bus factor" — एक morbid लेकिन useful metric: तुम्हारी team में कितने लोगों का गायब होना ज़रूरी है कि एक process पूरी तरह रुक जाए? अगर जवाब "एक" है, और वो एक तुम हो, तो तुम्हारे पास system नहीं है। तुम्हारे पास hostage situation है।
मैंने अपने हर recurring task की list बनाई और एक सवाल पूछा: "अगर मैं कल गायब हो जाऊं, तो ये कौन कर पाएगा?"
| Task | Bus factor | और कौन जानता है? |
|---|---|---|
| Production deploys | 1 (मैं) | कोई नहीं |
| Client billing issues | 1 (मैं) | कोई नहीं |
| Server monitoring response | 1 (मैं) | कोई नहीं |
| Sprint planning | 2 | Co-lead |
| Code reviews | 3 | कोई भी senior dev |
| Hiring interviews | 2 | Co-lead |
तीन critical processes जिनका bus factor 1 था। तीन चीज़ें जो पूरी तरह रुक जातीं अगर मुझे food poisoning हो जाती। ये operations नहीं है। ये one-man show है जिसने team का costume पहन रखा है।
ये concept open-source software culture से आया है, जहाँ projects contributor count पर टिके होते हैं। Wikipedia का bus factor page बड़ी tech companies के examples देता है — वही problem, बड़ा scale।
Step 2: Documentation नहीं, Runbooks लिखो
ये distinction important है। Documentation explain करती है कि कुछ कैसे काम करता है। Runbook — एक operational procedure document, किसी specific situation को handle करने की step-by-step recipe — बताता है कि क्या करना है।
Documentation: "Billing service Stripe webhooks (automatic notifications जो Stripe payment event होने पर भेजता है) use करती है payments process करने के लिए। Events Redis में queue होते हैं और billing worker process करता है।"
Runbook: "जब billing stuck हो: 1) Redis queue length check करो: redis-cli llen billing_queue। 2) अगर queue > 100 हो, billing worker restart करो: systemctl restart billing-worker। 3) अगर restart के 5 minutes बाद भी queue clear न हो, Stripe dashboard पर failed webhooks check करो।"
फ़र्क दिख रहा है? Documentation को समझने की ज़रूरत होती है। Runbook को बस follow करने की। कोई भी जो terminal — वो text-based interface जहाँ तुम directly commands type करते हो — में commands type कर सकता है, runbook follow कर सकता है। उन्हें ये समझने की ज़रूरत नहीं कि Redis (एक fast in-memory database जो अक्सर message queue की तरह use होता है) क्यों involved है। उन्हें बस ये जानना है कि क्या type करना है।
PagerDuty, जिन्होंने incident response के ऊपर पूरा business बनाया है, ने एक solid runbooks लिखने की guide publish की है जो same principle cover करती है: comprehension के लिए नहीं, action के लिए optimize करो।
मैंने तीनों bus-factor-1 processes के लिए runbooks लिखे। हर एक में 30–60 minutes लगे। Format ये रहा:
Runbook: Production Deploy
कब use करें:
जब main में merge करके production में deploy करना हो।
Prerequisites:
- Prod server पर SSH access (नहीं है तो IT से माँगो)
- #deploys Slack channel का access
Steps:
1. PR को main में merge करो
2. CI checks pass होने दो (GitHub Actions, ~5 min)
3. Server पर SSH करो: ssh [email protected]
4. Run करो: bash /srv/app/deploy.sh
5. Health check करो: curl -s http://localhost:8080/health | jq .
6. Health check fail हो तो: bash /srv/app/rollback.sh
7. #deploys में result post करो
अगर कुछ गड़बड़ हो:
- Deploy script fail हो → logs check करो /var/log/deploys/ पर
- Health check 503 return करे → JSON response में देखो कौन सा subsystem fail हुआ
- SSH न हो पाए → IT से contact करो, VPN check करो
- Rollback fail हो → Capitan को call करो। Slack नहीं। Phone।
Escalation:
अगर 15 minutes से ज़्यादा stuck हो, Capitan को call करो। Phone पर, Slack पर नहीं।
कोई theory नहीं। कोई architecture diagrams नहीं। बस: "जब ये हो, तो ये करो।"
Step 3: Shadow week
Runbooks लिखना काफ़ी नहीं है। तुम्हें इन्हें असली इंसानों पर test करना होगा।
मैंने एक "shadow week" चलाया — एक हफ्ता जिसमें मैं available रहा लेकिन तीनों processes को खुद हाथ नहीं लगाया। किसी और ने runbook follow किया। मैंने बस देखा।
Results:
- Deploy runbook: पहली बार में काम कर गया। Team member को step 4 में एक typo मिला (गलत file path)। दो minutes में fix हो गया।
- Billing runbook: Step 3 पर fail हुआ। मैंने लिखा था "Stripe dashboard check करो" लेकिन login कैसे करना है ये कभी explain नहीं किया। Credentials मेरे personal password manager में थे, shared वाले में नहीं। Shared access add किया — problem solved।
- Monitoring runbook: Partially काम किया। Steps सही थे, लेकिन monitoring tool का UI बदल गया था जब से मैंने doc लिखा था। Screenshots update किए।
हर एक runbook में कम से कम एक correction चाहिए था। ये normal है। जब तुम memory से लिखते हो, तो वो steps skip कर देते हो जो "obvious" लगते हैं क्योंकि तुमने वो 500 बार किए हैं। Shadow week इन gaps को expose करता है इससे पहले कि Saturday रात 3 बजे matter करें।
Google की SRE team — वो group जो Google का infrastructure चलाती रखती है — अपनी free Site Reliability Engineering book में यही principle cover करती है: documentation जो real conditions में test नहीं हुई, वो fiction है।
Step 4: Knowledge transfer meeting
हर runbook के लिए मैंने एक 30 minute की knowledge transfer session रखी। Training नहीं — transfer। Training skills सिखाती है। Transfer context सिखाता है।
Structure:
- साथ में runbook walk-through (10 min) — वो person हर step follow करता है, मैं देखता हूँ। Help तभी जब वो stuck हों।
- Critical steps का "why" explain करो (10 min) — execution के लिए ज़रूरी नहीं, लेकिन judgment calls में help करता है। "हम billing worker को investigate करने से पहले restart करते हैं क्योंकि downtime की cost $X per minute है। पहले speed, फिर root cause।"
- Q&A (10 min) — उनके सवाल exactly reveal करते हैं कि मैं क्या document करना भूल गया।
Meeting के बाद, वो process उनका है। "Process में help करना" नहीं। Own करना। मैं backup बन जाता हूँ, primary नहीं।
Step 5: Vacation test
Shadow week के दो महीने बाद, मैंने बिना laptop के तीन दिन का long weekend लिया। कोई emergency नहीं। कोई "quick questions" नहीं। Runbooks ने काम किया।
एक महीने बाद, पूरे हफ्ते की छुट्टी। एक minor issue: monitoring runbook ने एक specific edge case cover नहीं किया था — non-standard partition पर disk full। On-call person ने सही improvise किया और बाद में वो case runbook में add कर दिया। System ने मेरे बिना खुद को improve कर लिया। ये sign है कि चीज़ें काम कर रही हैं।
उसके एक महीने बाद: पूरे दो हफ्ते। Zero incidents जिनमें मेरी involvement ज़रूरी हो। Team ने मुझे whiteboard की photo भेजी जिस पर लिखा था: "Day 9: Capitan ने call नहीं किया। लगता है system काम कर रहा है।"
वो बात जो कोई नहीं करता
Processes से खुद को लिखकर बाहर करना ऐसा लगता है जैसे खुद को dispensable बना रहे हो। बना रहे हो। यही तो point है।
लेकिन ये कुछ uncomfortable trigger करता है — तुम्हारी identity का वो हिस्सा जो "सब कुछ जानने वाला इंसान" होने से जुड़ा है। वो जिसे लोग call करते हैं। वो जो दिन बचाता है।
Honestly बताऊं: जब deploys मेरे बिना होने लगे तो अजीब लगा। जब billing issues बिना text के resolve हो गईं। जब server alert fire हुआ और किसी और ने 8 minutes में handle कर लिया। मेरा एक हिस्सा चाहता था कि मेरी ज़रूरत हो।
इसके बदले मुझे ये मिला: freedom। सिर्फ़ vacation freedom नहीं — daily freedom। मैं bottleneck बनना बंद हुआ — वो single point जहाँ सारे decisions stack होकर wait करते थे। जो काम पहले मेरे पीछे queue में लगा रहता था वो अब real time में होने लगा। Team faster move करने लगी। मैं उन decisions पर focus कर पाया जिनमें सच में मेरी judgment ज़रूरी थी, बजाय उन tasks के जिनमें बस मेरी memory चाहिए थी।
तुम्हारी action list
March 2026 तक, मैंने ये process तीन अलग-अलग organizations में repeat किया है। Pattern हर बार hold करता है। अगर तुम दो हफ्ते की छुट्टी नहीं ले सकते बिना सब कुछ टूटे, तो तुम्हारे पास system नहीं है — तुम्हारे पास busy रहने की आदत है।
तुम्हारी checklist:
- अपना bus factor audit करो — हर recurring task list करो, mark करो कि और कौन कर सकता है
- Runbooks लिखो हर उस चीज़ के लिए जिसका bus factor = 1 (30–60 minutes budget करो हर एक पर)
- Shadow week चलाओ — कोई और execute करे, तुम देखो और docs fix करो
- Knowledge transfer meetings करो — हर process के लिए 30 minutes, structured
- Real vacation से test करो — पहले long weekend, फिर एक हफ्ता, फिर दो
Runbook लिखो। Shadow week करो। Vacation लो।
तुम rested होकर वापस आओगे, और team तुम्हारे जाने से पहले से ज़्यादा capable होगी। ये dispensable होना नहीं है। ये अच्छी engineering है।
