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

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

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

हम जारी रखते हैं।

ऑनबोर्डिंग नई सेवा के लिए दस्तावेज

यह सुनिश्चित करने के लिए कि सेवा परिचालन तत्परता मानकों को पूरा करती है, और यह सुनिश्चित करने के लिए कि सेवा मालिक समझें कि बड़े सिस्टम को प्रबंधित करने के लिए SRE ज्ञान का उपयोग कैसे करें।

उत्पादन में लॉन्च होने से पहले सेवा को इस परीक्षण से गुजरना पड़ता है। (लॉन्च से पहले, यह SRE द्वारा समर्थित नहीं है, लेकिन स्वयं विकास टीम द्वारा।) इस स्तर पर PRR का लक्ष्य यह सुनिश्चित करना है कि सेवा लॉन्च के समय विश्वसनीयता के न्यूनतम मानकों को पूरा करेगी।



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

सेवा को सौंपने से पहले पीआरआर का संचालन करके, एसआरई अधिक सवाल पूछ सकते हैं और लॉन्च से पहले पीआरआर का संचालन करते समय विश्वसनीयता और उपयोग में आसानी के लिए उच्च मानक निर्धारित कर सकते हैं। लॉन्च से पहले PRR "लाइट" हो सकता है ताकि विकास टीम को धीमा न करें।

ज़ो की कहानी में, टीम के पास एक मानकीकृत प्रक्रिया या PRR चेकलिस्ट नहीं है, जिसका अर्थ है कि सेवा को स्थानांतरित करते समय वे बहुत महत्वपूर्ण मुद्दों को याद कर सकते हैं। इस प्रकार, बड़ी संख्या में समस्याओं के साथ टकराव का खतरा होता है जिसे सेवा के प्रबंधन की जिम्मेदारी लेने से पहले आसानी से अनुमानित और हल किया जा सकता है।

PRR / सेवा हस्तांतरण के लिए PRR टेम्प्लेट और प्रोसेस डॉक्यूमेंटेशन (प्रोसेस डॉक) के निर्माण की आवश्यकता होती है, जो बताता है कि SRE की टीमें नई सेवा के साथ कैसे काम करेंगी और PRR टेम्प्लेट का उपयोग करेंगी। स्थानांतरण प्रक्रिया में उपयोग किए जाने वाले पैटर्न स्टार्टअप के दौरान उपयोग किए जाने वाले की तुलना में अधिक व्यापक हो सकते हैं।

PRR टेम्प्लेट कई क्षेत्रों को कवर करता है और महत्वपूर्ण प्रश्नों के उत्तर की जांच करना आवश्यक है। तालिका 1 में कुछ क्षेत्रों और संबंधित मुद्दों को दिखाया गया है जो टेम्पलेट कवर करते हैं।

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

तालिका 1. एक पीआरआर टेम्पलेट के उदाहरण क्षेत्र

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

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

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

• सेवा हस्तांतरण मानदंड और पीआरआर प्रक्रिया।
• सेवा-स्तरीय उद्देश्यों (संक्षेप में SLO) और त्रुटि गणना की रिपोर्ट पर चर्चा करने की प्रक्रिया।
• नए लॉन्च मानदंड और फ्रीज़ पॉलिसी शुरू करें (यदि संभव हो तो)।
• SRE टीम से सेवा की स्थिति की सामग्री और आवृत्ति।
• स्टाफ आवश्यकताएँ
• नई कार्यक्षमता के रोडमैप की योजना बनाने की प्रक्रिया और नए उत्पाद की कार्यक्षमता पर विश्वसनीयता (एसआरई द्वारा आवश्यक) को बढ़ाने वाली कार्यात्मक की प्राथमिकता।

सेवा संचालन दस्तावेज

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

सेवा साक्षात्कार

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

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

प्लेबुक

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

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

Playbooks सूचनाओं के लिए विशेष रूप से नहीं बनाई गई हैं। रिलीज, निगरानी और समस्या निवारण के लिए उनमें उत्पादन प्रक्रियाएं भी हो सकती हैं। उत्पादन प्रक्रियाओं के अन्य उदाहरणों में एक सेवा को चालू / बंद करना, एक सेवा का रखरखाव और एक दुर्घटना / वृद्धि शामिल है।

पोस्टमार्टम किया

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

SRE टीमों को उन वर्गों के साथ एक मानकीकृत पोस्टमार्टम टेम्पलेट बनाने की आवश्यकता है जो विफलता के बारे में महत्वपूर्ण जानकारी को कैप्चर करते हैं। आदर्श रूप से, टेम्पलेट को संरचित किया जाना चाहिए ताकि इसे डेटा विश्लेषण उपकरण द्वारा आसानी से पार्स किया जा सके। यह डेटा स्रोत के रूप में पोस्टमार्टम का उपयोग करके क्रैश डायनामिक्स रिपोर्ट भेजता है। इस टेम्पलेट का उपयोग करके बनाए गए प्रत्येक पोस्टमार्टम में निम्न जानकारी (न्यूनतम) सहित उत्पादन विफलता का वर्णन किया गया है:

• घटनाओं का कालक्रम (समयरेखा)।
• उपयोगकर्ता पर प्रभाव का विवरण।
• मूल कारण
• एक्शन पॉइंट्स / लेसन सीखे गए।

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

दिशा निर्देशों

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

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

सेवा स्तर का समझौता

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

प्रलेखन और SLAs का प्रकाशन, साथ ही उपयोगकर्ता अनुभव और SLAs के साथ इसकी तुलना का गहन विश्लेषण, SRE टीमों को UX गुणवत्ता को खोए बिना तेजी से नवाचार करने की अनुमति देता है। SRE जो एक स्पष्ट SLA नोटिस के साथ सेवाओं का समर्थन करती हैं वे तेजी से विफल हो जाती हैं और इसलिए उन्हें तेजी से ठीक करती हैं। SLA SRE और SWE टीमों (सॉफ़्टवेयर डेवलपर्स) के बीच घर्षण की मात्रा को भी कम करता है, जिससे टीमों को लक्ष्य और परिणामों पर उद्देश्यपूर्ण चर्चा करने की अनुमति मिलती है, जोखिम के बारे में व्यक्तिपरक निर्णय लेने से बचते हैं।

यह ध्यान देने योग्य है कि बाहरी, कानूनी रूप से वैध समझौते का अस्तित्व अधिकांश एसआरई टीमों पर लागू नहीं हो सकता है। ऐसे मामलों में, एसआरई टीमें सेवा-स्तर के उद्देश्यों (संक्षेप में एसएलओ) तक सीमित हो सकती हैं। एसएलओ - एक विशिष्ट मीट्रिक के लिए सेवा का वांछित स्तर निर्धारित करें, उदाहरण के लिए, उपलब्धता या देरी।

उत्पाद प्रलेखन

SRE टीम अपने समय का 50 प्रतिशत किसी प्रोजेक्ट पर काम करने, मैनुअल वर्क को स्वचालित करने के लिए सॉफ्टवेयर विकसित करने या सेवा की विश्वसनीयता में सुधार के लिए खर्च करने का प्रयास करती है। यह खंड एसआरई विकसित करने वाले उत्पाद और उपकरणों से संबंधित दस्तावेजों का वर्णन करता है।

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

उत्पाद पृष्ठ के बारे में

विवरण पृष्ठ एसआरई और उत्पाद विकास इंजीनियरों को यह समझने में मदद करता है कि उत्पाद या उपकरण क्या है, यह क्या करता है, और इसका उपयोग कैसे करें।

संकल्पना मैनुअल

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

शुरू हो रही गाइड

आरंभ किए गए गाइड का लक्ष्य इंजीनियरों को न्यूनतम विलंब के साथ जल्दी से तारीख तक लाना है। यह उन नए उपयोगकर्ताओं के लिए उपयोगी है जो उत्पाद आज़माना चाहते हैं।

Codelab

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

प्रैक्टिकल गाइड

ऐसे उपयोगकर्ताओं के लिए ऐसा मार्गदर्शन आवश्यक है जो एक विशिष्ट समस्या को हल करना चाहते हैं। ये गाइड आमतौर पर एक चरण-दर-चरण मार्गदर्शिका होती है जिसका आपको पालन करना चाहिए।
पूछे जाने वाले प्रश्न

अक्सर पूछे जाने वाले प्रश्न पृष्ठ पर, उपयोगकर्ता सबसे लोकप्रिय सवालों के जवाब पा सकता है, कठिनाइयों और सीमाओं के बारे में पता कर सकता है, और अधिक विस्तृत जानकारी के लिए दस्तावेजों और अन्य पृष्ठों के लिंक पा सकता है।

समर्थन

समर्थन पृष्ठ पर, इंजीनियर सीख सकते हैं कि वे किस समस्या का सामना कर रहे हैं। आप एक वृद्धि योजना, समस्या निवारण जानकारी, समूह लिंक, डैशबोर्ड और एसएलओ के साथ-साथ बदलाव की जानकारी भी पा सकते हैं।

एपीआई विवरण

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

डेवलपर गाइड

इस गाइड से, डेवलपर्स सीख सकते हैं कि उत्पाद एपीआई के साथ कैसे प्रोग्राम किया जाए। ऐसे गाइड आमतौर पर आवश्यक होते हैं यदि SREs डेवलपर्स को APIs प्रदान करने वाले उत्पाद बनाते हैं, जो आपको मिश्रित उपकरण बनाने की अनुमति देता है जो एक दूसरे के API को अधिक जटिल कार्य करने के लिए आह्वान करते हैं।

सेवा की स्थिति की रिपोर्ट करने के लिए दस्तावेज

यह खंड उन दस्तावेजों का वर्णन करता है जो SRE टीम समर्थित सेवाओं की स्थिति का वर्णन करने के लिए बनाती है।

त्रैमासिक सेवा की समीक्षा

सेवा की स्थिति के बारे में जानकारी दो स्वरूपों में प्रस्तुत की जाती है: SRE नेता द्वारा एक त्रैमासिक रिपोर्ट, जो पूरे SRE संगठन में वितरित की जाती है, और उत्पाद विकास और टीम में नेतृत्व के लिए प्रस्तुतिकरण से सहमत होती है।

SRE नेता तिमाही रिपोर्ट में रुचि रखते हैं, क्योंकि वे निम्नलिखित बातों पर जानकारी प्रदान करते हैं:

• समर्थन समस्याओं (बदलाव, टिकट, पोस्टमार्टम)। SRE नेताओं को पता है कि यदि समर्थन समस्याएं SRE टीम के संसाधनों का 50 प्रतिशत से अधिक लेना शुरू करती हैं, तो प्राथमिकताओं का जवाब देना और बदलना आवश्यक है। लक्ष्य पहले चरण में समस्या की पहचान करना है।
• SLA का निष्पादन। एसआरई नेता जानना चाहते हैं कि क्या सब कुछ एसएलए के साथ ठीक है, क्या पारिस्थितिकी तंत्र में अस्वास्थ्यकर घटक हैं जो खतरा पैदा करते हैं।
• जोखिम। एसएलए नेताओं को एसआरई के लिए उन जोखिमों के बारे में जानना चाहिए जो उत्पाद और व्यावसायिक लक्ष्यों में हस्तक्षेप कर सकते हैं।

त्रैमासिक रिपोर्ट एसआरई टीम को मौका देती है:

• उत्पाद विकास टीम, साथ ही SRE टीम के बहुत काम के लिए SRE के लाभों पर जोर दें।
• SRE (resilience) कमांड के साथ हस्तक्षेप करने वाले मुद्दों को हल करने के लिए प्राथमिकता का अनुरोध करें।
• SRE टीम प्राथमिकताओं पर प्रतिक्रिया का अनुरोध करें।
• टीम के व्यापक योगदान पर जोर दें।

सफल तकनीकों का अवलोकन

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

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

दूसरे भाग का अंत।

अगला भाग पढ़ें

हम हमेशा की तरह आपके सवालों और टिप्पणियों का इंतजार कर रहे हैं।