एक विशेषता के रूप में विश्लेषिकी: Plesk में डेटा के साथ काम करने की प्रक्रिया

सभी को नमस्कार, हमने हाल ही में लिखा है कि हमने GoP Practice Simulator के साथ डेटा चालित होना सीखा! इस अंक में हम डेटा विश्लेषण के विषय को जारी रखेंगे और Plesk टीम में एनालिटिक्स के साथ काम करने की प्रक्रिया के निर्माण के बारे में बात करेंगे।

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

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


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

1. कई घटनाओं, उपयोग की उच्च मात्रा। यदि हम केवल अपने अनुमानों के अनुसार, पैनल में उपयोगकर्ता क्रियाओं को ट्रैक करने के बारे में बात करते हैं, तो यह प्रति माह 60 मीटर की घटना है, और यह उन्नत Google विश्लेषिकी के लिए $ 150k देने के लिए एक दया है। एक और कठिनाई यह है कि जीए के साथ काम करने के लिए, आपको प्रत्येक कस्टम क्रिया को स्पष्ट रूप से संभालने की आवश्यकता है, लेकिन हम एक एकीकृत तंत्र प्राप्त करना चाहते थे जिसमें प्रत्येक नई सुविधा के लिए घटनाओं या कार्यों को मैन्युअल रूप से चिह्नित करने की आवश्यकता नहीं होती है।
2. बॉक्स के आयतन और प्रारूप के कारण (किसी भी परिवर्तन में समय लगता है), विश्लेषिकी वास्तविक समय में नहीं कर सकते हैं। उपयोगकर्ता उत्पाद के 8 विभिन्न संस्करणों पर बैठे हैं, जिनमें से 4 पहले से ही ईओएलईडी हैं। नवीनतम संस्करणों पर भी, केवल 60% उपयोगकर्ता रिलीज़ होने के बाद पहले दो हफ्तों में नए बदलावों में आते हैं।
   
3. जटिल उत्पाद। Plesk लिनक्स परिवार के 14 ऑपरेटिंग सिस्टम, 4 OC विंडोज, एक 150 3-पार्टी घटक, कई वेब सर्वर, मेल सर्वर, वेबमेल क्लाइंट, सांख्यिकी विज़ुअलाइज़र, एंटीवायरस समाधान, आदि का समर्थन करता है। संभावित कॉन्फ़िगरेशन की एक बड़ी संख्या मुख्य रूप से परीक्षण की जटिलता और मात्रा को प्रभावित करती है और ए / बी परीक्षणों का उपयोग करना लगभग असंभव बना देती है।
   
4. बी 2 बी की विशिष्टताएं। निर्णय निर्माता हमेशा "पैनल के वास्तविक उपयोगकर्ता" के बराबर नहीं होता है।
   
5. जीडीपीआर - कानून के पत्र का अनुपालन करने की आवश्यकता को डेटा का अनावरण करने के लिए अतिरिक्त प्रयासों की आवश्यकता होती है और उपयोगकर्ता विभाजन के कार्यों को जटिल बनाता है, और हमें अपनी संपर्क जानकारी का उपयोग करके आसानी से और जल्दी से संपर्क करने की क्षमता से भी वंचित करता है।
   

हम प्रक्रिया के दर्द के बारे में अधिक विस्तार से बात करेंगे। हाल तक तक, हमारे साथ एनालिटिक्स इकट्ठा करने की प्रक्रिया पूरी तरह से विकास की प्रक्रिया से तलाकशुदा थी - हमने अंत में ट्रैकिंग और मेट्रिक्स को याद किया, एक बार के समाधान को खराब कर दिया, और इसी तरह अगले फीचर तक। इसके अलावा, पिछले कुछ वर्षों में, Plesk ने डेटा स्रोतों का एक समूह जमा किया है - जिसने डेटा की स्थिरता, प्रासंगिकता बनाए रखने की लागतों को ध्यान में रखा है, यह ध्यान में रखने की आवश्यकता है कि यह कहाँ से आता है, किन परिस्थितियों में यह डेटाबेस को प्राप्त होता है और विभिन्न स्थानों में एक ही मेट्रिक्स क्यों होता है। भिन्न (उदाहरण के लिए, लाइसेंस कुंजी और भौतिक प्रतिष्ठानों की संख्या)। इन स्रोतों के बारे में बहुत सी जानकारी लिखी गई थी (270 हजार कुंजी के डेटाबेस से मासिक कटौती और 300 हजार सर्वर से दो बार आने वाली रिपोर्ट), लेकिन केवल कुछ लोग इस डेटा के साथ काम करने में सक्षम थे और समय मिला। मैं 2015 में Plesk में आया था, और मेरे पहले कार्य OLAP क्यूब और MongoDB डेटाबेस से विषम आंकड़े प्राप्त करने के लिए थे। इस डेटाबेस में 'हाउ टू' एक पेज था, जिसमें होस्ट से यूजरनेम और पासवर्ड और अंतिम लोकप्रिय अनुरोध से जेएस स्क्रिप्ट के साथ एक टेक्स्ट फाइल थी।

स्रोतों के एक समूह का अर्थ था उपकरण और सेवाओं का एक समूह, जिनमें से प्रत्येक को प्रत्येक प्रोग्राम मैनेजर को उपयोग करने में सक्षम होना चाहिए। काम के शुरुआती दिनों में भावना कुछ इस तरह थी:



हमने क्या किया है?

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

परिकल्पना

यह सब सुविधा योजना चरण में शुरू होता है: पीएम एक परिकल्पना तैयार करता है जिसके आधार पर अगले चरण में मीट्रिक का चयन किया जाएगा। उदाहरण के लिए: Plesk में एक सलाहकार सिफारिश प्रणाली है जो प्रस्तावित चरणों का पालन करके उपयोगकर्ता को सर्वर की स्थिति में सुधार करने में मदद करती है (एक ssl प्रमाणपत्र जोड़ें, अपडेट सक्षम करें, PHP संस्करण अपडेट करें, आदि)। सलाहकार जारी करने से, हम मानते हैं कि उपयोगकर्ता सिफारिशों का पालन करेंगे, सर्वर की "स्वास्थ्य" रेटिंग बढ़ेगी, और "उपलब्धियों" के लिए धन्यवाद, उपयोगकर्ता चल रहे आधार पर सलाहकार के साथ बातचीत में शामिल होगा।

मीट्रिक

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

कार्यान्वयन

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

परीक्षण और पूर्वावलोकन

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

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

सुविधा जीवन

जब एक रिलीज़ में एक फीचर लॉन्च किया जाता है, तो सबसे दिलचस्प हिस्सा शुरू होता है - उत्पाद में इसका "जीवन"। कोई और अधिक फेंकना: “क्या आपको पता है कि हमारे डेटाबेस में कौन सी फ़ील्ड अनुशंसाएँ दिखाने के बारे में जानकारी संग्रहीत करती है? नहीं? ब्लिन ... ”। डेटा विश्लेषक को सुस्त में संदेश प्राप्त नहीं होता है: "क्या आप फिर से गिन सकते हैं कि नवीनतम संस्करण में कितने इंप्रेशन हैं?" - इसके लिए कॉन्फ़िगर किए गए अलर्ट के साथ डैशबोर्ड पर चार्ट हैं जो कि पत्र भेजते हैं अगर मॉनिटर किए गए मान में तेजी से गिरावट आई है / बढ़ी / बदली गई है / डेटाबेस में कोई रिकॉर्ड नहीं मिला। लेकिन यह सब नहीं है। यह समझना कि काउंटर बढ़ गया है या n% से गिर गया है हमेशा विश्वास के साथ कहने के लिए पर्याप्त नहीं है कि यह एक महत्वपूर्ण बदलाव है, और त्रुटि के मार्जिन के भीतर मौसमी कूद या उतार-चढ़ाव नहीं है। हमारी टीम का एक सदस्य मीट्रिक परिवर्तनों के सांख्यिकीय महत्व को मापने के लिए एक रूपरेखा विकसित कर रहा है। गणितीय आँकड़ों के उपकरण का उपयोग करते हुए, वह परिवर्तनों के महत्व का आकलन करने के लिए आवश्यक न्यूनतम नमूने (उपयोगकर्ताओं / प्रतिष्ठानों / घटनाओं की संख्या) की गणना करता है, उन खंडों का चयन करता है जिनके बीच आप तुलना कर सकते हैं और विश्वास अंतराल निर्धारित कर सकते हैं जिसमें सबसे अधिक संभावना हमारे लिए ब्याज के मीट्रिक का वास्तविक मूल्य है। इस ढांचे का परीक्षण पहले ही किया गया था और पिछले सप्ताह ही दिलचस्प परिणाम दिए गए थे: हमने पाया कि जब हमने Plesk पैनल के अंदर विस्तार सूची में कीमतें दिखाना शुरू किया, तो लोगों ने इन उत्पादों के लिए कम वार्षिक और अधिक बार मासिक लाइसेंस कुंजी खरीदना शुरू कर दिया। अभी, हमारे सहयोगी एलटीवी पूर्वानुमान की गणना कर रहे हैं, जिसके बाद यह स्पष्ट हो जाएगा कि ये परिवर्तन लंबे समय में हमारे लिए हैं और कीमतों को दिखाने के तर्क में हमें किस विकल्प को बढ़ावा देना चाहिए।

समर्थन की समाप्ति

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

निष्कर्ष

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



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