यो वसन्तमा हामीले आफूलाई धेरै रमाइलो अवस्थामा भेट्टायौं। महामारीको कारण, यो स्पष्ट भयो कि हाम्रो गर्मी सम्मेलनहरू अनलाइन सार्न आवश्यक छ। र तिनीहरूलाई कुशलतापूर्वक अनलाइन सञ्चालन गर्नको लागि, तयार-निर्मित सफ्टवेयर समाधानहरू हाम्रो लागि उपयुक्त थिएनन्; हामीले आफ्नै लेख्न आवश्यक थियो। र हामीसँग यो गर्न तीन महिना थियो।

यो स्पष्ट छ कि यो एक रोमाञ्चक तीन महिना भएको छ। तर बाहिरबाट यो पूर्ण रूपमा स्पष्ट छैन: अनलाइन सम्मेलन प्लेटफर्म के हो? यसमा कुन भागहरू समावेश छन्? त्यसकारण, ग्रीष्मकालीन DevOops सम्मेलनहरूको अन्तिममा, मैले यस कार्यको लागि जिम्मेवार व्यक्तिहरूलाई सोधें:

• निकोले मोल्चानोव - JUG Ru समूह को प्राविधिक निर्देशक;
• भ्लादिमिर क्रासिलश्चिक ब्याकइन्डमा काम गर्ने एक व्यावहारिक जाभा प्रोग्रामर हो (तपाईंले हाम्रो जाभा सम्मेलनहरूमा उहाँका रिपोर्टहरू पनि हेर्न सक्नुहुन्छ);
• Artyom Nikonov हाम्रो सबै भिडियो स्ट्रिमिङ को लागी जिम्मेवार छ।

खैर, शरद ऋतु-जाडो सम्मेलनहरूमा हामी एउटै प्लेटफर्मको सुधारिएको संस्करण प्रयोग गर्नेछौं - यति धेरै हाब्रा पाठकहरू अझै पनि यसको प्रयोगकर्ता हुनेछन्।

ठूलो तस्वीर

- टोलीको संरचना के थियो?

निकोले मोल्चानोभ: हामीसँग एक विश्लेषक, एक डिजाइनर, एक परीक्षक, तीन फ्रन्ट-एन्डर, र एक ब्याक-एन्ड छन्। र, निस्सन्देह, एक टी-आकार विशेषज्ञ!

- प्रक्रिया सामान्य रूपमा कस्तो देखिन्थ्यो?

निकोले: मार्चको मध्यसम्म, हामीसँग अनलाइनका लागि कुनै पनि तयारी थिएन। र मार्च 15 मा, सम्पूर्ण अनलाइन क्यारोसेल स्पिन गर्न थाल्यो। हामीले धेरै भण्डारहरू स्थापना गर्यौं, योजना बनायौं, आधारभूत वास्तुकलाको बारेमा छलफल गर्यौं र तीन महिनामा सबै कुरा गर्यौं।

निस्सन्देह, यो योजना, वास्तुकला, सुविधा चयन, ती सुविधाहरूको लागि मतदान, ती सुविधाहरूको लागि नीति, तिनीहरूको डिजाइन, विकास, परीक्षणको क्लासिक चरणहरू पार गर्यो। नतिजाको रूपमा, जुन 6 मा, हामीले उत्पादनमा सबै रोल आउट गर्यौं। TechTrain। त्यहाँ सबै कुराको लागि 90 दिन थियो।

- के हामीले प्रतिबद्धता पूरा गर्न व्यवस्थित गर्यौं?

निकोले: हामी अब DevOops सम्मेलन अनलाइनमा भाग लिइरहेका हुनाले, यसको मतलब यो काम भयो। म व्यक्तिगत रूपमा मुख्य कुरामा प्रतिबद्ध छु: म ग्राहकहरूलाई एउटा उपकरण ल्याउनेछु जसको साथ उनीहरूले अनलाइन सम्मेलन गर्न सक्छन्।

चुनौती यो थियो: हामीलाई एउटा उपकरण दिनुहोस् जसको साथ हामी टिकट धारकहरूलाई हाम्रा सम्मेलनहरू प्रसारण गर्न सक्छौं।

सबै योजनालाई धेरै चरणहरूमा विभाजन गरिएको थियो, र सबै सुविधाहरू (लगभग 30 विश्वव्यापी) 4 कोटिहरूमा विभाजन गरिएको थियो:

• जुन हामी निश्चित रूपमा गर्नेछौं (हामी तिनीहरू बिना बाँच्न सक्दैनौं),
• जुन हामी दोस्रो काम गर्नेछौं,
• जुन हामी कहिल्यै गर्दैनौं,
• र जुन हामी कहिल्यै गर्दैनौं।

हामीले पहिलो दुई श्रेणीबाट सबै सुविधाहरू बनायौं।

— मलाई थाहा छ कुल 600 JIRA मुद्दाहरू सिर्जना गरिएको थियो। तीन महिनामा, तपाईंले 13 माइक्रोसेवाहरू बनाउनुभयो, र मलाई शंका छ कि ती जाभामा मात्र लेखिएका थिएनन्। तपाईंले विभिन्न प्रविधिहरू प्रयोग गर्नुभयो, तपाईंसँग तीन उपलब्धता क्षेत्रहरूमा दुईवटा Kubernetes क्लस्टरहरू छन् र Amazon मा 5 RTMP स्ट्रिमहरू छन्।

अब प्रणालीको प्रत्येक घटकलाई अलग-अलग हेरौं।

स्ट्रिमिङ

- हामीसँग पहिले नै एउटा भिडियो छवि छ, र यो केहि सेवाहरूमा प्रसारित भएको बेला सुरु गरौं। Artyom, हामीलाई भन्नुहोस् यो स्ट्रिमिङ कसरी हुन्छ?

Artyom Nikonov: हाम्रो सामान्य योजना यस्तो देखिन्छ: क्यामेराबाट छवि -> हाम्रो नियन्त्रण कोठा -> स्थानीय RTMP सर्भर -> Amazon -> भिडियो प्लेयर। थप विवरण यसको बारेमा लेखे जुनमा Habré मा।

सामान्यतया, त्यहाँ यो गर्न दुई विश्वव्यापी तरिकाहरू छन्: या त हार्डवेयरमा वा सफ्टवेयर समाधानहरूमा आधारित। हामीले सफ्टवेयर मार्ग रोज्यौं किनभने यो रिमोट स्पिकरहरूको मामलामा सजिलो छ। अर्को देशमा स्पिकरमा हार्डवेयर ल्याउन सधैं सम्भव छैन, तर स्पिकरलाई सफ्टवेयर डेलिभर गर्न सजिलो र अधिक विश्वसनीय देखिन्छ।

हार्डवेयरको दृष्टिकोणबाट, हामीसँग निश्चित संख्यामा क्यामेराहरू छन् (हाम्रो स्टुडियोहरूमा र रिमोट स्पिकरहरूमा), स्टुडियोमा रिमोट कन्ट्रोलहरूको निश्चित संख्या, जुन कहिलेकाँही प्रसारणको क्रममा तालिकामुनि मर्मत गर्नुपर्ने हुन्छ।

यी यन्त्रहरूबाट सिग्नलहरू क्याप्चर कार्डहरू, इनपुट/आउटपुट कार्डहरू, र ध्वनि कार्डहरूका साथ कम्प्युटरहरूमा प्रवेश गर्छन्। त्यहाँ संकेतहरू मिश्रित र लेआउटहरूमा भेला हुन्छन्:

4 स्पिकरहरूको लागि लेआउटको उदाहरण

4 स्पिकरहरूको लागि लेआउटको उदाहरण

यसबाहेक, लगातार प्रसारण तीन कम्प्युटरहरूको मद्दतले प्रदान गरिएको छ: त्यहाँ एउटा मुख्य मेसिन र पालैपालो काम गर्नेहरूको एक जोडी छ। पहिलो कम्प्युटरले पहिलो रिपोर्ट, दोस्रो - ब्रेक, पहिलो - अर्को रिपोर्ट, दोस्रो - अर्को ब्रेक, र यस्तै। र मुख्य मेसिनले पहिलोलाई दोस्रोसँग मिसाउँछ।

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

अर्को, कम्प्युटरबाट स्ट्रिमहरू स्थानीय सर्भरमा जान्छन्, जसमा दुई कार्यहरू छन्: रूट RTMP स्ट्रिमहरू र रेकर्ड ब्याकअपहरू। त्यसैले हामीसँग धेरै रेकर्डिङ बिन्दुहरू छन्। भिडियो स्ट्रिमहरू त्यसपछि Amazon SaaS सेवाहरूमा निर्मित हाम्रो प्रणालीको भागमा पठाइन्छ। हामी प्रयोग गर्छौ MediaLive, S3, क्लाउडफ्रन्ट।

निकोले: भिडियो दर्शकमाझ पुग्नुअघि त्यहाँ के हुन्छ ? तपाईंले यसलाई कुनै न कुनै रूपमा काट्नु पर्छ, हैन?

Artyom: हामी हाम्रो तर्फबाट भिडियो कम्प्रेस गर्छौं र मिडियालाइभमा पठाउँछौं। हामी त्यहाँ ट्रान्सकोडरहरू लन्च गर्छौं। तिनीहरूले भिडियोहरूलाई वास्तविक समयमा धेरै रिजोल्युसनहरूमा ट्रान्सकोड गर्छन् ताकि मानिसहरूले तिनीहरूलाई आफ्नो फोनमा हेर्न सकून्, देशमा कमजोर इन्टरनेट मार्फत, र यस्तै। त्यसपछि यी धाराहरू काटिएका छन् टुक्राहरू, यो प्रोटोकल कसरी काम गर्दछ HLS। हामी फ्रन्टएन्डमा प्लेलिस्ट पठाउँछौं जसमा यी टुक्राहरूमा पोइन्टर्सहरू छन्।

- के हामी 1080p रिजोल्युसन प्रयोग गर्दै हुनुहुन्छ?

Artyom: हाम्रो भिडियोको चौडाइ 1080p - 1920 पिक्सेल जत्तिकै छ, र उचाइ अलि कम छ, तस्विर बढी लम्बिएको छ - यसका कारणहरू छन्।

खेलाडी

— Artyom ले भिडियो कसरी स्ट्रिममा आउँछ, कसरी विभिन्न स्क्रिन रिजोल्युसनका लागि विभिन्न प्लेलिस्टहरूमा वितरण गरिन्छ, टुक्रामा काटेर प्लेयरमा पुग्छ भनेर वर्णन गरेको छ। कोल्या, अब मलाई भन्नुहोस् यो कस्तो खेलाडी हो, यसले कसरी स्ट्रिम खपत गर्छ, किन HLS?

निकोले: हामीसँग एक खेलाडी छ जुन सबै सम्मेलन दर्शकहरूले हेर्न सक्छन्।

अनिवार्य रूपमा, यो पुस्तकालय वरिपरि एक र्‍यापर हो hls.js, जसमा अन्य धेरै खेलाडीहरू लेखिएका छन्। तर हामीलाई धेरै विशिष्ट कार्यक्षमता चाहिन्छ: रिवाइन्ड गर्ने र व्यक्ति कहाँ छ भनेर चिन्ह लगाउने, कुन रिपोर्ट उसले हाल हेरिरहेको छ। हामीलाई हाम्रो आफ्नै लेआउटहरू, सबै प्रकारका लोगोहरू र हामीसँग निर्मित सबै चीजहरू पनि चाहिन्छ। त्यसकारण, हामीले हाम्रो आफ्नै पुस्तकालय (HLS माथि एउटा र्यापर) लेख्ने निर्णय गर्यौं र यसलाई साइटमा इम्बेड गर्यौं।

यो मूल कार्यक्षमता हो, त्यसैले यो लगभग पहिलो लागू गरिएको थियो। र त्यसपछि सबै कुरा यसको वरिपरि बढ्यो।

वास्तवमा, प्राधिकरण मार्फत, खेलाडीले ब्याकएन्डबाट समय र गुणस्तरसँग सम्बन्धित टुक्राहरूको लिङ्कको साथ प्लेलिस्ट प्राप्त गर्दछ, आवश्यक डाउनलोड गर्दछ र प्रयोगकर्तालाई देखाउँछ, बाटोमा केही "जादू" प्रदर्शन गर्दछ।

टाइमलाइन उदाहरण

- सबै रिपोर्टहरूको टाइमलाइन प्रदर्शन गर्न प्लेयरमा एउटा बटन बनाइएको छ...

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

र प्रयोगकर्ताहरूलाई हालको स्ट्रिममा नेभिगेट गर्न र ट्र्याकहरू बीच स्विच गर्न सजिलो बनाउन, हामीले ट्र्याकहरू र रिपोर्टहरू बीच स्विच गर्नको लागि "पूरै प्रसारण" बटन र तेर्सो रिपोर्ट कार्डहरू बनाउने निर्णय गर्यौं। त्यहाँ किबोर्ड नियन्त्रण छ।

- यसमा कुनै प्राविधिक कठिनाइहरू थिए?

निकोले: तिनीहरूसँग एउटा स्क्रोल पट्टी थियो जसमा विभिन्न रिपोर्टहरूको सुरुवात बिन्दुहरू चिन्ह लगाइएको थियो।

— अन्तमा, तपाईंले YouTube ले यस्तै केही गर्नु अघि स्क्रोल पट्टीमा यी चिन्हहरू लागू गर्नुभयो?

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

निकोले: तर हामीले वास्तवमा यसलाई छिटो बिक्री गर्न पायौं। इमानदारीपूर्वक, यो साधारण सुविधा पछाडि खेलाडी भित्र ब्याकएन्ड, फ्रन्टएन्ड, गणना र गणितको ठूलो मात्रा छ।

अगाडिको भाग

— हामीले देखाउने यो सामग्री (स्पीच कार्ड, स्पिकर, वेबसाइट, समयतालिका) अगाडिको छेउमा कसरी पुग्छ भनेर पत्ता लगाउनुहोस्?

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

वक्ताले पाइपलाइनलाई यसरी हेर्छन्

यो प्रणाली हाम्रो आन्तरिक विकास हो।

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

यस्तो देखिन्छ कि साइट केवल एक खेलाडी संग एक पृष्ठ हो, र यहाँ केहि जटिल छैन। बाहेक यो छैन। यस पृष्ठको पछाडिको ब्याकइन्ड कन्टेन्टफुलमा जान्छ, त्यहाँबाट तालिका प्राप्त गर्दछ, केही वस्तुहरू उत्पन्न गर्दछ र यसलाई फ्रन्टएन्डमा पठाउँदछ। वेबसकेट जडान प्रयोग गरेर, जुन हाम्रो प्लेटफर्मको प्रत्येक क्लाइन्टले बनाउँछ, हामी उसलाई ब्याकएन्डबाट फ्रन्टएन्डमा तालिकामा अद्यावधिक पठाउँछौं।

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

निकोले: यहाँ स्पष्ट गर्न महत्त्वपूर्ण छ कि हाम्रो साइट क्लासिक SPA अनुप्रयोग होइन। यो लेआउट-आधारित, रेन्डर गरिएको वेबसाइट र एक SPA दुवै हो। गुगलले वास्तवमा यस साइटलाई रेन्डर गरिएको HTML को रूपमा देख्छ। यो एसईओ को लागी राम्रो छ र प्रयोगकर्तालाई सामग्री डेलिभर गर्न को लागी। यो पृष्ठ हेर्नु अघि 1,5 मेगाबाइटको JavaScript लोड हुनको लागि पर्खदैन, यसले तुरुन्तै पहिले नै रेन्डर गरिएको पृष्ठ देख्छ, र तपाईंले प्रत्येक पटक रिपोर्ट स्विच गर्दा यो महसुस गर्नुहुन्छ। सबै कुरा आधा सेकेन्डमा हुन्छ, किनकि सामग्री पहिले नै तयार छ र सही ठाउँमा पोस्ट गरिएको छ।

- टेक्नोलोजीहरू सूचीबद्ध गरेर माथिका सबै मुनि रेखा कोरौं। ट्योमाले भने कि हामीसँग 5 अमेजन स्ट्रिमहरू छन्, र हामी त्यहाँ भिडियो र ध्वनि प्रदान गर्दछौं। हामीसँग त्यहाँ bash स्क्रिप्टहरू छन्, हामी तिनीहरूलाई सुरुवात र कन्फिगर गर्न प्रयोग गर्छौं ...

Artyom: यो AWS API मार्फत हुन्छ, त्यहाँ धेरै प्राविधिक पक्ष सेवाहरू छन्। हामीले हाम्रो जिम्मेवारी बाँडफाँड गर्यौं ताकि म पूरा गर्न सक्छु क्लाउडफ्रन्ट, र फ्रन्ट-एन्ड र ब्याक-एन्ड विकासकर्ताहरूले यसलाई त्यहाँबाट लिन्छन्। हामीसँग सामग्रीको लेआउटलाई सरल बनाउनका लागि हाम्रा आफ्नै बाइन्डिङहरू छन्, जुन हामी त्यसपछि 4K, इत्यादिमा बनाउँछौं। समयसीमा धेरै कडा भएकोले, हामीले यो लगभग पूर्ण रूपमा AWS मा गर्यौं।

- त्यसपछि यो सबै ब्याकएन्ड प्रणाली प्रयोग गरेर प्लेयरमा जान्छ। हामीसँग हाम्रो प्लेयरमा TypeScript, React, Next.JS छ। र ब्याकएन्डमा हामीसँग C#, Java, Spring Boot र Node.js मा धेरै सेवाहरू छन्। यो सबै Yandex.Cloud पूर्वाधार प्रयोग गरेर Kubernetes प्रयोग गरी तैनात गरिएको छ।

म यो पनि नोट गर्न चाहन्छु कि जब मलाई प्लेटफर्मसँग परिचित हुन आवश्यक थियो, यो सजिलो भयो: सबै भण्डारहरू GitLab मा छन्, सबै कुरा राम्ररी नाम दिइएको छ, परीक्षणहरू लेखिएका छन्, कागजातहरू छन्। त्यो हो, आपतकालीन मोडमा पनि, तिनीहरूले त्यस्ता चीजहरूको हेरचाह गरे।

व्यापार अवरोध र विश्लेषण

— हामीले व्यापार आवश्यकताहरूको आधारमा १०,००० प्रयोगकर्ताहरूलाई लक्षित गरेका छौं। यो हामीसँग भएको व्यापार प्रतिबन्धहरूको बारेमा कुरा गर्ने समय हो। हामीले उच्च कार्यभार सुनिश्चित गर्न, व्यक्तिगत डेटाको संरक्षणमा कानूनको पालना सुनिश्चित गर्नुपर्‍यो। अनि अरू के?

निकोले: सुरुमा, हामीले भिडियो आवश्यकताहरूबाट सुरु गर्यौं। सबैभन्दा महत्त्वपूर्ण कुरा ग्राहकलाई छिटो डेलिभरीको लागि विश्वभर भिडियो भण्डारण वितरण गरिएको छ। अन्यमा 1080p रिजोल्युसन, साथै रिवाइन्ड समावेश छ, जुन अन्य धेरैले लाइभ मोडमा लागू गर्दैनन्। पछि हामीले 2x गति सक्षम गर्ने क्षमता थप्यौं, यसको मद्दतले तपाईंले लाइभसँग "सम्पन्न" र वास्तविक समयमा सम्मेलन हेर्न जारी राख्न सक्नुहुन्छ। र बाटोमा, टाइमलाइन मार्किङ कार्यक्षमता देखा पर्‍यो। साथै, हामीले गल्ती-सहिष्णु हुनुपर्‍यो र 10 जडानहरूको भारको सामना गर्नुपर्‍यो। ब्याकइन्डको दृष्टिकोणबाट, यो लगभग 000 जडानहरू प्रत्येक पृष्ठ रिफ्रेसको लागि 10 अनुरोधहरूद्वारा गुणा गरिएको छ। र यो पहिले नै 000 RPS/सेकेन्ड छ। अलि अलि।

— के त्यहाँ साझेदारहरूको अनलाइन स्ट्यान्डहरूसँग "भर्चुअल प्रदर्शनी" को लागि कुनै अन्य आवश्यकताहरू थिए?

निकोले: हो, यो एकदम चाँडो र विश्वव्यापी रूपमा गर्नुपर्थ्यो। हामीसँग प्रत्येक सम्मेलनको लागि 10 साझेदार कम्पनीहरू थिए, र ती सबै एक वा दुई हप्तामा पूरा गर्नुपर्ने थियो। यद्यपि, तिनीहरूको सामग्री ढाँचामा थोरै फरक छ। तर एउटा निश्चित टेम्प्लेट इन्जिन बनाइएको थियो जसले यी पृष्ठहरूलाई उडानमा जम्मा गर्छ, वस्तुतः कुनै थप विकास सहभागिता बिना।

- त्यहाँ वास्तविक-समय दृश्यहरू र तथ्याङ्कहरूको विश्लेषणका लागि आवश्यकताहरू पनि थिए। मलाई थाहा छ कि हामी यसको लागि प्रोमिथियस प्रयोग गर्छौं, तर हामीलाई थप विवरणमा बताउनुहोस्: हामीले विश्लेषणका लागि के आवश्यकताहरू पूरा गर्छौं, र यो कसरी लागू हुन्छ?

निकोले: प्रारम्भमा, हामीसँग A/B परीक्षणको लागि सङ्कलन गर्न र भविष्यमा ग्राहकलाई राम्रो सामग्री कसरी डेलिभर गर्ने भनेर बुझ्नको लागि जानकारी सङ्कलन गर्न मार्केटिङ आवश्यकताहरू छन्। साझेदार गतिविधिहरू र तपाईंले देख्नुहुने एनालिटिक्स (काउन्टरमा जानुहोस्) मा केही एनालिटिक्सका लागि पनि आवश्यकताहरू छन्। सबै जानकारी वास्तविक समयमा सङ्कलन गरिन्छ।

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

रिपोर्टहरूमा उपस्थितिको ग्राफहरू निर्माण गर्न प्लेटफर्ममा पहिले नै मार्केटिङ उपकरणहरू र वास्तविक समयमा प्रयोगकर्ता गतिविधि (कसले रिपोर्टको कुन सेकेन्ड हेर्यो) मापन गर्नका लागि हाम्रो मेट्रिक्सहरू छन्। यस तथ्याङ्कको आधारमा, अनुसन्धान भइरहेको छ जसले आगामी सम्मेलनहरू अझ राम्रो बनाउनेछ।

धोखाधडी

- के हामीसँग ठगी विरोधी संयन्त्र छ?

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

भ्लादिमिर: यसको क्रेडिटमा, प्रतिबन्धित प्रयोगकर्ताहरू मध्ये एकले यो किन भयो भनेर बुझे। उनी आए, माफी मागे र टिकट किन्न वाचा गरे।

- यो सबै हुनको लागि, तपाईंले सबै प्रयोगकर्ताहरूलाई प्रवेशबाट बाहिर निस्कनका लागि पूर्ण रूपमा ट्रेस गर्नुपर्छ, सधैं तिनीहरू के गर्दैछन् भनेर थाहा पाउनुहोस्। यो प्रणालीले कसरी काम गर्छ?

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

समान जानकारी भण्डारण गरिएको छ मोन्गो र हाम्रो डेटा तालमा जान्छ, जहाँबाट हामीसँग थप रोचक ग्राफ निर्माण गर्ने अवसर छ। प्रश्न उठ्छ: कति अद्वितीय प्रयोगकर्ताहरूले यो रिपोर्ट हेर्नुभयो? हामी जान्छौं पोस्टग्रेस, यस रिपोर्टको आईडीबाट आएका सबै व्यक्तिहरूको पिंगहरू छन्। हामीले सङ्कलन गर्‍यौं, अद्वितीयहरू एकत्रित गर्‍यौं, र अब हामी बुझ्न सक्छौं।

निकोले: तर एकै समयमा, हामीले प्रोमेथियसबाट वास्तविक-समय डाटा पनि प्राप्त गर्दछौं। यो सबै Kubernetes सेवाहरू, Kubernetes को विरुद्धमा सेट गरिएको छ। यसले बिल्कुल सबै कुरा सङ्कलन गर्दछ, र Grafana को साथ हामी वास्तविक समयमा कुनै पनि ग्राफहरू निर्माण गर्न सक्छौं।

भ्लादिमिर: एकातिर, हामी यसलाई थप OLAP प्रशोधनको लागि डाउनलोड गर्छौं। र OLTP को लागि, अनुप्रयोगले प्रोमिथियस, ग्राफाना र ग्राफहरू पनि कन्भर्जमा सम्पूर्ण कुरा डाउनलोड गर्दछ!

- ग्राफहरू कन्भर्ज हुँदा यो मामला हो।

गतिशील परिवर्तनहरू

— हामीलाई बताउनुहोस् कि कसरी गतिशील परिवर्तनहरू रोल आउट हुन्छन्: यदि रिपोर्ट सुरु हुनुभन्दा 6 मिनेट अघि रद्द गरियो भने, कार्यहरूको श्रृंखला के हो? कुन पाइपलाइन काम गर्छ?

भ्लादिमिर: पाइपलाइन धेरै सशर्त छ। त्यहाँ धेरै सम्भावनाहरू छन्। पहिलो हो कि तालिका उत्पादन कार्यक्रमले काम गर्यो र तालिका परिवर्तन गर्यो। परिमार्जित तालिका सामग्रीपूर्ण मा अपलोड गरिएको छ। जस पछि ब्याकइन्डले कन्टेन्टफुलमा यस सम्मेलनको लागि परिवर्तनहरू छन् भनी बुझ्छ, यसलाई लिन्छ र यसलाई पुन: निर्माण गर्दछ। सबै संकलन गरी वेबसकेट मार्फत पठाइन्छ।

दोस्रो सम्भावना, जब सबै कुरा डरलाग्दो गतिमा हुन्छ: सम्पादकले कन्टेन्टफुल (टेलीग्राममा लिङ्क, स्पिकरको प्रस्तुति, आदि) मा जानकारी म्यानुअल रूपमा परिवर्तन गर्दछ र उही तर्कले पहिलो पटकको रूपमा काम गर्दछ।

निकोले: पृष्ठ ताजा नगरी सबै कुरा हुन्छ। सबै परिवर्तनहरू ग्राहकको लागि बिल्कुल निर्बाध रूपमा हुन्छन्। रिपोर्टहरू स्विच गर्नका लागि पनि त्यस्तै हुन्छ। जब समय आउँछ, रिपोर्ट र इन्टरफेस परिवर्तन।

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

परिनियोजन

- म तैनाती बारे सोध्न चाहन्छु। कोल्या र टोलीले सम्पूर्ण पूर्वाधार सेटअप गर्न सुरुमा धेरै समय बिताए जसमा हाम्रो लागि सबै कुरा खुल्छ। मलाई भन्नुहोस्, यो सबै के बनेको हो?

निकोले: प्राविधिक दृष्टिकोणबाट, हामीले प्रारम्भमा उत्पादनको लागि कुनै पनि विक्रेताबाट सम्भव भएसम्म अमूर्त हुन आवश्यक थियो। टेराफर्म स्क्रिप्टहरू बनाउनको लागि AWS मा आउनुहोस् विशेष रूपमा AWS बाट, वा विशेष गरी Yandex बाट, वा Azure, आदि बाट। वास्तवमा फिट भएन। कुनै न कुनै बेला कतै सर्नु पर्थ्यो ।

पहिलो तीन हप्ताको लागि हामीले यसलाई अझ राम्रो गर्ने तरिका खोजिरहेका थियौं। नतिजाको रूपमा, हामी यो निष्कर्षमा पुग्यौं कि यस मामलामा Kubernetes हाम्रो सबै कुरा हो, किनभने यसले हामीलाई स्वचालित-स्केलिंग सेवाहरू, स्वत-रोलआउट, र लगभग सबै सेवाहरू बक्सबाट बाहिर निकाल्न अनुमति दिन्छ। स्वाभाविक रूपमा, सबै सेवाहरू Kubernetes, Docker सँग काम गर्न प्रशिक्षित हुनुपर्थ्यो र टोलीले पनि सिक्नुपर्‍यो।

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

हामीले चाँडै (१० मिनेट भित्र ब्याकइन्डको लागि, ५ मिनेट भित्र फ्रन्टएन्डको लागि) सबै परीक्षणहरू, एकीकरणहरू, चलिरहेको कार्यात्मक परीक्षणहरू, वातावरणमा एकीकरण परीक्षणहरू, र लोड परीक्षणहरू सहित कुनै पनि वातावरणमा परिवर्तनहरू रोल आउट गर्ने अवसर पाउँछौं। एक परिक्षण वातावरण लगभग उस्तै कुरा हो जुन हामी उत्पादन मा प्राप्त गर्न चाहन्छौं।

परीक्षण बारे

- तपाईले लगभग सबै कुराको परीक्षण गर्नुहुन्छ, तपाईले सबै कुरा कसरी लेख्नुभयो भनेर विश्वास गर्न गाह्रो छ। के तपाइँ हामीलाई ब्याकएन्ड परीक्षणहरूको बारेमा बताउन सक्नुहुन्छ: सबै कुरा कति कभर गरिएको छ, कुन परीक्षणहरू?

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

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

यस समयमा मसँग बोर्डमा लगभग 70 घटक परीक्षणहरू र लगभग 40 एकीकरण परीक्षणहरू छन्। कभरेज 95% को धेरै नजिक छ। यो कम्पोनेन्टका लागि हो, एकीकरणका लागि कम, त्यहाँ यति धेरै आवश्यक छैन। यो परियोजनाले सबै प्रकारका कोड उत्पादनहरू समावेश गर्दछ भन्ने कुरालाई ध्यानमा राख्दै, यो धेरै राम्रो सूचक हो। हामीले तीन महिनामा जे गर्यौं, त्यो गर्नुको विकल्प थिएन। किनभने यदि हामीले म्यानुअल रूपमा परीक्षण गर्‍यौं, हाम्रो परीक्षकलाई सुविधाहरू दिँदै, र उसले त्रुटिहरू फेला पार्छ र तिनीहरूलाई समाधानको लागि हामीलाई फिर्ता गर्छ, तब कोड डिबग गर्नको लागि यो राउन्ड ट्रिप धेरै लामो हुनेछ, र हामीले कुनै समयसीमा पूरा गर्ने छैनौं।

निकोले: परम्परागत रूपमा, कुनै प्रकार्य परिवर्तन गर्दा सम्पूर्ण प्लेटफर्ममा प्रतिगमन गर्न, तपाईंले दुई दिनको लागि जताततै बसेर पोक गर्न आवश्यक छ।

भ्लादिमिर: तसर्थ, यो एक ठूलो सफलता हो कि जब मैले एक सुविधा अनुमान गर्छु, म भन्छु कि मलाई दुई सरल कलम र 4 वेबसकेटको लागि 1 दिन चाहिन्छ, कोल्याले अनुमति दिन्छ। उहाँ पहिले नै यस तथ्यको अभ्यस्त हुनुहुन्छ कि यी 4 दिनहरूमा 2 प्रकारका परीक्षणहरू समावेश छन्, र त्यसपछि, सम्भवतः, यसले काम गर्नेछ।

निकोले: मसँग पनि 140 परीक्षणहरू लेखिएका छन्: घटक + कार्यात्मक, जसले समान काम गर्दछ। सबै समान परिदृश्यहरू उत्पादनमा, परीक्षणमा र उत्पादनमा परीक्षण गरिन्छ। हामीले हालसालै कार्यात्मक आधारभूत UI परीक्षणहरू पनि थपेका छौं। यस तरिकाले हामी सबैभन्दा आधारभूत कार्यक्षमता कभर गर्छौं जुन अलग हुन सक्छ।

भ्लादिमिर: निस्सन्देह, यो लोड परीक्षणको बारेमा कुरा गर्न लायक छ। सबै कुरा कस्तो छ, खरगोशसँग के भइरहेको छ, JVMs सँग के भइरहेको छ, वास्तवमा कति मेमोरी आवश्यक छ भनेर बुझ्नको लागि यो प्लेटफर्मलाई वास्तविकको नजिक लोड अन्तर्गत परीक्षण गर्न आवश्यक थियो।

- मलाई पक्का थाहा छैन कि हामीले स्ट्रिम साइडमा केहि परीक्षण गर्दैछौं, तर मलाई याद छ कि हामीले भेटघाट गर्दा ट्रान्सकोडरहरूमा समस्याहरू थिए। के हामीले स्ट्रिमहरू परीक्षण गरेका छौं?

Artyom: पुनरावृत्ति परीक्षण गरियो। भेटघाट आयोजना गर्ने । बैठकहरू आयोजना गर्ने क्रममा, लगभग 2300 JIRA टिकटहरू थिए। यी केवल सामान्य चीजहरू हुन् जुन मानिसहरूले भेटघाट गर्न गरे। हामीले प्लेटफर्मका केही भागहरू बैठकहरूका लागि छुट्टै पृष्ठमा लिएका छौं, जुन किरिल टोल्काचेभ (talkkv).

इमानदार हुन, त्यहाँ कुनै ठूलो समस्या थिएन। शाब्दिक रूपमा हामीले CloudFront मा क्यासिङ बगहरू समात्यौं, हामीले यसलाई चाँडै हल गर्यौं - हामीले केवल नीतिहरू पुन: कन्फिगर गर्यौं। साइटमा स्ट्रिमिङ प्रणालीहरूमा मानिसहरूमा उल्लेखनीय रूपमा धेरै बगहरू थिए।

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

उपकरण

- मलाई याद छ कि कसरी सम्मेलन सुरु हुनु अघि हामीले आंशिक रूपमा अतिरिक्त उपकरणहरू किनेका थियौं।

Artyom: हामीले कम्प्युटर, ल्यापटप र ब्याट्री प्याकहरू किन्यौं। अहिले हामी बिजुली बिना ४० मिनेट बाँच्न सक्छौं। जुनमा सेन्ट पिटर्सबर्गमा ठूलो आँधीबेहरी थियो - त्यसैले हामीले यस्तो ब्ल्याकआउट गरेका थियौं। एकै समयमा, धेरै प्रदायकहरू विभिन्न बिन्दुहरूबाट अप्टिकल लिङ्कहरू लिएर हामीकहाँ आउँछन्। यो वास्तवमै ४० मिनेट बिल्डिङ डाउनटाइम हो, जसमा हामीसँग बत्तीहरू, ध्वनि, क्यामेराहरू, आदि काम हुनेछन्।

- हामीसँग इन्टरनेटको साथ यस्तै कथा छ। हाम्रो स्टुडियो रहेको अफिसमा हामीले भुइँको बिचमा कडा जाल तानेका थियौं।

Artyom: हामीसँग भुइँहरू बीचमा 20 Gbit फाइबर छ। भुइँहरूसँगै, कतै अप्टिक्स छ, कतै अप्टिक्स छैन, तर अझै पनि गिगाबिटहरू भन्दा कम च्यानलहरू छन् - हामी सम्मेलनको ट्र्याकहरू बीचमा तिनीहरूमा भिडियो चलाउँछौं। सामान्यतया, तपाईंको आफ्नै पूर्वाधारमा काम गर्न धेरै सुविधाजनक छ; तपाईंले साइटहरूमा अफलाइन सम्मेलनहरूमा यो विरलै गर्न सक्नुहुन्छ।

— मैले JUG Ru समूहमा काम गर्नु अघि, मैले कसरी अफलाइन सम्मेलनहरूमा हार्डवेयर कोठाहरू रातारात सेटअप गरिएको देखेँ, जहाँ तपाईंले Grafana मा निर्माण गर्नुहुने सबै मेट्रिकहरूसहितको ठूलो मनिटर थियो। अब त्यहाँ एक मुख्यालय कोठा पनि छ जसमा विकास टोली बस्छ, जसले सम्मेलनको समयमा केही बगहरू समाधान गर्दछ र सुविधाहरू विकास गर्दछ। एकै समयमा, त्यहाँ एक निगरानी प्रणाली छ जुन ठूलो स्क्रिनमा प्रदर्शित हुन्छ। Artyom, Kolya र अन्य केटाहरू बस्छन् र निश्चित गर्नुहोस् कि यो सबै खस्दैन र राम्रोसँग काम गर्दछ।

जिज्ञासा र समस्याहरू

— तपाईले यस तथ्यको बारेमा राम्रोसँग कुरा गर्नुभयो कि हामीसँग Amazon सँग स्ट्रिमिङ छ, त्यहाँ वेबसँग एक प्लेयर छ, सबै कुरा विभिन्न प्रोग्रामिङ भाषाहरूमा लेखिएको छ, गल्ती सहिष्णुता र अन्य व्यावसायिक आवश्यकताहरू प्रदान गरिएको छ, एक व्यक्तिगत खाता सहित जुन कानूनी संस्थाहरूको लागि समर्थित छ र। व्यक्तिहरू, र हामी OAuth 2.0 प्रयोग गरेर कसैसँग एकीकृत गर्न सक्छौं, त्यहाँ एन्टी-फ्राड, प्रयोगकर्ता ब्लकिङ छ। हामी परिवर्तनहरू गतिशील रूपमा रोल आउट गर्न सक्छौं किनभने हामीले यो राम्रो गर्यौं, र यो सबै परीक्षण गरिएको छ।

म जान्न इच्छुक छु कि केहि सुरु गर्नमा के विचित्रताहरू समावेश थिए। के त्यहाँ कुनै अनौठो परिस्थितिहरू छन् जब तपाइँ ब्याकएन्ड, फ्रन्टएन्ड विकास गर्दै हुनुहुन्छ, केहि पागल भयो र तपाइँ यसलाई के गर्ने भनेर बुझ्नुभएको छैन?

भ्लादिमिर: मलाई लाग्छ यो विगत तीन महिनाको लागि मात्र भएको हो। हरेक दिन। तपाईं देख्न सक्नुहुन्छ, मेरो सबै कपाल बाहिर तानिएको छ।

Vladimir Krasilshchik 3 महिना पछि, जब केहि प्रकारको खेल बाहिर आयो र कसैले यसलाई के गर्ने भनेर बुझेन

हरेक दिन केहि यस्तो हुन्थ्यो, जब यस्तो पल आउथ्यो जब तपाईले यसलाई लिनुहुन्छ र आफ्नो कपाल च्यात्नु हुन्छ, वा महसुस गर्नुहुन्छ कि त्यहाँ कोही छैन, र तपाईले मात्र गर्न सक्नुहुन्छ। हाम्रो पहिलो ठूलो कार्यक्रम TechTrain थियो। जुन ६ मा दिउँसो २ बजे हामीले उत्पादनको वातावरण तयार पारेका थिएनौं, कोल्याले रोल आउट गर्दै थिए। र व्यक्तिगत खाताले OAuth6 प्रयोग गरेर प्राधिकरण सर्भरको रूपमा काम गरेन। प्लेटफर्मलाई यसमा जडान गर्न हामीले यसलाई OAuth2 प्रदायकमा परिणत गर्यौं। म सायद 2.0 घण्टा सीधा काम गरिरहेको थिएँ, मैले कम्प्युटरमा हेरेँ र केहि पनि देखिन, मैले किन काम गरिरहेको छैन भनेर बुझिन, र कोल्याले टाढाबाट मेरो कोड हेरे, वसन्त कन्फिगरेसनमा बग खोजे। , यो फेला पर्यो, र LC ले काम गर्यो, र उत्पादनमा पनि।

निकोले: र TechTrain रिलिज हुनु अघि एक घण्टा भयो।

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

प्रदर्शनको बारेमा

- के तपाइँ मलाई बताउन सक्नुहुन्छ कि एकै ट्र्याकमा साइटमा कति व्यक्ति थिए? त्यहाँ कुनै प्रदर्शन समस्याहरू थिए?

निकोले: त्यहाँ कुनै प्रदर्शन समस्याहरू थिएनन्, हामीले पहिले नै भनेका छौं। एक रिपोर्टमा उपस्थित भएका व्यक्तिहरूको अधिकतम संख्या 1300 मानिसहरू थियो, यो हाइजेनबगमा छ।

- स्थानीय अवलोकन संग कुनै समस्या थियो? र यो सबै कसरी काम गर्दछ को रेखाचित्र संग एक प्राविधिक विवरण हुन सम्भव छ?

निकोले: हामी पछि यस बारे एक लेख बनाउनेछौं।

तपाईं स्थानीय रूपमा स्ट्रिमहरू डिबग गर्न सक्नुहुन्छ। एक पटक सम्मेलनहरू सुरु भएपछि, यो अझ सजिलो भयो, किनभने उत्पादन स्ट्रिमहरू देखा पर्यो कि हामी सबै समय हेर्न सक्छौं।

भ्लादिमिर: मैले यो बुझेको रूपमा, फ्रन्ट-एन्ड विकासकर्ताहरूले स्थानीय रूपमा नक्कलहरूका साथ काम गरे, र त्यसपछि, अगाडिको डेभहरूमा रोल आउट गर्ने समय पनि छोटो छ (5 मिनेट), प्रमाणपत्रहरूसँग के भइरहेको छ भनेर जाँच गर्न कुनै समस्या छैन।

- सबै स्थानीय रूपमा पनि परीक्षण र डिबग गरिएको छ। यसको मतलब हामी सबै प्राविधिक सुविधाहरू सहितको एउटा लेख लेख्नेछौं, तपाईंलाई देखाउनेछौं, रेखाचित्रसहित सबै कुरा बताउनेछौं, यो कस्तो थियो।

भ्लादिमिर: तपाईं यसलाई लिन र यसलाई दोहोर्याउन सक्नुहुन्छ।

- 3 महिनामा।

परिणाम

— सँगै वर्णन गरिएको सबै कुरा राम्रो लाग्छ, यो तीन महिनामा एउटा सानो टोलीले गरेको हो भनेर विचार गर्दै।

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

- ग्रीष्मकालीन सम्मेलनहरू भइसकेका बेला तपाईंको थप कार्यहरूको सूचीमा के थियो?

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

र सम्पूर्ण प्लेटफर्ममा थप्दै, स्ट्रिमिङ र सम्मेलन बाहेक, एक पोस्ट-कन्फ्रेन्स राज्य पनि। यी प्लेलिस्टहरू हुन् (प्रयोगकर्ताहरूद्वारा संकलित गरिएका सहित), सम्भवतः अन्य विगतका सम्मेलनहरूबाट सामग्री, एकीकृत, लेबल गरिएको, प्रयोगकर्ताको लागि पहुँचयोग्य, र हाम्रो वेबसाइटमा हेर्नको लागि पनि उपलब्ध छ।live.jugru.org).

- साथीहरू, तपाइँको जवाफ को लागी धेरै धेरै धन्यवाद!

यदि पाठकहरू माझ हाम्रो ग्रीष्मकालीन सम्मेलनहरूमा भाग लिनेहरू छन् भने, कृपया खेलाडी र प्रसारणको आफ्नो प्रभाव साझा गर्नुहोस्। के सुविधाजनक थियो, तपाईंलाई के रिस उठ्यो, तपाईं भविष्यमा के हेर्न चाहनुहुन्छ?

यदि तपाइँ प्लेटफर्ममा रुचि राख्नुहुन्छ र यसलाई "लडाईमा" हेर्न चाहनुहुन्छ भने, हामी यसलाई हाम्रो मा फेरि प्रयोग गर्छौं शरद ऋतु-जाडो सम्मेलनहरू। त्यहाँ तिनीहरूको सम्पूर्ण दायरा छन्, त्यसैले त्यहाँ लगभग निश्चित रूपमा तपाईंको लागि सही छ।

स्रोत: www.habr.com