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

यस अर्थमा, लियोन फायरको अनुभव, जुन उनले साझा गरे DevOpsConf, ठ्याक्कै अनौठो होइन, तर उनको अनुभव र विभिन्न भूमिकाहरूको संख्या द्वारा गुणा गरिएको छ जुन उनले 20 वर्षको अवधिमा प्रयास गर्न व्यवस्थित गरे, यो धेरै उपयोगी छ। कट तल 90 दिन भन्दा बढीका घटनाहरूको कालक्रम र धेरै कथाहरू छन् जुन अरू कसैसँग हुँदा हाँस्न रमाइलो हुन्छ, तर व्यक्तिगत रूपमा सामना गर्न त्यति रमाइलो हुँदैन।

लियोन रूसीमा धेरै रंगीन बोल्छ, त्यसैले यदि तपाईंसँग 35-40 मिनेट छ भने, म भिडियो हेर्न सिफारिस गर्दछु। तल समय बचत गर्न पाठ संस्करण।

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

एक महिना अगाडि

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

शिक्षण रणनीतिहरू धेरै साना बच्चाहरू जन्मदेखि तीन वर्षको उमेरसम्मका लागि पाठ्यक्रममा बजार नेतृत्व हो। परम्परागत "पेपर" कम्पनी पहिले नै 40 वर्ष पुरानो छ, र प्लेटफर्मको डिजिटल SaaS संस्करण 10 वर्ष पुरानो छ, सापेक्ष रूपमा, कम्पनी मापदण्डहरूमा डिजिटल प्रविधि अनुकूलन गर्ने प्रक्रिया सुरु भयो। "नयाँ" संस्करण 2017 मा सुरु भयो र लगभग पुरानो जस्तै थियो, केवल यसले खराब काम गर्यो।

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

अलि अगाडि हेर्दै, म नोट गर्नेछु कि मैले मेरो काम उच्चतम वार्षिक ट्राफिकको अवधिमा सुरु गरें, जुन विभिन्न कारणले रोचक छ।

प्लेटफर्म, जुन केवल 2 वर्ष पुरानो देखिन्थ्यो, एक विचित्र स्ट्याक थियो: कोल्डफ्यूजन र SQL सर्भर 2008 बाट। ColdFusion, यदि तपाईलाई थाहा छैन, र सम्भवतः तपाईलाई थाहा छैन, एक उद्यम PHP हो जुन 90 को दशकको मध्यमा बाहिर आयो, र त्यसपछि मैले यसको बारेमा सुनेको छैन। त्यहाँ पनि थिए: रुबी, MySQL, PostgreSQL, Java, Go, Python। तर मुख्य मोनोलिथ ColdFusion र SQL Server मा चल्यो।

समस्याहरू

मैले कम्पनीका कर्मचारीहरूसँग काम र कस्ता समस्याहरू सामना गरे भन्ने बारे जति धेरै कुरा गरें, मैले समस्याहरू प्राविधिक मात्र होइनन् भन्ने महसुस गरें। ठीक छ, प्रविधि पुरानो छ - र तिनीहरूले यसमा काम गरेनन्, तर टोली र प्रक्रियाहरूसँग समस्याहरू थिए, र कम्पनीले यो बुझ्न थाले।

परम्परागत रूपमा, तिनीहरूका प्राविधिकहरू कुनामा बसेर कुनै प्रकारको काम गर्थे। तर अधिक र अधिक व्यापार डिजिटल संस्करण मार्फत जान थाले। त्यसकारण, मैले काम गर्न थालेको अघिल्लो वर्षमा, कम्पनीमा नयाँहरू देखा परे: सञ्चालक समिति, CTO, CPO र QA निर्देशक। अर्थात् कम्पनीले प्रविधि क्षेत्रमा लगानी गर्न थालेको छ ।

भारी विरासतको ट्रेसहरू प्रणालीहरूमा मात्र थिएनन्। कम्पनीसँग विरासत प्रक्रियाहरू, विरासत मानिसहरू, विरासत संस्कृति थियो। यी सबै परिवर्तन हुनुपर्यो । मैले सोचें कि यो निश्चित रूपमा बोरिंग हुनेछैन, र यसलाई प्रयास गर्ने निर्णय गरे।

दुई दिन अगाडि

नयाँ काम सुरु गर्नुभन्दा दुई दिन अघि, म अफिसमा पुगें, अन्तिम कागजी कार्यहरू भरें, टोलीलाई भेटें, र टोलीले त्यतिबेला समस्यासँग संघर्ष गरिरहेको थाहा पाए। यो औसत पृष्ठ लोडिङ समय 4 सेकेन्डमा उफ्रिएको थियो, अर्थात्, 2 पटक।

ग्राफ द्वारा न्याय गर्दै, केहि स्पष्ट रूपमा भयो, र यो के स्पष्ट छैन। यो समस्या डाटा सेन्टरमा नेटवर्क लेटन्सी थियो: डाटा सेन्टरमा 5 ms विलम्बता प्रयोगकर्ताहरूको लागि 2 s मा परिणत भयो। मलाई थाहा भएन यो किन भयो, तर कुनै पनि अवस्थामा यो समस्या डाटा केन्द्र मा थियो भनेर थाहा भयो।

पहिलो दिन

दुई दिन बित्यो र मेरो कामको पहिलो दिन मैले समस्या हटेको छैन भनेर पत्ता लगाएँ।

दुई दिनको लागि, प्रयोगकर्ताका पृष्ठहरू औसतमा 4 सेकेन्डमा लोड हुन्छन्। म सोध्छु कि तिनीहरूले के समस्या भेट्टाए।

- हो, हामीले टिकट खोल्यौं।
- अनि?
- ठीक छ, तिनीहरूले हामीलाई अझै जवाफ दिएका छैनन्।

त्यसपछि मैले महसुस गरें कि मलाई पहिले भनिएको सबै कुरा आइसबर्गको एउटा सानो टुप्पो मात्र थियो जुन मैले लड्नुपर्ने थियो।

त्यहाँ एक राम्रो उद्धरण छ जुन यो धेरै राम्रोसँग फिट हुन्छ:

"कहिलेकाहीं प्रविधि परिवर्तन गर्न तपाईंले संगठन परिवर्तन गर्नुपर्छ।"

तर मैले वर्षको सबैभन्दा व्यस्त समयमा काम सुरु गरेपछि, मैले समस्या समाधान गर्न दुवै विकल्पहरू हेर्नुपर्ने थियो: द्रुत र दीर्घकालीन दुवै। र अहिले के महत्वपूर्ण छ संग सुरु गर्नुहोस्।

दिन तीन

त्यसोभए, लोडिङ 4 सेकेन्डसम्म रहन्छ, र 13 देखि 15 सम्म सबैभन्दा ठूलो चुचुराहरू।

यस अवधिको तेस्रो दिनमा, डाउनलोड गति यस्तो देखिन्थ्यो:

मेरो दृष्टिकोणबाट, केहि पनि काम गरेन। सबैको दृष्टिकोणबाट यो सामान्य भन्दा अलि ढिलो चलिरहेको थियो। तर यो त्यस्तो हुँदैन - यो एक गम्भीर समस्या हो।

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

तर हामीले यो बिर्सनु हुँदैन कि तपाईंले सही जवाफ पाउनु अघि, तपाईंले सही प्रश्न सोध्न आवश्यक छ। मेरो अर्को प्रश्न थियो: हामीसँग कतिवटा फ्रन्टएन्ड सर्भरहरू छन्? जवाफले "मलाई थोरै छक्क पार्यो" - हामीसँग 17 फ्रन्टएन्ड सर्भरहरू थिए!

- मलाई सोध्न लाज लाग्छ, तर 150 लाई 17 ले भाग गर्दा लगभग 8 आउँछ? के तपाइँ प्रत्येक सर्भरले प्रति सेकेन्ड 8 अनुरोधहरू अनुमति दिन्छ भनी भन्नुहुन्छ, र यदि भोलि प्रति सेकेन्ड 160 अनुरोधहरू छन् भने, हामीलाई 2 थप सर्भरहरू चाहिन्छ?

अवश्य पनि, हामीलाई थप सर्भरहरू आवश्यक थिएन। समाधान कोडमा नै थियो, र सतहमा:

var currentClass = classes.getCurrentClass();
return currentClass;

कार्यक्रम थियो getCurrentClass(), किनभने साइट मा सबै कुरा एक वर्ग को सन्दर्भ मा काम गर्दछ - यो सही छ। र यसका लागि प्रत्येक पृष्ठमा एउटा प्रकार्य थियो 200+ अनुरोधहरू.

यस तरिकाको समाधान धेरै सरल थियो, तपाईंले केहि पनि पुन: लेख्नु पर्दैन: केवल उही जानकारी फेरि न सोध्नुहोस्।

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

म धेरै खुसी थिएँ किनभने मैले निर्णय गरें कि तेस्रो दिनमा मैले मुख्य समस्या भेट्टाएँ। म जस्तो भोली थिएँ, यो धेरै समस्याहरू मध्ये एक मात्र थियो।

तर यो पहिलो समस्या समाधान गर्दा ग्राफ धेरै तल खस्यो।

एकै समयमा, हामीले अन्य अप्टिमाइजेसनहरू गरिरहेका थियौं। त्यहाँ धेरै चीजहरू थिए जुन निश्चित गर्न सकिन्छ। उदाहरणका लागि, उही तेस्रो दिनमा मैले पत्ता लगाए कि त्यहाँ प्रणालीमा सबै पछि क्यास थियो (पहिले मैले सोचे कि सबै अनुरोधहरू सीधा डाटाबेसबाट आउँदैछन्)। जब म क्यासको बारेमा सोच्दछु, म मानक Redis वा Memcached को बारेमा सोच्दछु। तर यस्तो सोच्ने म मात्र थिएँ, किनभने त्यो प्रणालीले क्यासिङका लागि MongoDB र SQL Server प्रयोग गर्‍यो - जसबाट डाटा भर्खरै पढिएको थियो।

दस दिन

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

केहि रोचक फेरि पत्ता लाग्यो। टोलीमा 18 विकासकर्ताहरू थिए; 8 परीक्षकहरू; 3 प्रबन्धकहरू; 2 आर्किटेक्टहरू। र तिनीहरू सबैले साझा अनुष्ठानमा भाग लिए, अर्थात्, हरेक बिहान 30 भन्दा बढी व्यक्तिहरू स्ट्यान्ड-अपमा आए र उनीहरूले के गरे भने। बैठक ५ वा १५ मिनेट नबनेको स्पष्ट छ । सबैले फरक-फरक प्रणालीमा काम गर्ने भएकाले कसैले कसैको कुरा सुनेन। यस फारममा, ग्रूमिङ सत्रको लागि प्रति घण्टा 5-15 टिकट पहिले नै राम्रो परिणाम थियो।

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

नतिजाको रूपमा हामीले पायौं:

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

हामीले मुख्यतया दक्षता, उत्पादकता र गुणस्तरमा ध्यान केन्द्रित गर्यौं - यी समस्याहरू हुन् जुन हामीले टोलीको रूपान्तरणको साथ समाधान गर्ने प्रयास गर्यौं।

दिन एघार

टोली संरचना परिवर्तन गर्ने प्रक्रियामा, मैले कसरी गणना गर्ने भनेर पत्ता लगाए कथाअंक। 1 SP एक दिन बराबर थियो, र प्रत्येक टिकटमा विकास र QA दुवैको लागि SP समावेश थियो, अर्थात्, कम्तिमा 2 SP।

मैले यो कसरी पत्ता लगाए?

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

यस पछि हामी:

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

बीसौं दिन

पहिलो महिनाको मध्यमा कतै, स्थिति थोरै स्थिर भयो, मैले मूल रूपमा के भइरहेको थियो भनेर बुझें, र पहिले नै भविष्यमा हेर्न र दीर्घकालीन समाधानहरूको बारेमा सोच्न थाले।

दीर्घकालीन लक्ष्यहरू:

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

विगतमा यो अक्सर भनिन्थ्यो: "[भाषा/ढाँचा] मा सबै कुरा पुन: लेखौं, सबै राम्रो काम गर्नेछ!"

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

• परियोजनाको मिशन र लक्ष्यहरू प्रतिबिम्बित गर्दछ;
• मुख्य लक्ष्यहरूलाई प्राथमिकता दिन्छ;
• तिनीहरूलाई प्राप्त गर्न तालिका समावेश छ।

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

त्यो हो, संगठनात्मक KPIs टोलीहरू द्वारा समर्थित छन्, र टोली KPIs व्यक्तिगत KPIs द्वारा समर्थित छन्। अन्यथा, यदि प्राविधिक केपीआईहरू संगठनात्मकहरूसँग मेल खाँदैनन् भने, सबैले आफैंमा कम्बल तान्छन्।

उदाहरणका लागि, संगठनात्मक KPIs मध्ये एकले नयाँ उत्पादनहरू मार्फत बजार साझेदारी बढाउँदैछ।

तपाईं थप नयाँ उत्पादनहरू भएको लक्ष्यलाई कसरी समर्थन गर्न सक्नुहुन्छ?

• पहिलो, हामी दोषहरू समाधान गर्नुको सट्टा नयाँ उत्पादनहरू विकास गर्न बढी समय खर्च गर्न चाहन्छौं। यो एक तार्किक समाधान हो जुन मापन गर्न सजिलो छ।
• दोस्रो, हामी लेनदेन भोल्युममा वृद्धिलाई समर्थन गर्न चाहन्छौं, किनकि जति धेरै बजार सेयर, धेरै प्रयोगकर्ताहरू र, तदनुसार, अधिक ट्राफिक।

त्यसपछि समूह भित्र कार्यान्वयन गर्न सकिने व्यक्तिगत KPIs, उदाहरणका लागि, मुख्य दोषहरू आउने ठाउँमा हुनेछ। यदि तपाइँ यस खण्डमा विशेष रूपमा ध्यान केन्द्रित गर्नुहुन्छ भने, तपाइँ निश्चित गर्न सक्नुहुन्छ कि त्यहाँ धेरै कम दोषहरू छन्, र त्यसपछि नयाँ उत्पादनहरू विकास गर्न र संगठनात्मक KPIs लाई समर्थन गर्ने समय बढ्नेछ।

यसैले, प्रत्येक निर्णय, पुन: लेखन कोड सहित, कम्पनीले हाम्रो लागि सेट गरेको विशिष्ट लक्ष्यहरूलाई समर्थन गर्नुपर्दछ (संगठनात्मक वृद्धि, नयाँ सुविधाहरू, भर्ती)।

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

तीस दिन

महिनाको अन्त्यमा, मैले अर्को न्युनन्स फेला पारे: मेरो Ops टोलीमा कसैले पनि हामीले ग्राहकहरूसँग गर्ने सम्झौताहरू देखेका छैनन्। तपाईंले किन सम्पर्कहरू हेर्न आवश्यक छ भनेर सोध्न सक्नुहुन्छ।

• पहिलो, किनभने SLA हरू सम्झौताहरूमा निर्दिष्ट गरिएका छन्।
• दोस्रो, SLA सबै फरक छन्। प्रत्येक ग्राहक आफ्नै आवश्यकताहरू लिएर आए, र बिक्री विभागले नहेरी हस्ताक्षर गरे।

अर्को चाखलाग्दो नक्सा यो हो कि सबैभन्दा ठूलो ग्राहकहरु मध्ये एक संग सम्झौताले प्लेटफर्म द्वारा समर्थित सबै सफ्टवेयर संस्करणहरू n-1 हुनुपर्दछ, त्यो हो, नवीनतम संस्करण होइन, तर अन्तिम संस्करण।

यो स्पष्ट छ कि हामी n-1 बाट कति टाढा थियौं यदि प्लेटफर्म ColdFusion र SQL Server 2008 मा आधारित थियो, जुन अब जुलाईमा समर्थित थिएन।

पैंतालीस दिन

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

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

जब मैले यो गरें, दुई चीजहरूले मेरो आँखा समात्यो:

• QA बाट विकासकर्ताहरूलाई फिर्ता गरिएका टिकटहरूको उच्च प्रतिशत;
• पुल अनुरोध समीक्षाहरू धेरै लामो भयो।

समस्या यो थियो कि यी निष्कर्षहरू थिए: यसले धेरै समय लिने देखिन्छ, तर हामी निश्चित छैनौं कि कति समय।

"तपाईले मापन गर्न नसक्ने कुरा सुधार गर्न सक्नुहुन्न।"

समस्या कत्तिको गम्भीर छ भनेर कसरी न्याय गर्ने? के यसले दिन वा घण्टा बर्बाद गर्छ?

यो मापन गर्न, हामीले Jira प्रक्रियामा केही चरणहरू थप्यौं: प्रत्येक टिकट कति समय पर्खन्छ र कति पटक निश्चित चरणमा फर्कन्छ मापन गर्न "देवका लागि तयार" र "QA को लागि तयार"।

हामीले समीक्षाको लागि औसत कति टिकटहरू छन् भनेर जान्नको लागि "समीक्षामा" पनि थप्यौं, र यसबाट तपाईं नाच्न सुरु गर्न सक्नुहुन्छ। हामीसँग प्रणाली मेट्रिकहरू थिए, अब हामीले नयाँ मेट्रिकहरू थप्यौं र मापन गर्न थाल्यौं:

• प्रक्रिया दक्षता: कार्यसम्पादन र योजनाबद्ध/डिलिभर।
• प्रक्रिया गुणस्तर: त्रुटिहरूको संख्या, QA बाट त्रुटिहरू।

यसले के राम्रो भइरहेको छ र के राम्रो भइरहेको छैन भनेर बुझ्न मद्दत गर्दछ।

पचासौं दिन

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

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

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

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

सही सन्तुलन के हो, यसलाई कसरी कायम राख्ने, कति जना राख्ने र कति धकेल्ने भन्ने प्रश्नको राम्रो जवाफ मसँग छैन। यो एक विशुद्ध व्यक्तिगत प्रक्रिया हो।

पचासौं दिन

मसँग को छ भनेर बुझ्नको लागि मैले टोलीलाई नजिकबाट हेर्न थाले, र एक पटक फेरि मैले सम्झे:

"धेरै समस्याहरू मानिसहरूको समस्या हुन्।"

मैले फेला पारेको छु कि टोली जस्तै - दुबै देव र ओप्स - तीन ठूला समस्याहरू छन्:

• हालको अवस्था प्रति सन्तुष्टि।
• जिम्मेवारीको अभाव - किनकि कसैले पनि व्यवसायलाई प्रभाव पार्न कलाकारहरूको कामको नतिजा ल्याएको छैन।
• परिवर्तनको डर।

परिवर्तनले जहिले पनि तपाइँलाई तपाइँको कम्फर्ट जोनबाट बाहिर लैजान्छ, र युवाहरू, उनीहरूले परिवर्तनलाई मन पराउँदैनन् किनभने उनीहरूले किन बुझ्दैनन् र कसरी बुझ्दैनन्। मैले सुनेको सबैभन्दा सामान्य जवाफ हो, "हामीले त्यो कहिल्यै गरेका छैनौं।" यसबाहेक, यो पूर्ण बेतुकाको बिन्दुमा पुग्यो - सानातिना परिवर्तनहरू कसैलाई क्रोधित बिना हुन सकेन। र परिवर्तनहरूले उनीहरूको कामलाई जतिसुकै असर गरे तापनि मानिसहरूले भने: "होइन, किन? यसले काम गर्दैन।"

तर तपाईं केहि परिवर्तन नगरी राम्रो हुन सक्नुहुन्न।

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

राम्रो प्रश्न - किन? यो जस्तो छ कि यो पहिले भन्दा अहिले राम्रो छ, तब सबै कुरा पर्याप्त छ। यसले जिम्मेवारीको कमी निम्त्याउँछ, जुन सिद्धान्तमा बिल्कुल सामान्य छ। मैले भनेझैं, प्राविधिक समूह थोरै छेउमा थियो। कम्पनीको विश्वास थियो कि तिनीहरू अवस्थित हुनुपर्छ, तर कसैले मापदण्ड तोकेन। प्राविधिक समर्थनले कहिले पनि SLA देखेन, त्यसैले यो समूहको लागि एकदम "स्वीकार्य" थियो (र यसले मलाई सबैभन्दा बढी प्रभावित गर्यो):

• 12 सेकेन्ड लोड गर्दै;
• 5-10 मिनेट डाउनटाइम प्रत्येक रिलीज;
• महत्वपूर्ण समस्याहरू समाधान गर्न दिन र हप्ता लाग्छ;
• ड्यूटी कर्मीहरूको अभाव 24x7 / अन-कल।

हामीले यसलाई अझ राम्रो किन नगर्ने भनेर कसैले सोध्ने प्रयास गरेन, र कसैले पनि कहिल्यै महसुस गरेन कि यो यसरी हुनु हुँदैन।

बोनसको रूपमा, त्यहाँ अर्को समस्या थियो: अनुभवको कमी। वरिष्ठहरू गए, र बाँकी युवा टोली अघिल्लो शासन अन्तर्गत हुर्के र त्यसबाट विषाक्त भए।

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

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

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

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

जवाफमा, मैले निम्न अभ्यासहरू प्रस्तुत गरें:

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

साठौं दिन

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

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

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

सूची परिणाम:

• हामीले एउटै डाटा सेन्टर छोड्यौं।
• हामीले 3 लग सेवाहरूसँग सम्झौता समाप्त गर्यौं। किनभने हामीसँग ती मध्ये 5 वटा थिए - प्रत्येक विकासकर्ता जसले केहिसँग खेल्न थाले नयाँ लिनुभयो।
• 7 AWS प्रणालीहरू बन्द गरियो। फेरि, कसैले पनि मृत परियोजनाहरू रोकेन; तिनीहरू सबै काम जारी राखे।
• ६ गुणाले सफ्टवेयरको लागत घटाइयो।

पचहत्तरी दिन

समय बित्दै गयो र साढे दुई महिनामा मैले सञ्चालक समितिसँग भेट्नुपर्‍यो । हाम्रो बोर्ड अफ डाइरेक्टर अरूहरू भन्दा राम्रो वा खराब छैन; यो सबै कुरा जान्न चाहन्छ। मानिसहरू पैसा लगानी गर्छन् र हामीले के केपीआईहरू सेटमा फिट हुन्छ भनेर बुझ्न चाहन्छन्।

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

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

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

त्यो हो, ColdFusion जेट्टी र nginx मार्फत जान्छ र पृष्ठहरू सुरू गर्दछ। र छविहरू, JS र CSS आफ्नै कन्फिगरेसनहरूसँग छुट्टै nginx मार्फत जान्छन्। यो एकदम मानक अभ्यास हो जुन मैले कुरा गरिरहेको छु लेखियो केही वर्ष पहिले। फलस्वरूप, तस्बिरहरू धेरै छिटो लोड हुन्छन्, र... औसत लोडिङ गति 200 ms ले बढेको छ।

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

पचासी दिन

तेस्रो महिनाको अन्त्यमा, मैले महसुस गरें कि त्यहाँ एउटा चीज थियो जुन मैले कहिल्यै गनेको थिएन: समय। मैले बोलेको सबै कुराले समय लिन्छ।

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

निष्कर्षमा

यति मात्र होइन। यस कथामा, मैले कसरी उत्पादनसँग काम गर्यौं र सामान्य लहरमा ट्युन इन गर्ने प्रयास गर्‍यौं, वा हामीले प्राविधिक समर्थन कसरी एकीकृत गर्यौं, वा हामीले अन्य प्राविधिक समस्याहरू कसरी समाधान गर्यौं भन्ने कुरा पनि मैले बुझेको छैन। उदाहरण को लागी, मैले संयोगवश सिकें कि डेटाबेस मा सबै भन्दा ठूलो टेबल मा हामी प्रयोग गर्दैनौं SEQUENCE। हामीसँग स्व-लिखित प्रकार्य छ nextID, र यो लेनदेन मा प्रयोग गरिदैन।

त्यहाँ लाखौं समान चीजहरू थिए जुन हामीले लामो समयको लागि कुरा गर्न सक्छौं। तर अझै पनि भन्नु पर्ने सबैभन्दा महत्त्वपूर्ण कुरा भनेको संस्कृति हो।

यो संस्कृति हो वा यसको अभावले अन्य सबै समस्याहरू निम्त्याउँछ। हामी एक संस्कृति निर्माण गर्न कोशिस गर्दैछौं जहाँ मानिसहरू:

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

यससँगै अरू सबै कुरा आउँछन्।

लियोन फायर twitter मा, फेसबुक र मा मध्यम.

विरासतको सम्बन्धमा दुईवटा रणनीतिहरू छन्: कुनै पनि हालतमा यसको साथ काम नगर्नुहोस्, वा साहसपूर्वक सम्बन्धित कठिनाइहरूलाई पार गर्नुहोस्। हामीले ग DevOpsConf हामी दोस्रो बाटो लिइरहेका छौं, प्रक्रियाहरू र दृष्टिकोणहरू परिवर्तन गर्दै। हामीसँग सामेल हुनुहोस् YouTube, न्यूजलेटर и टेलिग्राम, र सँगै हामी एक DevOps संस्कृति लागू गर्नेछौं।

स्रोत: www.habr.com