وجدنا أنفسنا هذا الربيع في ظروف مبهجة للغاية. بسبب الوباء، أصبح من الواضح أن مؤتمراتنا الصيفية يجب أن تنتقل عبر الإنترنت. ومن أجل إجرائها عبر الإنترنت بكفاءة، لم تكن الحلول البرمجية الجاهزة مناسبة لنا، وكان علينا أن نكتب حلولنا الخاصة. وكان لدينا ثلاثة أشهر للقيام بذلك.

من الواضح أنها كانت ثلاثة أشهر مثيرة. ولكن من الخارج ليس الأمر واضحًا تمامًا: ما هي منصة المؤتمرات عبر الإنترنت؟ ما هي الأجزاء التي تتكون منها؟ لذلك، في آخر مؤتمرات DevOops الصيفية، سألت المسؤولين عن هذه المهمة:

• نيكولاي مولتشانوف - المدير الفني لمجموعة JUG Ru؛
• فلاديمير كراسيلشيك هو مبرمج جافا عملي يعمل على الواجهة الخلفية (يمكنك أيضًا الاطلاع على تقاريره في مؤتمرات Java الخاصة بنا)؛
• أرتيوم نيكونوف هو المسؤول عن جميع عمليات بث الفيديو لدينا.

بالمناسبة، في مؤتمرات الخريف والشتاء، سنستخدم نسخة محسنة من نفس المنصة - لذلك سيظل العديد من قراء الهبرة من مستخدميها.

الصورة الكبيرة

– كيف كان تشكيل الفريق؟

نيكولاي مولتشانوف: لدينا محلل، ومصمم، ومختبر، وثلاثة واجهات أمامية، وواجهة خلفية. وبالطبع متخصص على شكل حرف T!

- كيف بدت العملية بشكل عام؟

نيكولاي: حتى منتصف شهر مارس، لم يكن لدينا أي شيء جاهز للعب عبر الإنترنت على الإطلاق. وفي 15 مارس، بدأ العرض الدائري بأكمله على الإنترنت في الدوران. أنشأنا العديد من المستودعات، وخططنا لها، وناقشنا البنية الأساسية لها، وقمنا بكل شيء في ثلاثة أشهر.

وقد مر هذا بالطبع بالمراحل الكلاسيكية للتخطيط والهندسة المعمارية واختيار الميزات والتصويت لتلك الميزات وسياسة تلك الميزات وتصميمها وتطويرها واختبارها. ونتيجة لذلك، في 6 يونيو، قمنا بطرح كل شيء للإنتاج. قطار التكنولوجيا. كان هناك 90 يومًا لكل شيء.

– هل نجحنا في إنجاز ما التزمنا به؟

نيكولاي: وبما أننا نشارك الآن في مؤتمر DevOops عبر الإنترنت، فهذا يعني أنه نجح. أنا شخصيًا ملتزم بالشيء الرئيسي: سأقدم للعملاء أداة يمكنهم من خلالها عقد مؤتمر عبر الإنترنت.

كان التحدي كالتالي: أعطونا أداة يمكننا من خلالها بث مؤتمراتنا لحاملي التذاكر.

تم تقسيم كل التخطيط إلى عدة مراحل، وتم تقسيم جميع الميزات (حوالي 30 عالمية) إلى 4 فئات:

• وهو ما سنفعله بالتأكيد (لا يمكننا العيش بدونهم)،
• وهو ما سنفعله ثانيا
• وهو ما لن نفعله أبداً
• وهو ما لن نفعله أبدًا.

لقد صنعنا جميع الميزات من الفئتين الأوليين.

- أعلم أنه تم إنشاء إجمالي 600 إصدار من JIRA. في ثلاثة أشهر، قمت بإنشاء 13 خدمة صغيرة، وأظن أنها لم تكن مكتوبة بلغة Java فقط. لقد استخدمت تقنيات مختلفة، ولديك مجموعتان من مجموعات Kubernetes في ثلاث مناطق توافر و5 تدفقات RTMP في Amazon.

دعونا الآن نلقي نظرة على كل مكون من مكونات النظام على حدة.

تدفق

— لنبدأ عندما يكون لدينا بالفعل صورة فيديو، ويتم نقلها إلى بعض الخدمات. أرتيوم، أخبرنا كيف يحدث هذا البث؟

أرتيوم نيكونوف: يبدو مخططنا العام كما يلي: صورة من الكاميرا -> غرفة التحكم لدينا -> خادم RTMP المحلي -> أمازون -> مشغل الفيديو. المزيد من التفاصيل كتب عنها في حبري في يونيو.

بشكل عام، هناك طريقتان عالميتان للقيام بذلك: إما على الأجهزة أو على أساس الحلول البرمجية. لقد اخترنا مسار البرنامج لأنه أسهل في حالة مكبرات الصوت عن بعد. ليس من الممكن دائمًا جلب الأجهزة إلى مكبر صوت في بلد آخر، ولكن يبدو توصيل البرامج إلى مكبر الصوت أسهل وأكثر موثوقية.

من وجهة نظر الأجهزة، لدينا عدد معين من الكاميرات (في استوديوهاتنا وفي مكبرات الصوت عن بعد)، وعدد معين من أجهزة التحكم عن بعد في الاستوديو، والتي يجب في بعض الأحيان إصلاحها مباشرة أسفل الطاولة أثناء البث.

تدخل الإشارات الصادرة عن هذه الأجهزة إلى أجهزة الكمبيوتر المزودة ببطاقات الالتقاط وبطاقات الإدخال/الإخراج وبطاقات الصوت. هناك يتم خلط الإشارات وتجميعها في تخطيطات:

مثال على تخطيط لأربعة مكبرات صوت

مثال على تخطيط لأربعة مكبرات صوت

علاوة على ذلك، يتم توفير البث المستمر بمساعدة ثلاثة أجهزة كمبيوتر: يوجد جهاز رئيسي واحد وزوج من الأجهزة العاملة على التوالي. يقوم الكمبيوتر الأول بجمع التقرير الأول، والثاني - الاستراحة، والأول - التقرير التالي، والثاني - الاستراحة التالية، وهكذا. والآلة الرئيسية تخلط الأول مع الثاني.

يؤدي هذا إلى إنشاء نوع من المثلث، وإذا فشلت أي من هذه العقد، فيمكننا الاستمرار بسرعة ودون فقدان الجودة في تقديم المحتوى للعملاء. كان لدينا مثل هذا الوضع. خلال الأسبوع الأول من المؤتمرات، قمنا بإصلاح جهاز واحد وتشغيله وإيقاف تشغيله. يبدو أن الناس سعداء بمرونتنا.

بعد ذلك، تنتقل التدفقات من أجهزة الكمبيوتر إلى خادم محلي، له مهمتان: توجيه تدفقات RTMP وتسجيل النسخ الاحتياطية. لذلك لدينا نقاط تسجيل متعددة. يتم بعد ذلك إرسال تدفقات الفيديو إلى جزء نظامنا المبني على خدمات Amazon SaaS. نحن نستخدم ميديا ​​لايف،S3، كلاودفرونت.

نيكولاي: ماذا يحدث هناك قبل أن يصل الفيديو إلى الجمهور؟ عليك أن تقطعها بطريقة أو بأخرى، أليس كذلك؟

أرتيوم: نقوم بضغط الفيديو من جانبنا وإرساله إلى MediaLive. نطلق أجهزة الترميز هناك. يقومون بتحويل مقاطع الفيديو في الوقت الفعلي إلى عدة درجات دقة حتى يتمكن الأشخاص من مشاهدتها على هواتفهم، عبر الإنترنت الضعيف في البلاد، وما إلى ذلك. ثم يتم قطع هذه التدفقات قطع، هذه هي الطريقة التي يعمل بها البروتوكول HLS. نرسل قائمة تشغيل إلى الواجهة الأمامية تحتوي على مؤشرات لهذه القطع.

- هل نستخدم دقة 1080 بكسل؟

أرتيوم: عرض الفيديو الخاص بنا هو نفس 1080 بكسل - 1920 بكسل، والارتفاع أقل قليلاً، والصورة أكثر استطالة - وهناك أسباب لذلك.

لاعب

— وصف Artyom كيفية وصول الفيديو إلى التدفقات، وكيفية توزيعه إلى قوائم تشغيل مختلفة لدرجات دقة شاشة مختلفة، وتقطيعه إلى أجزاء ودخوله إلى المشغل. كوليا، أخبرني الآن ما هو نوع هذا اللاعب، وكيف يستهلك الدفق، ولماذا HLS؟

نيكولاي: لدينا لاعب يمكن لجميع مشاهدي المؤتمر مشاهدته.

في الأساس، هذا غلاف حول المكتبة hls.js، والتي كتب عليها العديد من اللاعبين الآخرين. لكننا كنا بحاجة إلى وظيفة محددة للغاية: الترجيع ووضع علامة على المكان الذي يتواجد فيه الشخص، والتقرير الذي يشاهده حاليًا. كنا بحاجة أيضًا إلى تخطيطاتنا الخاصة وجميع أنواع الشعارات وكل شيء آخر تم تصميمه معنا. لذلك، قررنا كتابة مكتبتنا الخاصة (مجمع فوق HLS) وإدراجها في الموقع.

هذه هي وظيفة الجذر، لذلك تم تنفيذها أولاً تقريبًا. ثم نما كل شيء من حوله.

في الواقع، من خلال الترخيص، يتلقى اللاعب من الواجهة الخلفية قائمة تشغيل تحتوي على روابط لمقاطع مرتبطة بالوقت والجودة، ويقوم بتنزيل العناصر الضرورية ويعرضها للمستخدم، مما يؤدي إلى بعض "السحر" على طول الطريق.

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

- يوجد زر مدمج في المشغل مباشرةً لعرض جدول زمني لجميع التقارير...

نيكولاي: نعم، لقد قمنا على الفور بحل مشكلة تنقل المستخدم. في منتصف أبريل، قررنا أننا لن نبث كل مؤتمر من مؤتمراتنا على موقع منفصل، بل سنجمع كل شيء في موقع واحد. بحيث يمكن لمستخدمي تذكرة Full Pass التبديل بحرية بين المؤتمرات المختلفة: كل من البث المباشر وتسجيلات المؤتمرات السابقة.

ولتسهيل على المستخدمين التنقل في البث الحالي والتبديل بين المسارات، قررنا إنشاء زر "البث الكامل" وبطاقات التقارير الأفقية للتبديل بين المسارات والتقارير. هناك التحكم في لوحة المفاتيح.

– هل كانت هناك أي صعوبات فنية في هذا؟

نيكولاي: كان لديهم شريط تمرير تم تحديد نقاط البداية للتقارير المختلفة عليه.

— في النهاية، هل قمت بتطبيق هذه العلامات على شريط التمرير قبل أن يفعل يوتيوب شيئًا مشابهًا؟

أرتيوم: كان لديهم في مرحلة تجريبية بعد ذلك. يبدو أن هذه ميزة معقدة جدًا لأنهم اختبروها جزئيًا مع المستخدمين خلال العام الماضي. والآن وصلت للبيع.

نيكولاي: لكننا في الواقع نجحنا في بيعه بشكل أسرع. بصراحة، خلف هذه الميزة البسيطة يوجد كم هائل من الواجهة الخلفية والواجهة الأمامية والحسابات والرياضيات داخل اللاعب.

نهاية المقدمة

— دعونا نتعرف على كيفية وصول هذا المحتوى الذي نعرضه (بطاقة الكلام، مكبرات الصوت، موقع الويب، الجدول الزمني) إلى الواجهة الأمامية؟

فلاديمير كراسيلشيك: لدينا العديد من أنظمة تكنولوجيا المعلومات الداخلية. يوجد نظام يتم من خلاله إدخال جميع التقارير وجميع المتحدثين. هناك عملية يشارك من خلالها المتحدث في المؤتمر. يقدم المتحدث طلبا، ويقوم النظام بالتقاطه، ثم هناك مسار معين يتم من خلاله إنشاء التقرير.

هذه هي الطريقة التي يرى بها المتحدث خط الأنابيب

هذا النظام هو تطورنا الداخلي.

بعد ذلك، تحتاج إلى إنشاء جدول زمني من التقارير الفردية. كما تعلمون، هذه مشكلة NP-صعبة، ولكننا قمنا بحلها بطريقة ما. للقيام بذلك، نطلق مكونًا آخر يقوم بإنشاء جدول وتحميله إلى الخدمة السحابية التابعة لجهة خارجية Contentful. هناك، يبدو كل شيء وكأنه جدول توجد فيه أيام المؤتمر، وفي الأيام توجد فترات زمنية، وفي الفترات توجد تقارير أو فترات راحة أو أنشطة رعاية. لذا فإن المحتوى الذي نراه موجود في خدمة تابعة لجهة خارجية. والمهمة هي نقله إلى الموقع.

يبدو أن الموقع مجرد صفحة بها لاعب، ولا يوجد شيء معقد هنا. إلا أنها ليست كذلك. تنتقل الواجهة الخلفية خلف هذه الصفحة إلى Contentful، وتحصل على الجدول الزمني من هناك، وتقوم بإنشاء بعض الكائنات وإرسالها إلى الواجهة الأمامية. باستخدام اتصال websocket، الذي يقوم به كل عميل لمنصتنا، نرسل له تحديثًا للجدول الزمني من الواجهة الخلفية إلى الواجهة الأمامية.

حالة حقيقية: قام المتحدث بتغيير وظائفه أثناء المؤتمر. نحن بحاجة إلى تغيير شارة شركة صاحب العمل. كيف يحدث هذا من الخلفية؟ يتم إرسال تحديث إلى جميع العملاء عبر websocket، ثم تقوم الواجهة الأمامية نفسها بإعادة رسم المخطط الزمني. كل هذا يحدث بسلاسة. يمنحنا الجمع بين الخدمة السحابية والعديد من مكوناتنا الفرصة لإنشاء كل هذا المحتوى وتقديمه إلى المقدمة.

نيكولاي: ومن المهم التوضيح هنا أن موقعنا ليس تطبيقًا كلاسيكيًا للـ SPA. هذا موقع ويب قائم على التخطيط ومنتجع صحي. ترى Google في الواقع أن هذا الموقع هو HTML معروض. يعد هذا أمرًا جيدًا لتحسين محركات البحث ولتقديم المحتوى للمستخدم. فهو لا ينتظر تحميل 1,5 ميغابايت من JavaScript قبل رؤية الصفحة، بل يرى على الفور الصفحة المعروضة بالفعل، وتشعر بذلك في كل مرة تقوم فيها بتبديل التقرير. كل شيء يحدث في نصف ثانية، حيث أن المحتوى جاهز بالفعل ويتم نشره في المكان المناسب.

- دعونا نرسم خطًا تحت كل ما سبق من خلال سرد التقنيات. قال تيوما إن لدينا 5 تدفقات على أمازون، ونقوم بتوصيل الفيديو والصوت هناك. لدينا نصوص باش هناك، نستخدمها للتشغيل والتكوين...

أرتيوم: يحدث هذا من خلال AWS API، وهناك العديد من الخدمات الجانبية التقنية هناك. لقد قسمنا مسؤولياتنا حتى أسلمها CloudFront، ويأخذها مطورو الواجهة الأمامية والخلفية من هناك. لدينا عدد من الارتباطات الخاصة بنا لتبسيط تخطيط المحتوى، والتي نصنعها بعد ذلك بدقة 4K، وما إلى ذلك. نظرًا لأن المواعيد النهائية كانت ضيقة للغاية، فقد قمنا بذلك بالكامل تقريبًا على AWS.

- ثم يذهب كل هذا إلى المشغل باستخدام نظام الواجهة الخلفية. لدينا TypeScript وReact وNext.JS في مشغلنا. وعلى الواجهة الخلفية لدينا العديد من الخدمات في C# وJava وSpring Boot وNode.js. يتم نشر كل هذا باستخدام Kubernetes باستخدام البنية التحتية لـ Yandex.Cloud.

أريد أيضًا أن أشير إلى أنه عندما كنت بحاجة إلى التعرف على النظام الأساسي، فقد تبين أن الأمر سهل: جميع المستودعات موجودة على GitLab، وكل شيء مسمى جيدًا، والاختبارات مكتوبة، وهناك وثائق. وهذا هو، حتى في وضع الطوارئ، اعتنوا بمثل هذه الأشياء.

قيود الأعمال والتحليلات

— استهدفنا 10 مستخدم بناءً على متطلبات العمل. حان الوقت للحديث عن القيود التجارية التي كانت لدينا. كان علينا ضمان عبء عمل كبير، وضمان الامتثال لقانون الحفاظ على البيانات الشخصية. وماذا ايضا؟

نيكولاي: في البداية، بدأنا من متطلبات الفيديو. أهم شيء هو تخزين الفيديو الموزع حول العالم من أجل التسليم السريع للعميل. يتضمن البعض الآخر دقة 1080 بكسل، بالإضافة إلى الترجيع، وهو ما لا ينفذه كثيرون آخرون في الوضع المباشر. أضفنا لاحقًا القدرة على تمكين السرعة 2x، وبمساعدتها يمكنك "متابعة" البث المباشر ومواصلة مشاهدة المؤتمر في الوقت الفعلي. وعلى طول الطريق، ظهرت وظيفة تحديد الجدول الزمني. بالإضافة إلى ذلك، كان علينا أن نكون متسامحين مع الأخطاء وأن نتحمل حمل 10 اتصال. من وجهة نظر الواجهة الخلفية، هذا يعادل حوالي 000 اتصال مضروبًا في 10 طلبات لكل تحديث للصفحة. وهذا بالفعل 000 دورة في الثانية/ثانية. لا بأس به من.

— هل كانت هناك أي متطلبات أخرى لـ “المعرض الافتراضي” مع منصات الشركاء عبر الإنترنت؟

نيكولاي: نعم، كان لا بد من القيام بذلك بسرعة وبشكل شامل. كان لدينا ما يصل إلى 10 شركات شريكة لكل مؤتمر، وكان لا بد من الانتهاء منها جميعًا خلال أسبوع أو أسبوعين. ومع ذلك، فإن محتواها يختلف قليلا في الشكل. ولكن تم إنشاء محرك قالب معين يقوم بتجميع هذه الصفحات بسرعة، دون أي مشاركة في التطوير تقريبًا.

- كانت هناك أيضًا متطلبات لتحليلات المشاهدات والإحصاءات في الوقت الفعلي. أعلم أننا نستخدم بروميثيوس لهذا الغرض، لكن أخبرنا بمزيد من التفاصيل: ما هي المتطلبات التي نلبيها للتحليلات، وكيف يتم تنفيذها؟

نيكولاي: في البداية، لدينا متطلبات تسويقية للتجميع لاختبار أ/ب وجمع المعلومات من أجل فهم كيفية تقديم أفضل محتوى بشكل صحيح للعميل في المستقبل. هناك أيضًا متطلبات لبعض التحليلات حول أنشطة الشركاء والتحليلات التي تراها (عداد الزيارة). يتم جمع كافة المعلومات في الوقت الحقيقي.

يمكننا تقديم هذه المعلومات بشكل مجمع حتى للمتحدثين: كم عدد الأشخاص الذين كانوا يشاهدونك في وقت معين. وفي الوقت نفسه، امتثالاً للقانون الاتحادي رقم 152، لا يتم تتبع حسابك الشخصي وبياناتك الشخصية بأي شكل من الأشكال.

تحتوي المنصة بالفعل على أدوات تسويقية ومقاييسنا لقياس نشاط المستخدم في الوقت الفعلي (من شاهد أي ثانية من التقرير) من أجل إنشاء رسوم بيانية لحضور التقارير. وبناءً على هذه البيانات، يتم إجراء الأبحاث التي من شأنها أن تجعل المؤتمرات القادمة أفضل.

احتيال

– هل لدينا آليات لمكافحة الاحتيال؟

نيكولاي: نظرًا للإطار الزمني الضيق من وجهة نظر الأعمال، لم يتم تعيين المهمة في البداية لحظر الاتصالات غير الضرورية على الفور. إذا قام مستخدمان بتسجيل الدخول تحت نفس الحساب، فيمكنهما عرض المحتوى. لكننا نعرف عدد المشاهدات المتزامنة التي تمت من حساب واحد. وقمنا بحظر العديد من المخالفين الضارين بشكل خاص.

فلاديمير: ويُحسب أن أحد المستخدمين المحظورين فهم سبب حدوث ذلك. لقد جاء واعتذر ووعد بشراء تذكرة.

— لكي يحدث كل هذا، يجب عليك تتبع جميع المستخدمين بشكل كامل من الدخول إلى الخروج، ومعرفة ما يفعلونه دائمًا. كيف يعمل هذا النظام؟

فلاديمير: أود أن أتحدث عن التحليلات والإحصائيات، التي نقوم بعد ذلك بتحليلها لتحقيق نجاح التقرير أو يمكننا بعد ذلك تقديمها للشركاء. يتم توصيل جميع العملاء عبر اتصال websocket بمجموعة خلفية محددة. انها تقف هناك البندق. يرسل كل عميل في كل فترة زمنية ما يفعله وما هو المسار الذي يشاهده. ثم يتم تجميع هذه المعلومات باستخدام وظائف Hazelcast السريعة وإرسالها مرة أخرى إلى كل من يشاهد هذه المسارات. نرى في الزاوية عدد الأشخاص الموجودين معنا الآن.

يتم تخزين نفس المعلومات في مونغو وينتقل إلى بحيرة البيانات الخاصة بنا، والتي لدينا منها الفرصة لإنشاء رسم بياني أكثر إثارة للاهتمام. السؤال الذي يطرح نفسه: كم عدد المستخدمين الفريدين الذين شاهدوا هذا التقرير؟ نحن نذهب الي بوستجرس، هناك أصوات لجميع الأشخاص الذين جاءوا بمعرف هذا التقرير. لقد قمنا بجمع وتجميع العناصر الفريدة، والآن يمكننا أن نفهم.

نيكولاي: ولكن في الوقت نفسه، نتلقى أيضًا بيانات في الوقت الفعلي من بروميثيوس. تم وضعه ضد جميع خدمات Kubernetes، وضد Kubernetes نفسها. إنه يجمع كل شيء على الإطلاق، ومع Grafana يمكننا إنشاء أي رسوم بيانية في الوقت الفعلي.

فلاديمير: من ناحية، نقوم بتنزيل هذا لمزيد من معالجة OLAP. وبالنسبة لـ OLTP، يقوم التطبيق بتنزيل كل شيء على Prometheus وGrafana وتتقارب الرسوم البيانية!

- هذا هو الحال عندما تتقارب الرسوم البيانية.

التغييرات الديناميكية

— أخبرنا كيف يتم تنفيذ التغييرات الديناميكية: إذا تم إلغاء التقرير قبل 6 دقائق من البداية، فما هي سلسلة الإجراءات؟ أي خط أنابيب يعمل؟

فلاديمير: خط الأنابيب مشروط للغاية. هناك عدة احتمالات. الأول هو أن برنامج إنشاء الجدول الزمني يعمل ويغير الجدول. يتم تحميل الجدول المعدل إلى Contentful. وبعد ذلك تفهم الواجهة الخلفية أن هناك تغييرات لهذا المؤتمر في Contentful، وتأخذه وتعيد بنائه. يتم جمع كل شيء وإرساله عبر websocket.

الاحتمال الثاني، عندما يحدث كل شيء بوتيرة مذهلة: يقوم المحرر يدويًا بتغيير المعلومات الموجودة في Contentful (رابط إلى Telegram، العرض التقديمي للمتحدث، وما إلى ذلك) ويعمل نفس المنطق كما في المرة الأولى.

نيكولاي: كل شيء يحدث دون تحديث الصفحة. تتم جميع التغييرات بسلاسة تامة للعميل. الأمر نفسه ينطبق على تبديل التقارير. عندما يحين الوقت، يتغير التقرير والواجهة.

فلاديمير: بالإضافة إلى ذلك، هناك حدود زمنية لبدء التقارير في المخطط الزمني. في البداية لا يوجد شيء. وإذا قمت بتمرير مؤشر الماوس فوق الشريط الأحمر، ففي مرحلة ما، بفضل مدير البث، ستظهر القطع. يقوم المخرج بتعيين البداية الصحيحة للبث، وتلتقط الواجهة الخلفية هذا التغيير، وتحسب أوقات البداية والنهاية لعروض المسار بالكامل وفقًا لجدول المؤتمر، وترسلها إلى عملائنا، ويقوم اللاعب برسم القطع. الآن يمكن للمستخدم التنقل بسهولة إلى بداية التقرير ونهايته. لقد كان متطلبًا تجاريًا صارمًا، ومريحًا ومفيدًا للغاية. لن تضيع الوقت في العثور على وقت البدء الفعلي للتقرير. وعندما نقوم بالمعاينة، سيكون الأمر رائعًا للغاية.

تعيين

– أود أن أسأل عن النشر. قضى كوليا والفريق الكثير من الوقت في البداية لإعداد البنية التحتية بأكملها التي يتكشف فيها كل شيء بالنسبة لنا. قل لي، مما يتكون كل هذا؟

نيكولاي: من وجهة نظر فنية، كان لدينا في البداية شرط أن يكون المنتج مجردًا قدر الإمكان من أي بائع. تعال إلى AWS لإنشاء نصوص Terraform البرمجية خصيصًا من AWS، أو على وجه التحديد من Yandex، أو من Azure، وما إلى ذلك. لم يكن مناسبا حقا. كان علينا أن ننتقل إلى مكان ما في مرحلة ما.

خلال الأسابيع الثلاثة الأولى، كنا نبحث باستمرار عن طريقة للقيام بذلك بشكل أفضل. ونتيجة لذلك، توصلنا إلى استنتاج مفاده أن Kubernetes في هذه الحالة هو كل شيء لدينا، لأنه يسمح لنا بإنشاء خدمات قابلة للتوسيع تلقائيًا، والبدء التلقائي، والحصول على جميع الخدمات تقريبًا خارج الصندوق. وبطبيعة الحال، كان لا بد من تدريب جميع الخدمات على العمل مع Kubernetes وDocker، وكان على الفريق أن يتعلم أيضًا.

لدينا مجموعتان. الاختبار والإنتاج. إنها متطابقة تمامًا من حيث الأجهزة والإعدادات. نحن ننفذ البنية التحتية كرمز. يتم نشر جميع الخدمات تلقائيًا في ثلاث بيئات من فروع الميزات والفروع الرئيسية وفروع الاختبار وGitLab باستخدام مسار تلقائي. تم دمج هذا إلى أقصى حد في GitLab، وتكامل إلى أقصى حد مع Elastic وPrometheus.

لدينا الفرصة للقيام بسرعة (للواجهة الخلفية في غضون 10 دقائق، وللواجهة الأمامية في غضون 5 دقائق) بإجراء تغييرات على أي بيئة مع جميع الاختبارات وعمليات التكامل وتشغيل الاختبارات الوظيفية واختبارات التكامل على البيئة، وكذلك الاختبار باستخدام اختبارات التحميل على بيئة الاختبار تقريبًا نفس الشيء الذي نريد الحصول عليه في الإنتاج.

حول الاختبارات

- أنت تختبر كل شيء تقريبًا، ومن الصعب تصديق كيف كتبت كل شيء. هل يمكنك إخبارنا عن اختبارات الواجهة الخلفية: ما مقدار تغطية كل شيء، وما هي الاختبارات؟

فلاديمير: تمت كتابة نوعين من الاختبارات. الأول هو اختبارات المكونات. اختبارات مستوى الرفع لتطبيق الزنبرك بأكمله والقاعدة فيه حاويات الاختبار. هذا اختبار لسيناريوهات الأعمال على أعلى مستوى. أنا لا أختبر الوظائف. نحن نختبر فقط بعض الأشياء الكبيرة. على سبيل المثال، مباشرة في الاختبار، تتم محاكاة عملية تسجيل الدخول للمستخدم، وطلب المستخدم للحصول على تذاكر إلى المكان الذي يمكنه الذهاب إليه، وطلب الوصول لمشاهدة البث. سيناريوهات مستخدم واضحة جدًا.

يتم تنفيذ نفس الشيء تقريبًا في ما يسمى باختبارات التكامل، والتي يتم إجراؤها فعليًا على البيئة. في الواقع، عندما يتم نشر النشر التالي في الإنتاج، يتم أيضًا تشغيل السيناريوهات الأساسية الحقيقية في الإنتاج. نفس تسجيل الدخول، وطلب التذاكر، وطلب الوصول إلى CloudFront، والتحقق من أن البث يتصل بالفعل بأذوناتي، والتحقق من واجهة المخرج.

لدي حاليًا حوالي 70 اختبارًا للمكونات وحوالي 40 اختبارًا للتكامل على متن الطائرة. التغطية قريبة جدًا من 95٪. هذا بالنسبة للمكونات، وأقل بالنسبة للتكامل، ببساطة ليس هناك حاجة إلى الكثير. وبالنظر إلى أن المشروع يتضمن جميع أنواع إنشاء الأكواد، فهذا مؤشر جيد جدًا. ولم تكن هناك طريقة أخرى للقيام بما فعلناه في ثلاثة أشهر. لأنه إذا اختبرنا يدويًا، وأعطينا ميزات للمختبر لدينا، وعثرت على أخطاء وأعادتها إلينا لإصلاحها، فستكون هذه الرحلة ذهابًا وإيابًا لتصحيح أخطاء الكود طويلة جدًا، ولن نلتزم بأي مواعيد نهائية.

نيكولاي: بشكل تقليدي، لتنفيذ الانحدار على النظام الأساسي بأكمله عند تغيير بعض الوظائف، تحتاج إلى الجلوس والضغط في كل مكان لمدة يومين.

فلاديمير: لذلك، إنه نجاح كبير عندما أقوم بتقدير ميزة ما، أقول إنني بحاجة إلى 4 أيام لقلمين بسيطين ومقبس ويب واحد، كوليا تسمح بذلك. لقد اعتاد بالفعل على حقيقة أن هذه الأيام الأربعة تتضمن نوعين من الاختبارات، وبعد ذلك، على الأرجح، سيعمل.

نيكولاي: لدي أيضًا 140 اختبارًا مكتوبًا: مكون + وظيفي، والذي يفعل نفس الشيء. يتم اختبار كافة السيناريوهات نفسها في الإنتاج، وفي الاختبار، وفي الإنتاج. لقد أضفنا مؤخرًا اختبارات واجهة المستخدم الأساسية الوظيفية. بهذه الطريقة نغطي الوظائف الأساسية التي يمكن أن تنهار.

فلاديمير: وبطبيعة الحال، فإنه يستحق الحديث عن اختبارات الحمل. كان من الضروري اختبار النظام الأساسي تحت حمل قريب من الحمل الحقيقي لفهم كيف يكون كل شيء، وما يحدث مع Rabbit، وما يحدث مع JVMs، ومقدار الذاكرة المطلوبة بالفعل.

- لا أعرف على وجه اليقين ما إذا كنا نختبر أي شيء على جانب البث، لكنني أتذكر أنه كانت هناك مشكلات في أجهزة تحويل الشفرة عندما عقدنا لقاءات. هل اختبرنا التدفقات؟

أرتيوم: تم اختباره بشكل متكرر. تنظيم اللقاءات. في عملية تنظيم اللقاءات، كان هناك ما يقرب من 2300 تذكرة JIRA. هذه مجرد أشياء عامة فعلها الأشخاص لعقد لقاءات. لقد أخذنا أجزاء من المنصة إلى صفحة منفصلة للاجتماعات، والتي كان يديرها كيريل تولكاتشيف (talkkv).

بصراحة، لم تكن هناك مشاكل كبيرة. لقد اكتشفنا عدة مرات أخطاء في التخزين المؤقت على CloudFront، وقمنا بحلها بسرعة كبيرة - لقد قمنا ببساطة بإعادة تكوين السياسات. كان هناك عدد أكبر بكثير من الأخطاء لدى الأشخاص، في أنظمة البث على الموقع.

خلال المؤتمرات، كان علي أن أكتب العديد من المصدرين لتغطية المزيد من المعدات والخدمات. في بعض الأماكن، كان عليّ أن أصنع دراجتي بنفسي من أجل المقاييس فقط. عالم أجهزة AV (الصوت والفيديو) ليس ورديًا جدًا - لديك نوع من "واجهة برمجة التطبيقات" للمعدات التي لا يمكنك التأثير عليها ببساطة. وليس من الحقيقة أنك ستتمكن من الحصول على المعلومات التي تحتاجها. إن بائعي الأجهزة بطيئون للغاية، ويكاد يكون من المستحيل الحصول على ما تريد منهم. في المجموع، هناك أكثر من 100 قطعة من الأجهزة، ولا يعيدون ما تحتاجه، وتكتب مصدرين غريبين وزائدين عن الحاجة، بفضل ما يمكنك على الأقل تصحيح أخطاء النظام بطريقة أو بأخرى.

معدات

— أتذكر كيف اشترينا معدات إضافية جزئيًا قبل بدء المؤتمرات.

أرتيوم: اشترينا أجهزة الكمبيوتر وأجهزة الكمبيوتر المحمولة وحزم البطاريات. في الوقت الحالي يمكننا العيش بدون كهرباء لمدة 40 دقيقة. في يونيو/حزيران، كانت هناك عواصف رعدية شديدة في سانت بطرسبرغ - لذلك حدث انقطاع للتيار الكهربائي. وفي الوقت نفسه، يأتي إلينا العديد من مقدمي الخدمة بروابط بصرية من نقاط مختلفة. هذا هو في الحقيقة 40 دقيقة من توقف البناء، سيتم خلالها تشغيل الأضواء والصوت والكاميرات وما إلى ذلك.

– لدينا قصة مماثلة مع الإنترنت. في المكتب الذي يقع فيه استوديوهاتنا، قمنا بسحب شبكة شرسة بين الطوابق.

أرتيوم: لدينا 20 جيجابت من الألياف بين الطوابق. علاوة على ذلك، على طول الطوابق، في مكان ما توجد بصريات، في مكان ما لا توجد بصريات، ولكن لا يزال هناك قنوات أقل من جيجابت - نقوم بتشغيل الفيديو عليها بين مسارات المؤتمر. بشكل عام، من المريح للغاية العمل على البنية التحتية الخاصة بك، ونادرا ما يمكنك القيام بذلك في المؤتمرات غير المتصلة بالإنترنت على المواقع.

— قبل أن أعمل في JUG Ru Group، رأيت كيف تم إعداد غرف الأجهزة في المؤتمرات غير المتصلة بالإنترنت بين عشية وضحاها، حيث كانت هناك شاشة كبيرة بها جميع المقاييس التي تقوم بإنشائها في Grafana. توجد الآن أيضًا غرفة المقر الرئيسي التي يجلس فيها فريق التطوير، والذي يقوم خلال المؤتمر بإصلاح بعض الأخطاء وتطوير الميزات. وفي نفس الوقت يوجد نظام مراقبة يتم عرضه على شاشة كبيرة. يجلس أرتيوم وكوليا والرجال الآخرون ويتأكدون من أن كل شيء لا يسقط ويعمل بشكل جميل.

غرائب ​​ومشاكل

- لقد تحدثت جيدًا عن حقيقة أننا نجري البث مع أمازون، وهناك مشغل على الويب، وكل شيء مكتوب بلغات برمجة مختلفة، ويتم توفير التسامح مع الأخطاء ومتطلبات العمل الأخرى، بما في ذلك الحساب الشخصي المدعوم للكيانات القانونية و الأفراد، ويمكننا التكامل مع شخص يستخدم OAuth 2.0، وهناك مكافحة الاحتيال، وحظر المستخدم. يمكننا تنفيذ التغييرات بشكل ديناميكي لأننا قمنا بذلك بشكل جيد، وتم اختبار كل شيء.

أنا مهتم بمعرفة ما هي الأمور الشاذة التي كانت متضمنة في بدء شيء ما. هل كانت هناك أي مواقف غريبة عندما كنت تقوم بتطوير واجهة خلفية، أو واجهة أمامية، أو حدث شيء مجنون ولم تفهم ماذا تفعل به؟

فلاديمير: ويبدو لي أن هذا لم يحدث إلا خلال الأشهر الثلاثة الماضية. كل يوم. كما ترون، تم سحب كل شعري.

فلاديمير كراسيلشيك بعد 3 أشهر، عندما ظهرت بعض الألعاب ولم يفهم أحد ما يجب فعله بها

كل يوم كان هناك شيء من هذا القبيل، عندما تكون هناك لحظة تأخذها وتمزق شعرك، أو تدرك أنه لا يوجد أحد آخر، وأنك وحدك من يستطيع فعل ذلك. كان أول حدث كبير لنا هو TechTrain. في 6 يونيو، الساعة 2 صباحًا، لم نكن قد طرحنا بيئة الإنتاج بعد، وكانت كوليا تطرحها. ولم يعمل الحساب الشخصي كخادم ترخيص باستخدام OAuth2.0. لقد قمنا بتحويله إلى مزود OAuth2.0 لتوصيل النظام الأساسي به. لقد كنت أعمل لمدة 18 ساعة متواصلة على الأرجح، ونظرت إلى الكمبيوتر ولم أر أي شيء، ولم أفهم سبب عدم عمله، ونظرت كوليا إلى الكود الخاص بي عن بعد، وبحثت عن خطأ في تكوين الربيع ، وجدته، وعمل LC، وفي الإنتاج أيضًا.

نيكولاي: وقبل ساعة من إطلاق TechTrain.

تم محاذاة الكثير من النجوم هنا. لقد كنا محظوظين للغاية لأنه كان لدينا فريق رائع، وقد ألهم الجميع فكرة القيام بذلك عبر الإنترنت. طوال هذه الأشهر الثلاثة، كنا مدفوعين بحقيقة أننا "صنعنا موقع YouTube". لم أسمح لنفسي بتمزيق شعري، لكنني أخبرت الجميع أن كل شيء سينجح، لأنه في الواقع، تم حساب كل شيء منذ فترة طويلة.

حول الأداء

- هل يمكن أن تخبرني كم عدد الأشخاص الذين كانوا في الموقع في مسار واحد؟ هل كانت هناك أي مشاكل في الأداء؟

نيكولاي: ولم تكن هناك مشاكل في الأداء كما قلنا من قبل. الحد الأقصى لعدد الأشخاص الذين حضروا التقرير الواحد كان 1300 شخص، وهذا على موقع Heisenbug.

- هل كانت هناك أي مشاكل في المشاهدة المحلية؟ وهل من الممكن الحصول على وصف تقني مع الرسوم البيانية لكيفية عمل كل شيء؟

نيكولاي: وسنقوم بإعداد مقال حول هذا لاحقًا.

يمكنك حتى تصحيح التدفقات محليًا. وبمجرد أن بدأت المؤتمرات، أصبح الأمر أسهل، لأنه ظهرت تيارات الإنتاج التي يمكننا مشاهدتها طوال الوقت.

فلاديمير: كما أفهم، عمل مطورو الواجهة الأمامية محليًا مع النماذج الوهمية، وبعد ذلك، نظرًا لأن وقت النشر إلى المطورين في المقدمة قصير أيضًا (5 دقائق)، فلا توجد مشاكل في التحقق مما يحدث مع الشهادات.

- يتم اختبار كل شيء وتصحيح أخطائه، حتى محليًا. هذا يعني أننا سنكتب مقالًا بجميع الميزات التقنية، ونعرض لك، ونخبرك بكل شيء بالرسوم البيانية، وكيف كان الأمر.

فلاديمير: يمكنك أخذها وتكرارها.

- في 3 أشهر.

مجموع

- كل ما تم وصفه معًا يبدو رائعًا، مع الأخذ في الاعتبار أنه تم إنجازه بواسطة فريق صغير في ثلاثة أشهر.

نيكولاي: فريق كبير لن يفعل هذا ولكن يمكن لمجموعة صغيرة من الأشخاص الذين يتواصلون بشكل وثيق وجيد مع بعضهم البعض ويمكنهم التوصل إلى اتفاق أن يفعلوا ذلك. ليس لديهم أي تناقضات، فقد تم اختراع الهندسة المعمارية في يومين، وتم الانتهاء منها ولم تتغير فعليا. هناك تسهيل صارم للغاية لمتطلبات العمل الواردة من حيث تراكم طلبات الميزات والتغييرات.

— ما الذي كان مدرجًا في قائمة المهام الإضافية الخاصة بك عندما كانت المؤتمرات الصيفية قد انعقدت بالفعل؟

نيكولاي: على سبيل المثال، الاعتمادات. خطوط زاحفة على الفيديو، ونوافذ منبثقة في بعض الأماكن في الفيديو حسب المحتوى المعروض. على سبيل المثال، يريد المتحدث طرح سؤال على الجمهور، فينبثق تصويت على الشاشة، والذي يعود إلى الخلف بناءً على نتائج التصويت للمتحدث نفسه. نوع من النشاط الاجتماعي على شكل إعجابات وقلوب وتقييمات للتقرير أثناء العرض التقديمي نفسه، بحيث يمكنك ملء التعليقات في اللحظة المناسبة دون تشتيت انتباهك لاحقًا عن طريق نماذج التعليقات. في البداية مثل هذا.

وأيضًا إضافة إلى النظام الأساسي بأكمله، باستثناء البث المباشر والمؤتمرات، وأيضًا حالة ما بعد المؤتمر. هذه هي قوائم التشغيل (بما في ذلك تلك التي قام المستخدمون بتجميعها)، وربما محتوى من مؤتمرات سابقة أخرى، ومتكاملة، ومُصنفة، ويمكن للمستخدم الوصول إليها، ومتاحة أيضًا للعرض على موقعنا الإلكتروني (Live.jugru.org).

- يا رفاق، شكرًا جزيلاً لكم على إجاباتكم!

إذا كان من بين القراء من حضر مؤتمراتنا الصيفية، يرجى مشاركة انطباعاتك عن اللاعب والبث. ما الذي كان مناسبًا، ما الذي أزعجك، ما الذي تود رؤيته في المستقبل؟

إذا كنت مهتمًا بالمنصة وترغب في رؤيتها "في المعركة"، فإننا نستخدمها مرة أخرى على موقعنا مؤتمرات الخريف والشتاء. هناك مجموعة كاملة منها، لذلك من المؤكد أن هناك المجموعة المناسبة لك.

المصدر: www.habr.com