स्वस्थ On-Call संस्कृति बनाना

• काम के समय के बाहर समस्या होने पर page प्राप्त करके उसे हल करने वाले इंजीनियर को नामित करने वाली "on-call" व्यवस्था पर SoundCloud के टिप्स

1. on-call ड्यूटी वैकल्पिक है (Optional, केवल इच्छुक लोगों के लिए)

2. यह नियमित काम के घंटों के बाहर का काम है, इसलिए इसके लिए प्रति घंटा भत्ता दिया जाता है, और paging का जवाब देने पर प्रति घंटा अतिरिक्त भुगतान किया जाता है

3. on-call इंजीनियर कई rotations से मिलकर बनते हैं

4. प्रत्येक rotation

→ एक या कई टीमों का प्रतिनिधित्व करने वाले इंजीनियरों के समूह से बना होता है

→ rotation में मौजूद सभी टीमों की समस्याओं के लिए प्राथमिक सहायता संभालने वाला 1 इंजीनियर हमेशा standby पर रहता है

→ बाकी इंजीनियर अपनी-अपनी टीमों की services से जुड़ी समस्याओं के लिए secondary support देने हेतु standby पर रहते हैं

→ secondary support best-efforts आधार पर होता है: किसी भी समय page मिल सकता है और संभव हो तो पूरी कोशिश से उसे संभाला जाता है, लेकिन यदि स्वयं के लिए संभव न हो to जवाब देना अनिवार्य नहीं है

on-call ड्यूटी इंजीनियरों के लिए अच्छी क्यों है?

• DevOps और SRE(Site Reliability Engineers) के अलावा विभिन्न इंजीनियरों को on-call ड्यूटी में शामिल करना कंपनी और इंजीनियर दोनों के लिए अच्छा है

• इससे उन operations टीम इंजीनियरों का बोझ कम होता है जो हमेशा overtime काम करते हैं

• यह इंजीनियरों को स्थिर और अच्छी तरह documented systems बनाने के लिए प्रेरित करता है

→ समस्या आने पर उसे सीधे देखना इस बारे में insight देता है कि system को कैसे बेहतर और अधिक मज़बूत बनाया जाए

• अपने systems और दूसरों के systems दोनों को support करना इंजीनियरों के लिए सीखने का अच्छा अवसर है

प्रक्रियागत best practices: हर संगठन अलग होता है, लेकिन यह वह सर्वोत्तम process है जो SoundCloud ने पाया

• हर rotation का handoff cycle अलग होता है, लेकिन अधिकतर 1 से 2 दिन के अंतराल पर बदलते हैं

• महीने में लगभग 3 दिन on-call पर रहना सबसे अच्छा है। इससे अधिक होने पर burnout होता है, और इससे कम होने पर यह प्रभावी नहीं रहता।

→ यानी rotation का आदर्श आकार 8~12 लोग है। 10 लोग हों तो सबसे बेहतर।

• rotation के भीतर औपचारिक/अनौपचारिक manager चुने जाते हैं, जो shift schedule management, सदस्य बदलाव आदि के जरिए rotation को manage करते हैं

→ उदाहरण) छुट्टियों के दौरान shift schedule का समायोजन

rotation टीम और संगठन

• SoundCloud का संगठन समय के साथ विकसित हुआ, और उसमें merger, split, नई टीमों का निर्माण, और टीमों का विभागों के बीच स्थानांतरण हुआ

• लेकिन on-call rotation टीमें engineering organization की गति के साथ विकसित नहीं हुईं

• वर्तमान में कई rotations ऐसे भी दिखते हैं जैसे वे बिल्कुल असंबंधित टीमों का random group हों

• लेकिन यह समस्या नहीं बनी, और इसे बदलने की कोशिश इंजीनियरों की आपत्ति के कारण रोक दी गई

सांस्कृतिक best practices: on-call इंजीनियरों और पूरी कंपनी के हित के लिए निम्न norms और attitudes को बढ़ावा देना

• जो लोग on-call पर हैं, वे on-call पर रहना चाहते हैं। स्वेच्छा से ज़िम्मेदारी लेने वाले (और उसके लिए भुगतान पाने वाले) इंजीनियर incident response के समय अधिक motivated रहते हैं

• handoff cycle जैसी बातें प्रत्येक rotation के इंजीनियर आपस में चर्चा करके तय करते हैं। कंपनी handoff pattern, handoff time, या व्यक्तियों के बीच handoff transfer के बारे में standard process नहीं देती

• on-call इंजीनियर अक्सर नियमित काम के समय में यह जांचने में समय लगाते हैं कि ये समस्याएँ और न बढ़ें या काम के बाहर किसी और को page न करना पड़े

• incident response के दौरान इंजीनियर अन्य इंजीनियरों को बुलाकर मदद मांग सकते हैं। किसी को भी आधी रात में secondary support के लिए page मिलना पसंद नहीं होता, लेकिन यदि संभव हो तो जवाब देकर मदद की जाती है, ताकि बाद में वही व्यक्ति ऐसी स्थिति को अकेले संभालने लायक सीख सके

• उचित समय बीत जाने के बाद काम किसी और को स्वतंत्र रूप से सौंपा जा सकता है। गंभीर या लंबे समय तक चलने वाले incidents में, यदि इंजीनियर थक जाएँ और प्रभावी ढंग से काम न कर पाएं, तो 4 घंटे के भीतर या उससे पहले भी handoff कर देना बेहतर है

• सबसे महत्वपूर्ण बात है, "blame culture नहीं बल्कि learning culture को बढ़ावा देना"। इस पर कितना भी ज़ोर दिया जाए, कम है

→ incident response में गलतियाँ होना अपरिहार्य है, और गलतियों से सीखने पर अधिक मज़बूत और तकनीकी रूप से सक्षम engineering organization बनती है

→ यदि गलतियों के लिए लोगों को दंडित किया जाए, तो इंजीनियर नई स्थिति आने पर कार्रवाई करने से डरने लगते हैं, मदद मांगने से डरते हैं, और transparency से भी डरने लगते हैं

→ अंततः blame culture में लोग on-call rotation छोड़ देते हैं या कंपनी ही छोड़ देते हैं

जब बड़ा incident होता है

• पूरे site का down होना या किसी गंभीर incident का response करना हर किसी के लिए stressful होता है

• यह कंपनी की on-call culture की stress test भी है

• इंजीनियरों का साथ मिलकर काम करना और एक-दूसरे पर भरोसा करना किसी भी चीज़ से अधिक महत्वपूर्ण है

• यदि लोग यह स्वीकार कर सकें कि वे क्या नहीं जानते, दूसरों से मदद मांग सकें, अपनी गलती के बारे में ईमानदारी से बता सकें, और यह कह सकें कि वे इतने थक गए हैं कि आगे बढ़ना मुश्किल है, तो समस्या को और जल्दी हल किया जा सकता है

• ऐसे व्यवहार को बड़े incident होने से पहले विकसित करना चाहिए। इंजीनियर छोटे incidents का response करते हुए और साथियों के साथ सहयोग करते हुए अनुभव से सीखते हैं.

→ छोटे incidents, बड़े incidents की practice होते हैं

[xguru]

• GitHub द्वारा बनाई गई on-call संस्कृति https://hi.news.hada.io/topic?id=3551

• GitLab On-Call Runbooks https://hi.news.hada.io/topic?id=966

startup में लोग कम होते हैं, इसलिए अक्सर ऐसा लगता है कि हमेशा on-call रहना पड़ता है..

लेकिन जैसे-जैसे organization थोड़ा बड़ा होने लगता है, कुछ ही लोग लगातार on-call पर रहने लगते हैं, और शाम व weekend में भी समस्याएँ हल करते-करते उनके burnout होने का जोखिम दिखने लगता है.

मूल रूप से लगता है कि संस्कृति को सही ढंग से बनाना बहुत ज़रूरी है (असल में मैं खुद भी यह ठीक से नहीं कर पाया था, इसलिए इस पर थोड़ा आत्मचिंतन कर रहा हूँ..)