👃🏻 🏇🏽 ⚫️ كيف ساعدنا المدارس على التحول إلى التعلم عن بعد والتعامل مع الحمل 🚁 👧🏿 👂

مرحبا يا هابر! اسمي أليكسي فاخوف ، أنا المدير الفني لـ Uchi.ru. في منتصف مارس ، عندما بدأت المدارس في التحول إلى التعلم عن بعد ، قدمنا للمعلمين والطلاب العديد من الخدمات للصفوف عبر الإنترنت. وفقًا لحساباتنا ، كان لدينا هامش أمان لتحمل 1.5-2 ضعف الحمل. في منتصف أبريل ، زادت حركة المرور لدينا 8 مرات. كان علي أن أفعل الكثير لأبقى طافيا. ربما يحتاج شخص ما إلى تجربتنا من أجل البقاء على قيد الحياة هذه أو أزمة مستقبلية.

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

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

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

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

الاعتماد على أنفسهم

خلال أزمة ما قبل حركة المرور ، تصبح كفريق واحد. سيعتمد ذلك على موظفيك سواء كنت ستجد حلولًا أو تتعامل مع الأزمة أم لا.

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

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

سحابة موسعة

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

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

أدوات مراقبة مطورة

خلال الأزمة ، لم ينجز التنبيه وظيفته بالفعل. قام جميع أعضاء الفريق بالفعل بمراقبة جميع الأنظمة على مدار الساعة ، وتم تقليل إدارة الحوادث إلى العمل المستمر على جميع الجبهات. لتشخيص المشكلات التي واجهناها بشكل كامل ، كانت لدينا بيانات قليلة جدًا. على سبيل المثال ، لمراقبة الأجهزة الافتراضية ، نستخدم مُصدِّر Node القياسي لـ Prometheus. إنه جيد لرؤية الصورة الكبيرة ، لإلقاء نظرة فاحصة على جهاز افتراضي واحد بدأ في استخدام NetData.

تخزين ذاكرة التخزين المؤقت الأمثل

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

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

وسعت الشبكة

كما تعلمون ، 640 كيلوبايت كافية للجميع. استخدمنا دائمًا شبكة خاصة / 24 شبكة فرعية ، ولكن على خلفية الحجر الصحي كان علينا التوسع بشكل عاجل إلى / 22. الآن تستوعب الشبكة أربعة أضعاف عدد الخوادم ، نأمل أن تكون كافية بالتأكيد.

نفذ PgBouncer بشكل منفصل

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

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

قمنا بنقل الحراس إلى خادم منفصل ، مما ساعدنا على توفير 20-25 ٪ من وحدة المعالجة المركزية على كل خادم قاعدة بيانات.

في مواجهة المفاجآت

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

لتسجيل مركزي نستخدم ELK. يعتمد خط توصيل التسليم الخاص بنا على Apache Kafka و Elastic Filebeat. تحت الحمل المرتفع ، توقف ناقل تسليم السجل عن الإدارة ، وبدأت السجلات في الضياع أو التأخر. لقد قمنا بزيادة سرعة نقل السجلات وفهرسة التخزين من خلال معالجة فهارس Elasticsearch ، وزيادة عدد الأقسام في Kafka و Filebeat ، وضغط مضغوط في جميع المراحل. نظرًا لحقيقة أن خط الأنابيب الخاص بجمع السجلات منفصل عن الإنتاج ، لم يكن للمشكلات المتعلقة بزيادة حركة مرور السجلات أي تأثير على عمل الموقع.

قبلت قواعد اللعبة

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

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

كيف ساعدنا المدارس على التحول إلى التعلم عن بعد والتعامل مع الحمل