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

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

लियोन रूसी में बहुत रंगीन है, इसलिए यदि आपके पास 35-40 मिनट हैं, तो मैं वीडियो देखने की सलाह देता हूं। नीचे दिए गए समय को बचाने के लिए पाठ संस्करण।


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

एक महीने पहले

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

शिक्षण रणनीतियाँ बहुत छोटे बच्चों के लिए शैक्षिक कार्यक्रमों के लिए बाजार का नेतृत्व करती हैं - जन्म से लेकर तीन साल तक। पारंपरिक "पेपर" कंपनी पहले से ही 40 साल पुरानी है, और मंच 10 के डिजिटल सास संस्करण। अपेक्षाकृत हाल ही में, कंपनी के मानकों के लिए डिजिटल प्रौद्योगिकी को अपनाने की प्रक्रिया शुरू हो गई है। "नया" संस्करण 2017 में लॉन्च किया गया था और यह लगभग पुराने जैसा था, केवल इसने बदतर काम किया।

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



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

प्लेटफ़ॉर्म, जो केवल 2 साल पुराना था, में एक अजीबोगरीब स्टैक था: कोल्डफ़्यूज़न और एसक्यूएल सर्वर 2008। कोल्डफ़्यूज़न, यदि आप नहीं जानते हैं, लेकिन सबसे अधिक संभावना है, यह नहीं पता है, एक ऐसा उद्यम PHP है जो 90 के दशक के मध्य में निकला था, और तब से मैंने इसके बारे में सुना भी नहीं है। इसके अलावा वहाँ थे: रूबी, MySQL, PostgreSQL, जावा, गो, पायथन। लेकिन मुख्य मोनोलिथ को कोल्डफ्यूजन और एसक्यूएल सर्वर पर काम किया।

समस्याओं

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

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

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

दो दिन पहले

नई नौकरी शुरू करने से दो दिन पहले, मैं कार्यालय पहुंचा, आखिरी प्रश्नपत्र भरे, टीम से परिचित हुआ और पाया कि टीम उस समय समस्या से जूझ रही थी। यह इस तथ्य में शामिल था कि औसत पृष्ठ लोड समय 4 एस, यानी 2 बार कूद गया।



अनुसूची को देखते हुए, स्पष्ट रूप से कुछ हुआ, और यह स्पष्ट नहीं है कि क्या है। यह पता चला कि समस्या डेटा सेंटर में नेटवर्क विलंबता में थी: डेटा सेंटर में 5 एमएस विलंबता उपयोगकर्ताओं के लिए 2 एस में परिवर्तित हो गई थी। ऐसा क्यों हुआ, मुझे नहीं पता था, लेकिन किसी भी मामले में यह ज्ञात हो गया कि समस्या डेटा सेंटर में है।

पहला दिन

दो दिन बीत गए, और मेरे पहले कार्य दिवस पर मुझे पता चला कि समस्या दूर नहीं हुई थी।



दो दिनों के लिए, पेज के उपयोगकर्ता औसत 4 s पर लोड होते हैं। मैं पूछता हूं कि क्या उन्होंने पाया कि समस्या क्या है।

- हां, हमने एक टिकट खोला।
- और?
"ठीक है, उन्होंने अभी तक हमें जवाब नहीं दिया है।"

तब मुझे एहसास हुआ कि मुझे जो कुछ भी पहले बताया गया था वह हिमखंड का सिर्फ एक छोटा सा सिरा था जिससे मुझे लड़ना था।

एक अच्छा उद्धरण है जो इस मामले के लिए बहुत उपयुक्त है:

"कभी-कभी आपको तकनीक बदलने के लिए संगठन को बदलने की आवश्यकता होती है।"

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

दिन तीन

तो, लोडिंग में 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 सर्वर का उपयोग किया गया था - वही जिसमें से डेटा अभी पढ़ा गया था।

दिन दस

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

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

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

परिणामस्वरूप, हमने प्राप्त किया:

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

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

ग्यारहवाँ दिन

टीम की संरचना को बदलने की प्रक्रिया में, मुझे पता चला कि स्टोरी पॉइंट कैसे गिने जाते हैं। 1 एसपी एक दिन के बराबर था, और प्रत्येक टिकट में उनके पास एसपी थे जो विकास और क्यूए दोनों के लिए थे, यानी कम से कम 2 एसपी।

मुझे यह कैसे पता चला?



एक बग मिला: एक रिपोर्ट में, जहां उस अवधि की शुरुआत और समाप्ति की तारीख जिसके लिए रिपोर्ट की आवश्यकता है, दर्ज किया गया है, अंतिम दिन को ध्यान में नहीं रखा गया है। अर्थात्, अनुरोध में कहीं <= नहीं था, लेकिन बस <। मुझे बताया गया कि ये तीन स्टोरी पॉइंट हैं, यानी 3 दिन ।

उसके बाद हम:

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

बीसवाँ दिन

पहले महीने के मध्य तक, स्थिति थोड़ी स्थिर हो गई थी, मुझे पता चला कि मुख्य रूप से क्या हो रहा था, और पहले से ही भविष्य को देखने और दीर्घकालिक समाधान के बारे में सोचना शुरू कर दिया।

दीर्घकालिक लक्ष्य:

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

अतीत में अक्सर कहा जाता था: "चलो [भाषा / रूपरेखा] में सब कुछ फिर से लिखना, सब कुछ बेहतर काम करेगा!"

ज्यादातर मामलों में, यह काम नहीं करता है, ठीक है, अगर फिर से लिखा जाएगा तो सभी काम करेंगे। इसलिए, हमें एक रोडमैप बनाने की आवश्यकता है - एक ठोस रणनीति जो कदम से कदम बताती है कि व्यावसायिक लक्ष्यों को कैसे प्राप्त किया जाएगा (हम क्या करेंगे और क्यों करेंगे), जो:

• मिशन और परियोजना के लक्ष्यों को दर्शाता है;
• प्रमुख लक्ष्यों को प्राथमिकता देता है;
• उनकी उपलब्धि के लिए एक कार्यक्रम है।

इससे पहले, किसी ने टीम के साथ इस बारे में बात नहीं की थी कि कोई बदलाव किस उद्देश्य से किया गया है। इसके लिए सही सफलता दर की आवश्यकता होती है। कंपनी के इतिहास में पहली बार, हमने एक तकनीकी समूह के लिए KPI निर्धारित किया, और ये संकेतक संगठनात्मक लोगों के लिए बंधे थे।



यही है, संगठनात्मक KPI को टीमों द्वारा समर्थित किया जाता है, और टीम KPI को पहले से ही अलग-अलग लोगों द्वारा समर्थित किया जाता है। अन्यथा, यदि तकनीकी KPI संगठनात्मक लोगों से सहमत नहीं हैं, तो हर कोई अपने ऊपर कंबल खींचता है।

उदाहरण के लिए, संगठनात्मक KPI में से एक नए उत्पादों के माध्यम से बाजार में हिस्सेदारी बढ़ाना है।

आप अधिक नए उत्पादों के लक्ष्य का समर्थन कैसे कर सकते हैं?

• सबसे पहले, हम बग को ठीक करने के बजाय नए उत्पादों को विकसित करने में अधिक समय बिताना चाहते हैं। यह एक तार्किक समाधान है जिसे मापना आसान है।
• दूसरे, हम लेन-देन की मात्रा में वृद्धि का समर्थन करना चाहते हैं, क्योंकि अधिक से अधिक बाजार में हिस्सेदारी, अधिक उपयोगकर्ता और तदनुसार, अधिक यातायात।

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

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

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

तीसवां दिन

महीने के अंत में, मैंने एक और बारीकियों की खोज की कि मेरी किसी भी ऑप्स टीम ने कभी भी अनुबंध नहीं देखा था जिसे हम ग्राहकों के साथ समाप्त करते हैं। आप पूछ सकते हैं कि संपर्क क्यों देखें।

• सबसे पहले, क्योंकि SLAs अनुबंधों में पंजीकृत हैं।
• दूसरे, SLAs सभी अलग हैं। प्रत्येक ग्राहक अपनी आवश्यकताओं के साथ आया, और बिक्री विभाग ने बिना देखे हस्ताक्षर किए।

एक और दिलचस्प बारीकियों - सबसे बड़े ग्राहकों में से एक के साथ अनुबंध में यह लिखा गया है कि प्लेटफ़ॉर्म का समर्थन करने वाले सॉफ़्टवेयर के सभी संस्करणों को n-1 होना चाहिए, अर्थात नवीनतम संस्करण नहीं, बल्कि एक से एक।

यह स्पष्ट है कि यदि प्लेटफ़ॉर्म कोल्डफ़्यूज़न और एसक्यूएल सर्वर 2008 पर एन -1 से हम कितनी दूर थे, जो जुलाई में बिल्कुल भी बंद नहीं हुआ।

चालीसवाँ दिन

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

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

जब मैंने ऐसा किया, तो दो चीजों ने मेरी आंखें पकड़ लीं:

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

समस्या यह थी कि ये निष्कर्ष जैसे थे: यह बहुत समय लगता है, लेकिन हमें यकीन नहीं है कि कितना।

"जो मापा नहीं जा सकता उसे सुधारना असंभव है।"

समस्या के गंभीर होने की पुष्टि कैसे करें? क्या यह दिन या घंटे खर्च करता है?

इसे मापने के लिए, हमने जीरा प्रक्रिया में कुछ चरणों को जोड़ा: "देव के लिए तैयार" और "क्यूए के लिए तैयार", यह मापने के लिए कि प्रत्येक टिकट कितनी देर तक प्रतीक्षा करता है और कितनी बार एक निश्चित कदम पर लौटता है।



हमने यह जानने के लिए "समीक्षा" में भी जोड़ा है कि औसतन कितने टिकट समीक्षा में हैं, और इसलिए वे पहले से ही नृत्य कर रहे हैं। हमारे पास सिस्टम मेट्रिक्स थे, अब हमने नए मेट्रिक्स जोड़े, और मापना शुरू किया:

• प्रक्रिया दक्षता: प्रदर्शन और नियोजित / वितरित।
• प्रक्रिया गुणवत्ता: दोषों की संख्या, क्यूए से दोष।

यह वास्तव में यह समझने में मदद करता है कि क्या अच्छा चल रहा है और क्या बुरा है।

पचासवां दिन

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

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

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

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

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

पहले दिन पचास

मैं टीम को करीब से देखने के लिए समझने लगा कि मेरे पास कौन है, और एक बार फिर याद किया गया:

"ज्यादातर समस्याएं लोगों की समस्याएं हैं।"

मैंने पाया कि टीम में, जैसे - डेवलपर्स और ऑप्स - दोनों में तीन बड़ी समस्याएं हैं:

• चीजों की वर्तमान स्थिति के साथ संतुष्टि।
• जिम्मेदारी की कमी - क्योंकि किसी ने कभी भी व्यवसाय को प्रभावित करने के लिए कलाकारों के काम के परिणाम नहीं लाए हैं।
• बदलाव का डर।

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

लेकिन आप बिना कुछ बदले बेहतर नहीं हो सकते।

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

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

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

किसी ने कभी यह पूछने की कोशिश नहीं की कि हमें इसे बेहतर क्यों नहीं करना चाहिए, और किसी ने कभी महसूस नहीं किया कि यह नहीं होना चाहिए।

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

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

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

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

दूसरे, वे लोग जो अक्षम प्रतीत होने से डरते हैं, अनावश्यक रूप से विश्लेषण करते हैं । जब आप कहते हैं कि वास्तव में क्या करने की आवश्यकता है, तो यह शुरू होता है: "नहीं, लेकिन अगर हम यहां सोचते हैं तो क्या होगा?" इस अर्थ में, हमारी कंपनी अद्वितीय नहीं है, यह एक मानक युवा समस्या है।

जवाब में, मैंने निम्नलिखित अभ्यास शुरू किए:

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

छठे दिन

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

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

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

इन्वेंटरी परिणाम:

• हमने एक डेटा सेंटर छोड़ा।
• 3 लॉग सेवाओं के साथ अनुबंध समाप्त कर दिया। क्योंकि हमारे पास उनमें से 5 थे - प्रत्येक डेवलपर जिसने कुछ के साथ खेलना शुरू किया, एक नया लिया।
• 7 एडब्ल्यूएस सिस्टम को बंद कर दिया। फिर से, किसी ने मृत परियोजनाओं को नहीं रोका, वे सभी काम करना जारी रखते थे।
• सॉफ्टवेयर लागत में 6 गुना की कमी।

सत्तरवां दिन

समय बीतता गया, और ढाई महीने के बाद मुझे निदेशक मंडल के साथ मिलना था। हमारा निदेशक मंडल दूसरों से बेहतर और कोई बुरा नहीं है, यह सभी निदेशक मंडल की तरह सब कुछ जानना चाहता है। लोग पैसे का निवेश करते हैं और यह समझना चाहते हैं कि हम सेट केपीआई में कितना फिट हैं।

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

एकमात्र समस्या यह है कि मेरा मानना ​​है कि औसत मूल्य शुद्ध बुराई है। लेकिन निदेशक मंडल को समझाना बहुत मुश्किल है। वे एकत्रित संख्या के साथ संचालन के आदी हैं, और उदाहरण के लिए, प्रति सेकंड लोड समय के प्रसार से नहीं।

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



यही है, कोल्डफ्यूजन जेट्टी और नेग्नेक्स के माध्यम से जाता है और पृष्ठों को लॉन्च करता है। और चित्र, जेएस और सीएसएस अपने स्वयं के विन्यास के साथ एक अलग नग्नेक्स से गुजरते हैं। यह एक काफी मानक अभ्यास है जो मैंने कुछ साल पहले लिखा था। , … 200 .



, , Jetty. — . , , , - 12%?

, — . , , .



— , . . - , .

निष्कर्ष

. , , , . , , SEQUENCE . nextID , .

, . , , — .



. , :

• ;
• ;
• ;
• ;
• ;
• ;
• .

.

twitter , facebook medium .

legacy : , . c DevOpsConf , . youtube , , DevOps.