بهار امسال در شرایط بسیار شادی قرار گرفتیم. با توجه به همه‌گیری، مشخص شد که کنفرانس‌های تابستانی ما باید به صورت آنلاین منتقل شوند. و برای انجام کارآمد آنها به صورت آنلاین، راه حل های نرم افزاری آماده برای ما مناسب نبودند؛ ما نیاز داشتیم که خودمان را بنویسیم. و ما سه ماه فرصت داشتیم تا این کار را انجام دهیم.

واضح است که سه ماه هیجان انگیز بوده است. اما از بیرون کاملاً واضح نیست: پلت فرم کنفرانس آنلاین چیست؟ از چه قسمت هایی تشکیل شده است؟ بنابراین، در آخرین کنفرانس تابستانی DevOops، از کسانی که مسئول این کار بودند پرسیدم:

• نیکولای مولچانوف - مدیر فنی گروه JUG Ru.
• ولادیمیر کراسیلشچیک یک برنامه نویس عملگرای جاوا است که روی باطن کار می کند (شما می توانید گزارش های او را در کنفرانس های جاوا ما نیز ببینید).
• Artyom Nikonov مسئول تمام پخش ویدیوی ما است.

به هر حال، در کنفرانس های پاییز و زمستان ما از نسخه بهبودیافته همان پلتفرم استفاده خواهیم کرد - بنابراین بسیاری از خوانندگان هابرا همچنان کاربران آن خواهند بود.

تصویر کلی

- ترکیب تیم چطور بود؟

نیکولای مولچانوف: ما یک تحلیلگر، یک طراح، یک تستر، سه قسمت جلو و یک بک اند داریم. و البته یک متخصص تی شکل!

- روند به طور کلی چگونه بود؟

نیکولای: تا اواسط ماه مارس، ما اصلاً چیزی برای آنلاین آماده نداشتیم. و در 15 مارس، کل چرخ فلک آنلاین شروع به چرخش کرد. ما چندین مخزن راه اندازی کردیم، برنامه ریزی کردیم، در مورد معماری اولیه بحث کردیم و همه چیز را در سه ماه انجام دادیم.

این، البته، مراحل کلاسیک برنامه ریزی، معماری، انتخاب ویژگی، رای دادن به آن ویژگی ها، سیاست گذاری برای آن ویژگی ها، طراحی، توسعه، آزمایش آنها را طی کرد. در نتیجه، در 6 ژوئن، همه چیز را به تولید رساندیم. TechTrain. 90 روز برای همه چیز وجود داشت.

- آیا ما توانستیم آنچه را که به آن متعهد بودیم به انجام برسانیم؟

نیکولای: از آنجایی که ما اکنون در کنفرانس DevOops به صورت آنلاین شرکت می کنیم، به این معنی است که کار کرده است. من شخصاً به چیز اصلی متعهد هستم: ابزاری را برای مشتریان به ارمغان می‌آورم که با آن بتوانند یک کنفرانس آنلاین برگزار کنند.

چالش این بود: ابزاری به ما بدهید که با آن بتوانیم کنفرانس های خود را برای دارندگان بلیط پخش کنیم.

تمام برنامه ریزی ها به چند مرحله تقسیم شدند و همه ویژگی ها (حدود 30 مورد جهانی) به 4 دسته تقسیم شدند:

• که ما قطعا انجام خواهیم داد (ما نمی توانیم بدون آنها زندگی کنیم)
• که در مرحله دوم انجام خواهیم داد،
• که ما هرگز انجام نمی دهیم،
• و ما هرگز و هرگز انجام نخواهیم داد.

ما تمام ویژگی ها را از دو دسته اول ساختیم.

- من می دانم که در مجموع 600 شماره JIRA ایجاد شده است. در سه ماه، شما 13 میکروسرویس ساختید، و من گمان می کنم که آنها نه تنها در جاوا نوشته شده باشند. شما از فناوری های مختلفی استفاده کردید، دو خوشه Kubernetes در سه منطقه در دسترس و 5 جریان RTMP در آمازون دارید.

حال بیایید هر یک از اجزای سیستم را جداگانه بررسی کنیم.

جریان

- بیایید با زمانی شروع کنیم که قبلاً یک تصویر ویدیویی داریم و به برخی از سرویس‌ها منتقل می‌شود. آرتیوم، به ما بگویید این استریم چگونه اتفاق می افتد؟

آرتیوم نیکونوف: طرح کلی ما به این صورت است: تصویر از دوربین -> اتاق کنترل ما -> سرور RTMP محلی -> آمازون -> پخش کننده ویدئو. جزئیات بیشتر در مورد آن نوشت در هابره در ماه ژوئن.

به طور کلی، دو راه جهانی برای انجام این کار وجود دارد: یا بر اساس سخت افزار یا بر اساس راه حل های نرم افزاری. ما مسیر نرم افزار را انتخاب کردیم زیرا در مورد بلندگوهای راه دور راحت تر است. همیشه نمی‌توان سخت‌افزار را به بلندگو در کشور دیگری آورد، اما تحویل نرم‌افزار به بلندگو آسان‌تر و قابل اعتمادتر به نظر می‌رسد.

از نقطه نظر سخت افزاری، ما تعداد معینی دوربین (در استودیوهایمان و بلندگوهای راه دور)، تعدادی کنترل از راه دور در استودیو داریم که گاهی اوقات باید درست زیر میز در حین پخش، تعمیر شوند.

سیگنال های این دستگاه ها با کارت های ضبط، کارت های ورودی/خروجی و کارت های صدا وارد رایانه می شوند. در آنجا سیگنال ها مخلوط شده و در طرح بندی ها جمع می شوند:

نمونه ای از چیدمان برای 4 بلندگو

نمونه ای از چیدمان برای 4 بلندگو

علاوه بر این، پخش مداوم با کمک سه رایانه ارائه می شود: یک دستگاه اصلی و یک جفت دستگاه کار به نوبه خود وجود دارد. کامپیوتر اول اولین گزارش را جمع آوری می کند، دومی - استراحت، اولی - گزارش بعدی، دومی - استراحت بعدی، و غیره. و ماشین اصلی اولی را با دومی مخلوط می کند.

این یک مثلث ایجاد می کند و اگر هر یک از این گره ها از کار بیفتند، می توانیم به سرعت و بدون افت کیفیت به ارائه محتوا به مشتریان ادامه دهیم. ما چنین شرایطی داشتیم. در هفته اول کنفرانس ها، یک دستگاه را تعمیر کردیم، آن را روشن/خاموش کردیم. به نظر می رسد مردم از انعطاف پذیری ما راضی هستند.

سپس، جریان‌های رایانه‌ها به یک سرور محلی می‌روند، که دو وظیفه دارد: مسیریابی جریان‌های RTMP و پشتیبان‌گیری ضبط. بنابراین ما چندین نقطه ضبط داریم. سپس جریان های ویدئویی به بخشی از سیستم ما که بر روی سرویس های Amazon SaaS ساخته شده است ارسال می شود. ما استفاده می کنیم MediaLive:,S3,CloudFront.

نیکولای: قبل از اینکه ویدیو به دست مخاطب برسد، در آنجا چه اتفاقی می افتد؟ باید یه جوری قطعش کنی، درسته؟

آرتیوم: ما ویدیو را از طرف خود فشرده می کنیم و آن را به MediaLive می فرستیم. ترانکودرها را در آنجا راه اندازی می کنیم. آنها ویدیوها را در زمان واقعی به چندین رزولوشن تبدیل می کنند تا مردم بتوانند آنها را در تلفن های خود، از طریق اینترنت ضعیف در کشور و غیره تماشا کنند. سپس این نهرها بریده می شوند تکه ها، پروتکل به این صورت کار می کند HLS. ما یک لیست پخش به قسمت جلویی ارسال می کنیم که حاوی نشانگرهایی به این قطعات است.

- آیا از وضوح 1080p استفاده می کنیم؟

آرتیوم: عرض ویدیوی ما برابر با 1080p - 1920 پیکسل است و ارتفاع کمی کمتر است، تصویر کشیده تر است - دلایلی برای این وجود دارد.

بازیکن

- آرتیوم توضیح داد که چگونه ویدئو به استریم می‌رود، چگونه در لیست‌های پخش مختلف برای وضوح صفحه نمایش مختلف توزیع می‌شود، به تکه‌ها بریده می‌شود و وارد پخش‌کننده می‌شود. کولیا، حالا بگو این چه نوع پلیری است، چگونه جریان را مصرف می کند، چرا HLS؟

نیکولای: ما پخش کننده ای داریم که همه بینندگان کنفرانس می توانند آن را تماشا کنند.

در اصل، این یک لفاف در اطراف کتابخانه است hls.js، که روی آن بسیاری از بازیکنان دیگر نوشته شده است. اما ما به عملکرد بسیار خاصی نیاز داشتیم: عقب بردن و علامت گذاری مکانی که شخص در آن است، چه گزارشی را که در حال حاضر تماشا می کند. ما همچنین به طرح‌بندی‌های خود، انواع لوگوها و هر چیز دیگری که با ما ساخته شده بود نیاز داشتیم. بنابراین، تصمیم گرفتیم کتابخانه خودمان را بنویسیم (یک لفاف بر روی HLS) و آن را در سایت جاسازی کنیم.

این عملکرد ریشه است، بنابراین تقریباً ابتدا اجرا شد. و سپس همه چیز در اطراف آن رشد کرد.

در واقع، از طریق مجوز، پخش کننده یک لیست پخش با پیوندهایی به قطعات مرتبط با زمان و کیفیت دریافت می کند، موارد لازم را دانلود می کند و به کاربر نشان می دهد و در طول مسیر "جادویی" انجام می دهد.

مثال جدول زمانی

- دکمه ای درست در پخش کننده تعبیه شده است تا جدول زمانی همه گزارش ها را نمایش دهد...

نیکولای: بله، ما بلافاصله مشکل ناوبری کاربر را حل کردیم. در اواسط آوریل، ما تصمیم گرفتیم که هر یک از کنفرانس های خود را در یک وب سایت جداگانه پخش نکنیم، بلکه همه چیز را در یک وب سایت ترکیب کنیم. به طوری که کاربران بلیط Full Pass می توانند آزادانه بین کنفرانس های مختلف جابجا شوند: هم پخش زنده و هم ضبط کنفرانس های گذشته.

و برای اینکه کاربران بتوانند در جریان فعلی حرکت کنند و بین آهنگ‌ها جابجا شوند، آسان‌تر شود، تصمیم گرفتیم یک دکمه «پخش کل» و کارت‌های گزارش افقی برای جابه‌جایی بین آهنگ‌ها و گزارش‌ها ایجاد کنیم. کنترل صفحه کلید وجود دارد.

- آیا مشکلات فنی در این مورد وجود داشت؟

نیکولای: آنها یک نوار اسکرول داشتند که نقطه شروع گزارش های مختلف روی آن مشخص شده بود.

— در پایان، آیا قبل از انجام کاری مشابه یوتیوب، این علامت‌ها را روی نوار اسکرول پیاده‌سازی کردید؟

آرتیوم: آن موقع آن را در نسخه بتا داشتند. به نظر می رسد این یک ویژگی بسیار پیچیده است زیرا آنها در طول سال گذشته تا حدی آن را با کاربران آزمایش کرده اند. و اکنون به فروش رسیده است.

نیکولای: اما ما در واقع آن را سریعتر به فروش رساندیم. راستش را بخواهید، پشت این ویژگی ساده، حجم عظیمی از باطن، فرانت اند، محاسبات و ریاضیات درون پلیر وجود دارد.

Frontend

— بیایید بفهمیم این محتوایی که نشان می‌دهیم (کارت سخنرانی، سخنرانان، وب‌سایت، برنامه زمانی) چگونه به صفحه اول می‌رسد؟

ولادیمیر کراسیلشچیک: ما چندین سیستم IT داخلی داریم. سیستمی وجود دارد که همه گزارش ها و همه بلندگوها در آن وارد می شوند. فرآیندی وجود دارد که طی آن سخنران در یک کنفرانس شرکت می کند. سخنران برنامه ای را ارسال می کند، سیستم آن را ضبط می کند، سپس خط لوله خاصی وجود دارد که طبق آن گزارش ایجاد می شود.

گوینده خط لوله را اینگونه می بیند

این سیستم توسعه داخلی ماست.

در مرحله بعد، شما باید یک برنامه زمانی از گزارش های فردی بسازید. همانطور که می دانید، این یک مشکل NP-hard است، اما ما به نوعی آن را حل می کنیم. برای انجام این کار، مؤلفه دیگری را راه‌اندازی می‌کنیم که یک زمان‌بندی ایجاد می‌کند و آن را در سرویس ابری شخص ثالث Contentful آپلود می‌کند. در آنجا، همه چیز شبیه جدولی است که در آن روزهای کنفرانس وجود دارد، در روزها شکاف های زمانی وجود دارد، و در اسلات ها گزارش ها، استراحت ها یا فعالیت های حمایت مالی وجود دارد. بنابراین محتوایی که می بینیم در یک سرویس شخص ثالث قرار دارد. و وظیفه انتقال آن به سایت است.

به نظر می رسد که سایت فقط یک صفحه با پخش کننده است و هیچ چیز پیچیده ای در اینجا وجود ندارد. جز این نیست. Backend پشت این صفحه به Contentful می رود، برنامه را از آنجا دریافت می کند، برخی از آبجکت ها را تولید می کند و آن را به frontend ارسال می کند. با استفاده از یک اتصال وب سوکت، که هر مشتری پلتفرم ما ایجاد می کند، به روز رسانی برنامه را از باطن به فرانت اند برای او ارسال می کنیم.

مورد واقعی: سخنران درست در طول کنفرانس شغل خود را تغییر داد. باید نشان شرکت کارفرمایش را عوض کنیم. چگونه این اتفاق از باطن رخ می دهد؟ یک به روز رسانی از طریق وب سوکت برای همه مشتریان ارسال می شود و سپس خود فرانت اند خط زمانی را دوباره ترسیم می کند. همه اینها یکپارچه اتفاق می افتد. ترکیبی از سرویس ابری و چندین مؤلفه ما این فرصت را به ما می دهد تا همه این محتوا را تولید کرده و آن را در اختیار شما قرار دهیم.

نیکولای: در اینجا مهم است که توضیح دهیم که سایت ما یک برنامه کلاسیک SPA نیست. این هم یک وب سایت مبتنی بر چیدمان و رندر شده و هم یک SPA است. گوگل در واقع این سایت را به عنوان HTML رندر شده می بیند. این برای سئو و ارائه محتوا به کاربر خوب است. قبل از دیدن صفحه منتظر نمی ماند تا 1,5 مگابایت جاوا اسکریپت بارگیری شود، بلافاصله صفحه رندر شده را می بیند و هر بار که گزارش را تغییر می دهید آن را احساس می کنید. همه چیز در نیم ثانیه اتفاق می افتد، زیرا محتوا از قبل آماده است و در مکان مناسب پست شده است.

- بیایید با فهرست کردن فناوری‌ها، زیر همه موارد بالا خط بکشیم. تیوما گفت که ما 5 استریم آمازون داریم و ویدیو و صدا را در آنجا تحویل می دهیم. ما اسکریپت های bash را در آنجا داریم، از آنها برای راه اندازی و پیکربندی استفاده می کنیم...

آرتیوم: این از طریق API AWS اتفاق می افتد، خدمات جانبی فنی بیشتری در آنجا وجود دارد. ما مسئولیت های خود را تقسیم کردیم تا من به آنها تحویل دهم CloudFront قابلیت، و توسعه دهندگان فرانت اند و بک اند آن را از آنجا می گیرند. ما تعدادی پیوند خودمان برای ساده‌سازی طرح محتوا داریم که سپس آن‌ها را در 4K و غیره می‌سازیم. از آنجایی که ضرب‌الاجل‌ها بسیار فشرده بود، تقریباً به طور کامل این کار را در AWS انجام دادیم.

- سپس همه اینها با استفاده از سیستم Backend به پخش کننده می رود. ما TypeScript، React، Next.JS را در پلیر خود داریم. و در backend چندین سرویس در C#، Java، Spring Boot و Node.js داریم. همه اینها با استفاده از Kubernetes با استفاده از زیرساخت Yandex.Cloud مستقر شده است.

همچنین می خواهم توجه داشته باشم که وقتی نیاز به آشنایی با پلتفرم داشتم، معلوم شد که آسان است: همه مخازن در GitLab هستند، همه چیز به خوبی نامگذاری شده است، آزمایش ها نوشته شده اند، اسناد وجود دارد. یعنی حتی در حالت اضطراری هم به این گونه موارد رسیدگی می کردند.

محدودیت های کسب و کار و تجزیه و تحلیل

- ما 10 کاربر را بر اساس نیازهای تجاری هدف قرار دادیم. وقت آن است که در مورد محدودیت های تجاری که داشتیم صحبت کنیم. ما مجبور بودیم از حجم کاری بالا اطمینان حاصل کنیم، از انطباق با قانون حفظ اطلاعات شخصی اطمینان حاصل کنیم. و دیگر چه؟

نیکولای: در ابتدا، ما از الزامات ویدیو شروع کردیم. مهمترین چیز این است که ذخیره سازی ویدئویی در سراسر جهان برای تحویل سریع به مشتری توزیع شده است. موارد دیگر شامل رزولوشن 1080p و همچنین بازگشت به عقب است که بسیاری دیگر در حالت زنده اجرا نمی کنند. بعداً قابلیت فعال کردن سرعت 2 برابری را اضافه کردیم، با کمک آن می‌توانید با برنامه زنده «پیش‌گیری» کنید و به تماشای کنفرانس در زمان واقعی ادامه دهید. و در طول راه، قابلیت علامت گذاری جدول زمانی ظاهر شد. بعلاوه، ما مجبور بودیم عیب را تحمل کنیم و بار 10 اتصال را تحمل کنیم. از نقطه نظر Backend، این تقریباً 000 اتصال است که در 10 درخواست برای هر بازخوانی صفحه ضرب می شود. و این در حال حاضر 000 RPS / ثانیه است. کمی از

- آیا شرایط دیگری برای "نمایشگاه مجازی" با غرفه های آنلاین شرکا وجود داشت؟

نیکولای: بله، این باید به سرعت و به طور جهانی انجام شود. برای هر کنفرانس حداکثر 10 شرکت شریک داشتیم و همه آنها باید در یک یا دو هفته تکمیل می شد. با این حال، محتوای آنها در قالب کمی متفاوت است. اما موتور الگوی خاصی ساخته شد که این صفحات را در لحظه مونتاژ می کند، بدون مشارکت بیشتر در توسعه.

- همچنین الزاماتی برای تجزیه و تحلیل نماها و آمار در زمان واقعی وجود داشت. من می دانم که ما از Prometheus برای این کار استفاده می کنیم، اما با جزئیات بیشتر به ما بگویید: چه الزاماتی را برای تجزیه و تحلیل برآورده می کنیم، و این چگونه اجرا می شود؟

نیکولای: در ابتدا، ما نیازمندی‌های بازاریابی برای جمع‌آوری برای آزمایش A/B و جمع‌آوری اطلاعات به منظور درک نحوه ارائه صحیح بهترین محتوا به مشتری در آینده هستیم. همچنین الزاماتی برای برخی از تجزیه و تحلیل های مربوط به فعالیت های شریک و تجزیه و تحلیل هایی که مشاهده می کنید (پیشخوان بازدید) وجود دارد. تمام اطلاعات در زمان واقعی جمع آوری می شود.

ما می‌توانیم این اطلاعات را به صورت جمع‌آوری شده حتی برای سخنرانان ارائه کنیم: چند نفر در یک زمان خاص شما را تماشا می‌کردند. در عین حال، برای رعایت قانون فدرال 152، حساب شخصی و اطلاعات شخصی شما به هیچ وجه ردیابی نمی شود.

این پلتفرم از قبل دارای ابزارهای بازاریابی و معیارهای ما برای اندازه‌گیری فعالیت کاربر در زمان واقعی (کسی که چه ثانیه‌ای از گزارش را تماشا کرده است) دارد تا نمودارهایی از حضور در گزارش‌ها ایجاد کند. بر اساس این داده ها تحقیقاتی در حال انجام است که کنفرانس های بعدی را بهتر می کند.

تقلب

- آیا مکانیزم های ضد تقلب داریم؟

نیکولای: به دلیل محدودیت زمانی از نقطه نظر تجاری، این وظیفه در ابتدا برای مسدود کردن فوری اتصالات غیر ضروری تنظیم نشده بود. اگر دو کاربر با یک حساب کاربری وارد شوند، می توانند محتوا را مشاهده کنند. اما می دانیم که چند بازدید همزمان از یک حساب وجود داشته است. و ما چندین متخلف به خصوص بدخواه را ممنوع کردیم.

ولادیمیر: به اعتبار خود، یکی از کاربران ممنوعه متوجه شد که چرا این اتفاق افتاده است. آمد عذرخواهی کرد و قول خرید بلیط داد.

- برای اینکه همه اینها اتفاق بیفتد، باید همه کاربران را از ورود تا خروج به طور کامل ردیابی کنید، همیشه بدانید که آنها چه می کنند. این سیستم چگونه کار می کند؟

ولادیمیر: من می خواهم در مورد تجزیه و تحلیل و آمار صحبت کنم، که سپس برای موفقیت گزارش تجزیه و تحلیل می کنیم یا می توانیم آن را در اختیار شرکا قرار دهیم. همه مشتریان از طریق یک اتصال وب سوکت به یک خوشه باطن خاص متصل می شوند. آنجا ایستاده است فندقی. هر مشتری در هر دوره زمانی کاری را که انجام می دهد و آهنگی را که تماشا می کند ارسال می کند. سپس این اطلاعات با استفاده از کارهای Hazelcast سریع جمع‌آوری می‌شود و برای همه کسانی که این آهنگ‌ها را تماشا می‌کنند ارسال می‌شود. در گوشه ای می بینیم که الان چند نفر با ما هستند.

همین اطلاعات در آن ذخیره می شود Mongo ها و به دریاچه داده ما می رود، که از آن فرصت داریم تا نمودار جالب تری بسازیم. این سوال مطرح می شود: چند کاربر منحصر به فرد این گزارش را مشاهده کرده اند؟ می رویم به پست گرس، پینگ تمام افرادی که با شناسه این گزارش آمده اند وجود دارد. ما موارد منحصر به فرد را جمع آوری کردیم و اکنون می توانیم درک کنیم.

نیکولای: اما در عین حال، ما داده های بلادرنگ را نیز از پرومتئوس دریافت می کنیم. در برابر تمام سرویس های Kubernetes، علیه خود Kubernetes تنظیم شده است. کاملاً همه چیز را جمع آوری می کند و با Grafana می توانیم هر نموداری را در زمان واقعی بسازیم.

ولادیمیر: از یک طرف، ما این را برای پردازش بیشتر OLAP دانلود می کنیم. و برای OLTP، برنامه همه چیز را به Prometheus، Grafana بارگیری می کند و نمودارها حتی همگرا می شوند!

- این مورد زمانی است که نمودارها همگرا شوند.

تغییرات پویا

- به ما بگویید تغییرات پویا چگونه انجام می شود: اگر گزارش 6 دقیقه قبل از شروع لغو شد، زنجیره اقدامات چیست؟ کدام خط لوله کار می کند؟

ولادیمیر: خط لوله بسیار مشروط است. چند احتمال وجود دارد. اول این که برنامه تولید زمانبندی کار کرد و برنامه را تغییر داد. برنامه اصلاح شده در Contentful بارگذاری می شود. پس از آن backend متوجه می شود که تغییراتی برای این کنفرانس در Contentful وجود دارد، آن را می گیرد و آن را بازسازی می کند. همه چیز از طریق وب سوکت جمع آوری و ارسال می شود.

امکان دوم، زمانی که همه چیز با سرعت سرسام آوری اتفاق می افتد: ویرایشگر به صورت دستی اطلاعات موجود در Contentful را تغییر می دهد (لینک به تلگرام، ارائه سخنران و غیره) و همان منطق بار اول کار می کند.

نیکولای: همه چیز بدون رفرش کردن صفحه اتفاق می افتد. همه تغییرات کاملاً یکپارچه برای مشتری رخ می دهد. همین امر در مورد تغییر گزارشات نیز صدق می کند. وقتی زمانش فرا می رسد، گزارش و رابط کاربری تغییر می کند.

ولادیمیر: همچنین برای شروع گزارش ها در تایم لاین محدودیت های زمانی وجود دارد. در همان ابتدا چیزی وجود ندارد. و اگر ماوس خود را روی نوار قرمز نگه دارید، در نقطه ای، به لطف کارگردان پخش، برش ها ظاهر می شوند. کارگردان شروع صحیح پخش را تنظیم می‌کند، بخش پشتیبان این تغییر را دریافت می‌کند، زمان شروع و پایان کل ارائه‌های آهنگ را مطابق با برنامه کنفرانس محاسبه می‌کند، آن را برای مشتریان ما ارسال می‌کند، و پخش‌کننده برش‌ها را ترسیم می‌کند. اکنون کاربر می تواند به راحتی به ابتدا و انتهای گزارش حرکت کند. این یک الزام تجاری سخت، بسیار راحت و مفید بود. شما زمان را برای یافتن زمان شروع واقعی گزارش تلف نمی کنید. و وقتی یک پیش نمایش انجام می دهیم، کاملاً فوق العاده خواهد بود.

گسترش

- من می خواهم در مورد استقرار بپرسم. کولیا و تیم در ابتدا زمان زیادی را صرف راه‌اندازی زیرساخت‌هایی کردند که همه چیز برای ما در آن آشکار می‌شود. به من بگو، این همه از چه ساخته شده است؟

نیکولای: از نقطه نظر فنی، ما در ابتدا این الزام را داشتیم که محصول تا حد امکان از هر فروشنده ای انتزاعی باشد. به 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 ها چه اتفاقی می افتد، واقعاً چقدر حافظه مورد نیاز است، باید پلت فرم را تحت باری نزدیک به واقعی آزمایش کنیم.

- مطمئناً نمی‌دانم که آیا ما در حال آزمایش چیزی در سمت استریم هستیم یا خیر، اما به یاد دارم که هنگام ملاقات با رمزگذارها مشکلاتی وجود داشت. آیا استریم ها را آزمایش کرده ایم؟

آرتیوم: به صورت تکراری تست شد. سازماندهی جلسات. در روند سازماندهی جلسات، تقریباً 2300 بلیط JIRA وجود داشت. اینها فقط کارهای عمومی هستند که مردم برای تشکیل جلسات انجام می دادند. ما بخش‌هایی از پلتفرم را برای ملاقات‌ها در صفحه‌ای جداگانه قرار دادیم که توسط کریل تولکاچف اداره می‌شد.talkkv).

صادقانه بگویم، هیچ مشکل بزرگی وجود نداشت. به معنای واقعی کلمه چند بار در CloudFront باگ‌های ذخیره‌سازی پنهان را گرفتیم، خیلی سریع آن را حل کردیم - ما به سادگی سیاست‌ها را دوباره پیکربندی کردیم. به طور قابل توجهی باگ های بیشتری در افراد در سیستم های پخش در سایت وجود داشت.

در طول کنفرانس ها مجبور شدم چندین صادرکننده دیگر بنویسم تا تجهیزات و خدمات بیشتری را پوشش دهم. بعضی جاها مجبور شدم دوچرخه های خودم را فقط به خاطر معیارها بسازم. دنیای سخت افزار AV (صوتی-تصویری) چندان خوشگل نیست - شما نوعی "API" از تجهیزات دارید که به سادگی نمی توانید بر آنها تأثیر بگذارید. و این که بتوانید اطلاعات مورد نیاز خود را به دست آورید دور از واقعیت است. فروشندگان سخت افزار واقعا کند هستند و تقریباً غیرممکن است که آنچه را که می خواهید از آنها بدست آورید. در مجموع بیش از 100 قطعه سخت افزار وجود دارد، آنها آنچه را که نیاز دارید پس نمی دهند، و شما صادرکنندگان عجیب و غریب و اضافی می نویسید، به لطف آنها حداقل می توانید سیستم را به نحوی اشکال زدایی کنید.

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

- به یاد دارم که چگونه قبل از شروع کنفرانس ها تا حدی تجهیزات اضافی خریداری کردیم.

آرتیوم: ما کامپیوتر، لپ تاپ و بسته باتری خریدیم. در حال حاضر می توانیم 40 دقیقه بدون برق زندگی کنیم. در ماه ژوئن رعد و برق شدید در سنت پترزبورگ بود - بنابراین ما چنین خاموشی داشتیم. در همان زمان چندین ارائه دهنده با لینک های نوری از نقاط مختلف به ما مراجعه می کنند. این واقعاً 40 دقیقه از کار افتادگی ساختمان است که در طی آن چراغ‌ها، صدا، دوربین‌ها و غیره کار می‌کنند.

- ما داستان مشابهی با اینترنت داریم. در دفتری که استودیوهای ما در آن قرار دارند، توری محکم بین طبقات کشیدیم.

آرتیوم: ما بین طبقات 20 گیگابیت فیبر داریم. بیشتر در امتداد طبقات، جایی اپتیک وجود دارد، جایی اپتیک وجود ندارد، اما هنوز کانال های کمتری نسبت به کانال های گیگابیتی وجود دارد - ما بین آهنگ های کنفرانس ویدیو را روی آنها اجرا می کنیم. به طور کلی، کار بر روی زیرساخت های خود بسیار راحت است؛ به ندرت می توانید این کار را در کنفرانس های آفلاین در سایت ها انجام دهید.

- قبل از اینکه در گروه JUG Ru کار کنم، دیدم که چگونه اتاق‌های سخت‌افزار در کنفرانس‌های آفلاین یک شبه راه‌اندازی می‌شوند، جایی که یک مانیتور بزرگ با تمام معیارهایی که شما در Grafana می‌سازید وجود دارد. اکنون یک اتاق ستاد نیز وجود دارد که تیم توسعه در آن نشسته است، که در طول کنفرانس برخی از باگ ها را برطرف کرده و ویژگی ها را توسعه می دهد. در عین حال، یک سیستم مانیتورینگ وجود دارد که در یک صفحه نمایش بزرگ نمایش داده می شود. آرتیوم، کولیا و دیگر بچه ها می نشینند و مطمئن می شوند که همه چیز سقوط نمی کند و به زیبایی کار می کند.

کنجکاوی ها و مشکلات

- شما به خوبی در مورد این واقعیت صحبت کردید که ما با آمازون استریم داریم، یک پخش کننده با وب وجود دارد، همه چیز به زبان های برنامه نویسی مختلف نوشته شده است، تحمل خطا و سایر الزامات تجاری ارائه شده است، از جمله یک حساب شخصی که برای اشخاص حقوقی پشتیبانی می شود و افراد، و ما می توانیم با شخصی با استفاده از OAuth 2.0 ادغام کنیم، ضد کلاهبرداری، مسدود کردن کاربر وجود دارد. ما می‌توانیم تغییرات را به‌صورت پویا اجرا کنیم، زیرا آن را به خوبی انجام دادیم، و همه آن‌ها آزمایش شده‌اند.

من علاقه مندم بدانم چه چیزهای عجیبی در شروع کاری دخیل بوده است. آیا موقعیت های عجیب و غریبی وجود داشته است که در حال توسعه یک باطن، فرانت اند، چیزی دیوانه کننده بوده و شما نفهمیده اید که با آن چه کار کنید؟

ولادیمیر: به نظر من فقط در سه ماه گذشته این اتفاق افتاده است. هر روز. همانطور که می بینید تمام موهایم کنده شده است.

ولادیمیر کراسیلشچیک بعد از 3 ماه، زمانی که نوعی بازی به پایان رسید و هیچ کس نفهمید که با آن چه کند

هر روز چیزی شبیه به این وجود داشت، زمانی که چنین لحظه‌ای بود که آن را می‌گیری و موهایت را در می‌آوری، یا می‌فهمیدی که هیچ کس دیگری وجود ندارد و فقط تو می‌توانی این کار را انجام دهی. اولین رویداد بزرگ ما TechTrain بود. در 6 ژوئن، ساعت 2 بامداد، ما هنوز محیط تولید را راه اندازی نکرده بودیم، کولیا در حال پخش آن بود. و حساب شخصی به عنوان یک سرور مجوز با استفاده از OAuth2.0 کار نمی کند. ما آن را به یک ارائه دهنده OAuth2.0 تبدیل کردیم تا پلتفرم را به آن متصل کنیم. من احتمالاً 18 ساعت متوالی کار کرده بودم، به کامپیوتر نگاه کردم و چیزی ندیدم، متوجه نشدم چرا کار نمی کند، و کولیا از راه دور به کد من نگاه کرد، به دنبال یک اشکال در تنظیمات Spring گشت. ، آن را پیدا کرد، و LC کار کرد، و در حال تولید نیز بود.

نیکولای: و یک ساعت قبل از انتشار TechTrain انجام شد.

بسیاری از ستاره ها در اینجا قرار گرفتند. ما بسیار خوش شانس بودیم زیرا یک تیم فوق العاده داشتیم و همه از ایده انجام آن به صورت آنلاین الهام گرفتند. در تمام این سه ماه ما تحت تأثیر این واقعیت بودیم که «یوتیوب» را ساختیم. من به خودم اجازه ندادم موهایم را پاره کنم، اما به همه گفتم که همه چیز درست می شود، زیرا در واقع، همه چیز از مدت ها قبل محاسبه شده بود.

درباره عملکرد

- می‌توانید به من بگویید چند نفر در یک آهنگ در سایت بودند؟ آیا مشکلات عملکردی وجود داشت؟

نیکولای: همانطور که قبلاً گفتیم هیچ مشکلی در عملکرد وجود نداشت. حداکثر تعداد افرادی که در یک گزارش شرکت کردند 1300 نفر بود، این در Heisenbug است.

- آیا در مشاهده محلی مشکلی وجود داشت؟ و آیا می توان یک توضیح فنی با نمودارهایی از نحوه کار همه آن داشت؟

نیکولای: بعداً مقاله ای در این مورد خواهیم نوشت.

حتی می توانید جریان ها را به صورت محلی اشکال زدایی کنید. پس از شروع کنفرانس ها، کار آسان تر شد، زیرا جریان های تولیدی ظاهر شد که ما می توانیم همیشه تماشا کنیم.

ولادیمیر: همانطور که می‌دانم، توسعه‌دهندگان فرانت‌اند به‌صورت محلی با ماک‌ها کار می‌کردند، و سپس، از آنجایی که زمان عرضه به برنامه‌نویس‌های جلویی نیز کوتاه است (۵ دقیقه)، هیچ مشکلی برای بررسی آنچه در گواهی‌ها می‌گذرد وجود ندارد.

- همه چیز تست شده و اشکال زدایی می شود، حتی به صورت محلی. این بدان معنی است که ما مقاله ای با تمام ویژگی های فنی می نویسیم، به شما نشان می دهیم، همه چیز را با نمودار به شما می گوییم، چگونه بود.

ولادیمیر: می توانید آن را بگیرید و تکرار کنید.

- در 3 ماه.

مجموع

- همه چیزهایی که با هم توضیح داده می شوند، با توجه به اینکه توسط یک تیم کوچک در سه ماه انجام شد، جالب به نظر می رسد.

نیکولای: یک تیم بزرگ این کار را نمی کند. اما گروه کوچکی از مردم که ارتباط نزدیک و خوبی با یکدیگر دارند و می توانند به توافق برسند، می توانند. آنها هیچ تناقضی ندارند، معماری در دو روز اختراع شد، نهایی شد و در واقع تغییری نکرده است. تسهیلات بسیار دقیقی برای الزامات کسب و کار ورودی از نظر انباشته کردن درخواست‌ها و تغییرات ویژگی وجود دارد.

- وقتی کنفرانس های تابستانی قبلاً برگزار شده بود، در لیست کارهای بعدی شما چه بود؟

نیکولای: مثلاً اعتبارات. خطوط خزنده روی ویدیو، بسته به محتوایی که نشان داده می‌شود، در برخی از مکان‌های ویدیو پنجره‌های بازشو ظاهر می‌شوند. به عنوان مثال، گوینده می خواهد یک سوال از مخاطب بپرسد و یک رای روی صفحه ظاهر می شود که بر اساس نتایج رای گیری به خود گوینده به پشت باز می گردد. نوعی فعالیت اجتماعی به شکل لایک، قلب، رتبه بندی گزارش در حین ارائه، به طوری که بتوانید در لحظه مناسب بازخورد را پر کنید بدون اینکه بعداً توسط فرم های بازخورد منحرف شوید. در ابتدا اینگونه است.

و همچنین اضافه کردن به کل پلت فرم، به جز پخش و کنفرانس، همچنین وضعیت پس از کنفرانس. اینها لیست‌های پخش (از جمله آنهایی که توسط کاربران گردآوری شده‌اند)، احتمالاً محتوایی از کنفرانس‌های گذشته، یکپارچه، برچسب‌گذاری شده، قابل دسترسی برای کاربر و همچنین برای مشاهده در وب‌سایت ما در دسترس هستند (live.jugru.org).

- بچه ها، خیلی ممنون از پاسخ های شما!

اگر در بین خوانندگان کسانی هستند که در کنفرانس های تابستانی ما شرکت کردند، لطفاً برداشت خود را از پخش کننده و پخش به اشتراک بگذارید. چه چیزی راحت بود، چه چیزی شما را عصبانی کرد، دوست دارید در آینده چه چیزی را ببینید؟

اگر به این پلتفرم علاقه مند هستید و می خواهید آن را "در نبرد" ببینید، ما دوباره از آن در سایت خود استفاده می کنیم کنفرانس های پاییز و زمستان. طیف وسیعی از آنها وجود دارد، بنابراین تقریباً مطمئناً یکی برای شما مناسب است.

منبع: www.habr.com