कोड के रूप में इन्फ्रास्ट्रक्चर: XP का उपयोग करके समस्याओं को कैसे दूर करें

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

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

हम कौन हैं, कहां हैं और हमारी क्या समस्याएं हैं

वर्तमान में हम श्री ऑनबोर्डिंग टीम में हैं, जिसमें छह प्रोग्रामर और तीन इंफ्रास्ट्रक्चर इंजीनियर शामिल हैं। हम सभी इंफ्रास्ट्रक्चर को कोड (IaC) के रूप में लिखने का प्रयास कर रहे हैं। हम ऐसा इसलिए करते हैं क्योंकि हम मूल रूप से कोड लिखना जानते हैं और हमारे पास "औसत से ऊपर" डेवलपर होने का इतिहास है।

• हमारे पास कई फायदे हैं: एक निश्चित पृष्ठभूमि, प्रथाओं का ज्ञान, कोड लिखने की क्षमता, नई चीजें सीखने की इच्छा।
• और एक हिस्सा ढीला है, जो एक नुकसान भी है: बुनियादी ढांचे के हार्डवेयर के बारे में ज्ञान की कमी।

प्रौद्योगिकी स्टैक जिसका उपयोग हम अपने IaC में करते हैं।

• संसाधन बनाने के लिए टेराफॉर्म।
• छवियों को असेंबल करने के लिए पैकर। ये विंडोज़, CentOS 7 छवियाँ हैं।
• Jsonnet कोdrone.io में एक शक्तिशाली निर्माण करने के साथ-साथ पैकर json और हमारे टेराफॉर्म मॉड्यूल उत्पन्न करने के लिए।
• Azure।
• छवियाँ तैयार करते समय उत्तर देने योग्य।
• सहायक सेवाओं और प्रावधान स्क्रिप्ट के लिए पायथन।
• और यह सब VSCode में टीम के सदस्यों के बीच साझा किए गए प्लगइन्स के साथ।

मेरे से निष्कर्ष अंतिम लेख इस प्रकार था: मैंने (सबसे पहले अपने आप में) आशावाद जगाने की कोशिश की, मैं कहना चाहता था कि हम इस क्षेत्र में मौजूद कठिनाइयों और जटिलताओं से निपटने के लिए हमारे द्वारा ज्ञात दृष्टिकोण और प्रथाओं को आजमाएंगे।

वर्तमान में हम निम्नलिखित IaC समस्याओं से जूझ रहे हैं:

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

एक्सट्रीम प्रोग्रामिंग (एक्सपी) बचाव के लिए

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

आपके उद्योग में XP दृष्टिकोण की प्रयोज्यता की जाँच करनायहां उस वातावरण का विवरण दिया गया है जिसके लिए XP उपयुक्त है, और यह हमसे कैसे संबंधित है:

1. गतिशील रूप से बदलती सॉफ़्टवेयर आवश्यकताएँ। यह हमारे लिए स्पष्ट था कि अंतिम लक्ष्य क्या था। लेकिन विवरण अलग-अलग हो सकते हैं. हम स्वयं तय करते हैं कि हमें कहाँ टैक्सी चलानी है, इसलिए आवश्यकताएँ समय-समय पर बदलती रहती हैं (मुख्यतः स्वयं द्वारा)। यदि हम SRE टीम को लेते हैं, जो स्वयं स्वचालन करती है, और स्वयं ही कार्य की आवश्यकताओं और दायरे को सीमित करती है, तो यह बात अच्छी तरह से फिट बैठती है।

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

3,4. छोटी, सह-स्थित विस्तारित विकास टीम। आप जिस स्वचालित तकनीक का उपयोग कर रहे हैं वह इकाई और कार्यात्मक परीक्षणों की अनुमति देती है। ये दोनों बातें हमारे लिए बिल्कुल उपयुक्त नहीं हैं। सबसे पहले, हम एक समन्वित टीम नहीं हैं, और दूसरी बात, हममें से नौ लोग हैं, जिन्हें एक बड़ी टीम माना जा सकता है। हालाँकि, एक "बड़ी" टीम की कुछ परिभाषाओं के अनुसार, 14+ लोग होते हैं।

आइए कुछ एक्सपी प्रथाओं पर नजर डालें और वे फीडबैक की गति और गुणवत्ता को कैसे प्रभावित करते हैं।

एक्सपी फीडबैक लूप सिद्धांत

मेरी समझ में, फीडबैक इस सवाल का जवाब है कि क्या मैं सही काम कर रहा हूं, क्या हम वहां जा रहे हैं? एक्सपी के पास इसके लिए एक दिव्य योजना है: एक टाइम फीडबैक लूप। दिलचस्प बात यह है कि हम जितने नीचे होंगे, उतनी ही तेजी से हम आवश्यक प्रश्नों के उत्तर देने के लिए ओएस प्राप्त करने में सक्षम होंगे।

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

IaC के हमारे मामले में, फीडबैक से हमें मदद मिलती है। मैं तुरंत ऊपर दिए गए चित्र में एक छोटा सा समायोजन करूंगा: रिलीज़ योजना में कोई मासिक चक्र नहीं होता है, लेकिन यह दिन में कई बार होता है। इस OS चक्र से जुड़ी कुछ प्रथाएँ हैं जिन पर हम अधिक विस्तार से विचार करेंगे।

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

अपने आप को निराशा की खाई से कैसे बाहर निकालें: तीन अभ्यास

परीक्षण

XP फीडबैक लूप में परीक्षणों का दो बार उल्लेख किया गया है। ये ऐसे ही नहीं है. वे संपूर्ण एक्सट्रीम प्रोग्रामिंग तकनीक के लिए अत्यंत महत्वपूर्ण हैं।

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

एक क्लासिक परीक्षण पिरामिड है, जो दर्शाता है कि अधिक परीक्षण होने चाहिए।

IaC प्रोजेक्ट में यह रूपरेखा हम पर कैसे लागू होती है? दरअसल... बिल्कुल नहीं.

• यूनिट परीक्षण, इस तथ्य के बावजूद कि उनमें से बहुत सारे होने चाहिए, बहुत अधिक नहीं हो सकते। या फिर वे बिल्कुल परोक्ष रूप से किसी चीज़ का परीक्षण कर रहे हैं. वास्तव में, हम कह सकते हैं कि हम उन्हें लिखते ही नहीं हैं। लेकिन यहां ऐसे परीक्षणों के लिए कुछ एप्लिकेशन दिए गए हैं जिन्हें हम करने में सक्षम थे:
  1. jsonnet कोड का परीक्षण। उदाहरण के लिए, यह हमारी ड्रोन असेंबली पाइपलाइन है, जो काफी जटिल है। jsonnet कोड परीक्षणों द्वारा अच्छी तरह से कवर किया गया है।
     हम इसका उपयोग करते हैं Jsonnet के लिए यूनिट परीक्षण ढांचा.
  2. स्क्रिप्ट के लिए परीक्षण जो संसाधन प्रारंभ होने पर निष्पादित होते हैं। स्क्रिप्ट पायथन में लिखी जाती हैं, और इसलिए उन पर परीक्षण लिखे जा सकते हैं।
• परीक्षणों में कॉन्फ़िगरेशन की जांच करना संभावित रूप से संभव है, लेकिन हम ऐसा नहीं करते हैं। संसाधन कॉन्फ़िगरेशन नियमों की जाँच को कॉन्फ़िगर करना भी संभव है tflint. हालाँकि, वहाँ के चेक टेराफॉर्म के लिए बहुत बुनियादी हैं, लेकिन AWS के लिए कई परीक्षण स्क्रिप्ट लिखी गई हैं। और हम Azure पर हैं, इसलिए यह फिर से लागू नहीं होता है।
• घटक एकीकरण परीक्षण: यह इस पर निर्भर करता है कि आप उन्हें कैसे वर्गीकृत करते हैं और उन्हें कहाँ रखते हैं। लेकिन वे मूलतः काम करते हैं.

  एकीकरण परीक्षण इस तरह दिखते हैं।

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

  छवि सत्यापन एल्गोरिथ्म

  1. पैकर को पहले छवि को पूरी तरह से तैयार करना होगा।
  2. परीक्षण के बगल में स्थानीय स्थिति वाला एक टेराफॉर्म है, जिसका उपयोग हम इस छवि को तैनात करने के लिए करते हैं।
  3. खोलते समय, छवि के साथ काम करना आसान बनाने के लिए पास में पड़े एक छोटे मॉड्यूल का उपयोग किया जाता है।
  4. एक बार जब वीएम को छवि से तैनात किया जाता है, तो जांच शुरू हो सकती है। मूल रूप से, जाँच कार द्वारा की जाती है। यह जांचता है कि स्क्रिप्ट स्टार्टअप पर कैसे काम करती है और डेमॉन कैसे काम करते हैं। ऐसा करने के लिए, ssh या winrm के माध्यम से हम नई उठाई गई मशीन में लॉग इन करते हैं और कॉन्फ़िगरेशन स्थिति की जांच करते हैं या सेवाएं चालू हैं या नहीं।

• टेराफॉर्म के लिए मॉड्यूल में एकीकरण परीक्षणों के साथ स्थिति समान है। यहां ऐसे परीक्षणों की विशेषताओं को समझाने वाली एक छोटी तालिका दी गई है।

  
  
  पाइपलाइन पर फीडबैक लगभग 40 मिनट का है। हर चीज़ बहुत लंबे समय के लिए होती है. इसका उपयोग प्रतिगमन के लिए किया जा सकता है, लेकिन नए विकास के लिए यह आम तौर पर अवास्तविक है। यदि आप इसके लिए बहुत-बहुत तैयार हैं, रनिंग स्क्रिप्ट तैयार करते हैं, तो आप इसे 10 मिनट तक कम कर सकते हैं। लेकिन ये अभी भी यूनिट परीक्षण नहीं हैं, जो 5 सेकंड में 100 टुकड़े करते हैं।

छवियों या टेराफ़ॉर्म मॉड्यूल को असेंबल करते समय यूनिट परीक्षणों की अनुपस्थिति काम को अलग-अलग सेवाओं में स्थानांतरित करने को प्रोत्साहित करती है जिन्हें केवल REST या पायथन स्क्रिप्ट के माध्यम से चलाया जा सकता है।

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

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

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

परीक्षणों के परिणाम: यूनिट परीक्षण, जो एक मिनट में ओएस देना चाहिए, वह नहीं देता है। और पिरामिड में उच्चतर परीक्षण के प्रकार प्रभावी हैं, लेकिन समस्याओं का केवल एक हिस्सा ही कवर करते हैं।

जोड़ा प्रोग्राम तैयार करना

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

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

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

नीचे जोड़ी प्रोग्रामिंग शैलियाँ और IaC पर काम करने में उनकी प्रयोज्यता दी गई है:

1. क्लासिक, अनुभवी+अनुभवी, टाइमर द्वारा बदलाव। दो भूमिकाएँ - चालक और नाविक। दो लोग। वे एक ही कोड पर काम करते हैं और एक निश्चित पूर्व निर्धारित अवधि के बाद भूमिकाएँ बदल लेते हैं।

आइए शैली के साथ हमारी समस्याओं की अनुकूलता पर विचार करें:

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

IaC में इस शैली का उपयोग करने में मुख्य समस्या काम की असमान गति है। पारंपरिक सॉफ़्टवेयर विकास में, आपकी गति बहुत समान होती है। आप पाँच मिनट बिता सकते हैं और N लिख सकते हैं। 10 मिनट बिता सकते हैं और 2N लिख सकते हैं, 15 मिनट - 3N लिख सकते हैं। यहां आप पांच मिनट बिता सकते हैं और एन लिख सकते हैं, और फिर 30 मिनट और बिता सकते हैं और एन का दसवां हिस्सा लिख ​​सकते हैं। यहां आप कुछ भी नहीं जानते हैं, आप फंस गए हैं, बेवकूफ हैं। जांच में समय लगता है और प्रोग्रामिंग से ध्यान भटक जाता है।

निष्कर्ष: अपने शुद्ध रूप में यह हमारे लिए उपयुक्त नहीं है।

2. पिंग-पोंग. इस दृष्टिकोण में एक व्यक्ति परीक्षण लिखता है और दूसरा इसके लिए कार्यान्वयन करता है। इस तथ्य को ध्यान में रखते हुए कि यूनिट परीक्षणों के साथ सब कुछ जटिल है, और आपको एक एकीकरण परीक्षण लिखना होता है जिसे प्रोग्राम करने में लंबा समय लगता है, पिंग-पोंग की सारी आसानी खत्म हो जाती है।

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

निष्कर्ष: अफसोस, काम की गति IaC में जोड़ी प्रोग्रामिंग अभ्यास के रूप में पिंग-पोंग के उपयोग की अनुमति नहीं देती है।

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

सीखने के लिए अच्छा है, लेकिन मजबूत सॉफ्ट कौशल की आवश्यकता है। यहीं हम लड़खड़ा गए. तकनीक कठिन थी. और यह बुनियादी ढांचे के बारे में भी नहीं है।

निष्कर्ष: इसका संभावित रूप से उपयोग किया जा सकता है, हम प्रयास करना नहीं छोड़ रहे हैं।

4. लामबंदी, झुंड बनाना और सभी ज्ञात लेकिन सूचीबद्ध शैलियाँ नहीं हम इस पर विचार नहीं करते, क्योंकि हमने इसकी कोशिश नहीं की है और हमारे काम के संदर्भ में इसके बारे में बात करना असंभव है।

जोड़ी प्रोग्रामिंग का उपयोग करने पर सामान्य परिणाम:

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

5. इसके बावजूद सफलताएं मिलीं. हम अपनी स्वयं की पद्धति "अभिसरण - विचलन" लेकर आए। मैं संक्षेप में बताऊंगा कि यह कैसे काम करता है।

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

योजना एवं संचार

प्रथाओं का अंतिम खंड जिसके माध्यम से ओएस समस्याओं का समाधान किया जाता है, स्वयं कार्यों के साथ काम का संगठन है। इसमें जोड़ी के काम से बाहर के अनुभव का आदान-प्रदान भी शामिल है। आइए तीन प्रथाओं पर नजर डालें:

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

यह योजना फीडबैक भी प्रदान करती है, जो दिन में एक बार तब होता है जब हम रैलियों में तालमेल बिठाते हैं। सबके सामने एक सामान्य योजना, लेकिन संरचित और पूरी तरह से खुली होने से, हर किसी को पता चलता है कि क्या हो रहा है और हम कितनी प्रगति कर चुके हैं।

कार्यों की दृश्य दृष्टि के लाभ:

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

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

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

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

इसका समाधान एक-दूसरे को किए गए काम को दिखाने और फिर उस पर चर्चा करने से निकला। हम सप्ताह में एक बार एक घंटे के लिए मिलते हैं और पिछले सप्ताह में किए गए कार्यों के समाधान का विवरण दिखाते हैं।

प्रदर्शन के दौरान, कार्य का विवरण प्रकट करना और उसके संचालन का प्रदर्शन करना सुनिश्चित करना आवश्यक है।

रिपोर्ट एक चेकलिस्ट का उपयोग करके आयोजित की जा सकती है।1. संदर्भ में प्रवेश करें. यह कार्य कहां से आया, इसकी आवश्यकता क्यों थी?

2. पहले समस्या का समाधान कैसे हुआ? उदाहरण के लिए, बड़े पैमाने पर माउस क्लिक करना आवश्यक था, या कुछ भी करना असंभव था।

3. हम इसे कैसे सुधारें. उदाहरण के लिए: "देखो, अब स्क्रिप्टोसिक है, यहाँ रीडमी है।"

4. दिखाएँ कि यह कैसे काम करता है। कुछ उपयोगकर्ता परिदृश्य को सीधे लागू करने की सलाह दी जाती है। मुझे X चाहिए, मुझे Y चाहिए, मुझे Y (या Z) दिखाई देता है। उदाहरण के लिए, मैं एनजीआईएनएक्स तैनात करता हूं, यूआरएल को स्मोक करता हूं और 200 ओके प्राप्त करता हूं। यदि कार्रवाई लंबी है, तो इसे पहले से तैयार करें ताकि आप इसे बाद में दिखा सकें। यह सलाह दी जाती है कि यदि यह नाजुक है तो डेमो से एक घंटे पहले इसे ज्यादा न तोड़ें।

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

प्रत्येक वक्ता के लिए इसे 5-10 मिनट तक रखना उचित है। यदि आपका भाषण स्पष्ट रूप से महत्वपूर्ण है और इसमें अधिक समय लगेगा, तो इसे पहले से ही एस-टेकओवर चैनल में समन्वयित करें।

आमने-सामने के भाग के बाद सूत्र में हमेशा चर्चा होती रहती है। यह वह जगह है जहां हमें अपने कार्यों पर आवश्यक फीडबैक दिखाई देता है।

परिणामस्वरूप, जो हो रहा है उसकी उपयोगिता निर्धारित करने के लिए एक सर्वेक्षण आयोजित किया जाता है। यह भाषण के सार और कार्य के महत्व पर प्रतिक्रिया है।

लंबे निष्कर्ष और आगे क्या है

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

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

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

ओएस को प्रभावित करने के उच्च-स्तरीय तरीके - योजना बनाना और कार्यों के साथ काम करना सटीक रूप से प्रभाव उत्पन्न करता है: उच्च गुणवत्ता वाले ज्ञान का आदान-प्रदान और बेहतर विकास गुणवत्ता।

एक पंक्ति में संक्षिप्त निष्कर्ष

• एचआर व्यवसायी IaC में काम करते हैं, लेकिन कम दक्षता के साथ।
• जो काम करता है उसे मजबूत करो.
• अपने स्वयं के प्रतिपूरक तंत्र और प्रथाओं के साथ आएं।

स्रोत: www.habr.com