हमने एक तकनीकी उत्पाद कैसे बनाया और नीचे तक गिर गया

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

शुरुआत

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

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

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

यहीं से कहानी का सकारात्मक हिस्सा खत्म होता है।

गिरने

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

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

2014 में संकट की दूसरी लहर के साथ, प्रदर्शन प्रति माह 300,000 अद्वितीय आगंतुकों से नीचे गिर गया। इस समय के आसपास, मुझे नौकरी मिल गई।

यहीं से कहानी का मेरा तकनीकी हिस्सा शुरू होता है ।

विसर्जन

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

हमारी तकनीक स्टैक निम्नानुसार थी: एमएस SQL ​​सर्वर 2012 + ASP.NET MVC 3 । आधार ने सब कुछ अपने आप में रखा। यहां तक ​​कि 3 सेट आकार (बड़े, बड़े, छोटे) के लिए द्विआधारी रूप में फोटो।

बैकएंड में कई मॉड्यूल शामिल थे:

• सोम स्थल
• सामान्य व्यवस्थापक क्षेत्र
• एसईओ व्यवस्थापक
• रोबोट पार्सर KLADR
• XML फ़ीड आयात रोबोट

यह सब समय मैं सिर्फ कार्य कर रहा था ताकि कोड काम करे और कोई त्रुटि न हो। विशेष रूप से आगे के विकास के बारे में या सोच के बिना। लेकिन समय आ गया है और यह आवश्यक हो गया है।

काम के दूसरे वर्ष में, मेरे प्रबंधक ने परियोजना छोड़ दी। और मुझे इस प्राचीन उपनिवेश के साथ आमने-सामने छोड़ दिया गया, जिसमें बल द्वारा मेरे कोड का 3% था।

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

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

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

काल्पनिक वृद्धि

इसलिए, अपनी आस्तीन को ऊपर उठाते हुए, मैंने गर्भ धारण करना शुरू किया। मैंने क्लासिक थ्री-टियर आर्किटेक्चर को चुना। .Net कोर + SQL + मैंगो बैकएंड, फ्रंटएंड बूटस्ट्रैप + JQuery + नॉकआउटJS है ।

एक डेटा लेयर का आयोजन किया। इंटरफेस, सार, रिपॉजिटरी सभी सही हैं। परत संग्रहीत प्रक्रियाओं पर काम किया (सौभाग्य से, मैं एसक्यूएल को अच्छी तरह से समझना शुरू कर दिया)। मैपिंग के लिए मैंने डैपर को चुना। यह सरल और सीधा है। कैश को एक अलग सर्वर पर लाने के लिए Redis के पक्ष में InMemoryCache को मना कर दिया। अगला व्यावसायिक तर्क का स्तर था। सभी एक ही इंटरफेस, सेवाओं, डीआई। तो नींव डेटा-लेयर (संग्रहीत कार्यविधियाँ + डैपर + रेडिस) और लॉजिक-लेयर के रूप में दिखाई दी। इसमें लगभग 3 महीने लगे।

और यहाँ, लगभग एक साल के काम के बाद, मैं अकेले ही मेरे लिए एक सहायक प्राप्त करने में कामयाब रहा, और जोर देकर कहा कि बहुत सारे कार्य थे (और उनमें से बहुत सारे थे)। एक साथ, सब कुछ बहुत तेजी से और बेहतर हुआ, और सबसे महत्वपूर्ण बात यह भी कि तर्कसंगत रूप से।

1. सबसे पहले, हमने तस्वीरों के लिए एक एपीआई विकसित किया। यह एक साधारण WebApi था, जो Get-request पर डिस्क से वांछित गुणवत्ता और आकार की तस्वीर देता था। हमने SSD पर स्विच किया और एक बुरे सपने के रूप में छवि डेटाबेस के बारे में भूल गए। यह वर्णन करना मुश्किल है कि इसके लिए एक अलग पूल आवंटित करने के बाद साइट का औसत पृष्ठ कितनी तेजी से लोड करना शुरू कर दिया।
2. हमने FIAD के पक्ष में KLADRA को छोड़ दिया। उन्होंने हमारी सुविधाओं को ध्यान में रखते हुए, हमारे डेटाबेस से FIAS से डेटा पार्स करने के लिए एक उच्च-गुणवत्ता वाली सेवा लिखी। उन्होंने उसे जियोकोडिंग घरों के लिए एक सेवा के लिए खराब कर दिया। सब कुछ लगभग एक घड़ी की तरह काम किया। केवल कभी-कभी FIASA डेटाबेस में डुप्लिकेट स्थानों या सड़कों से जुड़े बग होते थे।
   
3. फिर उन्होंने लंबे समय तक एक नया व्यक्तिगत खाता लिखा, इसे साइट से साझा किया। इसे लंबे समय तक डिजाइन और नियोजित किया गया था ताकि यह उपयोगकर्ता के अनुकूल हो। साथ ही तेज और कार्यात्मक। उन्होंने उसके भुगतान पर शिकंजा कसा और फिर चेक का राजकोषीयकरण (हाँ, हम तैयार एकीकृत समाधानों का उपयोग करने का जोखिम नहीं उठा सकते थे)। कुल मिलाकर एक अच्छी यूजर सर्विस बनी। और वे उससे प्रसन्न थे।
   
4. अंत में, हम XML फ़ीड्स आयात करने के लिए रोबोट के पास पहुंचे। ग्राहकों के लिए एक सुविधाजनक सत्यापनकर्ता और अच्छी लॉगिंग बनाई। नई सेवा इतनी अनुकूलित हो गई कि यदि पुराने (EF का उपयोग करके) ने लगभग 6-8 घंटे काम किया, तो नए ने 2-3 घंटों में समान डेटा संसाधित किया।
   
5. आखिरकार, उन्होंने सब कुछ के लिए प्रलेखन के साथ एक डोमेन उठाया। उन्होंने पोर्टल के उपयोगकर्ताओं और ग्राहकों के लिए सभी बिंदुओं को निर्धारित किया, और साथ ही प्रलेखन का एक हिस्सा बताया जो डेवलपर्स के लिए उपयोगी होगा। और यह वास्तव में महत्वपूर्ण है!
   
6. अंतिम चरण आधार का अनुकूलन करना था। हमने इसे पूरी तरह से काम किया। हमने अनावश्यक सब कुछ साफ कर दिया। उन्होंने 4-5 सेकंड से ~ 300 एमएस तक खोज की गति का त्वरण हासिल किया । उन्होंने सूचकांक बनाए, जटिल प्रश्न लिखे, संकेत का इस्तेमाल किया, और यहां तक ​​कि सांख्यिकीय तालिकाओं के विभाजन भी किए।
   

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

यहां तकनीकी कहानी समाप्त होती है और दुखद उपसंहार शुरू होता है।

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

"यह आवश्यक नहीं है, मैं आपको एक अचल संपत्ति विशेषज्ञ के रूप में बता रहा हूं"

या

"तो कोई नहीं देख रहा है, यह एक कम आवृत्ति वाली क्वेरी है, मुझे यकीन है"

और कुछ समय बाद, जब वह खुद इस पर आया, तो हमारे विचारों को एक दावे के साथ पेश किया गया था, हमने पहले क्यों नहीं कहा, या ईमानदारी से आश्चर्य के साथ

"मैं ऐसा नहीं कह सकता, यह बेतुका है"

हम आम सहमति में नहीं आ सके, जिसके परिणामस्वरूप, हम (डेवलपर्स) बस हीन थे। और उन्होंने अनुरोध के अनुसार किया। प्रोग्रामर का दर्द - किसी को बेकार "सुविधाएँ" बनाने के लिए।



मैं यह उल्लेख करना चाहूंगा कि वित्त में हमेशा समस्याएं रही हैं। एसईओ में सिवाय निवेश के कुछ भी नहीं था । यहां तक ​​कि 2 प्रोग्रामर रखना महंगा था। वित्तपोषण और प्रबंधन के ऐसे स्तर के साथ TOP-10 से नए पोर्टल्स के साथ प्रतिस्पर्धा करना स्पष्ट रूप से असंभव था।

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

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

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