चेनसॉ सिलिकॉन हत्याकांड

ड्यूटी अधिकांश आधुनिक संगठनों का एक महत्वपूर्ण घटक है। आखिरकार, अक्सर ऐसा होता है कि समस्या सुबह 3 बजे आती है। लेकिन ड्यूटी पर कौन होना चाहिए? और इस प्रक्रिया को कैसे व्यवस्थित किया जाए ताकि यह समझ में आए?

बिल्ली के नीचे देखो, वहां बारूक सदोगुरस्की (@jbaruch) और लियोनिद इगोलनिक ( @ लिगोलनिक ) एक अशुभ कर्तव्य अधिकारी के बारे में एक डरावनी कहानी बताते हैं। याद रखें वासिया, जिन्हें हमेशा सुबह तीन बजे बग्स को ठीक करना पड़ता था? यह सिर्फ शुरुआत है।



शरद ऋतु के देवोप्स 2017 सम्मेलन में बारूक और लियोनिद के भाषण के आधार पर सामग्री तैयार की गई थी।



तो ड्यूटी पर। एक उदाहरण के रूप में, काल्पनिक वसिया को लें, जो लगभग एक साल पहले एक निश्चित कंपनी में काम कर रहा है। आज शुक्रवार है और ऐसा हुआ कि वस्या ड्यूटी पर है। सब कुछ ठीक हो जाता है: वासना सो रही है, और उसके सपने सुंदर हैं।

जबकि उन्हें कुछ भी संदेह नहीं है, उनके तकनीकी सहायता सहयोगी को एक ग्राहक से कॉल आता है। उनका कहना है कि सोमवार को उन्हें सीईओ को एक बहुत ही महत्वपूर्ण डेमो दिखाना होगा, लेकिन कुछ काम नहीं करता है। तत्काल समस्या को ठीक करने की आवश्यकता है। समर्थन ने यह सब कुछ किया (सुझाव दिया कि इसे बंद और चालू कर सकता है) और इस समस्या को परिचर तक बढ़ाता है।

पूरी परियोजना के लिए वास्या अकेले ड्यूटी पर हैं, उन्हें यह करना होगा। एक टेक सपोर्ट इंजीनियर ने उसे जगाया और बहुत सरल शब्दों में समस्या को समझाने की कोशिश की: "कुछ काम नहीं कर रहा है, कुछ गलत है।"

वासिया अपने सहयोगी की बात सुनती है, सोचती है कि क्या हुआ है और केवल सही निर्णय लेता है ...



समर्थन इंजीनियर नाराज है, लेकिन फिर भी ग्राहक को सोमवार तक इंतजार करने के लिए कहता है। ग्राहक इस स्थिति से सहमत नहीं है और समस्या को समर्थन प्रबंधक तक बढ़ाता है। अब वह वस्या को फोन करता है और कहता है कि यह गंभीर नहीं है: "फिर भी, मामला महत्वपूर्ण है, ग्राहक चिंतित है, यह आवश्यक है।" वस्या एक जिम्मेदार व्यक्ति है। यह आवश्यक होना चाहिए: कॉफी और नृत्य (लॉग में कुछ के लिए देखो)।

लॉग में, सब कुछ सरल से दूर हो गया। पहले, वासिया 15 मिनट के लिए सही लॉग तक पहुंच वाले व्यक्ति की तलाश में था। उसने पाया और एक लॉग मिला। लेकिन कैसे? .Doc प्रारूप में मेल करने के लिए, निश्चित रूप से। वास्य जिम्मेदार है, युवा है और वर्ड में लॉग पढ़ता है: कुछ भी समझ में नहीं आता है। लेकिन ऐसे कीवर्ड हैं जिन्हें आप नॉलेज बेस में खोज सकते हैं। लगभग 20 मिनट तक वासना दिलचस्प चीजों पर लटकी रहती है, बहुत सारी दिलचस्प चीजें सीखती है, लेकिन फिलहाल कुछ भी जरूरी नहीं है।

वास्या आगे क्या करती है? आपको किसी की तलाश करने की आवश्यकता है, लेकिन वास्या एक युवा इंजीनियर है और सीनियर को जगाने के लिए यह डरावना है। इसलिए, वह तय करता है कि आपको एक सहयोगी, उसी जूनियर को कॉल करने की आवश्यकता है।



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

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



सोमवार को, वास्या काम करने के लिए आती है और एक असामान्य तस्वीर देखती है। सीईओ इंजीनियरिंग के वीपी पर चिल्ला रहा था क्योंकि ग्राहक सीईओ पर चिल्ला रहा था क्योंकि उसका सीईओ उस पर चिल्ला रहा था। यह पता चला है कि समस्या को हल करना संभव नहीं था।

अधिकारियों के चार सवाल हैं: "शुक्रवार को क्या हुआ?"; "मैंने सोमवार को बॉस से इसके बारे में क्यों सुना?"; "क्यों फिक्स छह घंटे लग गए?" और "किसे दोष देना है?" ऑप्स को कमरे में बुलाया जाता है, जो कहते हैं कि यह उनकी समस्या नहीं है। वास्या और दूसरी नौकरानी को कमरे में बुलाया जाता है, जो यह भी कहती है, "कुछ भी काम नहीं किया।" दोपहर के भोजन तक आलू का यह पूरा खेल जारी है।

रात के खाने के समय के बाद से, निर्णय "ठीक है, यह अपने आप से टूट गया है, किसी का दोष नहीं है।" कहानी का अंत।



आइए एक छोटे से डिबेरिंग की व्यवस्था करें: आइए इस दुःस्वप्न से गुजरें और सभी प्रश्नों के उत्तर देने का प्रयास करें।

जो ड्यूटी पर होना चाहिए

Sysadmins (या अधिक फैशनेबल शब्द - SRE) ड्यूटी पर हो सकता है। वे कई सालों से ऐसा कर रहे थे, उन्हें सब कुछ ठीक-ठाक मिला। DBA ड्यूटी पर हो सकते हैं, जो लोग संदेश भेजने में लगे हुए हैं। यदि आप भाग्यशाली हैं, तो एनओसी (नेटवर्क ऑपरेशन सेंटर) ड्यूटी पर है - यह तब है जब इन सभी लोगों को एक ही कमरे में रखा गया है। उनके पास रनबुक हैं जो कहते हैं कि मुश्किल स्थिति में क्या करना है।



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

दो कारण हैं कि लोग ड्यूटी पर क्यों नहीं रहना चाहते हैं। एक जब ऐसा है:



सब कुछ खराब होने पर कोई भी ड्यूटी पर नहीं जाना चाहता। इस समस्या का हल काफी सरल है:



आपको अच्छा कोड लिखना होगा, सब कुछ सरल है। लेकिन यह भी सीखने की जरूरत है। एक नया प्रश्न उठता है: "कैसे सीखें?"। आपको अपनी उंगलियों को सॉकेट में डालने की आवश्यकता है - #painisinstructional। दर्द मदद करता है।



ड्यूटी से ही कोड की गुणवत्ता में सुधार होता है। वही वास्या सोमवार को, सबसे अधिक संभावना है, अपनी गलतियों को ठीक करेगा ताकि त्रुटियों की तलाश में एक और रात न बैठें।

ड्यूटी पर बाधाएं

जब ड्यूटी पर होते हैं, तो कुछ बाधाएं होती हैं जो नहीं होनी चाहिए। आइए जाने वासिया के शुक्रवार के उपद्रव से याद रखें कि कैसे वह एक शब्द दस्तावेज़ में लॉग पढ़ता है?



हम सभी Microsoft उत्पादों से प्यार करते हैं, लेकिन आप आधुनिक दुनिया में ऐसा नहीं कर सकते। लॉग के बारे में स्पष्ट चीजें हैं जो हर किसी को समझना चाहिए। मुख्य बिंदु उन उपकरणों की संख्या है जो इन समस्याओं को हल करते हैं: लॉगस्टैश, लॉगजीली, सूमो लॉजिक, किबाना। उनका उपयोग करने की आवश्यकता है।

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

इन उपकरणों का एक और फायदा यह है कि उन पर "गरीबों के लिए निगरानी" का निर्माण किया जा सकता है। उदाहरण के लिए, लॉग में, त्रुटियों की एक निश्चित संख्या (कतार पूर्ण आदि) को देखने के बाद, आप एक एलर्जी को ट्रिगर कर सकते हैं।

जो समस्या के महत्व को निर्धारित करता है

कैसे समझें, ड्यूटी पर ड्यूटी पर जाएं या समस्या को ठीक करने के लिए तत्काल दौड़ें? गंभीरता की नियुक्ति कौन करता है? कौन तय करता है कि समस्या कितनी गंभीर है? हल का समर्थन करता है। और क्यों? क्योंकि समर्थन में समस्या की दृष्टि है। वह जानता है कि सब कुछ कितना बुरा है।

इसके अलावा, आज लगभग सभी कंपनियां "कंटीन्यूअस डिलीवरी" के सिद्धांत पर काम करती हैं, इसलिए सभी ग्राहकों को एक ही समय में सभी सुविधाएँ प्राप्त होती हैं (और एक ही समय में बग)। मान लीजिए कि एक बग है जो क्लाइंट के लिए लग रहा है "कुछ काम नहीं करता है, यह ठीक है।" इसी समय, समर्थन समस्या के बारे में सैकड़ों अलर्ट देखता है, और यह स्पष्ट रूप से गंभीर है।

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

ग्राहकों को महत्व दिखाने का अवसर देने की आवश्यकता है क्योंकि उत्पाद निर्माता हमेशा समस्या के संदर्भ को नहीं समझता है।

एसएलए - एक दिन के भीतर प्रतिक्रिया और समाधान की गारंटी, लेकिन तेज हो सकती है। यह, फिर से, संदर्भ पर निर्भर करता है।

संगठनात्मक चुनौतियां

वासना ने समस्या को अंत तक नहीं समझा। बेशक, वह बस जाग गया, और एक तकनीकी सहायता सहयोगी ने भी खराब तरीके से समझाया। इसका इलाज केवल एक ही तरीके से किया जाता है: एक टिकट। एक टिकट एक संदर्भ संख्या है जो बताती है कि यह सब क्या है। वास्या के लिए यह आवश्यक है, क्योंकि एक फोन के बजाय, समर्थन वासी को बता सकता है "हमारी टिकट प्रबंधन प्रणाली खोलें और टिकट संख्या 42 देखें"। यह कई कारणों से आवश्यक है। सबसे पहले, वासिया, एक नींद की स्थिति में एक सहकर्मी को सुनने के बजाय, जाग जाएगा, एक टिकट पढ़ें और समझें कि यह कितना महत्वपूर्ण है। दूसरे, एक से अधिक समस्याएँ हो सकती हैं।

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

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

खैर, एक आभासी फोन पुल, जिसकी तुलना आग के मामले में एक सभा स्थल से की जा सकती है: हर कोई जानता है कि समस्याओं के मामले में कहां जाना है। वैसे, ज़ूम या ब्लूजियंस जैसी आधुनिक प्रणालियों में, सभी आवश्यक कार्यक्षमता पहले से ही अंतर्निहित हैं।

वृद्धि पथ

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



ऐसे संचार हैं जो सीईओ से आने चाहिए। उसे महत्वपूर्ण मुद्दों के बारे में पता होना चाहिए।

त्रुटि प्रबंधक

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

उत्पादन तक पहुंच

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

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

कर्तव्य का परिवर्तन

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

अन्य समस्याएं

कई अन्य समस्याएं हैं जिन पर ध्यान देने की आवश्यकता है। उनमें से एक उत्पादन तक पहुंच का प्रमाणन है। प्रारंभिक प्रमाणीकरण करने की सलाह दी जाती है ताकि एक व्यक्ति यह दिखाए कि वह समझता है कि क्या संभव है और क्या नहीं है।

इसका अनुवाद कैसे करें?

लेकिन यह सब कंपनी के लिए कैसे लाया जा सकता है? आपको यह समझने की आवश्यकता है कि इसमें कुछ समय लगेगा।



हमें ड्यूटी पर वरिष्ठ लोगों के साथ शुरुआत करने की आवश्यकता है। उन्हें अनुभव है और पता है कि क्या और कैसे मरम्मत करनी है। स्वामी को कम समस्याएं हैं: लॉग आदि की पहुंच है।

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

निष्कर्ष

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

पुनश्च

हम ड्राइव नामक एक पुस्तक की सिफारिश करना चाहते हैं। यह उन लोगों की प्रेरणा के बारे में एक किताब है जो हमारे जैसे व्यवसायों में काम करते हैं। इस प्रेरणा में तीन मुख्य घटक होते हैं और (स्पॉइलर) उनमें से कोई भी पैसा नहीं है।

पहले से ही इस रविवार को, बारूक और लियोनिद सेंट पीटर्सबर्ग में देवोप्स 2018 में "#DataDrivenDevOps" रिपोर्ट देंगे। आओ, बहुत सारी दिलचस्प चीजें होंगी: यहां रिपोर्टें हैं , यहां जॉन विलिस है , और यहां BoFs और कराओके के साथ एक पार्टी है। आपका इंतजार है!