مرحبا، اسمي يفغيني. أنا أعمل في البنية التحتية للبحث في Yandex.Market. أريد أن أخبر مجتمع حبر عن المطبخ الداخلي للسوق - ولدي الكثير لأقوله. أولًا، كيف يعمل بحث السوق وعملياته وبنيته. كيف نتعامل مع حالات الطوارئ: ماذا يحدث إذا تعطل أحد الخوادم؟ ماذا لو كان هناك 100 من هذه الخوادم؟
سوف تتعلم أيضًا كيفية تنفيذ وظائف جديدة على مجموعة من الخوادم في وقت واحد. وكيف نختبر الخدمات المعقدة مباشرة في الإنتاج، دون التسبب في أي إزعاج للمستخدمين. بشكل عام، كيفية عمل بحث السوق حتى يتمكن الجميع من قضاء وقت ممتع.
قليلا عنا: ما هي المشكلة التي نحلها
عند إدخال نص، أو البحث عن منتج حسب المعلمات، أو مقارنة الأسعار في متاجر مختلفة، يتم إرسال جميع الطلبات إلى خدمة البحث. البحث هو أكبر خدمة في السوق.
نقوم بمعالجة جميع طلبات البحث: من مواقع market.yandex.ru، وberu.ru، وخدمة Supercheck، وYandex.Advisor، وتطبيقات الهاتف المحمول. نقوم أيضًا بتضمين عروض المنتجات في نتائج البحث على yandex.ru.
من خلال خدمة البحث، لا أعني البحث نفسه فحسب، بل أعني أيضًا قاعدة البيانات التي تحتوي على جميع العروض المتوفرة في السوق. المقياس هو كما يلي: تتم معالجة أكثر من مليار طلب بحث يوميًا. ويجب أن يعمل كل شيء بسرعة، دون انقطاع، ويؤدي دائمًا إلى النتيجة المرجوة.
ما هو: بنية السوق
سأصف بإيجاز البنية الحالية للسوق. ويمكن وصفها بشكل تقريبي من خلال الرسم البياني أدناه:
لنفترض أن متجرًا شريكًا يأتي إلينا. يقول أنني أريد بيع لعبة: هذه القطة الشريرة ذات الصرير. وقطة غاضبة أخرى بدون صرير. وفقط قطة. ثم يحتاج المتجر إلى إعداد العروض التي يبحث عنها السوق. يقوم المتجر بإنشاء ملف XML خاص يحتوي على العروض ويقوم بتوصيل المسار إلى ملف XML هذا من خلال واجهة الشركة التابعة. يقوم المفهرس بعد ذلك بتنزيل ملف XML هذا بشكل دوري، والتحقق من الأخطاء وحفظ جميع المعلومات في قاعدة بيانات ضخمة.
هناك العديد من ملفات XML المحفوظة. يتم إنشاء فهرس البحث من قاعدة البيانات هذه. يتم تخزين الفهرس بتنسيق داخلي. بعد إنشاء الفهرس، تقوم خدمة التخطيط بتحميله إلى خوادم البحث.
ونتيجة لذلك، تظهر قطة غاضبة ذات صرير في قاعدة البيانات، ويظهر فهرس القطة على الخادم.
سأخبرك كيف نبحث عن قطة في الجزء المتعلق بهندسة البحث.
بنية بحث السوق
نحن نعيش في عالم الخدمات الصغيرة: كل طلب وارد يسبب الكثير من الاستعلامات الفرعية، وتشارك العشرات من الخدمات في معالجتها. يظهر الرسم البياني عدد قليل فقط:
نظام مبسط لمعالجة الطلب
كل خدمة لها شيء رائع - موازنها الخاص باسم فريد:
يمنحنا الموازن مرونة أكبر في إدارة الخدمة: يمكنك، على سبيل المثال، إيقاف تشغيل الخوادم، وهو أمر مطلوب غالبًا للتحديثات. يرى الموازن أن الخادم غير متاح ويعيد توجيه الطلبات تلقائيًا إلى خوادم أو مراكز بيانات أخرى. عند إضافة خادم أو إزالته، تتم إعادة توزيع التحميل تلقائيًا بين الخوادم.
لا يعتمد الاسم الفريد للموازن على مركز البيانات. عندما تقوم الخدمة "أ" بتقديم طلب إلى "ب"، يقوم الموازن "ب" افتراضيًا بإعادة توجيه الطلب إلى مركز البيانات الحالي. إذا كانت الخدمة غير متوفرة أو غير موجودة في مركز البيانات الحالي، فسيتم إعادة توجيه الطلب إلى مراكز البيانات الأخرى.
يسمح FQDN واحد لجميع مراكز البيانات للخدمة "أ" بالاستخلاص الكامل من المواقع. سيتم دائمًا معالجة طلبه للخدمة B. الاستثناء هو الحالة عندما تكون الخدمة موجودة في جميع مراكز البيانات.
ولكن ليس كل شيء ورديًا جدًا مع هذا الموازن: لدينا مكون وسيط إضافي. قد يكون الموازن غير مستقر، ويتم حل هذه المشكلة عن طريق الخوادم المتكررة. هناك أيضًا تأخير إضافي بين الخدمتين A وB. ولكن من الناحية العملية، يكون هذا التأخير أقل من 1 مللي ثانية وهذا ليس بالأمر الحاسم بالنسبة لمعظم الخدمات.
التعامل مع ما هو غير متوقع: موازنة خدمة البحث ومرونتها
تخيل أن هناك انهيارًا: تحتاج إلى العثور على قطة ذات صرير، لكن الخادم يتعطل. أو 100 خادم. كيفية الخروج؟ هل سنترك المستخدم حقًا بدون قطة؟
الوضع مخيف، لكننا مستعدون له. سأخبرك بالترتيب.
تقع البنية التحتية للبحث في عدة مراكز بيانات:
عند التصميم، قمنا بتضمين إمكانية إغلاق مركز بيانات واحد. الحياة مليئة بالمفاجآت - على سبيل المثال، يمكن للحفارة قطع كابل تحت الأرض (نعم، لقد حدث ذلك). يجب أن تكون السعة الموجودة في مراكز البيانات المتبقية كافية لتحمل الحمل الأقصى.
دعونا نفكر في مركز بيانات واحد. كل مركز بيانات لديه نفس نظام تشغيل الموازن:
الموازن الواحد عبارة عن ثلاثة خوادم فعلية على الأقل. تم إجراء هذا التكرار من أجل الموثوقية. تعمل الموازنات على HAProx.
لقد اخترنا HAProx نظرًا لأدائه العالي ومتطلباته المنخفضة من الموارد ووظائفه الواسعة. يعمل برنامج البحث الخاص بنا داخل كل خادم.
احتمال فشل خادم واحد منخفض. ولكن إذا كان لديك العديد من الخوادم، فإن احتمالية تعطل خادم واحد على الأقل تزداد.
وهذا ما يحدث في الواقع: تعطل الخوادم. ولذلك، فمن الضروري مراقبة حالة كافة الخوادم باستمرار. إذا توقف الخادم عن الاستجابة، فسيتم قطع اتصاله تلقائيًا بحركة المرور. لهذا الغرض، يحتوي HAProxy على فحص صحي مدمج. ينتقل إلى جميع الخوادم مرة واحدة في الثانية باستخدام طلب HTTP "/ ping".
ميزة أخرى لـ HAProxy: فحص الوكيل يسمح لك بتحميل جميع الخوادم بالتساوي. للقيام بذلك، يتصل HAProxy بجميع الخوادم، ويعيدون وزنهم اعتمادًا على الحمل الحالي من 1 إلى 100. ويتم حساب الوزن بناءً على عدد الطلبات في قائمة الانتظار للمعالجة والحمل على المعالج.
الآن عن العثور على القطة. نتائج البحث في طلبات مثل: /search?text=angry+cat. لكي يكون البحث سريعًا، يجب أن يتناسب فهرس القط بالكامل مع ذاكرة الوصول العشوائي (RAM). حتى القراءة من SSD ليست بالسرعة الكافية.
ذات مرة، كانت قاعدة بيانات العروض صغيرة، وكانت ذاكرة الوصول العشوائي لخادم واحد كافية لها. مع نمو قاعدة العرض، لم يعد كل شيء مناسبًا لذاكرة الوصول العشوائي هذه، وتم تقسيم البيانات إلى قسمين: الجزء 1 والجزء 2.
لكن هذا يحدث دائمًا: أي حل، حتى لو كان جيدًا، يؤدي إلى ظهور مشكلات أخرى.
لا يزال الموازن يذهب إلى أي خادم. ولكن على الجهاز الذي جاء فيه الطلب، لم يكن هناك سوى نصف المؤشر. وكان الباقي على خوادم أخرى. ولذلك، كان على الخادم أن يذهب إلى بعض الأجهزة المجاورة. بعد تلقي البيانات من كلا الخادمين، تم دمج النتائج وإعادة ترتيبها.
نظرا لأن الموازن يوزع الطلبات بالتساوي، فقد انخرطت جميع الخوادم في إعادة الترتيب، وليس فقط إرسال البيانات.
حدثت المشكلة في حالة عدم توفر خادم مجاور. كان الحل هو تحديد عدة خوادم ذات أولويات مختلفة كخادم "مجاور". أولاً، تم إرسال الطلب إلى الخوادم الموجودة في الرف الحالي. إذا لم يكن هناك استجابة، فسيتم إرسال الطلب إلى كافة الخوادم في مركز البيانات هذا. وأخيرًا، ذهب الطلب إلى مراكز البيانات الأخرى.
ومع تزايد عدد المقترحات، تم تقسيم البيانات إلى أربعة أجزاء. ولكن هذا لم يكن الحد الأقصى.
حاليًا، يتم استخدام تكوين مكون من ثمانية أجزاء. بالإضافة إلى ذلك، لتوفير المزيد من الذاكرة، تم تقسيم الفهرس إلى جزء بحث (يُستخدم للبحث) وجزء مقتطف (لا يشارك في البحث).
يحتوي خادم واحد على معلومات لجزء واحد فقط. لذلك، للبحث في الفهرس الكامل، تحتاج إلى البحث في ثمانية خوادم تحتوي على أجزاء مختلفة.
يتم تجميع الخوادم في مجموعات. تحتوي كل مجموعة على ثمانية محركات بحث وخادم مقتطف واحد.
يقوم خادم المقتطف بتشغيل قاعدة بيانات ذات قيمة أساسية تحتوي على بيانات ثابتة. وهي ضرورية لإصدار المستندات، على سبيل المثال، وصف القط مع صرير. يتم نقل البيانات خصيصًا إلى خادم منفصل حتى لا يتم تحميل ذاكرة خوادم البحث.
نظرًا لأن معرفات المستندات تكون فريدة ضمن فهرس واحد فقط، فقد ينشأ موقف حيث لا توجد مستندات في المقتطفات. حسنا، أو أنه لمعرف واحد سيكون هناك محتوى مختلف. لذلك، لكي ينجح البحث ويتم إرجاع النتائج، كانت هناك حاجة إلى الاتساق عبر المجموعة بأكملها. سأخبرك أدناه كيف نراقب الاتساق.
يتم تنظيم البحث نفسه على النحو التالي: يمكن أن يأتي طلب البحث إلى أي من الخوادم الثمانية. لنفترض أنه جاء إلى الخادم 1. يعالج هذا الخادم جميع الوسائط ويفهم ما الذي تبحث عنه وكيفية البحث عنه. اعتمادًا على الطلب الوارد، يمكن للخادم تقديم طلبات إضافية إلى الخدمات الخارجية للحصول على المعلومات الضرورية. يمكن أن يتبع الطلب الواحد ما يصل إلى عشرة طلبات للخدمات الخارجية.
بعد جمع المعلومات اللازمة، يبدأ البحث في قاعدة بيانات العرض. للقيام بذلك، يتم إجراء الاستعلامات الفرعية على كافة الخوادم الثمانية الموجودة في المجموعة.
بمجرد تلقي الردود، يتم دمج النتائج. في النهاية، قد تكون هناك حاجة إلى عدة استعلامات فرعية أخرى لخادم المقتطف لإنشاء النتائج.
تبدو استعلامات البحث داخل المجموعة كما يلي: /shard1?text=angry+cat. بالإضافة إلى ذلك، يتم إجراء استعلامات فرعية للنموذج باستمرار بين جميع الخوادم داخل المجموعة مرة واحدة في الثانية: /حالة.
تحقيق /حالة يكتشف الحالة التي يكون فيها الخادم غير متوفر.
كما أنه يتحكم في أن إصدار محرك البحث وإصدار الفهرس متماثلان على جميع الخوادم، وإلا ستكون هناك بيانات غير متناسقة داخل المجموعة.
على الرغم من حقيقة أن خادم مقتطف واحد يعالج طلبات من ثمانية محركات بحث، إلا أن معالجه يتم تحميله بشكل خفيف للغاية. ولذلك، نقوم الآن بنقل بيانات المقتطف إلى خدمة منفصلة.
لنقل البيانات، قدمنا مفاتيح عالمية للمستندات. من المستحيل الآن حدوث موقف يتم فيه إرجاع محتوى من مستند آخر باستخدام مفتاح واحد.
لكن الانتقال إلى بنية أخرى لم يكتمل بعد. نريد الآن التخلص من خادم المقتطف المخصص. ثم ابتعد عن البنية العنقودية تمامًا. وهذا سيسمح لنا بمواصلة التوسع بسهولة. المكافأة الإضافية هي توفير كبير في الحديد.
والآن إلى القصص المخيفة ذات النهايات السعيدة. دعونا نفكر في عدة حالات لعدم توفر الخادم.
حدث شيء فظيع: خادم واحد غير متوفر
لنفترض أن خادمًا واحدًا غير متاح. ثم يمكن للخوادم المتبقية في المجموعة الاستمرار في الاستجابة، ولكن نتائج البحث لن تكون كاملة.
عبر التحقق من الحالة /حالة تدرك الخوادم المجاورة أن أحدها غير متاح. لذلك، للحفاظ على اكتمال جميع الخوادم في المجموعة لكل طلب / بينغ يبدأون في الرد على الموازن بأنهم غير متاحين أيضًا. اتضح أن جميع الخوادم الموجودة في المجموعة ماتت (وهذا غير صحيح). هذا هو العيب الرئيسي في مخططنا العنقودي - ولهذا السبب نريد الابتعاد عنه.
تتم إعادة إرسال الطلبات التي تفشل مع حدوث خطأ بواسطة الموازن على الخوادم الأخرى.
يتوقف الموازن أيضًا عن إرسال حركة مرور المستخدم إلى الخوادم الميتة، لكنه يستمر في التحقق من حالتها.
عندما يصبح الخادم متاحًا، يبدأ في الاستجابة له / بينغ. بمجرد أن تبدأ الاستجابات العادية لرسائل الاتصال من الخوادم المعطلة في الوصول، يبدأ الموازنون في إرسال حركة مرور المستخدم إلى هناك. تتم استعادة عملية الكتلة، يا هلا.
والأسوأ من ذلك: أن العديد من الخوادم غير متوفرة
تم قطع جزء كبير من الخوادم الموجودة في مركز البيانات. ماذا تفعل وأين تركض؟ يأتي الموازن للإنقاذ مرة أخرى. يقوم كل موازن بتخزين العدد الحالي من الخوادم الحية في الذاكرة باستمرار. فهو يحسب باستمرار الحد الأقصى لمقدار حركة المرور التي يمكن لمركز البيانات الحالي معالجتها.
عندما تتعطل العديد من الخوادم في مركز البيانات، يدرك الموازن أن مركز البيانات هذا لا يمكنه معالجة كل حركة المرور.
ثم يبدأ توزيع حركة المرور الزائدة بشكل عشوائي على مراكز البيانات الأخرى. كل شيء يعمل، الجميع سعداء.
كيف نفعل ذلك: نشر الإصدارات
الآن دعونا نتحدث عن كيفية نشر التغييرات التي تم إجراؤها على الخدمة. لقد سلكنا هنا طريق تبسيط العمليات: يتم طرح إصدار جديد تلقائيًا بالكامل تقريبًا.
عندما يتراكم عدد معين من التغييرات في المشروع، يتم إنشاء إصدار جديد تلقائيًا ويبدأ بنائه.
ثم يتم طرح الخدمة للاختبار، حيث يتم التحقق من استقرار التشغيل.
وفي الوقت نفسه، يتم إطلاق اختبار الأداء التلقائي. يتم التعامل مع هذا من خلال خدمة خاصة. لن أتحدث عنها الآن، فوصفها يستحق مقالًا منفصلاً.
إذا نجح النشر قيد الاختبار، فسيتم تلقائيًا بدء نشر الإصدار القابل للتشغيل. Prestable عبارة عن مجموعة خاصة حيث يتم توجيه حركة مرور المستخدم العادية. إذا قام بإرجاع خطأ، يقوم الموازن بإعادة طلب الإنتاج.
في الوضع القابل للضبط، يتم قياس أوقات الاستجابة ومقارنتها بالإصدار السابق في الإنتاج. إذا كان كل شيء على ما يرام، فسيقوم الشخص بالاتصال: يتحقق من الرسوم البيانية ونتائج اختبار التحميل ثم يبدأ في طرحه للإنتاج.
كل التوفيق يذهب إلى المستخدم: اختبار A/B
ليس من الواضح دائمًا ما إذا كانت التغييرات في الخدمة ستجلب فوائد حقيقية. لقياس مدى فائدة التغييرات، توصل الأشخاص إلى اختبار أ/ب. سأخبرك قليلاً عن كيفية عمله في بحث Yandex.Market.
يبدأ كل شيء بإضافة معلمة CGI جديدة تتيح وظائف جديدة. دع المعلمة لدينا تكون: market_new_functionality=1. ثم في الكود نقوم بتمكين هذه الوظيفة إذا كانت العلامة موجودة:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}يتم طرح وظائف جديدة في الإنتاج.
لأتمتة اختبار A/B، هناك خدمة مخصصة توفر معلومات مفصلة . يتم إنشاء تجربة في الخدمة. يتم تعيين حصة حركة المرور، على سبيل المثال، 15٪. يتم تعيين النسب المئوية ليس للاستعلامات، ولكن للمستخدمين. يشار أيضا إلى مدة التجربة، على سبيل المثال، أسبوع.
يمكن إجراء العديد من التجارب في وقت واحد. في الإعدادات، يمكنك تحديد ما إذا كان التقاطع مع تجارب أخرى ممكنًا.
ونتيجة لذلك، تقوم الخدمة تلقائيًا بإضافة وسيطة market_new_functionality=1 إلى 15% من المستخدمين. كما يقوم أيضًا بحساب المقاييس المحددة تلقائيًا. بعد الانتهاء من التجربة، ينظر المحللون إلى النتائج ويستخلصون النتائج. وبناءً على النتائج، يتم اتخاذ قرار بالبدء في الإنتاج أو التحسين.
يد السوق الماهرة: الاختبار في الإنتاج
غالبًا ما تحتاج إلى اختبار تشغيل وظيفة جديدة في الإنتاج، لكنك غير متأكد من كيفية تصرفها في الظروف "القتالية" تحت الحمل الثقيل.
يوجد حل: يمكن استخدام العلامات في معلمات CGI ليس فقط لاختبار A/B، ولكن أيضًا لاختبار الوظائف الجديدة.
لقد أنشأنا أداة تسمح لك بتغيير التكوين على الفور على آلاف الخوادم دون تعريض الخدمة للمخاطر. يطلق عليه "إيقاف الصنبور". كانت الفكرة الأصلية هي أن تكون قادرًا على تعطيل بعض الوظائف بسرعة دون تخطيط. ثم توسعت الأداة وأصبحت أكثر تعقيدا.
يتم عرض مخطط تدفق الخدمة أدناه:
يتم تعيين قيم العلامة عبر واجهة برمجة التطبيقات. تقوم خدمة الإدارة بتخزين هذه القيم في قاعدة البيانات. تذهب جميع الخوادم إلى قاعدة البيانات مرة كل عشر ثوانٍ، وتضخ قيم العلامة وتطبق هذه القيم على كل طلب.
في صنبور الإيقاف، يمكنك تعيين نوعين من القيم:
1) التعابير الشرطية. تنطبق عندما تكون إحدى القيم صحيحة. على سبيل المثال:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}سيتم تطبيق القيمة "3" عند معالجة الطلب في الموقع DC1. وتكون القيمة "4" عند معالجة الطلب في المجموعة الثانية لموقع beru.ru.
2) القيم غير المشروطة. يتم التقديم بشكل افتراضي في حالة عدم استيفاء أي من الشروط. على سبيل المثال:
القيمة، القيمة!
إذا انتهت القيمة بعلامة تعجب، فإنها تعطى أولوية أعلى.
يقوم محلل معلمة CGI بتوزيع عنوان URL. ثم يطبق القيم من Stop Tap.
يتم تطبيق القيم ذات الأولويات التالية:
- مع زيادة الأولوية من Stop Tap (علامة التعجب).
- القيمة من الطلب.
- القيمة الافتراضية من الصنبور إيقاف.
- القيمة الافتراضية في الكود
هناك العديد من العلامات المشار إليها بالقيم الشرطية - وهي كافية لجميع السيناريوهات المعروفة لدينا:
- مركز البيانات.
- البيئة: الإنتاج، الاختبار، الظل.
- المكان: السوق، بيرو.
- رقم الكتلة.
باستخدام هذه الأداة، يمكنك تمكين وظائف جديدة على مجموعة معينة من الخوادم (على سبيل المثال، في مركز بيانات واحد فقط) واختبار تشغيل هذه الوظيفة دون أي خطر معين على الخدمة بأكملها. حتى لو ارتكبت خطأً فادحًا في مكان ما، وبدأ كل شيء في الانخفاض وتعطل مركز البيانات بالكامل، فسيقوم الموازنون بإعادة توجيه الطلبات إلى مراكز البيانات الأخرى. لن يلاحظ المستخدمون النهائيون أي شيء.
إذا لاحظت مشكلة، يمكنك على الفور إعادة العلامة إلى قيمتها السابقة وسيتم التراجع عن التغييرات.
هذه الخدمة لها أيضًا سلبياتها: فالمطورون يحبونها كثيرًا ويحاولون غالبًا دفع جميع التغييرات إلى Stop Tap. نحن نحاول مكافحة سوء الاستخدام.
يعمل أسلوب Stop Tap بشكل جيد عندما يكون لديك بالفعل كود ثابت جاهز للنشر في الإنتاج. في الوقت نفسه، لا تزال لديك شكوك، وتريد التحقق من الكود في ظروف "القتال".
ومع ذلك، فإن Stop Tap غير مناسب للاختبار أثناء التطوير. هناك مجموعة منفصلة للمطورين تسمى "مجموعة الظل".
الاختبار السري: مجموعة الظل
يتم تكرار الطلبات الواردة من إحدى المجموعات إلى مجموعة الظل. لكن الموازن يتجاهل تمامًا استجابات هذه المجموعة. ويرد الرسم البياني لعملها أدناه.
نحصل على مجموعة اختبار في ظروف "قتالية" حقيقية. حركة مرور المستخدم العادية تذهب إلى هناك. الأجهزة في كلا المجموعتين هي نفسها، لذلك يمكن مقارنة الأداء والأخطاء.
وبما أن الموازن يتجاهل الاستجابات تمامًا، فلن يتمكن المستخدمون النهائيون من رؤية الاستجابات من مجموعة الظل. لذلك، ليس مخيفا أن نخطئ.
النتائج
إذًا، كيف قمنا ببناء بحث السوق؟
ولجعل كل شيء يسير بسلاسة، نقوم بفصل الوظائف إلى خدمات منفصلة. بهذه الطريقة يمكننا فقط قياس تلك المكونات التي نحتاجها وجعل المكونات أكثر بساطة. من السهل تعيين مكون منفصل لفريق آخر ومشاركة مسؤوليات العمل عليه. ويعد التوفير الكبير في الحديد باستخدام هذا النهج ميزة إضافية واضحة.
تساعدنا مجموعة الظل أيضًا: يمكننا تطوير الخدمات واختبارها أثناء العملية وعدم إزعاج المستخدم.
حسنا، الاختبار في الإنتاج، بطبيعة الحال. هل تحتاج إلى تغيير التكوين على آلاف الخوادم؟ من السهل استخدام "إيقاف الصنبور". بهذه الطريقة يمكنك طرح حل معقد جاهز على الفور والعودة إلى إصدار مستقر في حالة ظهور مشكلات.
آمل أن أتمكن من إظهار كيف نجعل السوق سريعًا ومستقرًا من خلال قاعدة العروض المتنامية باستمرار. كيف نحل مشاكل الخادم ونتعامل مع عدد كبير من الطلبات ونحسن مرونة الخدمة ونقوم بذلك دون مقاطعة عمليات العمل.
المصدر: www.habr.com