तकनीकी ऋण एक कंपनी संकट के लिए अग्रणी

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



डोडो पिज्जा आईटी टीम 7 साल के दौरान 12 देशों में सेवा करने वाले 60 लोगों को एक देश की सेवा करने वाले 2 डेवलपर्स से बढ़ी। एक स्क्रैम मास्टर और एक्सपी कोच के रूप में मैंने टीमों को प्रक्रियाओं को स्थापित करने और इंजीनियरिंग प्रथाओं को अपनाने में मदद की, लेकिन यह गोद लेना बहुत धीमा था। जब एक ही उत्पाद पर कई टीमें काम करती हैं तो मेरे लिए टीमों को उच्च कोड गुणवत्ता रखना चुनौतीपूर्ण था। हम तकनीकी उत्कृष्टता पर व्यापार सुविधाओं के लिए वरीयता के जाल में पड़ गए और बहुत अधिक वास्तु तकनीकी ऋण जमा हो गए। जब विपणन ने 2018 में बड़े पैमाने पर विज्ञापन अभियान शुरू किया, तो हम लोड को बर्दाश्त नहीं कर सके और नीचे गिर गए। यह शर्म की बात थी। लेकिन संकट के दौरान, हमने महसूस किया कि हम कई गुना अधिक कुशलता से काम करने में सक्षम हैं। संकट ने हमें प्रक्रियाओं में क्रांतिकारी बदलाव और सबसे प्रसिद्ध इंजीनियरिंग प्रथाओं के तेजी से परिचय की ओर धकेल दिया है।

पृष्ठभूमि

आप सोच सकते हैं कि डोडो पिज्जा एक नियमित पिज़्ज़ेरिया नेटवर्क है। लेकिन वास्तव में डोडो पिज्जा एक आईटी कंपनी है जो पिज्जा बेचने के लिए होता है । हमारा व्यवसाय डोडो आईएस - क्लाउड-आधारित प्लेटफ़ॉर्म पर आधारित है, जो सभी व्यावसायिक प्रक्रियाओं का प्रबंधन करता है, ऑर्डर लेने से शुरू होता है, फिर खाना पकाने और इन्वेंट्री प्रबंधन, लोगों के प्रबंधन और निर्णय लेने के लिए परिष्करण। केवल 7 वर्षों में हम 12 देशों में 470+ पिज़्ज़ेरिया की सेवा करने वाले 70+ डेवलपर्स के लिए एक एकल पिज़्ज़ेरिया की सेवा करने वाले 2 डेवलपर्स से बढ़े हैं।

जब मैं दो साल पहले कंपनी में शामिल हुआ, तो हमारे पास 6 टीमें और लगभग 30 डेवलपर्स थे। डोडो आईएस कोडबेस में कोड की लगभग 1M लाइनें थीं। इसमें एक अखंड वास्तुकला और बहुत कम इकाई परीक्षण कवरेज था। हमारे पास तब तक कोई एपीआई / यूआई परीक्षण नहीं था। सिस्टम की कोड गुणवत्ता निराशाजनक थी। हम इसे जानते थे और उज्ज्वल भविष्य के बारे में सपना देखा था, जब मोनोलिथ को दर्जनों सेवाओं में विभाजित किया था और सिस्टम के सबसे घनिष्ठ भागों को फिर से लिखा था। यहां तक ​​कि हम "आर्किटेक्चर होने के लिए" आरेख भी बनाते हैं, लेकिन ईमानदारी से भविष्य की स्थिति के लिए लगभग कुछ भी नहीं किया है। मेरा प्राथमिक लक्ष्य डेवलपर्स इंजीनियरिंग प्रथाओं को पढ़ाने और एक विकास प्रक्रिया का निर्माण करना था, जिससे 6 टीमों को एक ही उत्पाद पर काम करना पड़ता था ।

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

शिट होता है

2018 में मार्केटिंग टीवी पर हमारा पहला संघीय विज्ञापन अभियान चलाती है। यह हमारे लिए बहुत बड़ी घटना थी। हमने अभियान के वित्तपोषण के लिए 100M रूबल ($ 1.5M) खर्च किया - हमारे लिए काफी महत्वपूर्ण राशि। आईटी टीम ने अभियान के लिए भी तैयार किया। हमने अपनी तैनाती को स्वचालित और सरल बनाया - अब टीमसिटी में एक बटन के साथ हम 12 देशों में मोनोलिथ को तैनात कर सकते हैं। हमने प्रदर्शन परीक्षणों की जांच की और भेद्यता विश्लेषण किया। हमने अपना सर्वश्रेष्ठ किया लेकिन हमें अप्रत्याशित समस्याओं का सामना करना पड़ा।

विज्ञापन अभियान भयानक था। हम 100 से 300 ऑर्डर / मिनट तक चले गए। यह अच्छी खबर थी। बुरी खबरें थीं कि डोडो आईएस इस तरह के भार का सामना नहीं कर सका और मर गया। हमने अपनी वर्टिकल स्केलिंग सीमाएँ प्राप्त कर लीं और अब ऑर्डर को संभाल नहीं पाए। सिस्टम ने हर 3 घंटे में रिबूट किया। डाउनटाइम के हर मिनट में हमें लाखों पैसे खर्च करने के साथ-साथ उग्र ग्राहकों से सम्मान भी खोना पड़ता है।

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

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

गिरने और उठने की कहानी

प्रारंभिक अवस्था: अखंड वास्तुकला

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

सच्ची कहानी

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

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

अखंड वास्तुकला शुरू करने के लिए अच्छा है क्योंकि यह सरल है। लेकिन यह उच्च भार को विफलता का एकल बिंदु होने का सामना नहीं कर सकता है।

2017 की शुरुआत में असफल

14 फरवरी वेलेंटाइन डे है । इस छुट्टी को हर कोई पसंद करता है। प्रेमियों को एक-दूसरे को बधाई देने के लिए, 14 फरवरी को हम दिल के आकार में एक विशेष पिज्जा - पेपरोनी बनाते हैं। मुझे 14 फरवरी, 2017 हमेशा के लिए याद होगा, क्योंकि इस दिन, जब सभी पिज़्ज़ेरिया पूरे भार पर काम कर रहे थे, डोडो आईएस गिरने लगा। प्रत्येक पिज़्ज़ेरिया में हमारे पास ट्रैकिंग के लिए 4-5 गोलियां होती हैं, जो पिज्जा बनाने वाले के लिए आटा बनाते हैं, सामग्री डालते हैं, सेंकते हैं या डिलीवरी के लिए भेजते हैं। पिज़्ज़ेरिया की संख्या 300+ तक पहुंच गई, प्रत्येक टैबलेट ने प्रति मिनट कई बार अपनी स्थिति को अपडेट किया। इन सभी अनुरोधों ने डेटाबेस पर इतना भारी भार बनाया कि SQL सर्वर झेलना बंद हो गया और डेटाबेस विफल होने लगा। डोडो आईएस सबसे अनुचित क्षण में - बिक्री के चरम के दौरान नीचे रखा गया है। आगे एक व्यस्त छुट्टी का मौसम था: 23 फरवरी (सेना और नौसेना दिवस), 8 मार्च (अंतर्राष्ट्रीय महिला दिवस), 1 मई (श्रमिकों की अंतर्राष्ट्रीय एकजुटता का दिन) और 9 मई (द्वितीय विश्व युद्ध में विजय दिवस)। इन छुट्टियों के दौरान, हम और भी बड़े ऑर्डर बढ़ने की उम्मीद कर रहे थे।

जिस दिन तुम मर जाओगे । हमारी विकास योजनाओं और उस भार की सीमा को जानकर, जिसका हम सामना कर सकते हैं, हमने यह पता लगाया कि हम कितने समय तक जीवित रह सकते हैं, जब कि आज का शिखर भार नियमित हो जाता है। अगस्त या सितंबर में लगभग छह महीने में आर्मगेडन की अनुमानित तारीख। अपनी मौत की तारीख को जानकर कैसा लगता है?

एक साल के लिए सुविधा विकास बंद करो । सीईओ फेडर के साथ मिलकर हमें एक कठिन निर्णय लेना था। शायद कंपनी के इतिहास में सबसे कठिन फैसलों में से एक। हमने व्यावसायिक सुविधाओं के विकास को रोक दिया। हमने सोचा कि हम 3 महीने के लिए रुक जाएंगे, लेकिन जल्द ही हमें पता चला कि तकनीकी ऋण की मात्रा इतनी अधिक है कि 3 महीने पर्याप्त नहीं होंगे और हमें तकनीकी मुद्दों पर काम करना जारी रखना होगा और व्यवसाय के बैकलॉग को स्थगित करना होगा। वास्तव में, 6 टीमों के साथ हमने अगले वर्ष के दौरान केवल एक ही व्यवसाय सुविधा बनाई है। बाकी समय, टीमें तकनीकी ऋण के पुनर्भुगतान में लगी थीं। इस ऋण ने हमें बहुत खर्च किया - $ 1.5 मिलियन से अधिक।

एक साल बाद कुछ सुधार

वर्ष के दौरान, हमारे पास ये उल्लेखनीय उपलब्धियाँ थीं:

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

हमारे वास्तुकार ने तकनीकी बैकलॉग का प्रबंधन किया। हमने बैकलॉग को चलाने के लिए वास्तु परिवर्तनों का उपयोग किया। प्रत्येक टीम को वह करने की स्वतंत्रता थी जो एक उपयोगी वास्तुकला बनाने के लिए सही थी। 6 वीं टीमों के साथ वर्ष के लिए हमने व्यापार के लिए केवल एक मूल्यवान विशेषता बनाई। बाकी समय, टीमों ने तकनीकी ऋण पर काम किया। ऐसा लगता है कि हम खुद पर गर्व कर सकते हैं। लेकिन हमारे आगे एक बड़ी निराशा थी।

संघीय विपणन अभियान के दौरान विफल। भरोसे का दूसरा संकट।

तकनीकी ऋण जमा करना आसान है, लेकिन चुकाने में बहुत मुश्किल है। यह संभावना नहीं है कि आप पहले से समझ पाएंगे कि यह आपको कितना खर्च करेगा।

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

हमने उस क्षण को याद किया जब व्यवसाय सुविधाओं को विकसित करने की गति को धीमा करना और तकनीकी ऋण से निपटना आवश्यक था। जब हमने गौर किया तो बहुत देर हो चुकी थी। हम फिर से लोड के नीचे लेट गए। सिस्टम क्रैश हो गया और हर 3 घंटे में रिबूट हुआ। हमारे व्यापार ने लाखों रूबल को खो दिया।



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

सबक सीखा

पूर्वव्यापी के बाद, हमने अपनी प्रक्रियाओं को पूरी तरह से पुनर्गठित किया। हमने LeSS ढांचे को लिया और इसे इंजीनियरिंग प्रथाओं के साथ पूरक किया। अगले कुछ महीनों में, हमने इंजीनियरिंग प्रथाओं को अपनाने में सफलता हासिल की। LeSS ढांचे के आधार पर, हमने लागू किया है और इसका उपयोग जारी है:

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

6 प्रथाओं को हमने संकट के बाद चुना है

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

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

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

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


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

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

हमने मैन्युअल प्रतिगमन से छुटकारा पाने के लिए एक लक्ष्य निर्धारित किया है। इस तक पहुंचने में हमें 1.5 साल लगे। लेकिन एक दीर्घकालिक महत्वाकांक्षी लक्ष्य होने से आप लक्ष्य के लिए अग्रणी कदमों के बारे में सोचते हैं।


5. प्रदर्शन परीक्षण प्रतिगमन परीक्षण का हिस्सा है । संकट के दौरान हमने प्रदर्शन परीक्षणों का एक समूह बनाया। यह हमारे लिए बिल्कुल नया क्षेत्र था। फिर भी, केवल 2 सप्ताह में, हम विजुअल स्टूडियो टूल्स का उपयोग करके कुछ प्रदर्शन परीक्षण बनाने में कामयाब रहे। इन परीक्षणों ने न केवल प्रदर्शन में गिरावट को पकड़ने में हमारी मदद की। हमने प्रदर्शन सीमा की पहचान करने के लिए उन्हें उत्पादन सर्वर में सिंथेटिक लोड जोड़ने के लिए उपयोग किया। उदाहरण के लिए, यदि जैविक उत्पादन भार 100 ऑर्डर / मिनट है और हम अपने प्रदर्शन परीक्षणों की सहायता से 50 और ऑर्डर / मिनट जोड़ते हैं, तो हम देख सकते हैं कि क्या उत्पादन सर्वर बढ़े हुए भार को संभाल सकता है। जैसे ही हम अपवादों को देखते हैं या विलंबता को बढ़ाते हैं, हम परीक्षण रोक देते हैं। इन प्रयोगों को बनाते हुए, हमें लगा कि अधिकतम लोड हमारे उत्पादन सर्वर को संभाल सकता है, और हॉटस्पॉट क्या होगा।

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

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



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

आज हमारे पास एक ही बैकलॉग है जिसमें 9 फीचर टीमें काम कर रही हैं। फ़ीचर टीम स्थिर, क्रॉस-फ़ंक्शनल, क्रॉस-घटक टीम हैं। हमारी अधिकांश टीमें फीचर टीमें हैं।

6. इंजीनियरिंग प्रथाओं पर ध्यान दें । हमारी सभी टीम जोड़ी प्रोग्रामिंग का उपयोग करती हैं। मैं जोड़ी प्रोग्रामिंग को सबसे सरल लेकिन शक्तिशाली प्रथाओं में से एक मानता हूं जो अन्य इंजीनियरिंग प्रथाओं को लागू करने में मदद करता है। यदि आप नहीं जानते हैं कि कौन सा इंजीनियरिंग शुरू करने के लिए अभ्यास करता है, तो मैं जोड़ी प्रोग्रामिंग की सलाह देता हूं।

परिणाम

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

व्यापार के लिए परिणाम

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

आज हमारे पास 480 पिज़्ज़ेरिया ऑनलाइन हैं, जिनमें से 400 रूस में हैं। इस साल मई की छुट्टियों के दौरान, फिर से हमारे पिज़्ज़ेरिया में ऑर्डर प्रोसेसिंग के साथ समस्याएं थीं। लेकिन इस बार टोंटी पिज़्ज़ेरिया में ग्राहक सेवा थी। पिज़्ज़ेरिया और आदेशों की बढ़ती संख्या के बावजूद, डोडो आईएस घड़ी की कल की तरह चल रहा था।

टीमों के लिए परिणाम

आज हम इंजीनियरिंग प्रथाओं की एक विस्तृत श्रृंखला का उपयोग करते हैं:

1. पूरी तरह से क्रॉस-फ़ंक्शनल और क्रॉस-घटक फ़ीचर टीमें।
2. जोड़ी प्रोग्रामिंग / मोब प्रोग्रामिंग।
3. वास्तविक निरंतर एकीकरण, जिसका अर्थ है एक ही शाखा में 9 टीमों से कई कोड एकीकरण।
4. ट्रंक-आधारित विकास के साथ सरलीकृत विन्यास प्रबंधन।
5. कई टीमों के लिए सामान्य लक्ष्य।
6. टीम में विषय विशेषज्ञ है।
7. कोई अलग क्यूए टीम नहीं, क्यूए विशेषज्ञ विकास टीमों का हिस्सा हैं।
8. ऑटोटैस्ट्स के साथ अंतिम मैनुअल रिप्लेसमेंट रिप्लेसमेंट।
9. शून्य बग नीति।
10. तकनीकी ऋण बैकलॉग।
11. लाइन को पाइपलाइन के त्वरण के लिए ड्राइवर के रूप में रोकें।

वे एक सामान्य कोड और एक एकल उत्पाद पर काम करने के लिए 9 टीमों की मदद करते हैं जिसमें दर्जनों घटक शामिल हैं - एक मोबाइल और डेस्कटॉप साइट, आईओएस और एंड्रॉइड पर एक मोबाइल ऐप और एक विशाल बैक ऑफिस जिसमें कैश रजिस्टर, ट्रैकिंग, रेस्तरां प्रदर्शन, व्यक्तिगत खाता है , विश्लेषिकी और पूर्वानुमान।

इससे बेहतर क्या हो सकता है

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

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



कुछ टीमों ने सभी 12 XP प्रथाओं का उपयोग करने की इच्छा दिखाई और मुझसे XP कोच और स्क्रैम मास्टर के रूप में मदद मांगी।

जो हमने सीखा

काश मैं संकट न आने देता। एक डेवलपर के रूप में, मुझे बहुत बड़ा तकनीकी ऋण जमा करने और पहले लाल झंडा न उठाने की व्यक्तिगत जिम्मेदारी महसूस हुई:

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

तकनीकी ऋण हमें संकट की ओर ले जाता है। लेकिन संकट से डेवलपर्स और व्यापारी दोनों ने सीखा कि तकनीकी उत्कृष्टता और इंजीनियरिंग प्रथाओं पर ध्यान देना कितना महत्वपूर्ण है। हमने बड़े संगठनात्मक और प्रक्रियाओं में बदलाव के लिए संकट को ट्रिगर के रूप में इस्तेमाल किया।

---

स्वीकृतियाँ

मैं उन सभी लोगों को एक बड़ा धन्यवाद कहना चाहूंगा जिन्होंने संकट से लेकर एलएसएस परिवर्तन तक की मेरी यात्रा में मेरी मदद की। मैं लगातार आपका समर्थन महसूस करता हूं।

विश्वास के लिए हमारे सीईओ, फेडर ओविचनिकोव को बहुत धन्यवाद। आप वास्तविक फुर्तीली संस्कृति के साथ कंपनी के सच्चे नेता हैं।

दिमित्री पावलोव, हमारे उत्पाद मालिक, मेरे पुराने दोस्त और सह-प्रशिक्षक के लिए बहुत धन्यवाद।

मेरी भूमिका में मेरा समर्थन करने के लिए एलेक्स एंड्रोनोव और एंड्री मोरेव्स्की को धन्यवाद।

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

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