SRE प्रलेखन क्यों महत्वपूर्ण है भाग 1

सभी को शुभ संध्या!

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

आज हम लेख के पहले भाग को देखेंगे कि कैसे प्रलेखन SRE टीमों को नई और मौजूदा सेवाओं का प्रबंधन करने की अनुमति देता है।

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

SRE के मुख्य उद्देश्य:

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

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

एसआरई सेवा शुरू करने से पहले, वे सिस्टम आर्किटेक्चर के क्षेत्र में परामर्श करके, सॉफ्टवेयर प्लेटफॉर्म, फ्रेमवर्क और क्षमता योजनाओं को विकसित करने और लॉन्च की समीक्षा करने का समर्थन करते हैं।

जब कोई सेवा पहले से ही चल रही है, तो SREs इसका समर्थन करता है:

• वे सिस्टम की उपलब्धता, विलंबता और समग्र स्थिति की माप और निगरानी करते हैं।
• नियोजित सिस्टम परिवर्तनों की जाँच करें।
• वे कुछ तंत्रों का उपयोग करके सिस्टम की स्थिरता को मापते हैं, उदाहरण के लिए, स्वचालन।
• विश्वसनीयता और गति बढ़ाने के उद्देश्य से परिवर्तनों को बढ़ावा देकर प्रणाली में सुधार करें।
• घटना की प्रतिक्रिया और "निर्दोष" पोस्टमार्टम का संचालन करें।

जब किसी सेवा का जीवन समाप्त होने वाला होता है, तो एसआरई स्पष्ट व्याख्या और पूर्ण प्रलेखन के साथ इसका अनुमान लगाता है।

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

SRE का इतिहास

एसआरई प्रलेखन की बारीकियों पर चर्चा करने से पहले, आइए ज़ो के जीवन में एक दिन देखें, जो नवनिर्मित एसआरई है।

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

जैसा कि किस्मत में होता है, पेजर सुबह 2:30 बजे कॉल करता है। संदेश कहता है "नौकरी राग्नारोक वापस झुक गया", ज़ो को पता नहीं है कि इसका क्या मतलब है। वह अपने नोट्स के माध्यम से छलांग लगाती है और मुख्य डैशबोर्ड पृष्ठ पर एक लिंक ढूंढती है। सब कुछ ठीक लग रहा है। वह एक्मे इंट्रानेट पर राग्नारोक का उल्लेख करते हुए कुछ दस्तावेज खोजने की कोशिश करती है, और कुछ कीमती मिनटों के बाद वह सेवा वास्तुकला पर एक पुराना दस्तावेज ढूंढती है, जो एकमेले के लिए एक महत्वपूर्ण निर्भरता है।

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

रहस्यमय रागटूल लिपि के बारे में जानकारी के लिए कुछ समय बिताने के बाद, वह अपने कमांड लाइन मापदंडों के एक संक्षिप्त विवरण के साथ एक दस्तावेज ढूंढती है, साथ ही जहां यह पाया जा सकता है। वह एक रैगटूल-प्रेस्टार्ट शुरू करती है और आशा में अपनी उंगलियां पार करती है। कुछ भी नहीं बदलता है, ट्रैफ़िक और भी अधिक गिर जाता है। वह सख्त कमांड लाइन के बाकी विकल्पों को देखता है, लेकिन यह निश्चित नहीं है कि वे और भी अधिक नुकसान नहीं पहुंचाएंगे। अंत में, वह ragtool –rebalance e - dc = atlanta का उपयोग करने का निर्णय लेती है, क्योंकि यह ग्राफ़ से स्पष्ट है कि समस्या अटलांटा के डेटा केंद्र में विशेष रूप से ध्यान देने योग्य है। ट्रैफ़िक ग्राफ़ धीरे-धीरे रेंगना शुरू कर देता है, और ज़ो जीत में आनन्दित हो जाता है। MTTR (मरम्मत का समय) 45 मिनट है।

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

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

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

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

सौभाग्य से, इस कहानी के सभी पात्र और घटनाएँ बनी हैं। फिर भी, इस बारे में सोचें कि क्या यह उस चीज के समान है जो आपने वास्तविकता में सामना किया है। इस काल्पनिक टीम की समस्याओं का समाधान बहुत स्पष्ट है, और अगले भाग में हम इस पर और विस्तार से चर्चा करेंगे।

प्रलेखन का महत्व

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

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

इस लेख का शेष विभिन्न प्रकार के दस्तावेजों का वर्णन करता है जो SRE एक समर्थित सेवा के जीवन चक्र के दौरान बनाता है।

अंत

अगले भाग में, हम इन सभी प्रकारों पर विस्तार से विचार करेंगे, लेकिन अभी हम आपकी टिप्पणियों और प्रश्नों की प्रतीक्षा कर रहे हैं, और हम आपको एक खुले पाठ के लिए भी आमंत्रित करते हैं।