बर्नआउट को रोकने के लिए हमने हमेशा कनेक्टेड स्थिति को कैसे बदला

लेख का अनुवाद विशेष रूप से पाठ्यक्रम के छात्रों के लिए तैयार किया गया था "DevOps अभ्यास और उपकरण".

इंटरकॉम का मिशन ऑनलाइन व्यवसाय को निजीकृत करना है। लेकिन जब कोई उत्पाद काम नहीं करता तो आप उसे वैयक्तिकृत नहीं कर सकते। जैसा होना चाहिए. प्रदर्शन हमारे व्यवसाय की सफलता के लिए महत्वपूर्ण है, न केवल इसलिए कि हमारे ग्राहक हमें भुगतान करते हैं, बल्कि इसलिए भी कि हम स्वयं उपयोग करते हैं आपके उत्पाद के साथ. यदि हमारी सेवा काम नहीं करती है, तो हम सचमुच अपने ग्राहकों का दर्द महसूस करते हैं।

सुचारू संचालन कई कारकों पर निर्भर करता है, जैसे सॉफ़्टवेयर आर्किटेक्चर और दैनिक कार्य की गुणवत्ता। हालाँकि, अक्सर यह सब इस तथ्य पर निर्भर करता है कि जो व्यक्ति हमेशा संपर्क में रहता है वह कॉल का उत्तर देता है PagerDuty. इस प्रकार की तकनीकी सहायता एक शक्तिशाली ग्राहक-केंद्रित उपकरण हो सकती है जो आपके उत्पाद खरीदने पर ग्राहकों को मिलने वाली चीज़ों के साथ इंजीनियरों की मदद को जोड़ती है। यह सीखने और विकास के लिए भी एक शानदार अवसर है, क्योंकि आखिरकार, असफलताएं और गलतियाँ कौशल का अभ्यास करने और जटिल कार्य तंत्र को समझने का एक अच्छा अवसर हो सकती हैं।

काम के घंटों के बाहर "हमेशा चालू" रहने से आपके जीवन पर हानिकारक प्रभाव पड़ता है।

लेकिन साथ ही, "हमेशा चालू" रहना आपके जीवन पर हानिकारक प्रभाव डाल सकता है। आपको किसी चीज़ के टूटने की सूचना पर तुरंत और सक्षमता से प्रतिक्रिया देने के लिए तैयार रहना चाहिए। भले ही आपको किसी भी समय पेज नहीं किया जा रहा हो, "हमेशा चालू" रहना चिंता पैदा कर सकता है, जैसा कि मैं व्यक्तिगत अनुभव से जानता हूं। इस वजह से, नींद की गुणवत्ता विशेष रूप से खराब हो जाती है। दिन के किसी भी समय नियमित रूप से एक्सेस ज़ोन में रहने से जलन, उदासीनता, या सामान्य तौर पर, कंप्यूटर को फिर कभी न देखने की इच्छा हो सकती है।

इंटरकॉम में "हमेशा कनेक्टेड" स्थिति का इतिहास

इंटरकॉम के शुरुआती दिनों में, हमारे तकनीकी निदेशक, सियारन ने अकेले ही कार्यालय के अंदर और बाहर, XNUMX/XNUMX तकनीकी सहायता की एक पूरी टीम प्रदान की। जैसे-जैसे इंटरकॉम का विकास हुआ, सियारन की मदद के लिए एक टास्क फोर्स बनाई गई। इसके तुरंत बाद, नई विकास टीमों ने कई नई सुविधाएँ और सेवाएँ बनाना शुरू कर दिया, और उन्होंने सभी तकनीकी सहायता जिम्मेदारियाँ अपने ऊपर ले लीं।

किसी भी समय "कॉल पर" बहुत सारे लोग मौजूद थे।

उस समय, यह दृष्टिकोण बिना सोचे-समझे लग रहा था क्योंकि यह एक पल की सूचना पर हमारी तकनीकी सहायता टीम को बढ़ाने का एक आसान तरीका था, यह हमारे मूल्यों के साथ संरेखित था, और यह हमारे अनुकूल था स्वामित्व की भावना. अंत में, बिना किसी योजना के, हमें चार या पाँच टीमें मिल गईं जो ग्राहकों से उनके गैर-कार्य घंटों के दौरान नियमित रूप से संपर्क करती थीं। बाकी विकास टीमों के पास ऐसे कई जटिल मुद्दे नहीं थे जो कोई त्रुटि उत्पन्न कर सकें, इसलिए उन्हें शायद ही कभी बुलाया गया था।

हमें एहसास हुआ कि हम ऐसी स्थिति में थे जहां हमारे पास तकनीकी सहायता यांत्रिकी थी जिस पर हम गर्व नहीं कर सकते थे, और कई महत्वपूर्ण मुद्दे जिन्हें हम ठीक करना चाहते थे, जैसे:

• किसी भी समय चुनौती लेने के लिए बहुत सारे लोग तैयार थे। हमारा बुनियादी ढांचा इतना बड़ा नहीं था कि नियमित छुट्टी के बिना काम करने के लिए कम से कम पांच विकास इंजीनियरों की आवश्यकता हो।
• हमारे अलार्म और कॉल प्रक्रियाओं की गुणवत्ता सभी टीमों के बीच एक समान नहीं थी, और हमने नई और मौजूदा समस्या अलर्ट की समीक्षा करने के लिए तदर्थ प्रक्रियाओं का उपयोग किया। रनबुक में निर्देश (किसी समस्या की सूचना मिलने पर पालन किया जाना चाहिए) ज्यादातर उनकी अनुपस्थिति से स्पष्ट थे।
• इंजीनियरों ने जिस टीम में काम किया, उसके आधार पर उनकी परस्पर विरोधी अपेक्षाएँ थीं। उदाहरण के लिए, केवल पहली तकनीकी सहायता टीम के पास ऑन-कॉल शिफ्ट और बाधित सप्ताहांत के लिए कोई मुआवजा था।
• विषम समय में अनावश्यक कॉलों के प्रति सहनशीलता का एक सामान्य स्तर दिखाई दिया।
• अंततः, इस प्रकार का कार्य हर किसी के लिए नहीं है। जीवन की परिस्थितियाँ कभी-कभी दिखाती हैं कि ड्यूटी शिफ्ट का लोगों पर सबसे अच्छा प्रभाव नहीं पड़ता है।

सही "हमेशा चालू" स्थिति ढूँढना

हमने एक नई वर्चुअल टीम बनाने का निर्णय लिया जो गैर-कार्य घंटों के दौरान प्रत्येक टीम के लिए तकनीकी सहायता कार्य करेगी। टीम स्वयंसेवकों से बनी होगी, न कि संगठन की किसी टीम के सिपाहियों से। वर्चुअल टीम के इंजीनियर लगभग हर छह महीने में घूमते हैं और "कॉल पर" सप्ताह बिताते हैं। सौभाग्य से, हमें एक आभासी टीम को इकट्ठा करने के लिए पर्याप्त स्वयंसेवकों को ढूंढने में कोई समस्या नहीं हुई।

परिणामस्वरूप, हमारी सहायता टीम 30 लोगों से घटकर केवल 6 या 7 रह गई।

इसके बाद टीम इस पर सहमत हुई और परिभाषित किया कि रनबुक में किस मुद्दे के अलर्ट और विवरण दिखने चाहिए, और नई सहायता टीम को अलर्ट अग्रेषित करने की प्रक्रिया का वर्णन किया। उन्होंने टेराफ़ॉर्म मॉड्यूल का उपयोग करके कोड में सभी अलर्ट को परिभाषित किया, और प्रत्येक परिवर्तन के लिए सहकर्मी समीक्षा का उपयोग करना शुरू किया। हमने साप्ताहिक पाली के लिए मुआवजे का एक स्तर पेश किया जो ड्यूटी अधिकारियों के लिए काफी संतोषजनक था। हमने एक दूसरे स्तर की उन्नत टीम भी बनाई जिसमें केवल प्रबंधक शामिल थे। यह टीम तकनीकी सहायता इंजीनियरों के लिए उन्नति का एकमात्र बिंदु होनी चाहिए।

हमें कई महीनों की कड़ी मेहनत करनी पड़ी, जिसके दौरान हमने इस प्रक्रिया को स्थापित किया; परिणामस्वरूप, अब पहले की तरह कॉल पर 30 इंजीनियर नहीं थे, बल्कि केवल 6 या 7 थे। काम के घंटों के दौरान, टीमें स्वतंत्र रूप से अपने कार्यों से संबंधित समस्याओं से निपटती हैं या सेवाओं पर, यह वह समय है जब आमतौर पर सबसे अधिक संख्या में ब्रेकडाउन होते हैं, लेकिन अन्य सभी समय पर, स्वयंसेवकों द्वारा तकनीकी सहायता प्रदान की जाती है।

हमने क्या सीखा

जब हमने अपनी वर्चुअल तकनीकी सहायता टीम लॉन्च की, तो हमें नए कार्यों की आमद की उम्मीद थी, जैसे कि समस्याओं के कारणों की जांच करना या किसी एक समस्या को हल करने के लिए एक साथ इकट्ठा होना जो आउटेज का कारण बन रही थी। हालाँकि, हमारी विकास टीमों ने विफलताओं का कारण बनने वाले कारकों की पूरी ज़िम्मेदारी ली, और कोई भी बाद की प्रतिक्रिया आम तौर पर तत्काल थी। हमें ऐसी स्थिति से भी बचने की ज़रूरत थी जिसमें तकनीकी परामर्श कार्य को उसी टीम को वापस भेजा जाएगा जिससे वह आया था, ताकि इंजीनियरों को घंटों बाद संपर्क करने के लिए बाध्य न किया जाए।

काम के बाद की कॉलों की संख्या प्रति माह 10 से भी कम हो गई है।

हमारी वृद्धि प्रक्रिया का औपचारिक रूप से शायद ही कभी उपयोग किया गया था। एक अधिक आम धारणा यह थी कि इंजीनियर को अनौपचारिक रूप से उस टीम द्वारा मदद की गई थी जो वर्तमान में ऑनलाइन थी, विशेषकर सैन फ्रांसिस्को कार्यालय में हमारे लोगों द्वारा। टीम वर्क और तत्काल समाधान के माध्यम से कई मुद्दों को समाप्त या कम किया गया।

हमारे सैन फ्रांसिस्को कार्यालय में इंजीनियर पूर्णकालिक रूप से टीम में शामिल हुए और विशिष्ट तकनीकी सहायता से आगे बढ़ गए। हमें कुछ ओवरहेड लागतों का सामना करना पड़ा, लेकिन हमारी सहायता टीम की सदस्यता को कई कार्यालयों में फैलाने से हमें फायदा हुआ क्योंकि यह रिश्ते बनाने, उन्हें मजबूत करने और उस प्रौद्योगिकी स्टैक के बारे में अधिक जानने का एक अच्छा तरीका साबित हुआ जिसके साथ हम सभी काम करते हैं।

हमारी टीमों में इंटरकॉम डेवलपर्स का काम अधिक सुसंगत हो गया है, और हम अपनी साइट पर सिस्टम इंजीनियर होने के लाभों के बारे में आत्मविश्वास से बात कर सकते हैं करियर, यह कहते हुए कि जब तक आप जुड़े रहना नहीं चाहते तब तक हमेशा जुड़े रहने की कोई आवश्यकता नहीं है।

हमारे डेटा स्टोर को स्थिर और स्केल करने के लिए बुनियादी काम के साथ-साथ, समस्या समाधान पर निरंतर ध्यान देने से आउट-ऑफ-घंटे कॉल की संख्या प्रति माह 10 से भी कम हो गई है। हमें इस संख्या पर बहुत गर्व है.

हम अपनी तकनीकी सहायता टीम को बनाए रखने और सुधारने पर काम करना जारी रखते हैं, और जैसे-जैसे इंटरकॉम बढ़ता है हमें अपने निर्णयों पर पुनर्विचार करना पड़ सकता है, क्योंकि आज जो काम करता है वह जरूरी नहीं कि अगली बार जब हमारा स्टाफ दोगुना हो जाए तो भी काम करेगा। हालाँकि, यह अनुभव हमारे संगठन के लिए बेहद सकारात्मक रहा है और इसने हमारे विकास इंजीनियरों के जीवन की गुणवत्ता, कॉल पर हमारी प्रतिक्रियाओं की गुणवत्ता और सबसे बढ़कर, हमारे ग्राहकों के अनुभव में काफी सुधार किया है।

स्रोत: www.habr.com