या वसंत ऋतूत आम्ही स्वतःला खूप आनंदी परिस्थितीत सापडलो. साथीच्या रोगामुळे, हे स्पष्ट झाले की आमच्या उन्हाळ्याच्या परिषदा ऑनलाइन हलविण्याची आवश्यकता आहे. आणि ते ऑनलाइन कार्यक्षमतेने आयोजित करण्यासाठी, तयार सॉफ्टवेअर उपाय आमच्यासाठी योग्य नव्हते; आम्हाला स्वतःचे लिहावे लागेल. आणि हे करण्यासाठी आमच्याकडे तीन महिने होते.

हे स्पष्ट आहे की ते एक रोमांचक तीन महिने गेले आहेत. परंतु बाहेरून हे पूर्णपणे स्पष्ट नाही: ऑनलाइन कॉन्फरन्स प्लॅटफॉर्म म्हणजे काय? त्यात कोणत्या भागांचा समावेश आहे? म्हणून, उन्हाळ्याच्या शेवटच्या DevOops परिषदांमध्ये, मी या कार्यासाठी जबाबदार असलेल्यांना विचारले:

• निकोले मोल्चानोव - जेयूजी रु ग्रुपचे तांत्रिक संचालक;
• व्लादिमीर क्रॅसिलश्चिक हा एक व्यावहारिक Java प्रोग्रामर आहे जो बॅकएंडवर काम करतो (आपण आमच्या जावा कॉन्फरन्समध्ये त्याचे अहवाल देखील पाहू शकता);
• Artyom Nikonov आमच्या सर्व व्हिडिओ स्ट्रीमिंगसाठी जबाबदार आहे.

तसे, शरद ऋतूतील-हिवाळी कॉन्फरन्समध्ये आम्ही त्याच प्लॅटफॉर्मची सुधारित आवृत्ती वापरू - त्यामुळे बरेच हॅब्रा वाचक अजूनही त्याचे वापरकर्ते असतील.

मोठे चित्र

- संघाची रचना काय होती?

निकोले मोल्चानोव्ह: आमच्याकडे एक विश्लेषक, एक डिझायनर, एक परीक्षक, तीन फ्रंट-एंडर्स आणि बॅक-एंड आहेत. आणि, अर्थातच, एक टी-आकार तज्ञ!

— प्रक्रिया सर्वसाधारणपणे कशी दिसत होती?

निकोले: मार्चच्या मध्यापर्यंत, आमच्याकडे ऑनलाइनसाठी काहीही तयार नव्हते. आणि 15 मार्च रोजी, संपूर्ण ऑनलाइन कॅरोसेल फिरू लागला. आम्ही अनेक रिपॉझिटरीज सेट केल्या, योजना आखल्या, मूलभूत आर्किटेक्चरवर चर्चा केली आणि तीन महिन्यांत सर्वकाही केले.

हे अर्थातच नियोजन, आर्किटेक्चर, वैशिष्ट्यांची निवड, त्या वैशिष्ट्यांसाठी मतदान, त्या वैशिष्ट्यांसाठी धोरण, त्यांची रचना, विकास, चाचणी या उत्कृष्ट टप्प्यांतून गेले. परिणामी, 6 जून रोजी, आम्ही सर्वकाही उत्पादनासाठी आणले. टेकट्रेन. प्रत्येक गोष्टीसाठी ९० दिवस होते.

- आम्ही जे वचनबद्ध केले ते पूर्ण करण्यात आम्ही व्यवस्थापित केले का?

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

आव्हान हे होते: आम्हाला एक साधन द्या ज्याद्वारे आम्ही तिकीटधारकांना आमची परिषद प्रसारित करू शकू.

सर्व नियोजन अनेक टप्प्यात विभागले गेले आणि सर्व वैशिष्ट्ये (सुमारे 30 जागतिक) 4 श्रेणींमध्ये विभागली गेली:

• जे आम्ही नक्कीच करू (आम्ही त्यांच्याशिवाय जगू शकत नाही),
• जे आपण दुसरे करू,
• जे आपण कधीच करणार नाही,
• आणि जे आम्ही कधीच करणार नाही.

आम्ही पहिल्या दोन श्रेणींमधून सर्व वैशिष्ट्ये तयार केली.

— मला माहित आहे की एकूण 600 JIRA समस्या तयार केल्या गेल्या आहेत. तीन महिन्यांत, तुम्ही 13 मायक्रोसर्व्हिसेस केल्या आणि मला शंका आहे की ते फक्त जावामध्येच लिहिलेले नाहीत. तुम्ही वेगवेगळ्या तंत्रज्ञानाचा वापर केला आहे, तुमच्याकडे तीन उपलब्धता झोनमध्ये दोन Kubernetes क्लस्टर आहेत आणि Amazon मध्ये 5 RTMP प्रवाह आहेत.

आता सिस्टमच्या प्रत्येक घटकाकडे स्वतंत्रपणे पाहू.

प्रवाहित

- जेव्हा आमच्याकडे आधीपासूनच व्हिडिओ प्रतिमा असते आणि ती काही सेवांवर प्रसारित केली जाते तेव्हापासून सुरुवात करूया. आर्टिओम, हे प्रवाह कसे होते ते सांगा?

आर्टिओम निकोनोव: आमची सर्वसाधारण योजना यासारखी दिसते: कॅमेऱ्यातील प्रतिमा -> आमचा नियंत्रण कक्ष -> स्थानिक RTMP सर्व्हर -> Amazon -> व्हिडिओ प्लेयर. अधिक माहितीसाठी त्याबद्दल लिहिले जून मध्ये Habré वर.

सर्वसाधारणपणे, हे करण्याचे दोन जागतिक मार्ग आहेत: एकतर हार्डवेअरवर किंवा सॉफ्टवेअर सोल्यूशन्सवर आधारित. आम्ही सॉफ्टवेअर मार्ग निवडला कारण रिमोट स्पीकर्सच्या बाबतीत ते सोपे आहे. दुसर्‍या देशातील स्पीकरवर हार्डवेअर आणणे नेहमीच शक्य नसते, परंतु स्पीकरला सॉफ्टवेअर वितरित करणे सोपे आणि अधिक विश्वासार्ह वाटते.

हार्डवेअरच्या दृष्टिकोनातून, आमच्याकडे काही कॅमेरे आहेत (आमच्या स्टुडिओमध्ये आणि रिमोट स्पीकरमध्ये), स्टुडिओमध्ये काही विशिष्ट रिमोट कंट्रोल्स आहेत, जे काहीवेळा प्रसारणादरम्यान टेबलच्या खाली दुरुस्त करावे लागतात.

या उपकरणांमधील सिग्नल कॅप्चर कार्ड, इनपुट/आउटपुट कार्ड आणि साउंड कार्डसह संगणकांमध्ये प्रवेश करतात. तेथे सिग्नल मिसळले जातात आणि लेआउटमध्ये एकत्र केले जातात:

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

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

पुढे, तीन संगणकांच्या मदतीने सतत प्रक्षेपण प्रदान केले जाते: एक मुख्य मशीन आणि त्याऐवजी कार्यरत असलेल्यांची जोडी आहे. पहिला संगणक पहिला अहवाल, दुसरा - ब्रेक, पहिला - पुढील अहवाल, दुसरा - पुढील ब्रेक इत्यादी गोळा करतो. आणि मुख्य मशीन पहिल्याला दुसऱ्यामध्ये मिसळते.

यामुळे एक प्रकारचा त्रिकोण तयार होतो आणि यापैकी कोणतेही नोड अयशस्वी झाल्यास, आम्ही त्वरीत आणि गुणवत्ता न गमावता क्लायंटपर्यंत सामग्री वितरीत करणे सुरू ठेवू शकतो. आमची अशी परिस्थिती होती. परिषदेच्या पहिल्या आठवड्यात, आम्ही एक मशीन निश्चित केले, ते चालू/बंद केले. लोक आमच्या लवचिकतेवर खूश आहेत असे दिसते.

पुढे, संगणकावरील प्रवाह स्थानिक सर्व्हरवर जातात, ज्यामध्ये दोन कार्ये असतात: रूट RTMP प्रवाह आणि रेकॉर्ड बॅकअप. त्यामुळे आमच्याकडे अनेक रेकॉर्डिंग पॉइंट्स आहेत. व्हिडिओ प्रवाह नंतर Amazon SaaS सेवांवर तयार केलेल्या आमच्या सिस्टमच्या भागावर पाठवले जातात. आम्ही वापरतो मीडियालाइव्ह,S3,क्लाउडफ्रंट.

निकोले: व्हिडिओ प्रेक्षकांपर्यंत पोहोचण्यापूर्वी तिथे काय होते? तुम्हाला ते कसे तरी कापावे लागेल, बरोबर?

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

- आम्ही 1080p रिझोल्यूशन वापरत आहोत?

आर्टिओम: आमच्या व्हिडिओची रुंदी 1080p - 1920 पिक्सेल सारखीच आहे आणि उंची थोडी कमी आहे, चित्र अधिक लांबलचक आहे - याची कारणे आहेत.

खेळाडू

— आर्टिओमने व्हिडिओ स्ट्रीममध्ये कसा येतो, वेगवेगळ्या स्क्रीन रिझोल्यूशनसाठी वेगवेगळ्या प्लेलिस्टमध्ये कसा वितरित केला जातो, त्याचे तुकडे करून प्लेअरमध्ये कसे येते याचे वर्णन केले आहे. कोल्या, आता मला सांगा हा कोणता खेळाडू आहे, तो प्रवाह कसा वापरतो, HLS का?

निकोले: आमच्याकडे एक खेळाडू आहे जो सर्व कॉन्फरन्स दर्शक पाहू शकतात.

मूलत:, हे लायब्ररीभोवती एक आवरण आहे hls.js, ज्यावर इतर अनेक खेळाडू लिहिलेले आहेत. परंतु आम्हाला अतिशय विशिष्ट कार्यक्षमतेची आवश्यकता आहे: ती व्यक्ती जिथे आहे ते ठिकाण रिवाइंड करणे आणि चिन्हांकित करणे, तो सध्या कोणता अहवाल पाहत आहे. आम्हाला आमचे स्वतःचे लेआउट, सर्व प्रकारचे लोगो आणि आमच्यासोबत तयार केलेल्या इतर सर्व गोष्टींची देखील आवश्यकता होती. म्हणून, आम्ही आमची स्वतःची लायब्ररी (HLS वर एक आवरण) लिहिण्याचे ठरवले आणि ते साइटवर एम्बेड केले.

ही मूळ कार्यक्षमता आहे, म्हणून ती जवळजवळ प्रथम लागू केली गेली. आणि मग त्याभोवती सर्व काही वाढले.

खरं तर, अधिकृततेद्वारे, खेळाडूला बॅकएंडमधून वेळ आणि गुणवत्तेशी संबंधित भागांच्या लिंकसह प्लेलिस्ट प्राप्त होते, आवश्यक ते डाउनलोड करते आणि त्या वापरकर्त्याला दाखवते, वाटेत काही "जादू" करते.

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

— सर्व अहवालांची टाइमलाइन प्रदर्शित करण्यासाठी प्लेअरमध्ये एक बटण तयार केले आहे...

निकोले: होय, आम्ही त्वरित वापरकर्त्याच्या नेव्हिगेशनची समस्या सोडवली. एप्रिलच्या मध्यात, आम्ही ठरवले की आम्ही आमची प्रत्येक परिषद वेगळ्या वेबसाइटवर प्रसारित करणार नाही, परंतु सर्व काही एका वेबसाइटवर एकत्र करू. जेणेकरून पूर्ण पास तिकीट वापरकर्ते वेगवेगळ्या परिषदांमध्ये मुक्तपणे स्विच करू शकतील: थेट प्रक्षेपण आणि मागील गोष्टींचे रेकॉर्डिंग.

आणि वापरकर्त्यांना वर्तमान प्रवाहात नेव्हिगेट करणे आणि ट्रॅक दरम्यान स्विच करणे सोपे करण्यासाठी, आम्ही ट्रॅक आणि अहवालांमध्ये स्विच करण्यासाठी "संपूर्ण प्रसारण" बटण आणि क्षैतिज अहवाल कार्ड बनवण्याचा निर्णय घेतला. कीबोर्ड कंट्रोल आहे.

- यामध्ये काही तांत्रिक अडचणी होत्या का?

निकोले: त्यांच्याकडे एक स्क्रोल बार होता ज्यावर वेगवेगळ्या अहवालांचे प्रारंभ बिंदू चिन्हांकित केले गेले होते.

— सरतेशेवटी, YouTube ने असे काहीतरी करण्यापूर्वी तुम्ही स्क्रोल बारवर या खुणा लागू केल्या होत्या का?

आर्टिओम: ते तेव्हा बीटामध्ये होते. असे दिसते की हे एक अतिशय जटिल वैशिष्ट्य आहे कारण ते गेल्या वर्षभरात वापरकर्त्यांसह अंशतः चाचणी करत आहेत. आणि आता ते विक्रीपर्यंत पोहोचले आहे.

निकोले: पण प्रत्यक्षात आम्ही ते जलद विक्रीसाठी मिळवले. प्रामाणिकपणे, या साध्या वैशिष्ट्यामागे प्लेअरच्या आत बॅकएंड, फ्रंटएंड, गणिते आणि गणिते आहेत.

फ्रंटएंड

— आपण दाखवत असलेली ही सामग्री (स्पीच कार्ड, स्पीकर, वेबसाइट, शेड्यूल) समोरच्या टोकाला कशी पोहोचते ते शोधूया?

व्लादिमीर क्रॅसिलश्चिक: आमच्याकडे अनेक अंतर्गत आयटी प्रणाली आहेत. एक प्रणाली आहे ज्यामध्ये सर्व अहवाल आणि सर्व स्पीकर प्रविष्ट केले जातात. एक प्रक्रिया आहे ज्याद्वारे वक्ता कॉन्फरन्समध्ये भाग घेतो. स्पीकर एक अर्ज सबमिट करतो, सिस्टम ते कॅप्चर करते, त्यानंतर एक विशिष्ट पाइपलाइन असते ज्यानुसार अहवाल तयार केला जातो.

अशा प्रकारे स्पीकर पाइपलाइन पाहतो

ही व्यवस्था आपला अंतर्गत विकास आहे.

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

असे दिसते की साइट केवळ प्लेअरसह एक पृष्ठ आहे आणि येथे काहीही क्लिष्ट नाही. ते नसल्याशिवाय. या पानामागील बॅकएंड कंटेंटफुलला जातो, तिथून शेड्यूल मिळवतो, काही ऑब्जेक्ट्स तयार करतो आणि फ्रंटएंडला पाठवतो. वेबसॉकेट कनेक्शन वापरून, जे आमच्या प्लॅटफॉर्मचा प्रत्येक क्लायंट बनवतो, आम्ही त्याला बॅकएंडपासून फ्रंटएंडपर्यंत शेड्यूलचे अपडेट पाठवतो.

वास्तविक केस: कॉन्फरन्स दरम्यान स्पीकरने नोकरी बदलली. आम्हाला त्याचा नियोक्ता कंपनीचा बॅज बदलण्याची गरज आहे. बॅकएंडवरून हे कसे घडते? वेबसॉकेटद्वारे सर्व क्लायंटना अपडेट पाठवले जाते आणि नंतर फ्रंटएंड स्वतःच टाइमलाइन पुन्हा काढतो. हे सर्व अखंडपणे घडते. क्लाउड सेवा आणि आमच्या अनेक घटकांचे संयोजन आम्हाला ही सर्व सामग्री तयार करण्याची आणि समोरच्याला प्रदान करण्याची संधी देते.

निकोले: येथे हे स्पष्ट करणे महत्त्वाचे आहे की आमची साइट क्लासिक SPA अनुप्रयोग नाही. ही लेआउट-आधारित, प्रस्तुत वेबसाइट आणि एक SPA दोन्ही आहे. Google प्रत्यक्षात ही साइट प्रस्तुत HTML म्हणून पाहते. हे एसइओसाठी आणि वापरकर्त्याला सामग्री वितरीत करण्यासाठी चांगले आहे. हे पृष्ठ पाहण्यापूर्वी 1,5 मेगाबाइट JavaScript लोड होण्याची प्रतीक्षा करत नाही, ते लगेचच आधीच प्रस्तुत केलेले पृष्ठ पाहते आणि प्रत्येक वेळी जेव्हा तुम्ही अहवाल स्विच करता तेव्हा तुम्हाला ते जाणवते. सर्व काही अर्ध्या सेकंदात होते, कारण सामग्री आधीच तयार आहे आणि योग्य ठिकाणी पोस्ट केली आहे.

- तंत्रज्ञानाची यादी करून वरील सर्व खाली एक रेषा काढू. ट्योमा म्हणाले की आमच्याकडे 5 Amazon प्रवाह आहेत आणि आम्ही तेथे व्हिडिओ आणि ध्वनी वितरित करतो. आमच्याकडे तेथे बॅश स्क्रिप्ट आहेत, आम्ही त्यांचा वापर लॉन्च आणि कॉन्फिगर करण्यासाठी करतो...

आर्टिओम: हे AWS API द्वारे घडते, तेथे अनेक तांत्रिक बाजू सेवा आहेत. आम्ही आमच्या जबाबदाऱ्यांची विभागणी केली जेणेकरून मी ते पूर्ण करू शकेन क्लाउडफ्रंट, आणि फ्रंट-एंड आणि बॅक-एंड डेव्हलपर तेथून ते घेतात. सामग्रीचे लेआउट सुलभ करण्यासाठी आमच्याकडे आमच्या स्वतःच्या अनेक बंधने आहेत, जी आम्ही नंतर 4K मध्ये बनवतो, इ. डेडलाइन खूप कडक असल्याने, आम्ही ते जवळजवळ संपूर्ण AWS वर केले.

- मग हे सर्व बॅकएंड सिस्टम वापरून प्लेअरमध्ये जाते. आमच्या प्लेअरमध्ये TypeScript, React, Next.JS आहे. आणि बॅकएंडवर आमच्याकडे C#, Java, Spring Boot आणि Node.js मध्ये अनेक सेवा आहेत. हे सर्व Yandex.Cloud इन्फ्रास्ट्रक्चर वापरून Kubernetes वापरून तैनात केले आहे.

मला हे देखील लक्षात घ्यायचे आहे की जेव्हा मला प्लॅटफॉर्मशी परिचित होण्याची आवश्यकता होती तेव्हा ते सोपे झाले: सर्व भांडार GitLab वर आहेत, सर्व काही चांगले नाव दिले आहे, चाचण्या लिहिल्या आहेत, कागदपत्रे आहेत. म्हणजेच आपत्कालीन स्थितीतही त्यांनी अशा गोष्टींची काळजी घेतली.

व्यवसाय मर्यादा आणि विश्लेषण

— आम्ही व्यवसाय आवश्यकतांवर आधारित 10 वापरकर्त्यांना लक्ष्य केले. आमच्यावर असलेल्या व्यावसायिक निर्बंधांबद्दल बोलण्याची वेळ आली आहे. आम्हाला उच्च कामाचा ताण, वैयक्तिक डेटा जतन करण्याच्या कायद्याचे पालन सुनिश्चित करावे लागले. आणि आणखी काय?

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

— भागीदारांच्या ऑनलाइन स्टँडसह "आभासी प्रदर्शन" साठी इतर काही आवश्यकता होत्या का?

निकोले: होय, हे खूप लवकर आणि सार्वत्रिकपणे केले पाहिजे. प्रत्येक परिषदेसाठी आमच्याकडे 10 भागीदार कंपन्या होत्या आणि त्या सर्व एक किंवा दोन आठवड्यांत पूर्ण करायच्या होत्या. तथापि, त्यांची सामग्री फॉरमॅटमध्ये थोडी वेगळी आहे. परंतु एक विशिष्ट टेम्प्लेट इंजिन तयार केले गेले होते जे या पृष्ठांना फ्लायवर एकत्र करते, अक्षरशः पुढील विकास सहभागाशिवाय.

— रिअल-टाइम दृश्ये आणि आकडेवारीच्या विश्लेषणासाठी देखील आवश्यकता होत्या. मला माहित आहे की आम्ही यासाठी प्रोमिथियस वापरतो, परंतु आम्हाला अधिक तपशीलवार सांगा: आम्ही विश्लेषणासाठी कोणत्या आवश्यकता पूर्ण करतो आणि याची अंमलबजावणी कशी केली जाते?

निकोले: सुरुवातीला, भविष्यात क्लायंटला सर्वोत्तम सामग्री कशी वितरित करायची हे समजून घेण्यासाठी आमच्याकडे A/B चाचणीसाठी आणि माहिती गोळा करण्यासाठी विपणन आवश्यकता आहेत. भागीदार अ‍ॅक्टिव्हिटींवरील काही विश्लेषणे आणि तुम्ही पहात असलेल्या विश्लेषणासाठी (काउंटरला भेट द्या) आवश्यकता देखील आहेत. सर्व माहिती रिअल टाइममध्ये गोळा केली जाते.

आम्ही ही माहिती एकत्रित स्वरूपात अगदी स्पीकर्सनाही देऊ शकतो: ठराविक वेळी किती लोक तुम्हाला पाहत होते. त्याच वेळी, फेडरल लॉ 152 चे पालन करण्यासाठी, तुमचे वैयक्तिक खाते आणि वैयक्तिक डेटा कोणत्याही प्रकारे ट्रॅक केला जात नाही.

अहवालात उपस्थितीचा आलेख तयार करण्यासाठी प्लॅटफॉर्ममध्ये आधीच मार्केटिंग साधने आणि रिअल टाइममध्ये (ज्याने अहवालाचा कोणता सेकंद पाहिला) वापरकर्ता क्रियाकलाप मोजण्यासाठी आमचे मेट्रिक्स आहेत. या डेटाच्या आधारे, पुढील परिषदा अधिक चांगल्या बनतील असे संशोधन केले जात आहे.

फसवणूक

- आमच्याकडे फसवणूक विरोधी यंत्रणा आहे का?

निकोले: व्यवसायाच्या दृष्टीकोनातून कठोर कालावधीमुळे, कार्य सुरुवातीला अनावश्यक कनेक्शन त्वरित अवरोधित करण्यासाठी सेट केले गेले नाही. जर दोन वापरकर्त्यांनी एकाच खात्यात लॉग इन केले असेल तर ते सामग्री पाहू शकतील. परंतु एका खात्यातून एकाच वेळी किती दृश्ये होती हे आम्हाला माहीत आहे. आणि आम्ही अनेक विशेषतः दुर्भावनापूर्ण उल्लंघन करणाऱ्यांवर बंदी घातली.

व्लादिमीर: त्याच्या श्रेयासाठी, प्रतिबंधित वापरकर्त्यांपैकी एकास हे का झाले हे समजले. तो आला, माफी मागितली आणि तिकीट घेण्याचे आश्वासन दिले.

— हे सर्व होण्यासाठी, तुम्ही सर्व वापरकर्त्यांना प्रवेशापासून बाहेर पडण्यासाठी पूर्णपणे ट्रेस केले पाहिजे, ते काय करत आहेत हे नेहमी जाणून घ्या. ही यंत्रणा कशी काम करते?

व्लादिमीर: मला विश्लेषणे आणि आकडेवारीबद्दल बोलायचे आहे, जे आम्ही नंतर अहवालाच्या यशासाठी विश्लेषण करतो किंवा नंतर भागीदारांना प्रदान करू शकतो. सर्व क्लायंट एका विशिष्ट बॅकएंड क्लस्टरशी वेबसॉकेट कनेक्शनद्वारे जोडलेले आहेत. तो तिथेच उभा आहे हेझेलकास्ट. प्रत्येक क्लायंट प्रत्येक वेळेत तो काय करत आहे आणि कोणता ट्रॅक पाहत आहे ते पाठवतो. नंतर ही माहिती जलद Hazelcast जॉब वापरून एकत्रित केली जाते आणि हे ट्रॅक पाहणाऱ्या प्रत्येकाला परत पाठवली जाते. आम्ही कोपऱ्यात पाहतो की आता किती लोक आमच्याबरोबर आहेत.

मध्ये समान माहिती संग्रहित केली जाते मोंगो आणि आमच्या डेटा तलावाकडे जातो, जिथून आम्हाला अधिक मनोरंजक आलेख तयार करण्याची संधी आहे. प्रश्न उद्भवतो: किती अद्वितीय वापरकर्त्यांनी हा अहवाल पाहिला? आम्ही जातो पोस्टग्रेस, या अहवालाच्या आयडीद्वारे आलेल्या सर्व लोकांचे पिंग आहेत. आम्ही एकत्रित केले, अद्वितीय एकत्र केले आणि आता आम्ही समजू शकतो.

निकोले: परंतु त्याच वेळी, आम्हाला प्रोमिथियसकडून रिअल-टाइम डेटा देखील प्राप्त होतो. हे सर्व Kubernetes सेवांच्या विरुद्ध आहे, कुबर्नेट्सच्या विरुद्धच. हे पूर्णपणे सर्वकाही गोळा करते आणि ग्राफना सह आम्ही वास्तविक वेळेत कोणतेही आलेख तयार करू शकतो.

व्लादिमीर: एकीकडे, आम्ही पुढील OLAP प्रक्रियेसाठी हे डाउनलोड करतो. आणि OLTP साठी, अॅप्लिकेशन संपूर्ण गोष्ट प्रोमिथियस, ग्राफाना डाउनलोड करते आणि आलेख अगदी एकत्र होतात!

- जेव्हा आलेख एकत्र होतात तेव्हा असे होते.

डायनॅमिक बदल

— डायनॅमिक बदल कसे आणले जातात ते आम्हाला सांगा: जर अहवाल सुरू होण्याच्या 6 मिनिटे आधी रद्द केला गेला असेल, तर क्रियांची साखळी काय आहे? कोणती पाइपलाइन काम करते?

व्लादिमीर: पाइपलाइन अतिशय सशर्त आहे. अनेक शक्यता आहेत. पहिला म्हणजे शेड्यूल जनरेशन प्रोग्रामने काम केले आणि वेळापत्रक बदलले. सुधारित वेळापत्रक Contentful वर अपलोड केले आहे. ज्यानंतर बॅकएंडला समजते की Contentful मध्ये या कॉन्फरन्ससाठी बदल आहेत, ते घेते आणि ते पुन्हा तयार करते. सर्व काही गोळा केले जाते आणि वेबसॉकेटद्वारे पाठवले जाते.

दुसरी शक्यता, जेव्हा सर्व काही अत्यंत वेगाने घडते: संपादक स्वतः सामग्रीमध्ये माहिती बदलतो (टेलीग्रामची लिंक, स्पीकरचे सादरीकरण इ.) आणि तेच तर्क प्रथमच कार्य करते.

निकोले: पृष्ठ रीफ्रेश केल्याशिवाय सर्व काही होते. सर्व बदल क्लायंटसाठी पूर्णपणे अखंडपणे होतात. हेच अहवाल स्विच करण्यासाठी जाते. जेव्हा वेळ येते तेव्हा अहवाल आणि इंटरफेस बदलतात.

व्लादिमीर: तसेच, टाइमलाइनमध्ये अहवाल सुरू करण्यासाठी वेळ कटऑफ आहेत. अगदी सुरुवातीला काहीच नाही. आणि जर तुम्ही तुमचा माऊस लाल पट्टीवर फिरवला, तर काही क्षणी, ब्रॉडकास्ट डायरेक्टरचे आभार, कटऑफ दिसतील. डायरेक्टर ब्रॉडकास्टची योग्य सुरुवात सेट करतो, बॅकएंड हा बदल उचलतो, कॉन्फरन्स शेड्यूलनुसार संपूर्ण ट्रॅकच्या प्रेझेंटेशनची सुरुवात आणि शेवटची वेळ मोजतो, आमच्या क्लायंटला पाठवतो आणि खेळाडू कटऑफ काढतो. आता वापरकर्ता अहवालाच्या सुरूवातीस आणि शेवटी सहजपणे नेव्हिगेट करू शकतो. ही एक कठोर व्यवसाय आवश्यकता होती, अतिशय सोयीस्कर आणि उपयुक्त. अहवालासाठी वास्तविक प्रारंभ वेळ शोधण्यात तुम्ही वेळ वाया घालवू नका. आणि जेव्हा आम्ही पूर्वावलोकन करतो, तेव्हा ते पूर्णपणे आश्चर्यकारक असेल.

तैनाती

— मला तैनातीबद्दल विचारायचे आहे. कोल्या आणि टीमने संपूर्ण इन्फ्रास्ट्रक्चर सेट करण्यासाठी सुरुवातीला बराच वेळ घालवला ज्यामध्ये आमच्यासाठी सर्वकाही उलगडले. मला सांगा, हे सर्व कशापासून बनलेले आहे?

निकोले: तांत्रिक दृष्टिकोनातून, आम्हाला सुरुवातीला उत्पादन कोणत्याही विक्रेत्याकडून शक्य तितके अमूर्त असण्याची आवश्यकता होती. टेराफॉर्म स्क्रिप्ट्स विशेषतः AWS वरून किंवा विशेषत: Yandex वरून किंवा Azure वरून तयार करण्यासाठी AWS वर या. खरोखर बसत नाही. कधीतरी कुठेतरी हलवायचे होते.

पहिले तीन आठवडे आम्ही हे अधिक चांगले करण्याचा मार्ग सतत शोधत होतो. परिणामी, आम्ही या निष्कर्षापर्यंत पोहोचलो की या प्रकरणात कुबर्नेट्स हेच आमचे सर्वस्व आहे, कारण ते आम्हाला स्वयंचलितपणे स्केलिंग सेवा, स्वयं-रोलआउट तयार करण्यास आणि बॉक्सच्या बाहेर जवळजवळ सर्व सेवा मिळविण्याची अनुमती देते. साहजिकच, सर्व सेवांना कुबर्नेट्स, डॉकर यांच्यासोबत काम करण्यासाठी प्रशिक्षित करावे लागले आणि संघालाही शिकावे लागले.

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

आम्हाला त्वरीत (१० मिनिटांच्या आत बॅकएंडसाठी, ५ मिनिटांच्या आत फ्रंटएंडसाठी) कोणत्याही वातावरणात सर्व चाचण्या, एकत्रीकरण, कार्यरत कार्यात्मक चाचण्या, पर्यावरणावरील एकत्रीकरण चाचण्या आणि लोड चाचण्यांसह चाचणी घेण्याची संधी मिळते. चाचणी वातावरण अंदाजे समान गोष्ट आहे जी आम्हाला उत्पादनात मिळवायची आहे.

चाचण्यांबद्दल

- आपण जवळजवळ प्रत्येक गोष्टीची चाचणी घेत आहात, आपण सर्वकाही कसे लिहिले यावर विश्वास ठेवणे कठीण आहे. तुम्ही आम्हाला बॅकएंड चाचण्यांबद्दल सांगू शकता: सर्वकाही किती कव्हर केले आहे, कोणत्या चाचण्या आहेत?

व्लादिमीर: दोन प्रकारच्या चाचण्या लिहिल्या आहेत. प्रथम घटक चाचण्या आहेत. संपूर्ण स्प्रिंग ऍप्लिकेशनच्या लिफ्ट लेव्हल चाचण्या आणि बेस इन चाचणी कंटेनर. ही उच्चस्तरीय व्यावसायिक परिस्थितीची चाचणी आहे. मी फंक्शन्सची चाचणी करत नाही. आम्ही फक्त काही मोठ्या गोष्टींची चाचणी घेतो. उदाहरणार्थ, चाचणीमध्ये, वापरकर्त्याला लॉग इन करण्याची प्रक्रिया अनुकरण केली जाते, वापरकर्त्याने तो जिथे जाऊ शकतो तिकीटांसाठी केलेली विनंती आणि प्रवाह पाहण्यासाठी प्रवेशासाठी विनंती. अतिशय स्पष्ट वापरकर्ता परिस्थिती.

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

याक्षणी माझ्याकडे सुमारे 70 घटक चाचण्या आणि सुमारे 40 एकत्रीकरण चाचण्या आहेत. कव्हरेज 95% च्या अगदी जवळ आहे. हे घटकांसाठी आहे, एकत्रीकरणासाठी कमी आहे, इतके आवश्यक नाही. प्रकल्पामध्ये सर्व प्रकारच्या कोड जनरेशनचा समावेश आहे हे लक्षात घेता, हे एक अतिशय चांगले सूचक आहे. तीन महिन्यांत आम्ही जे केले ते करण्याचा दुसरा मार्ग नव्हता. कारण जर आम्ही व्यक्तिचलितपणे चाचणी केली, आमच्या परीक्षकाला वैशिष्ट्ये दिली, आणि ती दोष शोधून आम्हाला निराकरणासाठी परत करेल, तर कोड डीबग करण्यासाठी हा राउंड ट्रिप खूप लांब असेल आणि आम्ही कोणत्याही मुदतीची पूर्तता करणार नाही.

निकोले: पारंपारिकपणे, काही फंक्शन बदलताना संपूर्ण प्लॅटफॉर्मवर प्रतिगमन करण्यासाठी, तुम्हाला दोन दिवस सर्वत्र बसून पोक करणे आवश्यक आहे.

व्लादिमीर: म्हणून, हे एक मोठे यश आहे की जेव्हा मी एखाद्या वैशिष्ट्याचा अंदाज लावतो तेव्हा मी म्हणतो की मला दोन साध्या पेन आणि 4 वेबसॉकेटसाठी 1 दिवस हवे आहेत, कोल्या त्यास परवानगी देतो. या 4 दिवसांमध्ये 2 प्रकारच्या चाचण्यांचा समावेश आहे आणि नंतर बहुधा ते कार्य करेल याची त्याला आधीपासूनच सवय आहे.

निकोले: माझ्याकडे 140 चाचण्या देखील लिहिलेल्या आहेत: घटक + कार्यात्मक, जे समान कार्य करतात. सर्व समान परिस्थिती उत्पादनात, चाचणीमध्ये आणि उत्पादनामध्ये तपासल्या जातात. आम्ही अलीकडे कार्यशील मूलभूत UI चाचण्या देखील जोडल्या आहेत. अशा प्रकारे आम्ही सर्वात मूलभूत कार्यक्षमता कव्हर करतो जी खाली पडू शकते.

व्लादिमीर: अर्थात, लोड चाचण्यांबद्दल बोलणे योग्य आहे. सर्वकाही कसे आहे, सशाचे काय होत आहे, जेव्हीएममध्ये काय घडत आहे, प्रत्यक्षात किती मेमरी आवश्यक आहे हे समजून घेण्यासाठी प्लॅटफॉर्मची खऱ्या जवळ असलेल्या लोडखाली चाचणी करणे आवश्यक होते.

— आम्ही प्रवाहाच्या बाजूला कशाचीही चाचणी करत आहोत की नाही हे मला निश्चितपणे माहित नाही, परंतु मला आठवते की जेव्हा आम्ही भेटलो तेव्हा ट्रान्सकोडर्समध्ये समस्या होत्या. आम्ही प्रवाहांची चाचणी घेतली आहे का?

आर्टिओम: पुनरावृत्ती चाचणी केली. बैठकांचे आयोजन. मीटअप आयोजित करण्याच्या प्रक्रियेत, जवळपास 2300 JIRA तिकिटे होती. या फक्त सामान्य गोष्टी आहेत ज्या लोकांनी मीटअप करण्यासाठी केल्या. आम्ही प्लॅटफॉर्मचे काही भाग मीटअप्ससाठी वेगळ्या पृष्ठावर घेतले, जे किरिल टोल्काचेव्ह (talkkv).

खरे सांगायचे तर, कोणतीही मोठी समस्या नव्हती. अक्षरशः काही वेळा आम्ही क्लाउडफ्रंटवर कॅशिंग बग्स पकडले, आम्ही ते खूप लवकर सोडवले - आम्ही फक्त धोरणे पुन्हा कॉन्फिगर केली. साइटवरील स्ट्रीमिंग सिस्टममध्ये लोकांमध्ये लक्षणीयरीत्या अधिक बग होते.

कॉन्फरन्स दरम्यान, मला अधिक उपकरणे आणि सेवा समाविष्ट करण्यासाठी अनेक निर्यातदार लिहावे लागले. काही ठिकाणी फक्त मेट्रिक्ससाठी मला स्वतःच्या सायकली बनवाव्या लागल्या. AV (ऑडिओ-व्हिडिओ) हार्डवेअरचे जग फारसे गुलाबी नाही - तुमच्याकडे काही प्रकारचे “API” उपकरणे आहेत ज्यावर तुम्ही प्रभाव टाकू शकत नाही. आणि आपल्याला आवश्यक असलेली माहिती मिळवण्यात आपण सक्षम असाल हे वास्तवापासून दूर आहे. हार्डवेअर विक्रेते खरोखरच मंद असतात आणि त्यांच्याकडून तुम्हाला हवे ते मिळवणे जवळजवळ अशक्य आहे. एकूण 100 पेक्षा जास्त हार्डवेअरचे तुकडे आहेत, ते आपल्याला आवश्यक असलेले परत देत नाहीत आणि आपण विचित्र आणि अनावश्यक निर्यातदार लिहितो, ज्यामुळे आपण किमान कसा तरी सिस्टम डीबग करू शकता.

उपकरणे

- मला आठवते की परिषद सुरू होण्यापूर्वी आम्ही अंशतः अतिरिक्त उपकरणे कशी खरेदी केली.

आर्टिओम: आम्ही संगणक, लॅपटॉप आणि बॅटरी पॅक खरेदी केले. या क्षणी आपण विजेशिवाय 40 मिनिटे जगू शकतो. जूनमध्ये सेंट पीटर्सबर्गमध्ये जोरदार गडगडाटी वादळे होते - म्हणून आमच्याकडे असा ब्लॅकआउट होता. त्याच वेळी, अनेक प्रदाते वेगवेगळ्या बिंदूंमधून ऑप्टिकल लिंक्स घेऊन आमच्याकडे येतात. हा खरोखर 40 मिनिटांचा बिल्डिंग डाउनटाइम आहे, ज्या दरम्यान आमच्याकडे दिवे चालू असतील, ध्वनी, कॅमेरे इ.

- आमच्याकडे इंटरनेटशी समान कथा आहे. ज्या ऑफिसमध्ये आमचे स्टुडिओ आहेत, तिथल्या मजल्यांमध्ये आम्ही भयंकर जाळी ओढली.

आर्टिओम: आमच्याकडे मजल्यांमध्ये 20 Gbit फायबर आहे. मजल्यांच्या पुढे, कुठेतरी ऑप्टिक्स आहे, कुठेतरी ऑप्टिक्स नाही, परंतु तरीही गीगाबिटपेक्षा कमी चॅनेल आहेत - आम्ही कॉन्फरन्सच्या ट्रॅक दरम्यान व्हिडिओ चालवतो. सर्वसाधारणपणे, तुमच्या स्वतःच्या पायाभूत सुविधांवर काम करणे खूप सोयीचे असते; तुम्ही हे क्वचितच साइटवरील ऑफलाइन कॉन्फरन्समध्ये करू शकता.

— मी JUG Ru ग्रुपमध्ये काम करण्यापूर्वी, मी पाहिले की ऑफलाइन कॉन्फरन्समध्ये हार्डवेअर रूम्स रात्रभर कशा सेट केल्या जातात, जिथे तुम्ही Grafana मध्ये तयार करता त्या सर्व मेट्रिक्ससह एक मोठा मॉनिटर होता. आता मुख्यालयाची खोली देखील आहे ज्यामध्ये विकास कार्यसंघ बसतो, जो कॉन्फरन्स दरम्यान काही दोष दूर करतो आणि वैशिष्ट्ये विकसित करतो. त्याच वेळी, एक मॉनिटरिंग सिस्टम आहे जी मोठ्या स्क्रीनवर प्रदर्शित केली जाते. आर्टिओम, कोल्या आणि इतर मुले बसतात आणि हे सर्व पडणार नाही याची खात्री करतात आणि सुंदरपणे कार्य करतात.

जिज्ञासा आणि समस्या

— आमच्याकडे Amazon सोबत स्ट्रीमिंग आहे, वेबवर एक प्लेअर आहे, सर्व काही वेगवेगळ्या प्रोग्रामिंग भाषांमध्ये लिहिलेले आहे, कायदेशीर संस्थांसाठी समर्थित असलेल्या वैयक्तिक खात्यासह दोष सहिष्णुता आणि इतर व्यवसाय आवश्यकता प्रदान केल्या आहेत या वस्तुस्थितीबद्दल तुम्ही चांगले बोललात आणि व्यक्ती, आणि आम्ही OAuth 2.0 वापरून एखाद्याशी समाकलित करू शकतो, फसवणूक विरोधी, वापरकर्ता अवरोधित करणे आहे. आम्ही बदल डायनॅमिकरित्या रोल आउट करू शकतो कारण आम्ही ते चांगले केले आणि हे सर्व तपासले गेले आहे.

काहीतरी सुरू करण्यात कोणत्या विचित्र गोष्टींचा समावेश होता हे जाणून घेण्यात मला रस आहे. जेव्हा तुम्ही बॅकएंड, फ्रंटएंड विकसित करत असाल तेव्हा काही विचित्र परिस्थिती आली आहे का, काहीतरी वेडे झाले आहे आणि त्याचे काय करावे हे तुम्हाला समजले नाही?

व्लादिमीर: हे गेल्या तीन महिन्यांपासूनच घडले आहे असे मला वाटते. रोज. जसे तुम्ही बघू शकता, माझे सर्व केस बाहेर काढले गेले आहेत.

व्लादिमीर क्रॅसिलिशिक 3 महिन्यांनंतर, जेव्हा एक प्रकारचा खेळ निघाला आणि त्याचे काय करावे हे कोणालाही समजले नाही

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

निकोले: आणि टेकट्रेनच्या एक तासापूर्वी रिलीज झाली.

बरेच तारे येथे संरेखित होते. आम्ही खूप भाग्यवान होतो कारण आमच्याकडे एक सुपर टीम होती आणि प्रत्येकजण ते ऑनलाइन करण्याच्या कल्पनेने प्रेरित झाला होता. हे तीन महिने आम्ही "YouTube बनवले" या वस्तुस्थितीमुळे प्रेरित होतो. मी स्वत: ला माझे केस फाडण्याची परवानगी दिली नाही, परंतु प्रत्येकाला सांगितले की सर्वकाही कार्य करेल, कारण खरं तर, सर्वकाही खूप पूर्वी मोजले गेले होते.

कामगिरीबद्दल

— एका ट्रॅकवर साइटवर किती लोक होते ते तुम्ही मला सांगू शकता? काही कार्यप्रदर्शन समस्या होत्या का?

निकोले: आम्ही आधीच म्हटल्याप्रमाणे कार्यप्रदर्शनात कोणतीही समस्या नव्हती. एका अहवालात सहभागी झालेल्या लोकांची कमाल संख्या 1300 लोक होती, हे हायझेनबगवर आहे.

— स्थानिक पाहण्यात काही समस्या होत्या का? आणि हे सर्व कसे कार्य करते याचे आकृत्यांसह तांत्रिक वर्णन करणे शक्य आहे का?

निकोले: याबद्दल आम्ही नंतर एक लेख बनवू.

तुम्ही स्थानिक पातळीवर प्रवाह डीबग देखील करू शकता. एकदा कॉन्फरन्स सुरू झाल्या की, ते आणखी सोपे झाले, कारण उत्पादन प्रवाह दिसले की आम्ही सर्व वेळ पाहू शकतो.

व्लादिमीर: जसे मला समजले आहे, फ्रंट-एंड डेव्हलपर्सने स्थानिक पातळीवर मॉकसह काम केले आणि नंतर, समोरील डेव्हसवर रोल आउट करण्याची वेळ देखील कमी असल्याने (5 मिनिटे), प्रमाणपत्रांसह काय चालले आहे ते तपासण्यात कोणतीही समस्या नाही.

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

व्लादिमीर: तुम्ही ते घेऊ शकता आणि ते पुन्हा करू शकता.

- 3 महिन्यांत.

परिणाम

— एकत्रितपणे वर्णन केलेल्या सर्व गोष्टी छान वाटतात, कारण हे एका छोट्या टीमने तीन महिन्यांत केले आहे.

निकोले: मोठी टीम हे करणार नाही. परंतु लोकांचा एक लहान गट जो एकमेकांशी अगदी जवळून आणि चांगला संवाद साधतो आणि करार करू शकतो. त्यांच्यात कोणताही विरोधाभास नाही, आर्किटेक्चरचा शोध दोन दिवसांत लावला गेला, अंतिम झाला आणि प्रत्यक्षात बदलला नाही. वैशिष्ट्य विनंत्या आणि बदल जमा करण्याच्या दृष्टीने येणार्‍या व्यवसाय आवश्यकतांची अतिशय कठोर सुविधा आहे.

- उन्हाळ्याच्या परिषदा झाल्या होत्या तेव्हा तुमच्या पुढील कार्यांच्या यादीत काय होते?

निकोले: उदाहरणार्थ, क्रेडिट्स. व्हिडिओवर रेंगाळणाऱ्या रेंगा, दाखवल्या जात असलेल्या सामग्रीवर अवलंबून व्हिडिओमध्ये काही ठिकाणी पॉप-अप. उदाहरणार्थ, स्पीकरला श्रोत्यांना प्रश्न विचारायचा आहे आणि एक मत स्क्रीनवर पॉप अप होते, जे स्वतः स्पीकरला मतदानाच्या निकालांच्या आधारे मागे जाते. सादरीकरणादरम्यानच अहवालाच्या लाइक्स, हार्ट्स, रेटिंग या स्वरूपात काही प्रकारचे सामाजिक क्रियाकलाप, जेणेकरून तुम्ही फीडबॅक फॉर्मद्वारे नंतर विचलित न होता योग्य क्षणी फीडबॅक भरू शकता. सुरुवातीला असे.

आणि संपूर्ण प्लॅटफॉर्मवर जोडणे, स्ट्रीमिंग आणि कॉन्फरन्स वगळता, कॉन्फरन्सनंतरची स्थिती देखील. या प्लेलिस्ट आहेत (वापरकर्त्यांनी संकलित केलेल्यांसह), शक्यतो इतर मागील कॉन्फरन्समधील सामग्री, एकात्मिक, लेबल केलेली, वापरकर्त्यासाठी प्रवेशयोग्य आणि आमच्या वेबसाइटवर पाहण्यासाठी देखील उपलब्ध आहे (live.jugru.org).

- मित्रांनो, तुमच्या उत्तरांसाठी खूप खूप धन्यवाद!

जर वाचकांमध्ये आमच्या उन्हाळी परिषदांमध्ये सहभागी झालेले लोक असतील, तर कृपया प्लेअर आणि ब्रॉडकास्टबद्दलचे तुमचे इंप्रेशन शेअर करा. काय सोयीचे होते, तुम्हाला काय चिडवले, तुम्हाला भविष्यात काय पहायचे आहे?

जर तुम्हाला प्लॅटफॉर्ममध्ये स्वारस्य असेल आणि ते "युद्धात" पहायचे असेल, तर आम्ही ते आमच्यावर पुन्हा वापरतो शरद ऋतूतील-हिवाळी परिषद. त्यांची संपूर्ण श्रेणी आहे, त्यामुळे तुमच्यासाठी योग्य असलेली एक नक्कीच आहे.

स्त्रोत: www.habr.com