कोडको रूपमा पूर्वाधार: XP प्रयोग गरेर समस्याहरू कसरी हटाउने

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

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

हामी को हौं, हामी कहाँ छौं र हामीलाई के समस्याहरू छन्

हामी हाल Sre अनबोर्डिङ टोलीमा छौं, जसमा छ प्रोग्रामर र तीन पूर्वाधार इन्जिनियरहरू छन्। हामी सबै कोड (IaC) को रूपमा पूर्वाधार लेख्न कोशिस गर्दैछौं। हामी यो गर्छौं किनभने हामी मूलतः कोड कसरी लेख्ने र "औसत भन्दा माथि" विकासकर्ता भएको इतिहास छ भनेर जान्दछौं।

• हामीसँग फाइदाहरूको सेट छ: एक निश्चित पृष्ठभूमि, अभ्यासहरूको ज्ञान, कोड लेख्ने क्षमता, नयाँ चीजहरू सिक्ने इच्छा।
• र त्यहाँ एक ढिलो भाग छ, जुन एक माइनस पनि हो: पूर्वाधार हार्डवेयरको बारेमा ज्ञानको कमी।

हामीले हाम्रो IaC मा प्रयोग गर्ने प्रविधि स्ट्याक।

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

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

हामी हाल निम्न IaC मुद्दाहरूसँग संघर्ष गरिरहेका छौं:

• कोड विकासका लागि उपकरण र साधनहरूको अपूर्णता।
• ढिलो तैनाती। पूर्वाधार वास्तविक संसारको अंश हो, र यो ढिलो हुन सक्छ।
• दृष्टिकोण र अभ्यासको अभाव।
• हामी नयाँ छौं र धेरै थाहा छैन।

चरम प्रोग्रामिङ (XP) उद्धारको लागि

सबै विकासकर्ताहरू एक्स्ट्रिम प्रोग्रामिङ (XP) र यसको पछाडि खडा हुने अभ्यासहरूसँग परिचित छन्। हामी मध्ये धेरैले यो दृष्टिकोण संग काम गरेका छौं, र यो सफल भएको छ। त्यसोभए पूर्वाधार चुनौतीहरू पार गर्न त्यहाँ राखिएका सिद्धान्त र अभ्यासहरू किन प्रयोग नगर्ने? हामीले यो दृष्टिकोण लिने निर्णय गर्यौं र के हुन्छ हेर्नुहोस्।

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

1. गतिशील रूपमा सफ्टवेयर आवश्यकताहरू परिवर्तन गर्दै। अन्तिम लक्ष्य के हो भन्ने कुरा हामीलाई स्पष्ट भयो। तर विवरण फरक हुन सक्छ। हामी आफैं निर्णय गर्छौं कि हामीलाई कहाँ ट्याक्सी चाहिन्छ, त्यसैले आवश्यकताहरू आवधिक रूपमा परिवर्तन हुन्छन् (मुख्य रूपमा आफैंले)। यदि हामीले SRE टोलीलाई लियौं, जसले स्वचालन आफैं गर्छ, र आफैले आवश्यकताहरू र कामको दायरा सीमित गर्दछ, तब यो बिन्दु राम्रोसँग फिट हुन्छ।

2. नयाँ प्रविधि प्रयोग गरेर निश्चित समय परियोजनाहरु को कारण जोखिम। हामीलाई थाहा नभएका केही चीजहरू प्रयोग गर्दा हामीले जोखिमहरू सामना गर्न सक्छौं। र यो 100% हाम्रो मामला हो। हाम्रो सम्पूर्ण परियोजना टेक्नोलोजीहरूको प्रयोग थियो जुन हामी पूर्ण रूपमा परिचित थिएनौं। सामान्यतया, यो एक निरन्तर समस्या हो, किनभने ... पूर्वाधार क्षेत्रमा सधैं धेरै नयाँ प्रविधिहरू देखा पर्छन्।

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

केही XP अभ्यासहरू हेरौं र तिनीहरूले प्रतिक्रियाको गति र गुणस्तरलाई कसरी असर गर्छ।

XP प्रतिक्रिया लूप सिद्धान्त

मेरो बुझाइमा, प्रतिक्रिया भनेको प्रश्नको जवाफ हो, के मैले सही काम गरिरहेको छु, के हामी त्यहाँ जाँदैछौं? XP सँग यसको लागि ईश्वरीय योजना छ: समय प्रतिक्रिया लुप। चाखलाग्दो कुरा यो हो कि हामी जति तल छौं, हामी आवश्यक प्रश्नहरूको जवाफ दिनको लागि ओएस प्राप्त गर्न सक्षम छौं।

यो हाम्रो IT उद्योग मा यो चाँडै एक OS प्राप्त गर्न सम्भव छ कि छलफल को लागी एक बरु चाखलाग्दो विषय हो। ६ महिनासम्म कुनै प्रोजेक्ट गर्दा कति पीडादायी हुन्छ कल्पना गर्नुहोस् र त्यसपछि मात्र थाहा पाउनुहोस् कि सुरुमा गल्ती थियो। यो डिजाइन र जटिल प्रणाली को कुनै पनि निर्माण मा हुन्छ।

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

महत्त्वपूर्ण: प्रतिक्रिया माथि उल्लेखित सबै समस्याहरूको समाधान हुन सक्छ। XP अभ्यासहरूसँग संयुक्त, यसले तपाईंलाई निराशाको खाडलबाट बाहिर निकाल्न सक्छ।

निराशाको खाडलबाट आफूलाई कसरी बाहिर निकाल्ने: तीन अभ्यासहरू

टेस्ट

XP प्रतिक्रिया लुपमा परीक्षणहरू दुई पटक उल्लेख गरिएको छ। त्यति मात्रै होइन । तिनीहरू सम्पूर्ण चरम प्रोग्रामिङ प्रविधिको लागि अत्यन्त महत्त्वपूर्ण छन्।

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

त्यहाँ एक क्लासिक परीक्षण पिरामिड छ, जसले थप परीक्षणहरू हुनुपर्छ भनेर देखाउँछ।

IaC परियोजनामा ​​यो रूपरेखा हामीलाई कसरी लागू हुन्छ? वास्तवमा... पटक्कै होइन।

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

  यो एकीकरण परीक्षणहरू जस्तो देखिन्छ।

  
  
  ड्रोन CI मा छविहरू निर्माण गर्दा यो एउटा उदाहरण हो। तिनीहरूमा पुग्नको लागि, तपाईंले प्याकर छवि बन्नको लागि 30 मिनेट पर्खनुपर्छ, त्यसपछि तिनीहरू पास हुनको लागि अर्को 15 मिनेट पर्खनुहोस्। तर तिनीहरू अवस्थित छन्!

  छवि प्रमाणिकरण एल्गोरिथ्म

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

• टेराफर्मका लागि मोड्युलहरूमा एकीकरण परीक्षणहरूसँग स्थिति समान छ। यहाँ यस्तो परीक्षण को विशेषताहरु को व्याख्या एक छोटो तालिका छ।

  
  
  पाइपलाइनमा प्रतिक्रिया लगभग 40 मिनेट छ। सबै कुरा धेरै लामो समयको लागि हुन्छ। यो प्रतिगमनको लागि प्रयोग गर्न सकिन्छ, तर नयाँ विकासको लागि यो सामान्यतया अवास्तविक हुन्छ। यदि तपाईं यसको लागि धेरै तयार हुनुहुन्छ भने, चलिरहेको स्क्रिप्टहरू तयार गर्नुहोस्, त्यसपछि तपाइँ यसलाई 10 मिनेटमा घटाउन सक्नुहुन्छ। तर यी अझै पनि एकाइ परीक्षणहरू होइनन्, जसले 5 सेकेन्डमा 100 टुक्राहरू गर्छ।

छविहरू वा टेराफर्म मोड्युलहरू जम्मा गर्दा एकाइ परीक्षणहरूको अनुपस्थितिले कामलाई छुट्टै सेवाहरूमा स्थानान्तरण गर्न प्रोत्साहन दिन्छ जुन केवल REST वा पाइथन स्क्रिप्टहरू मार्फत चलाउन सकिन्छ।

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

हामीसँग सेवाको रूपमा ScaleFT भएकोले, हामी API मार्फत यसको साथ काम गर्न बाध्य छौं। त्यहाँ एउटा र्‍यापर लेखिएको थियो जसलाई तपाईंले तानेर भन्न सक्नुहुन्छ: "भित्र जानुहोस् र यो र त्यो मेटाउनुहोस्।" यसले सबै आवश्यक सेटिङहरू र पहुँचहरू भण्डारण गर्दछ।

हामी पहिले नै यसको लागि सामान्य परीक्षणहरू लेख्न सक्छौं, किनकि यो साधारण सफ्टवेयर भन्दा फरक छैन: कुनै प्रकारको एपिहालाई खिल्ली उडाइएको छ, तपाइँ यसलाई तान्नुहोस्, र हेर्नुहोस् के हुन्छ।

परीक्षणको नतिजा: एकाइ परीक्षण, जुन OS लाई एक मिनेटमा दिनुपर्छ, यसले दिँदैन। र पिरामिडमा उच्च परीक्षणका प्रकारहरू प्रभावकारी छन्, तर समस्याहरूको भाग मात्र समावेश गर्दछ।

जोडा प्रोग्रामिङ

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

कोड लेख्दा, तपाईं सकेसम्म चाँडो यसको गुणस्तरमा प्रतिक्रिया प्राप्त गर्न चाहनुहुन्छ। हो, तपाइँ एक सुविधा शाखामा सबै कुरा लेख्न सक्नुहुन्छ (कसैको लागि केहि पनि तोड्न नपरोस्), Github मा पुल अनुरोध गर्नुहोस्, यसलाई कसैलाई असाइन गर्नुहोस् जसको विचारमा वजन छ, र प्रतिक्रियाको लागि पर्खनुहोस्।

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

तल जोडी प्रोग्रामिङ शैलीहरू र IaC मा काम गर्ने तिनीहरूको प्रयोज्यता छन्:

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

शैली संग हाम्रो समस्या को अनुकूलता विचार गरौं:

• समस्या: कोड विकासका लागि उपकरण र उपकरणहरूको अपूर्णता।
  नकारात्मक प्रभाव: यो विकास गर्न धेरै समय लाग्छ, हामी ढिलो हुन्छ, कामको गति/लय हराउँछ।
  हामी कसरी लड्छौं: हामी फरक टुलिङ, साझा IDE प्रयोग गर्छौं र सर्टकटहरू पनि सिक्छौं।
• समस्या: ढिलो डिप्लोइमेन्ट।
  नकारात्मक प्रभाव: यसले कोडको काम गर्ने टुक्रा सिर्जना गर्न लाग्ने समयलाई बढाउँछ। हामी पर्खिरहँदा अल्छी हुन्छौं, कुर्दै गर्दा हाम्रा हातहरू अरू केही गर्न पुग्छन्।
  हामी कसरी लड्छौं: हामीले यसलाई जित्न सकेनौं।
• समस्या: दृष्टिकोण र अभ्यासको अभाव।
  नकारात्मक प्रभाव: यसलाई कसरी राम्रो गर्ने र कसरी खराब गर्ने भन्ने बारे कुनै ज्ञान छैन। प्रतिक्रियाको प्राप्तिलाई लम्ब्याउँछ।
  हामी कसरी लड्छौं: जोडी कार्यमा विचार र अभ्यासहरूको पारस्परिक आदानप्रदानले लगभग समस्या समाधान गर्दछ।

IaC मा यो शैली प्रयोग गर्दा मुख्य समस्या कामको असमान गति हो। परम्परागत सफ्टवेयर विकासमा, तपाईंसँग धेरै समान आन्दोलन छ। तपाईले पाँच मिनेट खर्च गरेर N लेख्न सक्नुहुन्छ। 10 मिनेट खर्च गर्नुहोस् र 2N, 15 मिनेट - 3N लेख्नुहोस्। यहाँ तपाईं पाँच मिनेट खर्च गर्न सक्नुहुन्छ र N लेख्न सक्नुहुन्छ, र त्यसपछि अर्को 30 मिनेट खर्च गर्नुहोस् र N को दशांश लेख्नुहोस्। यहाँ तपाईंलाई केहि थाहा छैन, तपाईं अडिग हुनुहुन्छ, मूर्ख हुनुहुन्छ। अनुसन्धानले समय लिन्छ र प्रोग्रामिङबाट नै विचलित हुन्छ।

निष्कर्ष: यसको शुद्ध रूप मा यो हाम्रो लागि उपयुक्त छैन।

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

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

निष्कर्ष: अफसोस, कामको गतिले IaC मा एक जोडी प्रोग्रामिङ अभ्यासको रूपमा पिंग-पोङको प्रयोगलाई अनुमति दिँदैन।

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

सिक्नको लागि राम्रो, तर बलियो नरम कौशल चाहिन्छ। यहीँ हामी लड्यौँ । प्रविधि गाह्रो थियो। र यो पूर्वाधारको बारेमा पनि होइन।

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

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

जोडी प्रोग्रामिङ प्रयोग गर्ने सामान्य परिणामहरू:

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

5. यसको बावजुद, त्यहाँ सफलताहरू थिए। हामीले हाम्रो आफ्नै विधि "कन्भर्जेन्स - डाइभर्जन्स" लिएर आएका छौं। म छोटकरीमा वर्णन गर्नेछु कि यसले कसरी काम गर्दछ।

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

योजना र संचार

अभ्यासहरूको अन्तिम ब्लक जसको माध्यमबाट OS समस्याहरू समाधान गरिन्छ कार्यहरू आफैंसँग कामको संगठन हो। यसमा जोडीको कामभन्दा बाहिरको अनुभवको आदानप्रदान पनि समावेश छ। आउनुहोस् तीन अभ्यासहरू हेरौं:

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

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

कार्यहरूको दृश्य दृष्टिको फाइदाहरू:

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

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

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

3. आन्तरिक डेमो। जोडी प्रोग्रामिङबाट समस्या समाधान गर्न मद्दत गर्नुहोस्, समस्या रूखमा दृश्यावलोकन र बिहानको स्क्रम बैठकहरूमा मद्दत राम्रो छ, तर आदर्श होइन। एक जोडीको रूपमा, तपाईं केवल आफ्नो ज्ञान द्वारा सीमित हुनुहुन्छ। टास्क ट्रीले विश्वव्यापी रूपमा कसले के गरिरहेको छ भनेर बुझ्न मद्दत गर्दछ। र बिहानको बैठकमा प्रस्तुतकर्ता र सहकर्मीहरूले तपाईंको समस्याहरूमा गहिरो डुब्ने छैनन्। तिनीहरूले पक्कै पनि केहि गुमाउन सक्छ।

एकअर्कालाई गरेको काम देखाएर छलफल गरेर समाधान खोजियो । हामी हप्तामा एक पटक एक घण्टाको लागि भेट्छौं र हामीले गत हप्तामा गरेका कार्यहरूको समाधानको विवरण देखाउँछौं।

प्रदर्शनको समयमा, कार्यको विवरणहरू प्रकट गर्न र यसको सञ्चालन प्रदर्शन गर्न निश्चित हुन आवश्यक छ।

रिपोर्ट चेकलिस्ट प्रयोग गरेर सञ्चालन गर्न सकिन्छ।1. सन्दर्भमा प्रविष्ट गर्नुहोस्। काम कहाँबाट आयो, किन आवश्यक पर्यो ?

2. पहिले समस्या कसरी हल गरिएको थियो? उदाहरणका लागि, ठूलो माउस क्लिक आवश्यक थियो, वा यो सबै गर्न असम्भव थियो।

3. हामी यसलाई कसरी सुधार गर्छौं। उदाहरणका लागि: "हेर्नुहोस्, अब त्यहाँ स्क्रिप्टोसिक छ, यहाँ रीडमी छ।"

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

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

प्रत्येक वक्ताको लागि यसलाई 5-10 मिनेटमा राख्न सल्लाह दिइन्छ। यदि तपाईंको भाषण स्पष्ट रूपमा महत्त्वपूर्ण छ र लामो समय लाग्ने छ भने, sre-टेकओभर च्यानलमा यसलाई पहिले नै समन्वय गर्नुहोस्।

आमनेसामने भाग पछि थ्रेडमा सधैं छलफल हुन्छ। हामीलाई हाम्रा कार्यहरूमा चाहिने प्रतिक्रिया यहाँ देखिन्छ।

नतिजाको रूपमा, के भइरहेको छ यसको उपयोगिता निर्धारण गर्न सर्वेक्षण गरिन्छ। यो भाषणको सार र कार्यको महत्त्वमा प्रतिक्रिया हो।

लामो निष्कर्ष र अर्को के छ

लेखको स्वर केही हदसम्म निराशावादी छ जस्तो लाग्न सक्छ। यो गलत हो। प्रतिक्रियाको दुई तल्लो स्तरहरू, अर्थात् परीक्षण र जोडी प्रोग्रामिङ, काम। परम्परागत विकासमा जति पूर्णता छैन, त्यसको सकारात्मक प्रभाव छ ।

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

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

OS लाई प्रभाव पार्ने उच्च-स्तरीय तरिकाहरू - योजना र कार्यहरूसँग काम गर्ने प्रभावहरू ठीक रूपमा उत्पादन गर्दछ: उच्च-गुणस्तरको ज्ञान विनिमय र सुधारिएको विकास गुणस्तर।

एक लाइन मा छोटो निष्कर्ष

• HR चिकित्सकहरू IaC मा काम गर्छन्, तर कम दक्षताका साथ।
• के काम गर्दछ बलियो बनाउनुहोस्।
• तपाईंको आफ्नै क्षतिपूर्ति संयन्त्र र अभ्यासहरूको साथ आउनुहोस्।

स्रोत: www.habr.com