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

यह स्पष्ट है कि ये तीन महीने रोमांचक रहे हैं। लेकिन बाहर से यह पूरी तरह से स्पष्ट नहीं है: एक ऑनलाइन सम्मेलन मंच क्या है? इसमें कौन से भाग शामिल हैं? इसलिए, ग्रीष्मकालीन DevOops सम्मेलन के आखिरी में, मैंने उन लोगों से पूछा जो इस कार्य के लिए जिम्मेदार थे:

• निकोले मोलचानोव - JUG Ru Group के तकनीकी निदेशक;
• व्लादिमीर क्रासिल्शचिक एक व्यावहारिक जावा प्रोग्रामर है जो बैकएंड पर काम करता है (आप उसकी रिपोर्ट हमारे जावा सम्मेलनों में भी देख सकते हैं);
• अर्टिओम निकोनोव हमारी सभी वीडियो स्ट्रीमिंग के लिए जिम्मेदार है।

वैसे, शरद ऋतु-सर्दियों के सम्मेलनों में हम उसी मंच के एक उन्नत संस्करण का उपयोग करेंगे - इतने सारे हाबरा पाठक अभी भी इसके उपयोगकर्ता होंगे।

कुल मिलाकर तस्वीर

- टीम की संरचना क्या थी?

निकोले मोलचानोव: हमारे पास एक विश्लेषक, एक डिज़ाइनर, एक परीक्षक, तीन फ्रंट-एंडर और एक बैक-एंड है। और, निःसंदेह, एक टी-आकार का विशेषज्ञ!

- सामान्य तौर पर यह प्रक्रिया कैसी दिखती थी?

निकोलाई: मार्च के मध्य तक, हमारे पास ऑनलाइन के लिए कुछ भी तैयार नहीं था। और 15 मार्च को पूरा ऑनलाइन हिंडोला घूमना शुरू हो गया। हमने कई रिपॉजिटरी स्थापित कीं, योजना बनाई, बुनियादी वास्तुकला पर चर्चा की और तीन महीनों में सब कुछ किया।

यह, निश्चित रूप से, योजना, वास्तुकला, फीचर चयन, उन सुविधाओं के लिए मतदान, उन सुविधाओं के लिए नीति, उनके डिजाइन, विकास, परीक्षण के क्लासिक चरणों से गुजरा। परिणामस्वरूप, 6 जून को, हमने उत्पादन के लिए सब कुछ शुरू कर दिया। टेकट्रेन. हर चीज़ के लिए 90 दिन थे.

- क्या हमने जो वादा किया था उसे पूरा करने में हम कामयाब रहे?

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

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

सभी नियोजन को कई चरणों में विभाजित किया गया था, और सभी सुविधाओं (लगभग 30 वैश्विक) को 4 श्रेणियों में विभाजित किया गया था:

• जो हम जरूर करेंगे (हम उनके बिना नहीं रह सकते),
• जो हम दूसरा करेंगे,
• जो हम कभी नहीं करेंगे,
• और जो हम कभी नहीं करेंगे।

हमने पहली दो श्रेणियों से सभी सुविधाएँ बनाईं।

- मुझे पता है कि कुल 600 JIRA मुद्दे बनाए गए थे। तीन महीनों में, आपने 13 माइक्रोसर्विसेज बनाईं, और मुझे संदेह है कि वे न केवल जावा में लिखे गए थे। आपने विभिन्न तकनीकों का उपयोग किया, आपके पास तीन उपलब्धता क्षेत्रों में दो कुबेरनेट क्लस्टर और अमेज़ॅन में 5 आरटीएमपी स्ट्रीम हैं।

आइए अब सिस्टम के प्रत्येक घटक को अलग से देखें।

स्ट्रीमिंग

—आइए शुरुआत तब करें जब हमारे पास पहले से ही एक वीडियो छवि हो, और यह कुछ सेवाओं तक प्रसारित हो। अर्टोम, हमें बताएं कि यह स्ट्रीमिंग कैसे होती है?

अर्टोम निकोनोव: हमारी सामान्य योजना इस तरह दिखती है: कैमरे से छवि -> हमारा नियंत्रण कक्ष -> स्थानीय आरटीएमपी सर्वर -> अमेज़ॅन -> वीडियो प्लेयर। अधिक जानकारी इसके बारे में लिखा जून में हैबे पर।

सामान्य तौर पर, ऐसा करने के दो वैश्विक तरीके हैं: या तो हार्डवेयर पर या सॉफ़्टवेयर समाधानों पर आधारित। हमने सॉफ़्टवेयर मार्ग चुना क्योंकि रिमोट स्पीकर के मामले में यह आसान है। किसी दूसरे देश में स्पीकर में हार्डवेयर लाना हमेशा संभव नहीं होता है, लेकिन स्पीकर तक सॉफ़्टवेयर पहुंचाना आसान और अधिक विश्वसनीय लगता है।

हार्डवेयर के दृष्टिकोण से, हमारे पास एक निश्चित संख्या में कैमरे हैं (हमारे स्टूडियो में और रिमोट स्पीकर पर), स्टूडियो में एक निश्चित संख्या में रिमोट कंट्रोल हैं, जिन्हें कभी-कभी प्रसारण के दौरान टेबल के ठीक नीचे मरम्मत करना पड़ता है।

इन उपकरणों से सिग्नल कैप्चर कार्ड, इनपुट/आउटपुट कार्ड और साउंड कार्ड के साथ कंप्यूटर में प्रवेश करते हैं। वहां सिग्नल मिश्रित होते हैं और लेआउट में इकट्ठे होते हैं:

4 स्पीकर के लिए लेआउट का उदाहरण

4 स्पीकर के लिए लेआउट का उदाहरण

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

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

इसके बाद, कंप्यूटर से स्ट्रीम एक स्थानीय सर्वर पर जाती हैं, जिसके दो कार्य होते हैं: आरटीएमपी स्ट्रीम को रूट करना और बैकअप रिकॉर्ड करना। इसलिए हमारे पास एकाधिक रिकॉर्डिंग बिंदु हैं। फिर वीडियो स्ट्रीम Amazon SaaS सेवाओं पर निर्मित हमारे सिस्टम के हिस्से में भेजी जाती हैं। हम उपयोग करते हैं मीडियालाइव,एस3,क्लाउडफ्रंट।

निकोलाई: दर्शकों तक वीडियो पहुंचने से पहले वहां क्या होता है? आपको इसे किसी भी तरह से काटना होगा, है ना?

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

— क्या हम 1080p रिज़ॉल्यूशन का उपयोग कर रहे हैं?

अर्टोम: हमारे वीडियो की चौड़ाई 1080p - 1920 पिक्सल के समान है, और ऊंचाई थोड़ी कम है, चित्र अधिक लम्बा है - इसके कुछ कारण हैं।

खिलाड़ी

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

निकोलाई: हमारे पास एक ऐसा प्लेयर है जिसे कॉन्फ्रेंस के सभी दर्शक देख सकते हैं।

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

यह मूल कार्यक्षमता है, इसलिए इसे लगभग सबसे पहले लागू किया गया था। और फिर इसके चारों ओर सब कुछ बढ़ता गया।

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

समयरेखा उदाहरण

- सभी रिपोर्टों की टाइमलाइन प्रदर्शित करने के लिए प्लेयर में ही एक बटन बनाया गया है...

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

और उपयोगकर्ताओं के लिए वर्तमान स्ट्रीम को नेविगेट करना और ट्रैक के बीच स्विच करना आसान बनाने के लिए, हमने ट्रैक और रिपोर्ट के बीच स्विच करने के लिए "संपूर्ण प्रसारण" बटन और क्षैतिज रिपोर्ट कार्ड बनाने का निर्णय लिया। कीबोर्ड नियंत्रण है.

— क्या इसमें कोई तकनीकी दिक्कतें थीं?

निकोलाई: उनके पास एक स्क्रॉल बार था जिस पर विभिन्न रिपोर्टों के शुरुआती बिंदु अंकित थे।

— अंत में, क्या YouTube द्वारा कुछ ऐसा ही करने से पहले आपने इन चिह्नों को स्क्रॉल बार पर लागू किया था?

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

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

फ़्रंट एंड

— आइए जानें कि यह सामग्री जो हम दिखाते हैं (स्पीच कार्ड, स्पीकर, वेबसाइट, शेड्यूल) फ्रंट एंड तक कैसे पहुंचती है?

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

इस प्रकार स्पीकर पाइपलाइन को देखता है

यह व्यवस्था हमारा आंतरिक विकास है।

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

ऐसा प्रतीत होता है कि साइट केवल एक प्लेयर वाला पेज है, और यहां कुछ भी जटिल नहीं है। सिवाय इसके कि ऐसा नहीं है. इस पृष्ठ के पीछे का बैकएंड कंटेंटफुल पर जाता है, वहां से शेड्यूल प्राप्त करता है, कुछ ऑब्जेक्ट बनाता है और इसे फ्रंटएंड पर भेजता है। वेबसॉकेट कनेक्शन का उपयोग करते हुए, जिसे हमारे प्लेटफ़ॉर्म का प्रत्येक ग्राहक बनाता है, हम उसे बैकएंड से फ्रंटएंड तक शेड्यूल का अपडेट भेजते हैं।

वास्तविक मामला: सम्मेलन के दौरान ही वक्ता ने नौकरी बदल ली। हमें उसका नियोक्ता कंपनी बैज बदलना होगा। यह बैकएंड से कैसे होता है? वेबसॉकेट के माध्यम से सभी क्लाइंट को एक अपडेट भेजा जाता है, और फिर फ्रंटएंड स्वयं टाइमलाइन को फिर से तैयार करता है। यह सब निर्बाध रूप से होता है. क्लाउड सेवा और हमारे कई घटकों का संयोजन हमें यह सारी सामग्री उत्पन्न करने और सामने वाले को प्रदान करने का अवसर देता है।

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

- आइए प्रौद्योगिकियों को सूचीबद्ध करके उपरोक्त सभी के अंतर्गत एक रेखा खींचें। टायोमा ने कहा कि हमारे पास 5 अमेज़ॅन स्ट्रीम हैं, और हम वहां वीडियो और ध्वनि वितरित करते हैं। हमारे पास वहां बैश स्क्रिप्ट हैं, हम उन्हें लॉन्च और कॉन्फ़िगर करने के लिए उपयोग करते हैं...

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

— फिर यह सब बैकएंड सिस्टम का उपयोग करके प्लेयर में चला जाता है। हमारे प्लेयर में टाइपस्क्रिप्ट, रिएक्ट, नेक्स्ट.जेएस है। और बैकएंड पर हमारे पास C#, Java, स्प्रिंग बूट और Node.js में कई सेवाएँ हैं। यह सब Yandex.Cloud बुनियादी ढांचे का उपयोग करके कुबेरनेट्स का उपयोग करके तैनात किया गया है।

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

व्यावसायिक बाधाएँ और विश्लेषिकी

— हमने व्यावसायिक आवश्यकताओं के आधार पर 10 उपयोगकर्ताओं को लक्षित किया। अब उन व्यावसायिक प्रतिबंधों के बारे में बात करने का समय आ गया है जो हमारे पास थे। हमें उच्च कार्यभार सुनिश्चित करना था, व्यक्तिगत डेटा के संरक्षण पर कानून का अनुपालन सुनिश्चित करना था। और क्या?

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

— क्या भागीदारों के ऑनलाइन स्टैंड के साथ "आभासी प्रदर्शनी" के लिए कोई अन्य आवश्यकताएं थीं?

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

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

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

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

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

धोखा

— क्या हमारे पास धोखाधड़ी-रोधी तंत्र हैं?

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

व्लादिमीर: इसका श्रेय, प्रतिबंधित उपयोगकर्ताओं में से एक को समझ में आया कि ऐसा क्यों हुआ। वह आया, माफी मांगी और टिकट खरीदने का वादा किया।

— यह सब होने के लिए, आपको प्रवेश से निकास तक सभी उपयोगकर्ताओं का पूरी तरह से पता लगाना होगा, हमेशा जानना होगा कि वे क्या कर रहे हैं। यह सिस्टम कैसे काम करता है?

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

वही जानकारी संग्रहीत है मोंगो और हमारे डेटा लेक तक जाता है, जहाँ से हमें और अधिक दिलचस्प ग्राफ़ बनाने का अवसर मिलता है। सवाल उठता है: कितने अद्वितीय उपयोगकर्ताओं ने इस रिपोर्ट को देखा? हम जाते हैं postgres, इस रिपोर्ट की आईडी से आए सभी लोगों के पिंग हैं। हमने अनूठे को एकत्र किया, एकत्रित किया, और अब हम समझ सकते हैं।

निकोलाई: लेकिन साथ ही, हमें प्रोमेथियस से वास्तविक समय का डेटा भी प्राप्त होता है। यह सभी Kubernetes सेवाओं के विरुद्ध, स्वयं Kubernetes के विरुद्ध सेट किया गया है। यह पूरी तरह से सब कुछ एकत्र करता है, और ग्राफाना के साथ हम वास्तविक समय में कोई भी ग्राफ़ बना सकते हैं।

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

- यह वह स्थिति है जब ग्राफ़ एकाग्र होते हैं।

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

— हमें बताएं कि गतिशील परिवर्तन कैसे किए जाते हैं: यदि रिपोर्ट शुरू होने से 6 मिनट पहले रद्द कर दी गई थी, तो कार्रवाइयों की श्रृंखला क्या है? कौन सी पाइपलाइन काम करती है?

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

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

निकोलाई: पेज को रिफ्रेश किए बिना सब कुछ होता है। क्लाइंट के लिए सभी परिवर्तन बिल्कुल निर्बाध रूप से होते हैं। रिपोर्ट बदलने के लिए भी यही बात लागू होती है। समय आने पर रिपोर्ट और इंटरफ़ेस बदल जाता है.

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

तैनाती

- मैं तैनाती के बारे में पूछना चाहूंगा। कोल्या और टीम ने शुरुआत में पूरे बुनियादी ढांचे को स्थापित करने में बहुत समय बिताया, जिसमें हमारे लिए सब कुछ सामने आता है। मुझे बताओ, यह सब किस चीज़ से बना है?

निकोलाई: तकनीकी दृष्टिकोण से, हमें शुरू में यह आवश्यकता थी कि उत्पाद किसी भी विक्रेता से जितना संभव हो सके उतना सारगर्भित हो। विशेष रूप से AWS से, या विशेष रूप से Yandex से, या Azure आदि से टेराफ़ॉर्म स्क्रिप्ट बनाने के लिए AWS पर आएं। वास्तव में फिट नहीं हुआ. हमें किसी समय कहीं जाना पड़ा।

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

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

हमें सभी परीक्षणों, एकीकरणों, कार्यात्मक परीक्षणों को चलाने, पर्यावरण पर एकीकरण परीक्षणों के साथ किसी भी वातावरण में परिवर्तन करने और लोड परीक्षणों के साथ परीक्षण करने का अवसर मिलता है (बैकएंड के लिए 10 मिनट के भीतर, फ्रंटएंड के लिए 5 मिनट के भीतर) एक परीक्षण वातावरण लगभग वही चीज़ है जो हम उत्पादन में प्राप्त करना चाहते हैं।

परीक्षणों के बारे में

— आप लगभग हर चीज़ का परीक्षण करते हैं, यह विश्वास करना कठिन है कि आपने सब कुछ कैसे लिखा। क्या आप हमें बैकएंड परीक्षणों के बारे में बता सकते हैं: कितना सब कुछ कवर किया गया है, कौन से परीक्षण?

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

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

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

निकोलाई: परंपरागत रूप से, किसी फ़ंक्शन को बदलते समय पूरे प्लेटफ़ॉर्म पर रिग्रेशन करने के लिए, आपको दो दिनों तक हर जगह बैठने और पोक करने की आवश्यकता होती है।

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

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

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

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

अर्टोम: पुनरावर्ती परीक्षण किया गया। बैठकों का आयोजन. मीटअप आयोजित करने की प्रक्रिया में, लगभग 2300 JIRA टिकट थे। ये केवल सामान्य चीज़ें हैं जो लोगों ने मुलाकातें करने के लिए कीं। हमने मंच के कुछ हिस्सों को मीटअप के लिए एक अलग पेज पर ले लिया, जिसे किरिल टोल्काचेव द्वारा चलाया गया था (टॉककेवी).

सच कहूँ तो कोई बड़ी समस्या नहीं थी। वस्तुतः कुछ बार हमने क्लाउडफ्रंट पर कैशिंग बग पकड़े, हमने इसे बहुत जल्दी हल कर लिया - हमने बस नीतियों को फिर से कॉन्फ़िगर किया। साइट पर स्ट्रीमिंग सिस्टम में लोगों में काफी अधिक बग थे।

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

Оборудование

— मुझे याद है कि कैसे सम्मेलन शुरू होने से पहले हमने आंशिक रूप से अतिरिक्त उपकरण खरीदे थे।

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

— इंटरनेट के साथ भी हमारी ऐसी ही कहानी है। जिस कार्यालय में हमारे स्टूडियो स्थित हैं, हमने फर्शों के बीच एक भयंकर जाल खींच लिया।

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

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

जिज्ञासाएँ एवं समस्याएँ

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

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

व्लादिमीर: मुझे तो ऐसा लगता है कि ऐसा पिछले तीन महीनों से ही हो रहा है. रोज रोज। जैसा कि आप देख सकते हैं, मेरे सारे बाल खींच लिये गये हैं।

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

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

निकोलाई: और टेकट्रेन से एक घंटे पहले रिलीज़ हुई।

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

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

— क्या आप मुझे बता सकते हैं कि साइट पर एक ट्रैक पर कितने लोग थे? क्या कोई प्रदर्शन संबंधी समस्याएँ थीं?

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

— क्या स्थानीय देखने में कोई समस्या थी? और क्या यह सब कैसे काम करता है इसका आरेख के साथ तकनीकी विवरण देना संभव है?

निकोलाई: हम इस बारे में बाद में एक लेख बनाएंगे।

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

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

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

व्लादिमीर: आप इसे ले सकते हैं और इसे दोहरा सकते हैं।

- 3 महीने में.

संपूर्ण

- एक साथ वर्णित हर चीज़ अच्छी लगती है, यह देखते हुए कि यह तीन महीनों में एक छोटी सी टीम द्वारा किया गया था।

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

- जब ग्रीष्मकालीन सम्मेलन पहले ही हो चुके थे तो आपके आगे के कार्यों की सूची में क्या था?

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

और स्ट्रीमिंग और कॉन्फ़्रेंस को छोड़कर, पूरे प्लेटफ़ॉर्म पर कॉन्फ़्रेंस के बाद की स्थिति भी जोड़ रहा है। ये प्लेलिस्ट हैं (उपयोगकर्ताओं द्वारा संकलित सहित), संभवतः अन्य पिछले सम्मेलनों की सामग्री, एकीकृत, लेबल, उपयोगकर्ता के लिए सुलभ, और हमारी वेबसाइट पर देखने के लिए भी उपलब्ध है (Live.jugru.org).

— दोस्तों, आपके उत्तरों के लिए बहुत-बहुत धन्यवाद!

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

यदि आप प्लेटफ़ॉर्म में रुचि रखते हैं और इसे "युद्ध में" देखना चाहते हैं, तो हम इसे फिर से अपने यहां उपयोग करते हैं शरद ऋतु-सर्दी सम्मेलन. उनमें से एक पूरी श्रृंखला है, इसलिए लगभग निश्चित रूप से एक ऐसा है जो आपके लिए सही है।

स्रोत: www.habr.com