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

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

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

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

एक महीने पहले

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

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

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

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

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

समस्याओं

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

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

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

दो दिन पहले

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

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

एक दिन

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

दो दिनों में, उपयोगकर्ताओं के पेज औसतन 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;

मैं बहुत खुश था क्योंकि मैंने तय कर लिया था कि तीसरे दिन ही मुझे मुख्य समस्या का पता चल गया है। मैं जितना नासमझ था, यह कई समस्याओं में से एक थी।

लेकिन इस पहली समस्या को हल करने से ग्राफ बहुत नीचे गिर गया।

साथ ही, हम अन्य अनुकूलन भी कर रहे थे। बहुत सारी चीज़ें नज़र आ रही थीं जिन्हें ठीक किया जा सकता था। उदाहरण के लिए, उसी तीसरे दिन मुझे पता चला कि सिस्टम में कैश था (पहले तो मुझे लगा कि सभी अनुरोध सीधे डेटाबेस से आ रहे थे)। जब मैं कैश के बारे में सोचता हूं, तो मैं मानक रेडिस या मेम्केच्ड के बारे में सोचता हूं। लेकिन मैं अकेला था जिसने ऐसा सोचा था, क्योंकि उस सिस्टम ने कैशिंग के लिए MongoDB और SQL सर्वर का उपयोग किया था - वही जिससे डेटा अभी पढ़ा गया था।

दसवां दिन

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

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

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

परिणामस्वरूप हमें मिला:

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

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

दिन ग्यारह

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

मुझे इसकी खोज कैसे हुई?

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

इसके बाद हम:

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

बीसवां दिन

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

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

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

अतीत में यह अक्सर कहा जाता था: "आइए सब कुछ [भाषा/ढांचे] में फिर से लिखें, सब कुछ बेहतर ढंग से काम करेगा!"

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

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

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

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

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

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

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

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

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

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

दिन तीस

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

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

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

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

दिन पैंतालीसवाँ

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

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

जब मैंने ऐसा किया, तो दो चीज़ों ने मेरा ध्यान खींचा:

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

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

"आप जिसे माप नहीं सकते उसे सुधार नहीं सकते।"

समस्या कितनी गंभीर है इसका औचित्य कैसे बताया जाए? क्या इससे दिन या घंटे बर्बाद होते हैं?

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

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

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

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

पचासवां दिन

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

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

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

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

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

दिन इक्यावन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जवाब में, मैंने निम्नलिखित प्रथाएँ पेश कीं:

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

दिन साठवाँ

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

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

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

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

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

दिन पचहत्तर

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

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

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

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

अर्थात्, कोल्डफ़्यूज़न जेट्टी और nginx के माध्यम से जाता है और पेज लॉन्च करता है। और छवियां, जेएस और सीएसएस अपने स्वयं के कॉन्फ़िगरेशन के साथ एक अलग nginx से गुजरते हैं। यह एक काफी मानक अभ्यास है जिसके बारे में मैं बात कर रहा हूं मैंने लिखा था कुछ साल पहले। परिणामस्वरूप, तस्वीरें बहुत तेजी से लोड होती हैं, और... औसत लोडिंग गति 200 एमएस तक बढ़ गई है।

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

दिन पचासी

तीसरे महीने के अंत में, मुझे एहसास हुआ कि एक ऐसी चीज़ थी जिस पर मैंने बिल्कुल भी भरोसा नहीं किया था: समय। मैंने जो भी बात की उसमें समय लगता है।

यह मेरा वास्तविक साप्ताहिक कैलेंडर है - केवल एक कार्य सप्ताह, बहुत व्यस्त नहीं। हर चीज़ के लिए पर्याप्त समय नहीं है. इसलिए, फिर से, आपको ऐसे लोगों को भर्ती करने की ज़रूरत है जो समस्याओं से निपटने में आपकी मदद करेंगे।

निष्कर्ष

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

ऐसी ही लाखों और चीज़ें थीं जिनके बारे में हम लंबे समय तक बात कर सकते थे। लेकिन सबसे महत्वपूर्ण बात जो अभी भी कही जानी चाहिए वह है संस्कृति।

यह संस्कृति या उसका अभाव ही है जो अन्य सभी समस्याओं को जन्म देता है। हम एक ऐसी संस्कृति का निर्माण करने का प्रयास कर रहे हैं जहां लोग:

• असफलताओं से नहीं डरते;
• गलतियों से सबक;
• अन्य टीमों के साथ सहयोग करें;
• पहल करें;
• जिम्मेदारी लें;
• लक्ष्य के रूप में परिणाम का स्वागत करें;
• सफलता का जश्न मना रहे हैं.

इसके साथ ही बाकी सब कुछ आ जाएगा.

लियोन फायर ट्विटर पर, facebook और मध्यम.

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

स्रोत: www.habr.com