ამ გაზაფხულზე ძალიან ხალისიან პირობებში აღმოვჩნდით. პანდემიის გამო, ცხადი გახდა, რომ ჩვენი საზაფხულო კონფერენციები საჭიროებდა ონლაინ გადატანას. და იმისათვის, რომ ისინი ეფექტურად ჩაგვეტარებინა ონლაინ რეჟიმში, მზა პროგრამული გადაწყვეტილებები არ იყო ჩვენთვის შესაფერისი; ჩვენ გვჭირდებოდა საკუთარი თავის დაწერა. და ჩვენ სამი თვე გვქონდა ამის გასაკეთებლად.

ნათელია, რომ ეს იყო საინტერესო სამი თვე. მაგრამ გარედან მთლად აშკარა არ არის: რა არის ონლაინ კონფერენციის პლატფორმა? რა ნაწილებისგან შედგება? ამიტომ, ზაფხულის ბოლო DevOops კონფერენციებზე ვკითხე მათ, ვინც პასუხისმგებელი იყო ამ დავალებაზე:

• ნიკოლაი მოლჩანოვი - JUG Ru Group-ის ტექნიკური დირექტორი;
• ვლადიმირ კრასილშჩიკი არის პრაგმატული Java პროგრამისტი, რომელიც მუშაობს backend-ზე (მისი მოხსენებები შეგიძლიათ ნახოთ ჩვენს Java კონფერენციებზე);
• არტიომ ნიკონოვი პასუხისმგებელია ჩვენს ყველა ვიდეო სტრიმინგზე.

სხვათა შორის, შემოდგომა-ზამთრის კონფერენციებზე გამოვიყენებთ იმავე პლატფორმის გაუმჯობესებულ ვერსიას - ამდენი ჰაბრა მკითხველი მაინც იქნება მისი მომხმარებელი.

Დიდი სურათი

- როგორი იყო გუნდის შემადგენლობა?

ნიკოლაი მოლჩანოვი: ჩვენ გვყავს ანალიტიკოსი, დიზაინერი, ტესტერი, სამი წინა ნაწილი და უკანა ნაწილი. და, რა თქმა უნდა, T- ფორმის სპეციალისტი!

— როგორ გამოიყურებოდა პროცესი ზოგადად?

ნიკოლაი: მარტის შუა რიცხვებამდე საერთოდ არაფერი გვქონდა მზად ონლაინ რეჟიმში. 15 მარტს კი მთელმა ონლაინ კარუსელმა დაიწყო ტრიალი. მოვაწყვეთ რამდენიმე საცავი, დავგეგმეთ, განვიხილეთ ძირითადი არქიტექტურა და ყველაფერი გავაკეთეთ სამ თვეში.

ამან, რა თქმა უნდა, გაიარა დაგეგმვის, არქიტექტურის, ფუნქციების შერჩევის, ამ მახასიათებლების ხმის მიცემის, ამ მახასიათებლების პოლიტიკის, მათი დიზაინის, განვითარების, ტესტირების კლასიკური ეტაპები. შედეგად, 6 ივნისს, ჩვენ ყველაფერი გამოვიტანეთ წარმოებაში. TechTrain. ყველაფრისთვის იყო 90 დღე.

- შევძელით თუ არა იმის ასრულება, რისი ვალდებულებაც გვაქვს?

ნიკოლაი: ვინაიდან ჩვენ ახლა ვმონაწილეობთ DevOops კონფერენციაში ონლაინ, ეს ნიშნავს, რომ ის მუშაობდა. მე პირადად ერთგული ვარ მთავარის: მომხმარებელს მივუტან ინსტრუმენტს, რომლითაც მათ შეუძლიათ ონლაინ კონფერენციის გაკეთება.

გამოწვევა ასეთი იყო: მოგვეცით ინსტრუმენტი, რომლითაც შეგვიძლია ჩვენი კონფერენციების გადაცემა ბილეთების მფლობელებისთვის.

ყველა დაგეგმვა დაყოფილი იყო რამდენიმე ეტაპად და ყველა მახასიათებელი (დაახლოებით 30 გლობალური) დაყოფილი იყო 4 კატეგორიად:

• რასაც ჩვენ აუცილებლად გავაკეთებთ (მათ გარეშე ვერ ვიცხოვრებთ),
• რასაც ჩვენ მეორედ გავაკეთებთ,
• რასაც ჩვენ არასდროს გავაკეთებთ,
• და რასაც ჩვენ არასდროს, არასდროს გავაკეთებთ.

ჩვენ შევქმენით ყველა ფუნქცია პირველი ორი კატეგორიიდან.

— ვიცი, რომ სულ 600 JIRA-ს ნომერი შეიქმნა. სამ თვეში თქვენ გააკეთეთ 13 მიკროსერვისი და მეეჭვება, რომ ისინი არამარტო ჯავაზე დაიწერა. თქვენ იყენებდით სხვადასხვა ტექნოლოგიებს, გაქვთ ორი Kubernetes კლასტერი სამ ხელმისაწვდომობის ზონაში და 5 RTMP ნაკადი ამაზონში.

ახლა მოდით შევხედოთ სისტემის თითოეულ კომპონენტს ცალკე.

სტრიმინგი

— დავიწყოთ იქიდან, როცა უკვე გვაქვს ვიდეო გამოსახულება და ის გადაეცემა ზოგიერთ სერვისს. არტიომ, გვითხარი, როგორ ხდება ეს ნაკადი?

არტიომ ნიკონოვი: ჩვენი ზოგადი სქემა ასე გამოიყურება: სურათი კამერიდან -> ჩვენი მართვის ოთახი -> ლოკალური RTMP სერვერი -> Amazon -> ვიდეო პლეერი. Უფრო ვრცლად დაწერა ამის შესახებ ჰაბრეზე ივნისში.

ზოგადად, ამის გაკეთების ორი გლობალური გზა არსებობს: ან აპარატურაზე ან პროგრამული გადაწყვეტილებების საფუძველზე. ჩვენ ავირჩიეთ პროგრამული მარშრუტი, რადგან ეს უფრო ადვილია დისტანციური დინამიკების შემთხვევაში. ყოველთვის არ არის შესაძლებელი სხვა ქვეყანაში დინამიკთან ტექნიკის მიტანა, მაგრამ სპიკერისთვის პროგრამული უზრუნველყოფის მიწოდება უფრო ადვილი და საიმედო ჩანს.

ტექნიკის თვალსაზრისით, ჩვენ გვაქვს გარკვეული რაოდენობის კამერები (ჩვენს სტუდიებში და დისტანციურ დინამიკებზე), გარკვეული რაოდენობის დისტანციური მართვის პულტი სტუდიაში, რომლებიც ზოგჯერ უნდა შეკეთდეს პირდაპირ მაგიდის ქვეშ გადაცემის დროს.

ამ მოწყობილობებიდან სიგნალები შედიან კომპიუტერებში გადაღების ბარათებით, შეყვანის/გამოსვლის ბარათებით და ხმის ბარათებით. იქ სიგნალები შერეულია და იკრიბება განლაგებებად:

4 დინამიკისთვის განლაგების მაგალითი

4 დინამიკისთვის განლაგების მაგალითი

გარდა ამისა, უწყვეტი მაუწყებლობა უზრუნველყოფილია სამი კომპიუტერის დახმარებით: არის ერთი მთავარი მანქანა და წყვილი მუშა. პირველი კომპიუტერი აგროვებს პირველ ანგარიშს, მეორე - შესვენებას, პირველი - მომდევნო ანგარიშს, მეორე - მომდევნო შესვენებას და ა.შ. და მთავარი მანქანა ურევს პირველს მეორეს.

ეს ქმნის ერთგვარ სამკუთხედს და თუ რომელიმე ამ კვანძიდან ვერ ხერხდება, ჩვენ შეგვიძლია სწრაფად და ხარისხის დაკარგვის გარეშე გავაგრძელოთ კონტენტის მიწოდება კლიენტებისთვის. ასეთი სიტუაცია გვქონდა. კონფერენციების პირველ კვირას დავაფიქსირეთ ერთი მანქანა, ჩავრთეთ/გამორთეთ. ხალხი, როგორც ჩანს, კმაყოფილია ჩვენი გამძლეობით.

შემდეგი, კომპიუტერებიდან ნაკადები გადადის ლოკალურ სერვერზე, რომელსაც აქვს ორი ამოცანა: RTMP ნაკადების მარშრუტი და ჩანაწერის სარეზერვო ასლები. ასე რომ, ჩვენ გვაქვს მრავალი ჩაწერის წერტილი. შემდეგ ვიდეო ნაკადები იგზავნება ჩვენი სისტემის ნაწილზე, რომელიც აგებულია Amazon SaaS სერვისებზე. Ჩვენ ვიყენებთ MediaLive,S3,CloudFront.

ნიკოლაი: რა ხდება იქ სანამ ვიდეო მიაღწევს აუდიტორიას? როგორმე უნდა გაჭრა, არა?

არტიომი: ჩვენ ვაკუმშებთ ვიდეოს ჩვენი მხრიდან და ვუგზავნით MediaLive-ს. ჩვენ იქ გავუშვით ტრანსკოდერები. ისინი ვიდეოებს რეალურ დროში გადააქვთ რამდენიმე რეზოლუციად, რათა ხალხმა შეძლოს მათი ყურება ტელეფონებით, ქვეყანაში ცუდი ინტერნეტის საშუალებით და ა.შ. შემდეგ ეს ნაკადები იჭრება ნაჭრები, ასე მუშაობს პროტოკოლი HLS. ჩვენ ვუგზავნით დასაკრავ სიას ფრონტზე, რომელიც შეიცავს მითითებებს ამ ნაწილებზე.

— ვიყენებთ 1080p გარჩევადობას?

არტიომი: ჩვენი ვიდეოს სიგანე იგივეა, რაც 1080p - 1920 პიქსელი, სიმაღლე კი ოდნავ ნაკლები, სურათი უფრო წაგრძელებული - ამის მიზეზები არსებობს.

მოთამაშე

— არტიომ აღწერა, თუ როგორ ხვდება ვიდეო სტრიმინგში, როგორ ნაწილდება ის სხვადასხვა დასაკრავ სიაში ეკრანის სხვადასხვა გარჩევადობისთვის, ნაწილებად იჭრება და ხვდება პლეერში. კოლია, ახლა მითხარი, როგორი მოთამაშეა ეს, როგორ მოიხმარს სტრიმინგს, რატომ HLS?

ნიკოლაი: ჩვენ გვყავს მოთამაშე, რომლის ყურებაც კონფერენციის ყველა მაყურებელს შეუძლია.

არსებითად, ეს არის შეფუთვა ბიბლიოთეკის გარშემო hls.js, რომელზედაც ბევრი სხვა მოთამაშეა დაწერილი. მაგრამ ჩვენ გვჭირდებოდა ძალიან სპეციფიკური ფუნქციონირება: გადახვევა და მონიშვნა იმ ადგილის შესახებ, სადაც ადამიანი იმყოფება, რა რეპორტაჟს უყურებს ის ამჟამად. ჩვენ ასევე გვჭირდებოდა საკუთარი განლაგება, ყველა სახის ლოგოტიპი და ყველაფერი, რაც ჩვენთან იყო აშენებული. ამიტომ, ჩვენ გადავწყვიტეთ დაგვეწერა საკუთარი ბიბლიოთეკა (შეფუთვა HLS-ზე) და ჩავსვათ იგი საიტზე.

ეს არის root ფუნქცია, ამიტომ იგი განხორციელდა თითქმის პირველი. და შემდეგ ყველაფერი გაიზარდა მის გარშემო.

ფაქტობრივად, ავტორიზაციის საშუალებით, მოთამაშე იღებს დასაკრავი სიას ბმულებით ნაწილებთან, რომლებიც დაკავშირებულია დროსა და ხარისხთან, ჩამოტვირთავს საჭიროებს და უჩვენებს მათ მომხმარებელს, ახორციელებს გარკვეულ „ჯადოსნობას“ გზაზე.

ვადების მაგალითი

— ღილაკი ჩაშენებულია პირდაპირ მოთამაშეში, რათა აჩვენოს ყველა მოხსენების ვადები...

ნიკოლაი: დიახ, ჩვენ მაშინვე მოვაგვარეთ მომხმარებლის ნავიგაციის პრობლემა. აპრილის შუა რიცხვებში გადავწყვიტეთ, რომ ყოველი ჩვენი კონფერენცია ცალკე ვებსაიტზე არ გადაგვეტანა, მაგრამ ყველაფერი ერთზე გავაერთიანოთ. ისე, რომ Full Pass ბილეთების მომხმარებლებს შეუძლიათ თავისუფლად გადაერთონ სხვადასხვა კონფერენციებს შორის: როგორც პირდაპირ ეთერში, ასევე წარსულის ჩანაწერებს.

და იმისთვის, რომ მომხმარებლებმა გაუადვილდეს მიმდინარე ნაკადზე ნავიგაცია და ტრეკებს შორის გადართვა, გადავწყვიტეთ შეგვექმნა ღილაკი „მთელი მაუწყებლობა“ და ჰორიზონტალური ანგარიშის ბარათები ტრეკებსა და ანგარიშებს შორის გადართვისთვის. არის კლავიატურის კონტროლი.

- რაიმე ტექნიკური სირთულე იყო ამ მხრივ?

ნიკოლაი: მათ ჰქონდათ გადახვევის ზოლი, რომელზეც მონიშნული იყო სხვადასხვა მოხსენების საწყისი წერტილები.

— საბოლოოდ, განახორციელეთ ეს ნიშნები გადახვევის ზოლზე, სანამ YouTube მსგავსი რამ გააკეთებდა?

არტიომი: ბეტაში ჰქონდათ მაშინ. როგორც ჩანს, ეს საკმაოდ რთული ფუნქციაა, რადგან ისინი ნაწილობრივ ამოწმებდნენ მას მომხმარებლებს გასული წლის განმავლობაში. ახლა კი გაყიდვაში მიაღწია.

ნიკოლაი: მაგრამ ჩვენ რეალურად მივიღეთ ის უფრო სწრაფად გასაყიდად. პატიოსნად, ამ მარტივი მახასიათებლის მიღმა მოთამაშის შიგნით არის დიდი რაოდენობით backend, frontend, გამოთვლები და მათემატიკა.

ფრონტენდი

— მოდით გავარკვიოთ, როგორ ხვდება ეს კონტენტი, რომელსაც ჩვენ ვაჩვენებთ (სამეტყველო ბარათი, დინამიკები, ვებსაიტი, განრიგი) ფრონტზე?

ვლადიმერ კრასილშჩიკი: გვაქვს რამდენიმე შიდა IT სისტემა. არის სისტემა, რომელშიც შეყვანილია ყველა ანგარიში და ყველა სპიკერი. არის პროცესი, რომლითაც მომხსენებელი იღებს მონაწილეობას კონფერენციაში. სპიკერი წარადგენს განცხადებას, სისტემა იჭერს მას, შემდეგ არის გარკვეული მილსადენი, რომლის მიხედვითაც იქმნება ანგარიში.

ასე ხედავს მომხსენებელი მილსადენს

ეს სისტემა ჩვენი შიდა განვითარებაა.

შემდეგი, თქვენ უნდა ააწყოთ გრაფიკი ინდივიდუალური ანგარიშებიდან. მოგეხსენებათ, ეს NP-მყარი პრობლემაა, მაგრამ ჩვენ როგორღაც მოვაგვარებთ მას. ამისათვის ჩვენ გავუშვით კიდევ ერთი კომპონენტი, რომელიც ქმნის განრიგს და ატვირთავს მას მესამე მხარის ღრუბლოვან სერვისში Contentful. იქ ყველაფერი უკვე ჰგავს მაგიდას, რომელშიც არის კონფერენციის დღეები, დღეებში არის დროის სლოტები, ხოლო სლოტებში არის მოხსენებები, შესვენებები ან სპონსორობა. ამრიგად, კონტენტი, რომელსაც ჩვენ ვხედავთ, მდებარეობს მესამე მხარის სერვისში. და ამოცანაა მისი გადმოცემა საიტზე.

როგორც ჩანს, საიტი მხოლოდ გვერდია მოთამაშით და აქ არაფერია რთული. გარდა იმისა, რომ არ არის. ამ გვერდის უკან ბექენდი მიდის Contentful-ზე, იღებს განრიგს იქიდან, ქმნის რამდენიმე ობიექტს და აგზავნის ფრონტენდში. ვებსოკეტის კავშირის გამოყენებით, რომელსაც ჩვენი პლატფორმის ყველა კლიენტი აკეთებს, ჩვენ ვუგზავნით მას განრიგის განახლებას ბექენდიდან ფრონტენტამდე.

რეალური შემთხვევა: მომხსენებელმა სამუშაო ადგილი შეცვალა კონფერენციის დროს. ჩვენ უნდა შევცვალოთ მისი დამსაქმებლის კომპანიის სამკერდე ნიშანი. როგორ ხდება ეს უკანა ნაწილიდან? განახლება ეგზავნება ყველა კლიენტს websocket-ის მეშვეობით, შემდეგ კი ფრონტენტი თავად გადახაზავს ვადებს. ეს ყველაფერი უპრობლემოდ ხდება. ღრუბლოვანი სერვისისა და ჩვენი რამდენიმე კომპონენტის ერთობლიობა გვაძლევს შესაძლებლობას შევქმნათ მთელი ეს შინაარსი და მივაწოდოთ იგი წინა მხარეს.

ნიკოლაი: მნიშვნელოვანია აქ განვმარტოთ, რომ ჩვენი საიტი არ არის კლასიკური SPA აპლიკაცია. ეს არის განლაგებაზე დაფუძნებული, გაწეული ვებსაიტი და SPA. Google რეალურად ხედავს ამ საიტს, როგორც HTML. ეს კარგია SEO-სთვის და მომხმარებლისთვის შინაარსის მიწოდებისთვის. ის არ ელოდება 1,5 მეგაბაიტი JavaScript-ის ჩატვირთვას გვერდის ნახვის წინ, ის მაშინვე ხედავს უკვე გაფორმებულ გვერდს და თქვენ გრძნობთ ამას ყოველ ჯერზე, როცა ანგარიშს გადართავთ. ყველაფერი ნახევარ წამში ხდება, ვინაიდან კონტენტი უკვე მზადაა და სწორ ადგილას არის განთავსებული.

— მოდით, ხაზი გავუსვათ ყოველივე ზემოთქმულს ტექნოლოგიების ჩამოთვლით. ტიომამ თქვა, რომ ჩვენ გვაქვს ამაზონის 5 ნაკადი და იქ ვაწვდით ვიდეოს და ხმას. ჩვენ გვაქვს bash სკრიპტები, მათ ვიყენებთ გასაშვებად და კონფიგურაციისთვის...

არტიომი: ეს ხდება AWS API-ს მეშვეობით, იქ კიდევ ბევრი ტექნიკური გვერდითი სერვისია. ჩვენ გავნაწილდით ჩვენი პასუხისმგებლობები ისე, რომ მივაწოდო CloudFront, და ფრონტ-ენდის და უკანა ნაწილის დეველოპერები მას იქიდან იღებენ. ჩვენ გვაქვს მთელი რიგი ჩვენი საკინძები შინაარსის განლაგების გასამარტივებლად, რომელსაც შემდეგ ვაკეთებთ 4K-ში და ა.შ. ვინაიდან ვადები ძალიან მჭიდრო იყო, ჩვენ ეს თითქმის მთლიანად გავაკეთეთ AWS-ზე.

— შემდეგ ეს ყველაფერი გადადის მოთამაშეში backend სისტემის გამოყენებით. ჩვენს პლეერში გვაქვს TypeScript, React, Next.JS. და backend-ზე გვაქვს რამდენიმე სერვისი C#, Java, Spring Boot და Node.js. ეს ყველაფერი განლაგებულია Kubernetes-ის გამოყენებით Yandex.Cloud ინფრასტრუქტურის გამოყენებით.

აქვე მინდა აღვნიშნო, რომ როცა დამჭირდა პლატფორმის გაცნობა, ეს მარტივი აღმოჩნდა: ყველა საცავი არის GitLab-ზე, ყველაფერი კარგად არის დასახელებული, ტესტები დაწერილია, არის დოკუმენტაცია. ანუ საგანგებო რეჟიმშიც იზრუნეს ასეთ რამეებზე.

ბიზნესის შეზღუდვები და ანალიტიკა

— ჩვენ მივმართეთ 10 მომხმარებელს ბიზნესის მოთხოვნებიდან გამომდინარე. დროა ვისაუბროთ იმ ბიზნეს შეზღუდვებზე, რაც გვქონდა. ჩვენ უნდა გვეზრუნა მაღალი დატვირთვით, უზრუნველვყოთ პერსონალური მონაცემების დაცვის შესახებ კანონის დაცვა. Და კიდევ რა?

ნიკოლაი: თავდაპირველად დავიწყეთ ვიდეო მოთხოვნებიდან. ყველაზე მნიშვნელოვანი არის ვიდეო საცავი მთელს მსოფლიოში, კლიენტისთვის სწრაფი მიწოდებისთვის. სხვები მოიცავს 1080p გარჩევადობას, ასევე გადახვევას, რასაც ბევრი სხვა არ ახორციელებს ლაივ რეჟიმში. მოგვიანებით ჩვენ დავამატეთ 2x სიჩქარის ჩართვის შესაძლებლობა, მისი დახმარებით თქვენ შეგიძლიათ „დაეწიოთ“ პირდაპირ ეთერში და განაგრძოთ კონფერენციის ყურება რეალურ დროში. და გზაში გამოჩნდა ვადების მარკირების ფუნქციონირება. გარდა ამისა, ჩვენ უნდა ვიყოთ შეცდომების შემწყნარებლობა და გავუძლოთ 10 კავშირის დატვირთვას. უკანა ნაწილის თვალსაზრისით, ეს არის დაახლოებით 000 კავშირი, გამრავლებული 10 მოთხოვნაზე თითოეული გვერდის განახლებისთვის. და ეს უკვე არის 000 RPS/წმ. საკმაოდ ცოტა.

— იყო თუ არა სხვა მოთხოვნები პარტნიორების ონლაინ სტენდებით „ვირტუალური გამოფენისთვის“?

ნიკოლაი: დიახ, ეს საკმაოდ სწრაფად და უნივერსალურად უნდა გაკეთებულიყო. თითოეულ კონფერენციაზე გვყავდა 10-მდე პარტნიორი კომპანია და ყველა მათგანი უნდა დასრულებულიყო ერთ-ორ კვირაში. თუმცა, მათი შინაარსი ოდნავ განსხვავდება ფორმატით. მაგრამ შეიქმნა გარკვეული შაბლონის ძრავა, რომელიც აწყობს ამ გვერდებს, პრაქტიკულად შემდგომი განვითარების გარეშე.

— ასევე იყო მოთხოვნები რეალურ დროში ნახვების და სტატისტიკის ანალიტიკაზე. ვიცი, რომ ამისთვის ვიყენებთ პრომეთეს, მაგრამ უფრო დეტალურად გვითხარით: რა მოთხოვნებს ვაკმაყოფილებთ ანალიტიკისთვის და როგორ ხდება ეს?

ნიკოლაი: თავდაპირველად, ჩვენ გვაქვს მარკეტინგული მოთხოვნები A/B ტესტირებისთვის და ინფორმაციის შეგროვებისთვის, რათა გავიგოთ, როგორ მივაწოდოთ საუკეთესო კონტენტი კლიენტს მომავალში. ასევე არსებობს მოთხოვნები პარტნიორის აქტივობების ზოგიერთი ანალიტიკისთვის და ანალიტიკისთვის, რომელსაც ხედავთ (ვიზიტების მრიცხველი). ყველა ინფორმაცია გროვდება რეალურ დროში.

ჩვენ შეგვიძლია მივაწოდოთ ეს ინფორმაცია გაერთიანებული ფორმით თუნდაც მომხსენებლებს: რამდენი ადამიანი გიყურებს დროის გარკვეულ მომენტში. ამავდროულად, 152 ფედერალური კანონის შესასრულებლად, თქვენი პირადი ანგარიში და პერსონალური მონაცემები არანაირად არ კონტროლდება.

პლატფორმას უკვე აქვს მარკეტინგული ინსტრუმენტები და ჩვენი მეტრიკა მომხმარებლის აქტივობის რეალურ დროში გასაზომად (ვინ უყურებდა მოხსენების რომელ წამს), რათა ავაშენოთ ანგარიშებზე დასწრების გრაფიკები. ამ მონაცემებზე დაყრდნობით ტარდება კვლევა, რომელიც შემდგომ კონფერენციებს უკეთესს გახდის.

თაღლითობა

— გვაქვს თუ არა თაღლითობის საწინააღმდეგო მექანიზმები?

ნიკოლაი: ბიზნესის თვალსაზრისით მჭიდრო დროის გამო, ამოცანა თავიდანვე არ იყო დასახული არასაჭირო კავშირების დაუყოვნებლივ დაბლოკვის მიზნით. თუ ორი მომხმარებელი შესული იყო ერთი და იმავე ანგარიშით, მათ შეეძლოთ შინაარსის ნახვა. მაგრამ ჩვენ ვიცით, რამდენი ერთდროული ნახვა იყო ერთი ანგარიშიდან. და ჩვენ ავკრძალეთ რამდენიმე განსაკუთრებით მავნე დამრღვევი.

ვლადიმერ: მისი დამსახურებაა, ერთ-ერთმა აკრძალულმა მომხმარებელმა გაიგო, რატომ მოხდა ეს. მივიდა, ბოდიში მოიხადა და ბილეთის ყიდვა დააპირა.

— იმისათვის, რომ ეს ყველაფერი მოხდეს, თქვენ უნდა აკონტროლოთ ყველა მომხმარებელი შესვლიდან გასასვლელამდე, ყოველთვის იცოდეთ რას აკეთებენ. როგორ მუშაობს ეს სისტემა?

ვლადიმერ: მსურს ვისაუბრო ანალიტიკასა და სტატისტიკაზე, რომელსაც შემდეგ ვაანალიზებთ ანგარიშის წარმატებისთვის ან შემდეგ შეგვიძლია მივაწოდოთ პარტნიორებს. ყველა კლიენტი დაკავშირებულია websocket კავშირის საშუალებით კონკრეტულ backend კლასტერთან. იქვე დგას თხილი. თითოეული კლიენტი ყოველ დროს აგზავნის რას აკეთებს და რა ტრეკს უყურებს. შემდეგ ეს ინფორმაცია გროვდება სწრაფი Hazelcast სამუშაოების გამოყენებით და უბრუნდება ყველას, ვინც უყურებს ამ ტრეკებს. ჩვენ კუთხეში ვხედავთ რამდენი ადამიანია ახლა ჩვენთან.

იგივე ინფორმაცია ინახება Mongo და მიდის ჩვენს მონაცემთა ტბაზე, საიდანაც გვაქვს შესაძლებლობა ავაშენოთ უფრო საინტერესო გრაფიკი. ჩნდება კითხვა: რამდენმა უნიკალურმა მომხმარებელმა ნახა ეს ანგარიში? Ჩვენ მივდივართ პოსტგრესი, არის ყველა იმ ადამიანის პინგები, ვინც მოვიდა ამ ანგარიშის ID-ით. ჩვენ შევიკრიბეთ, დავაგროვეთ უნიკალური და ახლა ჩვენ შეგვიძლია გავიგოთ.

ნიკოლაი: მაგრამ ამავე დროს, ჩვენ ასევე ვიღებთ რეალურ დროში მონაცემებს პრომეთესგან. ის დაყენებულია კუბერნეტის ყველა სერვისის წინააღმდეგ, თავად კუბერნეტის წინააღმდეგ. ის აგროვებს აბსოლუტურად ყველაფერს და Grafana-სთან ერთად შეგვიძლია ავაშენოთ ნებისმიერი გრაფიკი რეალურ დროში.

ვლადიმერ: ერთის მხრივ, ჩვენ ჩამოვტვირთავთ ამას OLAP შემდგომი დამუშავებისთვის. OLTP-ისთვის კი აპლიკაცია მთლიანად იტვირთება პრომეთეში, გრაფანაში და გრაფიკები კი იყრის თავს!

- ეს ის შემთხვევაა, როცა გრაფიკები ერთმანეთს ემთხვევა.

დინამიური ცვლილებები

— გვითხარით, რამდენად დინამიური ცვლილებები ხდება: თუ ანგარიში გაუქმდა დაწყებამდე 6 წუთით ადრე, რა არის ქმედებების ჯაჭვი? რომელი მილსადენი მუშაობს?

ვლადიმერ: მილსადენი ძალიან პირობითია. არსებობს რამდენიმე შესაძლებლობა. პირველი ის არის, რომ გრაფიკის გენერირების პროგრამამ იმუშავა და შეცვალა განრიგი. შეცვლილი განრიგი აიტვირთება Contentful-ში. რის შემდეგაც backend მიხვდება, რომ ამ კონფერენციისთვის არის ცვლილებები Contentful-ში, იღებს მას და აღადგენს მას. ყველაფერი გროვდება და იგზავნება ვებსოკეტის საშუალებით.

მეორე შესაძლებლობა, როდესაც ყველაფერი ხდება საშინელი ტემპით: რედაქტორი ხელით ცვლის ინფორმაციას Contentful-ში (ბმული Telegram-ზე, სპიკერის პრეზენტაცია და ა.შ.) და იგივე ლოგიკა მუშაობს, როგორც პირველად.

ნიკოლაი: ყველაფერი ხდება გვერდის განახლების გარეშე. ყველა ცვლილება ხდება აბსოლუტურად შეუფერხებლად კლიენტისთვის. იგივე ეხება ანგარიშების შეცვლას. როცა დრო მოვა, ანგარიში და ინტერფეისი იცვლება.

ვლადიმერ: ასევე, არის დროის შეფერხებები ანგარიშების დაწყების ვადებში. თავიდანვე არაფერია. და თუ თაგუნას წითელ ზოლზე გადააფარებთ, რაღაც მომენტში, მაუწყებლის დირექტორის წყალობით, წყვეტები გამოჩნდება. რეჟისორი ადგენს მაუწყებლობის სწორ დაწყებას, ბექენდი აირჩევს ამ ცვლილებას, ითვლის მთელი ტრეკის პრეზენტაციების დაწყების და დასრულების დროებს კონფერენციის განრიგის შესაბამისად, აგზავნის მას ჩვენს კლიენტებს და მოთამაშე ხაზავს წყვეტებს. ახლა მომხმარებელს შეუძლია ადვილად ნავიგაცია მოხსენების დასაწყისში და ბოლოს. ეს იყო მკაცრი ბიზნეს მოთხოვნა, ძალიან მოსახერხებელი და სასარგებლო. თქვენ არ კარგავთ დროს მოხსენების რეალური დაწყების დროის პოვნაში. და როდესაც ჩვენ გავაკეთებთ გადახედვას, ეს იქნება აბსოლუტურად მშვენიერი.

განლაგება

— განლაგების შესახებ მინდა გკითხოთ. კოლიამ და გუნდმა თავიდან დიდი დრო დაუთმეს მთელი ინფრასტრუქტურის მოწყობას, რომელშიც ჩვენთვის ყველაფერი ვითარდება. მითხარი, რისგან შედგება ეს ყველაფერი?

ნიკოლაი: ტექნიკური თვალსაზრისით, თავიდან გვქონდა მოთხოვნა, რომ პროდუქტი მაქსიმალურად აბსტრაქტული ყოფილიყო ნებისმიერი გამყიდველისაგან. მობრძანდით AWS-ზე, რომ გააკეთოთ Terraform სკრიპტები კონკრეტულად AWS-დან, ან კონკრეტულად Yandex-დან, ან Azure-დან და ა.შ. ნამდვილად არ ჯდებოდა. რაღაც მომენტში სადმე უნდა გადავსულიყავით.

პირველი სამი კვირის განმავლობაში ჩვენ მუდმივად ვეძებდით გზებს ამის უკეთესად გაკეთების მიზნით. შედეგად, მივედით დასკვნამდე, რომ Kubernetes ამ შემთხვევაში არის ჩვენი ყველაფერი, რადგან ის საშუალებას გვაძლევს შევქმნათ ავტომატურად მასშტაბური სერვისები, ავტომატური გაშვება და თითქმის ყველა სერვისი გამოვიყენოთ. ბუნებრივია, ყველა სერვისი უნდა გაწვრთნილიყო Kubernetes-თან, Docker-თან სამუშაოდ და გუნდსაც უნდა ესწავლა.

ჩვენ გვაქვს ორი კლასტერი. ტესტირება და წარმოება. ისინი აბსოლუტურად იდენტურია ტექნიკისა და პარამეტრების თვალსაზრისით. ჩვენ ვნერგავთ ინფრასტრუქტურას კოდის სახით. ყველა სერვისი ავტომატურად გადადის სამ გარემოში ფუნქციების ფილიალებიდან, ძირითადი განშტოებებიდან, სატესტო ფილიალებიდან და GitLab ავტომატური მილსადენის გამოყენებით. ეს არის მაქსიმალურად ინტეგრირებული GitLab-ში, მაქსიმალურად ინტეგრირებული Elastic-თან, Prometheus-თან.

ჩვენ ვიღებთ შესაძლებლობას სწრაფად (დაბრუნებისთვის 10 წუთში, ფრონტენდისთვის 5 წუთში) შემოვიტანოთ ცვლილებები ნებისმიერ გარემოში ყველა ტესტით, ინტეგრაციით, ფუნქციონალური ტესტების გაშვებით, გარემოზე ინტეგრაციის ტესტებით და ასევე შევამოწმოთ დატვირთვის ტესტებით სატესტო გარემო დაახლოებით იგივეა, რაც ჩვენ გვინდა მივიღოთ წარმოებაში.

ტესტების შესახებ

— თითქმის ყველაფერს ამოწმებ, ძნელი დასაჯერებელია, როგორ დაწერე ყველაფერი. შეგიძლიათ გვითხრათ backend ტესტების შესახებ: რამდენად არის დაფარული ყველაფერი, რა ტესტები?

ვლადიმერ: დაიწერა ორი ტიპის ტესტი. პირველი არის კომპონენტის ტესტები. აწევის დონის ტესტები მთელი ზამბარის აპლიკაციისა და ჩაყრის ტესტის კონტეინერები. ეს არის უმაღლესი დონის ბიზნეს სცენარების ტესტი. მე არ ვამოწმებ ფუნქციებს. ჩვენ მხოლოდ რამდენიმე დიდ რამეს ვამოწმებთ. მაგალითად, უშუალოდ ტესტში ხდება მომხმარებლის სისტემაში შესვლის პროცესის ემულაცია, მომხმარებლის მოთხოვნა ბილეთების შესახებ, სადაც მას შეუძლია წასვლა და მოთხოვნა წვდომის შესახებ ნაკადის ყურებაზე. ძალიან მკაფიო მომხმარებლის სცენარები.

დაახლოებით იგივე დანერგილია ეგრეთ წოდებული ინტეგრაციის ტესტებში, რომლებიც რეალურად მუშაობს გარემოზე. ფაქტობრივად, როდესაც წარმოებაში შემდეგი განლაგება დაიწყება, რეალური ძირითადი სცენარებიც მუშაობს წარმოებაში. იგივე შესვლა, ბილეთების მოთხოვნა, CloudFront-ზე წვდომის მოთხოვნა, იმის შემოწმება, რომ ნაკადი ნამდვილად უკავშირდება ჩემს ნებართვებს, რეჟისორის ინტერფეისის შემოწმება.

ამ დროისთვის ბორტზე მაქვს დაახლოებით 70 კომპონენტის ტესტი და დაახლოებით 40 ინტეგრაციის ტესტი. დაფარვა ძალიან ახლოს არის 95%. ეს არის კომპონენტებისთვის, ნაკლებად ინტეგრაციისთვის, უბრალოდ არც ისე ბევრია საჭირო. იმის გათვალისწინებით, რომ პროექტი მოიცავს ყველა სახის კოდის შექმნას, ეს ძალიან კარგი მაჩვენებელია. სხვა გზა არ იყო, რაც სამ თვეში გავაკეთეთ. იმის გამო, რომ თუ ჩვენ შევამოწმებთ ხელით, მივცეთ ფუნქციები ჩვენს ტესტერს, და ის აღმოაჩენდა შეცდომებს და დაგვიბრუნებდა მათ გამოსასწორებლად, მაშინ კოდის გამართვის ეს მრგვალი მოგზაურობა ძალიან გრძელი იქნებოდა და ჩვენ ვერ შევასრულებთ ვადებს.

ნიკოლაი: პირობითად, გარკვეული ფუნქციის შეცვლისას მთელ პლატფორმაზე რეგრესიის განსახორციელებლად, თქვენ უნდა იჯდეთ და აწიოთ ყველგან ორი დღის განმავლობაში.

ვლადიმერ: ამიტომ, დიდი წარმატებაა, როცა მახასიათებელს ვაფასებ, ვამბობ, რომ ორი უბრალო კალმისთვის და 4 ვებსაკეტისთვის 1 დღე მჭირდება, კოლია ამის საშუალებას იძლევა. ის უკვე მიეჩვია, რომ ეს 4 დღე მოიცავს 2 ტიპის ტესტს და შემდეგ, დიდი ალბათობით, იმუშავებს.

ნიკოლაი: მეც მაქვს დაწერილი 140 ტესტი: კომპონენტი + ფუნქციონალური, რომლებიც იგივეს აკეთებენ. ყველა იგივე სცენარი ტესტირება ხდება წარმოებაში, ტესტირებაში და წარმოებაში. ჩვენ ასევე ახლახან დავამატეთ ფუნქციური ძირითადი UI ტესტები. ამ გზით ჩვენ ვფარავთ ყველაზე ძირითად ფუნქციას, რომელიც შეიძლება დაიშალოს.

ვლადიმერ: რა თქმა უნდა, ღირს საუბარი დატვირთვის ტესტებზე. საჭირო იყო პლატფორმის ტესტირება რეალურთან ახლოს დატვირთვის ქვეშ, რათა გავიგოთ, როგორ არის ყველაფერი, რა ხდება Rabbit-თან, რა ხდება JVM-ებთან, რამდენი მეხსიერებაა რეალურად საჭირო.

— ზუსტად არ ვიცი, ვამოწმებთ თუ არა რამეს ნაკადის მხარეს, მაგრამ მახსოვს, რომ შეხვედრების დროს ტრანსკოდერებთან იყო პრობლემები. ჩვენ გამოვცადეთ ნაკადები?

არტიომი: ტესტირება განმეორებით. შეხვედრების ორგანიზება. შეხვედრების ორგანიზების პროცესში JIRA-ს დაახლოებით 2300 ბილეთი იყო. ეს არის მხოლოდ ზოგადი რამ, რაც ადამიანებმა გააკეთეს შეხვედრების შესაქმნელად. ჩვენ გადავიღეთ პლატფორმის ნაწილები ცალკე გვერდზე შეხვედრებისთვის, რომელსაც მართავდა კირილ ტოლკაჩოვი (talkkv).

მართალი გითხრათ, დიდი პრობლემები არ ყოფილა. სიტყვასიტყვით რამდენჯერმე დავიჭირეთ CloudFront-ზე ქეშირების შეცდომები, საკმაოდ სწრაფად მოვაგვარეთ - ჩვენ უბრალოდ ხელახლა დავაყენეთ პოლიტიკა. საგრძნობლად მეტი ხარვეზი იყო ხალხში, საიტის სტრიმინგის სისტემებში.

კონფერენციების დროს მომიწია კიდევ რამდენიმე ექსპორტიორის დაწერა, რათა მეტი აღჭურვილობა და სერვისი მომეცვა. ზოგან მე მომიწია საკუთარი ველოსიპედის გაკეთება მხოლოდ მეტრიკის გულისთვის. AV (აუდიო-ვიდეო) ტექნიკის სამყარო არც თუ ისე ვარდისფერია - თქვენ გაქვთ რაიმე სახის "API" აღჭურვილობის, რომელზეც უბრალოდ ვერ იმოქმედებთ. და შორს არის ის ფაქტი, რომ თქვენ შეძლებთ მიიღოთ თქვენთვის საჭირო ინფორმაცია. ტექნიკის გამყიდველები ნამდვილად ნელია და თითქმის შეუძლებელია მათგან მიიღოთ ის, რაც გსურთ. მთლიანობაში 100-ზე მეტი აპარატურაა, არ გიბრუნებენ იმას, რაც გჭირდება და წერ უცნაურ და ზედმეტ ექსპორტიორებს, რისი წყალობითაც შეგიძლია როგორმე სისტემის გამართვა.

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

— მახსოვს, კონფერენციების დაწყებამდე როგორ ვიყიდეთ ნაწილობრივ დამატებითი აღჭურვილობა.

არტიომი: ჩვენ შევიძინეთ კომპიუტერები, ლეპტოპები და ბატარეის პაკეტები. ამ დროისთვის ჩვენ შეგვიძლია ვიცხოვროთ ელექტროენერგიის გარეშე 40 წუთის განმავლობაში. ივნისში სანქტ-პეტერბურგში ძლიერი ჭექა-ქუხილი იყო - ასე რომ, ჩვენ გვქონდა ასეთი ჩაქრობა. ამავდროულად, რამდენიმე პროვაიდერი მოდის ჩვენთან ოპტიკური ბმულებით სხვადასხვა წერტილიდან. ეს არის რეალურად 40 წუთი შენობის გაჩერება, რომლის დროსაც გვექნება ჩართული განათება, ხმა, კამერები და ა.შ.

— მსგავსი ამბავი გვაქვს ინტერნეტთან დაკავშირებით. ოფისში, სადაც ჩვენი სტუდიებია განთავსებული, სართულებს შორის სასტიკი ბადე გადავიტანეთ.

არტიომი: სართულებს შორის გვაქვს 20 გბიტი ბოჭკოვანი. სართულების გასწვრივ, სადღაც არის ოპტიკა, სადღაც არ არის ოპტიკა, მაგრამ მაინც ნაკლები არხია ვიდრე გიგაბიტი - ჩვენ მათზე ვუშვებთ ვიდეოს კონფერენციის ტრეკებს შორის. ზოგადად, ძალიან მოსახერხებელია საკუთარ ინფრასტრუქტურაზე მუშაობა; ამის გაკეთება იშვიათად შეგიძლიათ საიტებზე ოფლაინ კონფერენციებზე.

— სანამ JUG Ru Group-ში ვმუშაობდი, დავინახე, როგორ აწყობდნენ ოფლაინ კონფერენციებზე აპარატურულ ოთახებს ღამით, სადაც იყო დიდი მონიტორი ყველა იმ მეტრიკით, რომელსაც თქვენ ააგებთ Grafana-ში. ახლა ასევე არის სათაო ოფისი, რომელშიც დეველოპერების გუნდი ზის, რომელიც კონფერენციის დროს ასწორებს ზოგიერთ შეცდომებს და ავითარებს ფუნქციებს. ამავდროულად, არსებობს მონიტორინგის სისტემა, რომელიც ნაჩვენებია დიდ ეკრანზე. არტიომი, კოლია და სხვა ბიჭები სხედან და დარწმუნდებიან, რომ ეს ყველაფერი არ იშლება და ლამაზად მუშაობს.

კურიოზები და პრობლემები

— თქვენ კარგად ისაუბრეთ იმაზე, რომ ჩვენ გვაქვს სტრიმინგი ამაზონთან, არის მოთამაშე ინტერნეტით, ყველაფერი დაწერილია პროგრამირების სხვადასხვა ენაზე, გათვალისწინებულია შეცდომების ტოლერანტობა და სხვა ბიზნეს მოთხოვნები, მათ შორის პირადი ანგარიში, რომელიც მხარდაჭერილია იურიდიული პირებისთვის და ინდივიდებს, და ჩვენ შეგვიძლია ინტეგრირება ვინმესთან, ვინც იყენებს OAuth 2.0, არის თაღლითობის საწინააღმდეგო, მომხმარებლის დაბლოკვა. ჩვენ შეგვიძლია დინამიურად გამოვაქვეყნოთ ცვლილებები, რადგან ეს კარგად გავაკეთეთ და ეს ყველაფერი გამოცდილია.

მაინტერესებს ვიცოდე, რა უცნაურობებს უკავშირდება რაღაცის დაწყება. ყოფილა თუ არა რაიმე უცნაური სიტუაციები, როცა ავითარებდით ბექენდს, ფრონტენდს, რაღაც გიჟური აღმოჩნდა და ვერ გაიგეთ რა უნდა გააკეთოთ?

ვლადიმერ: მეჩვენება, რომ ეს მხოლოდ ბოლო სამი თვის განმავლობაში მოხდა. Ყოველ დღე. როგორც ხედავთ, მთელი თმა ამოჩემებული მაქვს.

ვლადიმირ კრასილშჩიკი 3 თვის შემდეგ, როდესაც რაღაც თამაში გამოვიდა და ვერავინ მიხვდა, რა უნდა გაეკეთებინა

ყოველდღე იყო ასეთი რაღაც, როცა იყო ისეთი მომენტი, როცა იღებ და თმას იშორებ, ან ხვდები, რომ სხვა არავინ არის და ეს მხოლოდ შენ შეგიძლია. ჩვენი პირველი დიდი ღონისძიება იყო TechTrain. 6 ივნისს დილის 2 საათზე ჯერ არ გვქონდა გამოშვებული საწარმოო გარემო, კოლია გამოდიოდა. და პირადი ანგარიში არ მუშაობდა ავტორიზაციის სერვერად OAuth2.0-ის გამოყენებით. ჩვენ გადავაქციეთ ის OAuth2.0 პროვაიდერად, რომ პლატფორმა მას დავუკავშიროთ. ალბათ 18 საათი ვმუშაობდი, კომპიუტერს დავხედე და ვერაფერი დავინახე, ვერ მივხვდი რატომ არ მუშაობდა და კოლიამ დისტანციურად დახედა ჩემს კოდს, ეძება ხარვეზი Spring Configuration-ში. იპოვა და LC მუშაობდა და წარმოებაშიც.

ნიკოლაი: და ერთი საათით ადრე TechTrain-ის გამოშვება მოხდა.

აქ უამრავი ვარსკვლავი იყო გასწორებული. ჩვენ ძალიან გაგვიმართლა, რადგან გვყავდა სუპერ გუნდი და ყველას შთაგონებული იყო ამის ონლაინ გაკეთების იდეა. მთელი ეს სამი თვის განმავლობაში ჩვენ გვამოძრავებდა ის ფაქტი, რომ ჩვენ გავაკეთეთ YouTube. თავს უფლებას არ ვაძლევდი თმების დაშლას, მაგრამ ყველას ვუთხარი, რომ ყველაფერი გამოვიდოდა, რადგან სინამდვილეში ყველაფერი დიდი ხნის წინ იყო გათვლილი.

შესრულების შესახებ

— შეგიძლიათ მითხრათ რამდენი ადამიანი იყო საიტზე ერთ ტრეკზე? იყო რაიმე შესრულების პრობლემები?

ნიკოლაი: შესრულების პრობლემები არ ყოფილა, როგორც უკვე ვთქვით. ერთ მოხსენებაში მონაწილეთა მაქსიმალური რაოდენობა იყო 1300 ადამიანი, ეს არის Heisenbug-ზე.

— იყო თუ არა პრობლემები ლოკალურ ყურებასთან დაკავშირებით? და შესაძლებელია თუ არა ტექნიკური აღწერა დიაგრამებით, თუ როგორ მუშაობს ეს ყველაფერი?

ნიკოლაი: ამის შესახებ სტატიას მოგვიანებით გავაკეთებთ.

თქვენ შეგიძლიათ ადგილობრივად ნაკადების გამართვაც კი. როგორც კი კონფერენციები დაიწყო, ეს კიდევ უფრო გამარტივდა, რადგან გამოჩნდა საწარმოო ნაკადები, რომელთა ყურება ყოველთვის შეგვიძლია.

ვლადიმერ: როგორც მე მესმის, ფრონტ-ენდის დეველოპერები მუშაობდნენ ლოკალურად დაცინვით, შემდეგ კი, რადგან წინა დეველოპერებზე გაშვების დრო ასევე მოკლეა (5 წუთი), არანაირი პრობლემა არ არის იმის შემოწმებასთან დაკავშირებით, თუ რა ხდება სერთიფიკატებთან.

— ყველაფერი შემოწმებულია და გამართულია, თუნდაც ადგილობრივად. ეს ნიშნავს, რომ ჩვენ დავწერთ სტატიას ყველა ტექნიკური მახასიათებლით, გაჩვენებთ, გეტყვით ყველაფერს დიაგრამებით, როგორ იყო.

ვლადიმერ: შეგიძლიათ აიღოთ და გაიმეოროთ.

- 3 თვეში.

სულ

— ყველაფერი, რაც ერთად არის აღწერილი, მაგრად ჟღერს, თუ გავითვალისწინებთ, რომ ეს სამ თვეში პატარა გუნდმა გააკეთა.

ნიკოლაი: დიდი გუნდი ამას არ გააკეთებს. მაგრამ ადამიანთა მცირე ჯგუფს, რომლებიც საკმაოდ მჭიდროდ და კარგად ურთიერთობენ ერთმანეთთან და შეუძლიათ შეთანხმებას მიაღწიონ. მათ არანაირი წინააღმდეგობა არ აქვთ, არქიტექტურა ორ დღეში გამოიგონეს, დასრულდა და რეალურად არ შეცვლილა. არსებობს შემომავალი ბიზნესის მოთხოვნების ძალიან მკაცრი გამარტივება ფუნქციების მოთხოვნებისა და ცვლილებების დაგროვების თვალსაზრისით.

- რა იყო თქვენი შემდგომი ამოცანების ჩამონათვალში, როდესაც ზაფხულის კონფერენციები უკვე გაიმართა?

ნიკოლაი: მაგალითად, კრედიტები. ვიდეოზე მცოცავი ხაზები, ვიდეოს ზოგიერთ ადგილას ამომხტარი ფანჯარა ნაჩვენები კონტენტის მიხედვით. მაგალითად, სპიკერს სურს დაუსვას შეკითხვა აუდიტორიას და ეკრანზე ჩნდება ხმა, რომელიც კენჭისყრის შედეგების საფუძველზე თავად სპიკერს უბრუნდება უკან. გარკვეული სახის სოციალური აქტივობა მოწონების, გულის, რეიტინგების სახით მოხსენების თავად პრეზენტაციის დროს, რათა შეავსოთ გამოხმაურება საჭირო მომენტში, შემდგომში უკუკავშირის ფორმებით ყურადღების გადატანის გარეშე. თავიდან ასე.

და ასევე მთელ პლატფორმას, გარდა სტრიმინგისა და კონფერენციისა, ასევე პოსტკონფერენციის მდგომარეობა. ეს არის დასაკრავი სიები (მათ შორის, მომხმარებლების მიერ შედგენილი), შესაძლოა კონტენტი სხვა წარსული კონფერენციებიდან, ინტეგრირებული, ეტიკეტირებული, ხელმისაწვდომი მომხმარებლისთვის და ასევე ხელმისაწვდომია ჩვენს ვებსაიტზე სანახავად (live.jugru.org).

- ბიჭებო, დიდი მადლობა პასუხებისთვის!

თუ მკითხველთა შორის არიან ისეთებიც, ვინც ესწრებოდა ჩვენს საზაფხულო კონფერენციებს, გთხოვთ, გაგვიზიაროთ თქვენი შთაბეჭდილებები მოთამაშის შესახებ და გადაიტანოთ. რა იყო მოსახერხებელი, რამ გაგაღიზიანა, რის ნახვას ისურვებდი მომავალში?

თუ თქვენ გაინტერესებთ პლატფორმა და გსურთ იხილოთ ის „ბრძოლაში“, ჩვენ მას ისევ ვიყენებთ ჩვენს გვერდზე შემოდგომა-ზამთრის კონფერენციები. მათი მთელი ასორტიმენტია, ასე რომ, თითქმის ნამდვილად არის თქვენთვის შესაფერისი.

წყარო: www.habr.com