कसरी हामीले बर्नआउट रोक्नको लागि सँधै जडान गरिएको राज्यलाई परिवर्तन गर्यौं

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

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

सहज सञ्चालन धेरै कारकहरूमा निर्भर गर्दछ, जस्तै सफ्टवेयर वास्तुकला र दैनिक कामको गुणस्तर। यद्यपि, प्रायः यो सबै तथ्यमा आउँछ कि सधैं सम्पर्कमा रहने व्यक्तिले कलको जवाफ दिन्छ पेजरड्यूटी। यस प्रकारको प्राविधिक समर्थन एक शक्तिशाली ग्राहक-केन्द्रित उपकरण हुन सक्छ जसले ईन्जिनियरहरूको मद्दतलाई संयोजन गर्दछ जुन ग्राहकहरूले तपाईंको उत्पादन खरीद गर्दा प्राप्त गर्छन्। यो सिक्ने र वृद्धिको लागि एक ठूलो अवसर पनि हो, किनभने सबै पछि, असफलता र गल्तीहरू सीपहरू अभ्यास गर्न र जटिल कार्य संयन्त्रहरू बुझ्नको लागि राम्रो अवसर हुन सक्छ।

कामको समय भन्दा बाहिर "सधैं सक्रिय" हुनुले तपाईंको जीवनमा हानिकारक प्रभाव पार्छ।

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

Intercom मा "सधैं जडान" राज्य को इतिहास

इन्टरकमको प्रारम्भिक दिनहरूमा, हाम्रो प्राविधिक निर्देशक, सियारनले एक्लैले कार्यालय भित्र र बाहिर दुवै XNUMX/XNUMX प्राविधिक सहयोगको सम्पूर्ण टोली प्रदान गर्नुभयो। इन्टरकम बढ्दै जाँदा, सियारनलाई मद्दत गर्नको लागि टास्क फोर्स सिर्जना गरियो। चाँडै पछि, नयाँ विकास टोलीहरूले धेरै नयाँ सुविधाहरू र सेवाहरू सिर्जना गर्न थाले, र तिनीहरूले सबै प्राविधिक समर्थन जिम्मेवारीहरू लिए।

कुनै पनि क्षणमा "कलमा" धेरै मानिसहरू थिए।

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

हामीले महसुस गर्यौं कि हामी यस्तो अवस्थामा थियौं जहाँ हामीसँग प्राविधिक समर्थन मेकानिकहरू छन् जसमा हामी गर्व गर्न सक्दैनौं, र हामीले समाधान गर्न चाहने धेरै महत्त्वपूर्ण मुद्दाहरू, जस्तै:

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

सही "सधैं सक्रिय" स्थिति खोज्दै

हामीले एउटा नयाँ भर्चुअल टोली सिर्जना गर्ने निर्णय गर्‍यौं जसले प्रत्येक टोलीको लागि गैर-काम गर्ने घण्टामा प्राविधिक समर्थन कार्य गर्ने छ। टोली स्वयंसेवकहरूको बनाइनेछ, संगठनको कुनै पनि टोलीबाट भर्ती होइन। भर्चुअल टोलीका इन्जिनियरहरूले लगभग हरेक छ महिनामा घुमाए, हप्ताहरू "कलमा" खर्च गरे। सौभाग्य देखि, हामीलाई भर्चुअल टोली भेला गर्न पर्याप्त स्वयंसेवकहरू फेला पार्न कुनै समस्या थिएन।

नतिजा स्वरूप, हाम्रो समर्थन टोली 30 जनाबाट घटाएर 6 वा 7 मात्र भयो।

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

हामीले धेरै महिनाको कडा परिश्रम गरेका थियौं, जसको अवधिमा हामीले यो प्रक्रिया स्थापना गरेका थियौं; फलस्वरूप, पहिले जस्तो कलमा 30 ईन्जिनियरहरू थिएनन्, तर 6 वा 7 मात्र थिए। कार्य घण्टामा, टोलीहरूले स्वतन्त्र रूपमा उनीहरूको कार्य वा सेवाहरू, यो समय हो जब ब्रेकडाउनहरूको सबैभन्दा ठूलो संख्या सामान्यतया हुन्छ, तर अन्य सबै समयमा, स्वयंसेवकहरूद्वारा प्राविधिक सहयोग प्रदान गरिन्छ।

हामीले के सिकेका छौं

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

घण्टा पछि कलहरूको संख्या प्रति महिना 10 भन्दा कममा झरेको छ।

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

हाम्रो स्यान फ्रान्सिस्को कार्यालयका इन्जिनियरहरू पूर्ण-समय टोलीमा सामेल भए र सामान्य प्राविधिक समर्थनभन्दा पर गए। हामीले केही ओभरहेड लागतहरूको सामना गरेका थियौं, तर धेरै अफिसहरूमा हाम्रो समर्थन टोलीको सदस्यता फैलाउनुले हाम्रो फाइदाको लागि काम गर्‍यो किनकि यो सम्बन्ध निर्माण गर्न, तिनीहरूलाई बलियो बनाउन र हामी सबैसँग काम गर्ने टेक्नोलोजी स्ट्याकको बारेमा थप जान्नको लागि राम्रो तरिका साबित भयो।

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

हाम्रा डाटा स्टोरहरूलाई स्थिर र मापन गर्ने आधारभूत कार्यको साथसाथै, समस्या समाधानमा निरन्तर ध्यान केन्द्रित गर्दा घण्टा बाहिर आउने कलहरूको संख्या प्रति महिना १० भन्दा कममा झरेको देखेको छ। हामी यो संख्यामा धेरै गर्व गर्छौं।

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

स्रोत: www.habr.com