ڪيئن Yandex.Market ڳولا ڪم ڪري ٿي ۽ ڇا ٿيندو جيڪڏهن سرور مان هڪ ناڪام ٿئي

هيلو، منهنجو نالو Evgeniy آهي. مان Yandex.Market سرچ انفراسٽرڪچر ۾ ڪم ڪريان ٿو. مان حبر ڪميونٽي کي مارڪيٽ جي اندروني باورچی خانه بابت ٻڌائڻ چاهيان ٿو - ۽ مون کي ٻڌائڻ لاءِ گهڻو ڪجهه آهي. سڀ کان پهريان، مارڪيٽ ڳولا ڪيئن ڪم ڪري ٿي، پروسيس ۽ فن تعمير. اسان هنگامي حالتن سان ڪيئن ڊيل ڪريون ٿا: ڇا ٿيندو جيڪڏهن هڪ سرور هيٺ ٿي وڃي؟ ڇا جيڪڏهن اهڙا 100 سرور آهن؟

توهان اهو پڻ سکندا سين ته اسان هڪ ئي وقت ۾ سرور جي هڪ گروپ تي نئين ڪارڪردگي ڪيئن لاڳو ڪندا آهيون. ۽ ڪيئن اسان پيچيده خدمتن کي سڌو سنئون پيداوار ۾ جانچون ٿا، صارفين کي ڪنهن به تڪليف جي بغير. عام طور تي، مارڪيٽ جي ڳولا ڪيئن ڪم ڪري ٿي ته جيئن هر ڪنهن وٽ سٺو وقت هجي.

اسان جي باري ۾ ٿورو: اسان کي ڪهڙو مسئلو حل

جڏهن توهان ٽيڪسٽ داخل ڪريو ٿا، پراڊڪٽ جي ڳولا ڪريو پيٽرول ذريعي، يا مختلف اسٽورن ۾ قيمتن جو مقابلو ڪريو، سڀئي درخواستون سرچ سروس ڏانهن موڪلي وينديون آهن. ڳولا مارڪيٽ ۾ سڀ کان وڏي خدمت آهي.

اسان سڀني ڳولا جي درخواستن تي عمل ڪريون ٿا: سائيٽن مان market.yandex.ru, beru.ru, Supercheck سروس, Yandex.Advisor, موبائل ايپليڪيشنون. اسان yandex.ru تي ڳولا جي نتيجن ۾ پراڊڪٽ جون آڇون پڻ شامل ڪيون ٿا.

سرچ سروس مان منهنجو مطلب آهي نه رڳو ڳولا خود، پر مارڪيٽ تي سڀني آڇن سان گڏ هڪ ڊيٽابيس پڻ. پيماني تي هي آهي: هڪ ارب کان وڌيڪ ڳولا جي درخواستن تي عمل ڪيو ويندو آهي في ڏينهن. ۽ هر شي کي جلدي ڪم ڪرڻ گهرجي، بغير ڪنهن رڪاوٽ جي ۽ هميشه گهربل نتيجو پيدا ڪرڻ گهرجي.

ڇا آهي: مارڪيٽ فن تعمير

مان مختصر طور تي مارڪيٽ جي موجوده فن تعمير کي بيان ڪندس. اهو تقريبا هيٺ ڏنل ڊراگرام ذريعي بيان ڪري سگهجي ٿو:

اچو ته هڪ پارٽنر اسٽور اسان وٽ اچي. هو چوي ٿو ته مان هڪ رانديڪو وڪڻڻ چاهيان ٿو: هي بڇڙي ٻلي هڪ چوڪيدار سان. ۽ هڪ ٻي ناراض ٻلي بغير ڪنهن چوڪيدار جي. ۽ صرف هڪ ٻلي. پوءِ اسٽور کي آڇون تيار ڪرڻ گهرجن جن لاءِ مارڪيٽ ڳولهي ٿي. اسٽور هڪ خاص ايڪس ايم ايل ٺاهي ٿو پيشڪش سان ۽ رابطو ڪري ٿو هن ايڪس ايم ايل ڏانهن رستو الحاق انٽرفيس ذريعي. انڊيڪسر وري وقتي طور تي هن xml کي ڊائون لوڊ ڪري ٿو، غلطين جي جانچ ڪري ٿو ۽ سڀني معلومات کي وڏي ڊيٽابيس ۾ محفوظ ڪري ٿو.

اهڙا ڪيترائي محفوظ ٿيل xmls آهن. هڪ سرچ انڊيڪس هن ڊيٽابيس مان ٺهيل آهي. انڊيڪس اندروني شڪل ۾ محفوظ ٿيل آهي. انڊيڪس ٺاھڻ کان پوءِ، لي آئوٽ سروس ان کي سرورز تي اپلوڊ ڪري ٿي.

نتيجي طور، ھڪڙي ناراض ٻلي ھڪڙي اسڪيڪر سان گڏ ڊيٽابيس ۾ ظاهر ٿئي ٿي، ۽ ٻلي جي انڊيڪس سرور تي ظاهر ٿئي ٿي.

مان توهان کي ٻڌايان ٿو ته اسان ڳولا جي فن تعمير بابت حصو ۾ ٻلي کي ڪيئن ڳوليندا آهيون.

مارڪيٽ ڳولا فن تعمير

اسان مائڪرو سروسز جي دنيا ۾ رهون ٿا: هر ايندڙ درخواست market.yandex.ru ڪيترن ئي ذيلي سوالن جو سبب بڻجن ٿا، ۽ درجنوں خدمتون انهن جي پروسيسنگ ۾ شامل آهن. خاڪو صرف چند ڏيکاري ٿو:

آسان درخواست پروسيسنگ اسڪيم

هر خدمت ۾ هڪ عجيب شيء آهي - ان جو پنهنجو بيلنس هڪ منفرد نالو سان:

بيلنس اسان کي خدمت کي منظم ڪرڻ ۾ وڌيڪ لچڪدار ڏئي ٿو: توهان ڪري سگهو ٿا، مثال طور، سرور بند ڪريو، جيڪو اڪثر ڪري تازه ڪاري لاء گهربل آهي. بيلنس ڏسي ٿو ته سرور دستياب ناهي ۽ خودڪار طريقي سان ٻين سرورن يا ڊيٽا سينٽرن ڏانهن درخواستن کي ريڊريٽ ڪري ٿو. جڏهن سرور کي شامل ڪرڻ يا ختم ڪرڻ، لوڊ خودڪار طور تي سرور جي وچ ۾ ورهايو ويندو آهي.

بيلنس جو منفرد نالو ڊيٽا سينٽر تي منحصر ناهي. جڏهن خدمت A بي کي درخواست ڪري ٿي، پوءِ ڊفالٽ بيلنسر بي طرفان موجوده ڊيٽا سينٽر ڏانهن درخواست کي ريڊريٽ ڪري ٿو. جيڪڏهن خدمت دستياب ناهي يا موجوده ڊيٽا سينٽر ۾ موجود ناهي، پوء درخواست کي ٻين ڊيٽا سينٽرن ڏانهن منتقل ڪيو ويو آهي.

سڀني ڊيٽا سينٽرن لاءِ هڪ واحد FQDN سروس A کي جڳهن کان مڪمل طور تي خلاصو ڪرڻ جي اجازت ڏئي ٿو. خدمت B لاء هن جي درخواست هميشه تي عمل ڪيو ويندو. استثنا اهو معاملو آهي جڏهن خدمت سڀني ڊيٽا سينٽرن ۾ واقع آهي.

پر هن بيلنس سان هر شيء ايترو گلابي ناهي: اسان وٽ هڪ اضافي وچولي جزو آهي. بيلنس غير مستحڪم ٿي سگهي ٿو، ۽ اهو مسئلو بيڪار سرور طرفان حل ڪيو ويو آهي. سروسز A ۽ B جي وچ ۾ اضافي دير پڻ آهي. پر عملي طور تي اهو 1 ms کان گهٽ آهي ۽ اڪثر خدمتن لاءِ اهو اهم ناهي.

غير متوقع سان ڊيل ڪرڻ: سرچ سروس بيلنسنگ ۽ لچڪ

تصور ڪريو ته ھڪڙو تباھ آھي: توھان کي ھڪڙي ٻلي ڳولڻ جي ضرورت آھي ھڪڙي اسڪيڪر سان، پر سرور حادثو. يا 100 سرور. ڪيئن ٻاهر نڪرڻ لاء؟ ڇا اسان واقعي بغير صارف کي ٻلي ڇڏڻ وارا آهيون؟

صورتحال خوفناڪ آهي، پر اسان ان لاءِ تيار آهيون. مان توهان کي ترتيب سان ٻڌايان ٿو.

سرچ انفراسٽرڪچر ڪيترن ئي ڊيٽا سينٽرن ۾ واقع آهي:

جڏهن ڊزائين ڪرڻ، اسان هڪ ڊيٽا سينٽر کي بند ڪرڻ جو امڪان شامل ڪريون ٿا. زندگي حيرتن سان ڀريل آهي - مثال طور، هڪ کوٽائي ڪندڙ هڪ زير زمين ڪيبل ڪٽي سگهي ٿو (ها، اهو ٿيو). باقي ڊيٽا سينٽرن ۾ گنجائش ڪافي هجڻ گهرجي ته چوٽي جي لوڊ کي منهن ڏيڻ لاءِ.

اچو ته ھڪڙي ڊيٽا سينٽر تي غور ڪريو. هر ڊيٽا سينٽر ۾ ساڳيو بيلنسر آپريشن اسڪيم آهي:

ھڪڙو بيلنس گھٽ ۾ گھٽ ٽي جسماني سرور آھي. هي redundancy reliability لاء ٺهيل آهي. بيلنسرز HAProx تي هلن ٿا.

اسان چونڊيو HAProx ان جي اعلي ڪارڪردگي، گهٽ وسيلن جي گهرج ۽ وسيع ڪارڪردگي جي ڪري. اسان جو سرچ سافٽ ويئر هر سرور اندر هلندو آهي.

ھڪڙي سرور جي ناڪامي جو امڪان گھٽ آھي. پر جيڪڏهن توهان وٽ ڪيترائي سرور آهن، گهٽ ۾ گهٽ هڪ ٿي وڃڻ جو امڪان وڌي ٿو.

اھو اھو آھي جيڪو حقيقت ۾ ٿئي ٿو: سرور حادثو. تنهن ڪري، اهو ضروري آهي ته مسلسل سڀني سرورن جي صورتحال جي نگراني ڪرڻ. جيڪڏهن سرور جواب ڏيڻ بند ڪري ٿو، اهو خودڪار طور تي ٽرئفڪ کان ڌار ٿي ويندو آهي. هن مقصد لاءِ، HAProxy وٽ هڪ ٺهيل صحت جي چڪاس آهي. اهو هڪ سيڪنڊ ۾ هڪ ڀيرو سڀني سرورن ڏانهن وڃي ٿو HTTP درخواست "/ping" سان.

HAProxy جي هڪ ٻي خاصيت: ايجنٽ-چڪ توهان کي سڀني سرورن کي هڪجهڙائي سان لوڊ ڪرڻ جي اجازت ڏئي ٿي. ائين ڪرڻ لاءِ، HAProxy سڀني سرورن سان ڳنڍي ٿو، ۽ اھي پنھنجو وزن واپس ڪن ٿا، موجوده لوڊ جي لحاظ کان 1 کان 100 تائين. وزن پروسيسنگ لاءِ قطار ۾ درخواستن جي تعداد ۽ پروسيسر تي لوڊ جي بنياد تي ڳڻيو ويندو آھي.

هاڻي ٻلي ڳولڻ بابت. درخواستن ۾ ڳولا جا نتيجا جهڙوڪ: /تلاش؟text=angry+cat. ڳولها تيز ٿيڻ لاءِ، پوري ٻلي انڊيڪس کي RAM ۾ فٽ ٿيڻ گھرجي. جيتوڻيڪ SSD کان پڙهڻ ڪافي تيز نه آهي.

هڪ دفعي، پيش ڪيل ڊيٽابيس ننڍڙو هو، ۽ هڪ سرور جي رام ان لاء ڪافي هئي. جيئن ته پيشڪش جو بنياد وڌو ويو، هر شيء هاڻي هن رام ۾ مناسب ناهي، ۽ ڊيٽا کي ٻن حصن ۾ ورهايو ويو: شارڊ 1 ۽ شارڊ 2.

پر اهو هميشه ٿئي ٿو: ڪو به حل، جيتوڻيڪ هڪ سٺو، ٻين مسئلن کي جنم ڏئي ٿو.

بيلنس اڃا تائين ڪنهن به سرور ڏانهن ويو. پر مشين تي جتي درخواست آئي، اتي صرف انڊيڪس جو اڌ هو. باقي ٻين سرورن تي هو. تنهن ڪري، سرور کي ڪنهن پاڙيسري مشين ڏانهن وڃڻو پيو. ٻنهي سرورن کان ڊيٽا حاصل ڪرڻ کان پوء، نتيجن کي گڏ ڪيو ويو ۽ ٻيهر ترتيب ڏنو ويو.

جيئن ته بيلنس درخواستن کي هڪجهڙائي سان ورهائي ٿو، سڀئي سرور ٻيهر ريٽنگ ۾ مصروف هئا، ۽ نه صرف ڊيٽا موڪلڻ.

مسئلو پيدا ٿيو جيڪڏهن هڪ پاڙيسري سرور موجود نه هو. حل اهو هو ته ڪيترن ئي سرورن کي مختلف ترجيحن سان "پاڙيسري" سرور جي طور تي بيان ڪيو وڃي. پهرين، درخواست موڪلي وئي سرورز کي موجوده ريڪ ۾. جيڪڏهن ڪو جواب نه هو، ته درخواست موڪلي وئي هئي سڀني سرورن ڏانهن هن ڊيٽا سينٽر ۾. ۽ آخر ۾، درخواست ٻين ڊيٽا مرڪز ڏانهن ويو.
جيئن تجويزن جو تعداد وڌندو ويو، ڊيٽا کي چئن حصن ۾ ورهايو ويو. پر اها حد نه هئي.

في الحال، اٺ شارڊ جي ترتيب استعمال ڪئي وئي آهي. ان کان علاوه، اڃا به وڌيڪ ياداشت کي بچائڻ لاء، انڊيڪس کي ورهايو ويو ڳولا واري حصي ۾ (جيڪو ڳولها لاء استعمال ڪيو ويندو آهي) ۽ هڪ ٽڪرو حصو (جيڪو ڳولا ۾ شامل ناهي).

ھڪڙو سرور صرف ھڪڙي شارڊ جي معلومات تي مشتمل آھي. تنهن ڪري، مڪمل انڊيڪس ڳولڻ لاء، توهان کي اٺ سرورن تي ڳولڻ جي ضرورت آهي جنهن ۾ مختلف شارڊ شامل آهن.

سرورز گروپن ۾ ورهايل آھن. هر ڪلستر ۾ اٺ سرچ انجڻ ۽ هڪ سنيپٽ سرور شامل آهي.

snippet سرور جامد ڊيٽا سان گڏ هڪ اهم-قدر ڊيٽابيس هلائي ٿو. انهن کي دستاويز جاري ڪرڻ جي ضرورت آهي، مثال طور، هڪ ٻلي جي وضاحت سان اسڪوڪر سان. ڊيٽا خاص طور تي هڪ الڳ سرور ڏانهن منتقل ڪيو ويو آهي ته جيئن سرچ سرورز جي ياداشت کي لوڊ نه ڪيو وڃي.

جيئن ته دستاويز جي سڃاڻپ صرف هڪ انڊيڪس ۾ منفرد آهن، هڪ صورتحال پيدا ٿي سگهي ٿي جتي دستاويزن ۾ ڪو به دستاويز نه هجي. خير، يا اهو هڪ ID لاءِ مختلف مواد هوندو. تنهن ڪري، ڳولا جي ڪم ڪرڻ ۽ نتيجن کي واپس ڪرڻ لاء، پوري ڪلستر ۾ تسلسل جي ضرورت هئي. مان توهان کي هيٺ ٻڌايان ٿو ته اسان تسلسل جي نگراني ڪيئن ڪندا آهيون.

ڳولها پاڻ کي هن ريت ترتيب ڏني وئي آهي: ڳولا جي درخواست ڪنهن به اٺن سرورن تي اچي سگهي ٿي. اچو ته چئو ته هو سرور 1 تي آيو. هي سرور سڀني دليلن تي عمل ڪري ٿو ۽ سمجهي ٿو ته ڇا ۽ ڪيئن ڳولڻو آهي. ايندڙ درخواست تي مدار رکندي، سرور گهربل معلومات لاءِ ٻاهرين خدمتن ڏانهن اضافي درخواستون ڪري سگهي ٿو. ھڪڙي درخواست کان پوءِ ٿي سگھي ٿو ڏھ درخواستن کان ٻاھرين خدمتن ڏانھن.

ضروري معلومات گڏ ڪرڻ کان پوء، هڪ ڳولا شروع ٿئي ٿي آڇ ڊيٽابيس ۾. هن کي ڪرڻ لاء، ڪلستر ۾ سڀني اٺن سرورن تي ذيلي سوال ڪيا ويا آهن.

هڪ دفعو جواب مليا آهن، نتيجا گڏيل آهن. آخر ۾، نتيجا پيدا ڪرڻ لاءِ سنيپٽ سرور تي ڪيترائي وڌيڪ ذيلي سوالن جي ضرورت پوندي.

ڳولا جا سوال ڪلستر ۾ نظر اچن ٿا: /shard1؟text=angry+cat. اضافي طور تي، فارم جي ذيلي سوالن کي مسلسل هڪ سيڪنڊ ۾ هڪ ڀيرو ڪلستر جي اندر سڀني سرورن جي وچ ۾ ٺاهيو ويندو آهي: / اسٽيٽس.

عرض ڪيو / اسٽيٽس اهڙي صورتحال کي ڳولي ٿو جتي سرور موجود ناهي.

اهو پڻ ڪنٽرول ڪري ٿو ته سرچ انجڻ جو نسخو ۽ انڊيڪس ورزن سڀني سرورن تي ساڳيو آهي، ٻي صورت ۾ ڪلستر جي اندر غير مطابقت واري ڊيٽا هوندي.

ان حقيقت جي باوجود ته هڪ سنيپٽ سرور اٺ سرچ انجڻن کان درخواستن تي عمل ڪري ٿو، ان جو پروسيسر تمام تيزيءَ سان لوڊ ٿيل آهي. تنهن ڪري، اسان هاڻي منتقل ڪري رهيا آهيون snippet ڊيٽا هڪ الڳ خدمت ڏانهن.

ڊيٽا کي منتقل ڪرڻ لاء، اسان متعارف ڪرايون يونيورسل ڪيز دستاويزن لاءِ. ھاڻي اھو ناممڪن آھي ھڪڙي صورتحال لاءِ جتي ڪنھن ٻئي دستاويز مان مواد ھڪڙي چيڪ کي استعمال ڪندي واپس ڪيو وڃي.

پر ٻئي فن تعمير جي منتقلي اڃا مڪمل نه آهي. هاڻي اسان چاهيون ٿا ته وقف ٿيل سنيپٽ سرور مان نجات حاصل ڪريو. ۽ پوءِ ڪلستر جي جوڙجڪ کان مڪمل طور تي ھليو. هي اسان کي آساني سان پيماني تي جاري رکڻ جي اجازت ڏيندو. هڪ اضافي بونس اهم لوهه جي بچت آهي.

۽ هاڻي خوفناڪ ڪهاڻيون خوشيءَ سان ختم ڪرڻ لاءِ. اچو ته سرور جي غير موجودگي جي ڪيترن ئي ڪيسن تي غور ڪريو.

ڪجهه خوفناڪ ٿيو: هڪ سرور دستياب ناهي

اچو ته هڪ سرور دستياب ناهي. پوء ڪلستر ۾ باقي سرورز جواب ڏيڻ جاري رکي سگھن ٿا، پر ڳولا جا نتيجا نامڪمل هوندا.

اسٽيٽس چيڪ ذريعي / اسٽيٽس پاڙيسري سرور سمجھن ٿا ته ھڪڙو دستياب ناهي. تنهن ڪري، مڪمل برقرار رکڻ لاء، ڪلستر ۾ سڀ سرورز في درخواست / پنگ اهي بيلنس کي جواب ڏيڻ شروع ڪن ٿا ته اهي پڻ دستياب نه آهن. اهو ظاهر ٿيو ته ڪلستر ۾ سڀ سرور مري ويا (جيڪو سچ ناهي). هي اسان جي ڪلسٽر اسڪيم جي بنيادي خرابي آهي - انهي ڪري اسان ان کان پري ٿيڻ چاهيون ٿا.

درخواستون جيڪي غلطي سان ناڪام ٿين ٿيون ٻين سرورن تي بيلنس طرفان موڪليا ويا آهن.
بيلنس پڻ بند ڪري ٿو صارف ٽرئفڪ کي مئل سرور ڏانهن موڪلڻ، پر انهن جي حيثيت کي جانچڻ جاري آهي.

جڏهن سرور دستياب ٿئي ٿو، اهو جواب ڏيڻ شروع ٿئي ٿو / پنگ. جيترو جلد ئي مئل سرورز کان پنگ جا عام جواب اچڻ شروع ٿين ٿا، بيلنس وارا صارف ٽرئفڪ موڪلڻ شروع ڪن ٿا. ڪلستر آپريشن بحال ٿيو، جلدي.

اڃا به بدتر: ڪيترائي سرور موجود نه آهن

ڊيٽا سينٽر ۾ سرورز جو هڪ اهم حصو ڪٽيو ويو آهي. ڇا ڪجي، ڪيڏانهن هلڻو آهي؟ بيلنس ٻيهر بچاء لاء اچي ٿو. هر بيلنس مسلسل ميموري ۾ محفوظ ڪندو آهي موجوده نمبر لائيو سرورز. اهو مسلسل حساب ڪري ٿو ٽرئفڪ جي وڌ ۾ وڌ مقدار جيڪا موجوده ڊيٽا سينٽر پروسيس ڪري سگهي ٿي.

جڏهن ڊيٽا سينٽر ۾ ڪيترائي سرور هيٺ ٿي ويندا آهن، بيلنسر اهو محسوس ڪري ٿو ته هي ڊيٽا سينٽر سڀني ٽرئفڪ تي عمل نٿو ڪري سگهي.

پوءِ اضافي ٽرئفڪ بي ترتيب طور تي ٻين ڊيٽا سينٽرن ڏانهن ورهائڻ شروع ٿئي ٿي. هرڪو ڪم ڪري ٿو، هرڪو خوش آهي.

اسان اهو ڪيئن ڪريون ٿا: پبلشنگ رليز

هاڻي اچو ته ان بابت ڳالهايون ته اسان خدمت ۾ ڪيل تبديلين کي ڪيئن شايع ڪريون ٿا. هتي اسان عملن کي آسان ڪرڻ جو رستو ورتو آهي: نئين رليز کي رول ڪرڻ لڳ ڀڳ مڪمل طور تي خودڪار آهي.
جڏهن پروجيڪٽ ۾ تبديلين جو هڪ خاص تعداد گڏ ڪيو ويندو آهي، هڪ نئين رليز خودڪار طريقي سان ٺاهي ويندي آهي ۽ ان جي تعمير شروع ٿيندي.

ان کان پوء خدمت کي جانچ ڪرڻ لاء تيار ڪيو ويو آهي، جتي آپريشن جي استحڪام جي جانچ ڪئي وئي آهي.

ساڳئي وقت، خودڪار ڪارڪردگي جاچ شروع ڪئي وئي آهي. اهو هڪ خاص سروس طرفان سنڀاليو ويندو آهي. مان هاڻي ان بابت نه ڳالهائيندس - ان جي وضاحت هڪ الڳ مضمون جي لائق آهي.

جيڪڏهن آزمائش ۾ اشاعت ڪامياب ٿي وڃي ٿي، پرسٽبل ۾ رليز جي اشاعت خودڪار طور تي شروع ٿي ويندي آهي. Prestable ھڪڙو خاص ڪلستر آھي جتي عام صارف ٽرئفڪ کي ھدايت ڪئي وئي آھي. جيڪڏهن اهو هڪ غلطي موٽائي ٿو، بيلنس ٻيهر پيداوار جي درخواست ڪري ٿو.

Prestable ۾، جوابي وقت ماپ ڪيا ويا آهن ۽ پيداوار ۾ پوئين رليز جي مقابلي ۾. جيڪڏهن سڀ ڪجهه ٺيڪ آهي، پوء هڪ شخص ڳنڍيندو آهي: گراف ۽ لوڊ جاچ جا نتيجا چيڪ ڪري ٿو ۽ پوء پيداوار ڏانهن وڌڻ شروع ٿئي ٿو.

تمام بهترين صارف ڏانهن وڃي ٿو: A/B جاچ

اهو هميشه واضح ناهي ته ڇا خدمت ۾ تبديليون حقيقي فائدا آڻيندو. تبديلين جي افاديت کي ماپڻ لاءِ، ماڻهو آيا A/B جاچ. مان توهان کي ٿورڙو ٻڌايان ٿو ته اهو ڪيئن ڪم ڪري ٿو Yandex.Market ڳولا ۾.

اهو سڀ هڪ نئين CGI پيٽرولر کي شامل ڪرڻ سان شروع ٿئي ٿو جيڪو نئين ڪارڪردگي کي چالو ڪري ٿو. اچو ته اسان جو پيٽرول هجي: مارڪيٽ_نئين_فعاليت = 1. پوء ڪوڊ ۾ اسان هن ڪارڪردگي کي فعال ڪريون ٿا جيڪڏهن پرچم موجود آهي:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

نئين ڪارڪردگي کي پيداوار ڏانهن وڌايو پيو وڃي.

A/B ٽيسٽ کي خودڪار ڪرڻ لاءِ، اتي هڪ وقف خدمت آهي جنهن جا تفصيل هتي بيان ڪيو ويو آهي. خدمت ۾ ھڪڙو تجربو ٺاھيو ويو آھي. ٽرئفڪ جو حصو مقرر ڪيو ويو آهي، مثال طور، 15٪. سيڪڙو مقرر ڪيا ويا آھن سوالن لاءِ نه، پر صارفين لاءِ. تجربن جي مدت پڻ اشارو ڪيو ويو آهي، مثال طور، هڪ هفتي.

ڪيترائي تجربا هڪ ئي وقت هلائي سگھجن ٿا. سيٽنگون ۾ توهان وضاحت ڪري سگھو ٿا ته ڇا ٻين تجربن سان ٽڪراء ممڪن آهي.

نتيجي طور، خدمت خودڪار طور تي هڪ دليل شامل ڪري ٿو مارڪيٽ_نئين_فعاليت = 1 صارفين جي 15٪ تائين. اهو پڻ خودڪار طريقي سان چونڊيل ميٽرڪ کي ڳڻپيندو آهي. تجربو مڪمل ٿيڻ کان پوء، تجزيه نگار نتيجن کي ڏسندا آهن ۽ نتيجو ڪڍندا آهن. نتيجن جي بنياد تي، هڪ فيصلو ڪيو ويو آهي رول آئوٽ ڪرڻ لاءِ پيداوار يا ريفائنمينٽ.

مارڪيٽ جي قابل هٿ: پيداوار ۾ جاچ

اهو اڪثر ٿئي ٿو ته توهان کي پيداوار ۾ نئين ڪارڪردگي جي آپريشن کي جانچڻ جي ضرورت آهي، پر توهان کي پڪ ناهي ته اهو ڪيئن ٿيندو "جنگ" جي حالتن ۾ ڳري لوڊ هيٺ.

اتي ھڪڙو حل آھي: CGI پيٽرولر ۾ جھنڊو استعمال ڪري سگھجن ٿا نه رڳو A/B جاچ لاءِ، پر نئين ڪارڪردگي کي جانچڻ لاءِ.

اسان ھڪڙو اوزار ٺاھيو آھي جيڪو توھان کي اجازت ڏئي ٿو فوري طور تي ھزارين سرورن تي ٺاھ جوڙ کي تبديل ڪرڻ کان سواءِ خدمت کي خطرن ۾. ان کي اسٽاپ ٽيپ سڏيو ويندو آهي. اصل خيال اهو هو ته بغير ڪنهن ترتيب جي ڪجهه ڪارڪردگي کي جلدي غير فعال ڪرڻ جي قابل هوندو. پوء اوزار وڌايو ۽ وڌيڪ پيچيده ٿي ويو.

سروس فلو ڊراگرام هيٺ پيش ڪيو ويو آهي:

پرچم قدر مقرر ڪيا ويا آهن API ذريعي. مئنيجمينٽ سروس انهن قدرن کي ڊيٽابيس ۾ محفوظ ڪري ٿو. سڀئي سرور هر ڏهن سيڪنڊن ۾ هڪ ڀيرو ڊيٽابيس ڏانهن ويندا آهن، پرچم جي قيمتن کي پمپ ڪريو ۽ انهن قيمتن کي هر درخواست تي لاڳو ڪريو.

اسٽاپ ٽيپ ۾ توھان ٻن قسمن جا قدر مقرر ڪري سگھو ٿا:

1) مشروط اظهار. لاڳو ڪريو جڏھن ھڪڙو قدر صحيح آھي. مثال طور:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

قيمت "3" لاڳو ٿيندي جڏهن درخواست تي عمل ڪيو ويندو هنڌ DC1 ۾. ۽ قيمت آهي "4" جڏهن درخواست تي عمل ڪيو ويندو آهي ٻئي ڪلستر تي beru.ru سائيٽ لاءِ.

2) غير مشروط قدر. ڊفالٽ طور لاڳو ڪريو جيڪڏهن شرطن مان ڪو به پورو نه ٿيو. مثال طور:

قدر، قدر!

جيڪڏهن ڪو قدر ختم ٿئي ٿو عجب واري نقطي سان، ان کي اعليٰ ترجيح ڏني ويندي آهي.

CGI پيٽرولر پارسر URL کي پارس ڪري ٿو. پوءِ اسٽاپ ٽيپ مان قدر لاڳو ڪريو.

قيمتون هيٺين ترجيحن سان لاڳو ٿين ٿيون:

1. اسٽاپ ٽيپ (عجيب جي نشان) کان وڌندڙ ترجيح سان.
2. درخواست مان قيمت.
3. اسٽاپ ٽيپ کان ڊفالٽ قدر.
4. ڪوڊ ۾ ڊفالٽ قدر.

اهڙا ڪيترائي جھنڊا آھن جيڪي مشروط قدرن ۾ ظاھر ڪيا ويا آھن - اھي ڪافي آھن انھن سڀني منظرنامي لاءِ جيڪي اسان کي سڃاتل آھن:

• ڊيٽا سينٽر.
• ماحول: پيداوار، جاچ، ڇانو.
• جڳھ: بازار، بيرو.
• ڪلستر نمبر.

هن اوزار سان، توهان سرور جي هڪ خاص گروپ تي نئين ڪارڪردگي کي چالو ڪري سگهو ٿا (مثال طور، صرف هڪ ڊيٽا سينٽر ۾) ۽ پوري سروس کي ڪنهن خاص خطري کان سواء هن ڪارڪردگي جي آپريشن کي جانچيو. جيتوڻيڪ جيڪڏهن توهان ڪٿي هڪ سنگين غلطي ڪئي آهي، هر شي گر ٿيڻ شروع ٿي وئي ۽ سڄو ڊيٽا سينٽر هيٺ ٿي ويو، بيلنس ٻين ڊيٽا سينٽرن ڏانهن درخواستن کي ريڊريٽ ڪندو. آخر صارفين ڪجھ به نوٽيس نه ڪندا.

جيڪڏهن توهان هڪ مسئلو محسوس ڪيو، توهان فوري طور تي پرچم کي ان جي پوئين قيمت ڏانهن واپس ڪري سگهو ٿا ۽ تبديليون واپس ٿي وينديون.

هن خدمت ۾ پڻ ان جا نقصان آهن: ڊولپرز ان کي تمام گهڻو پسند ڪن ٿا ۽ اڪثر ڪري ڪوشش ڪندا آهن سڀني تبديلين کي اسٽاپ ٽيپ ۾. اسان غلط استعمال کي منهن ڏيڻ جي ڪوشش ڪري رهيا آهيون.

اسٽاپ ٽيپ جو طريقو سٺو ڪم ڪري ٿو جڏهن توهان وٽ اڳ ۾ ئي مستحڪم ڪوڊ تيار آهي پيداوار لاءِ تيار ڪيو وڃي. ساڳئي وقت، توهان اڃا تائين شڪ آهي، ۽ توهان "جنگ" جي حالتن ۾ ڪوڊ چيڪ ڪرڻ چاهيو ٿا.

بهرحال، اسٽاپ ٽيپ ترقي جي دوران جاچ لاء مناسب ناهي. ڊولپرز لاءِ هڪ الڳ ڪلستر آهي جنهن کي ”شيڊو ڪلستر“ چيو ويندو آهي.

ڳجهي جاچ: شيڊ ڪلستر

ھڪڙي ڪلستر مان درخواستون شيڊ ڪلستر ڏانھن نقل ڪيون ويون آھن. پر بيلنس مڪمل طور تي هن ڪلستر جي جوابن کي نظر انداز ڪري ٿو. ان جي آپريشن جو خاڪو هيٺ پيش ڪيو ويو آهي.

اسان هڪ ٽيسٽ ڪلسٽر حاصل ڪندا آهيون جيڪو حقيقي "جنگي" حالتن ۾ آهي. عام صارف ٽرئفڪ اتي وڃي ٿو. هارڊويئر ٻنهي ڪلسترن ۾ ساڳيو آهي، تنهنڪري ڪارڪردگي ۽ غلطين جو مقابلو ڪري سگهجي ٿو.

۽ جيئن ته بيلنس مڪمل طور تي جوابن کي نظر انداز ڪري ٿو، آخر صارفين کي پاڇو ڪلستر کان جواب نه ڏسندا. تنهن ڪري، اها غلطي ڪرڻ کان ڊپ نه آهي.

پهچڻ

سو، اسان مارڪيٽ جي ڳولا کي ڪيئن ٺاهيو؟

هر شي کي آسانيءَ سان هلڻ لاءِ، اسان ڪارڪردگي کي الڳ الڳ خدمتن ۾ الڳ ڪريون ٿا. هن طريقي سان اسان صرف انهن حصن کي ماپ ڪري سگهون ٿا جن جي اسان کي ضرورت آهي ۽ اجزاء کي آسان بڻائي سگهون ٿا. اهو آسان آهي هڪ الڳ جزو کي ٻي ٽيم کي تفويض ڪرڻ ۽ ان تي ڪم ڪرڻ لاءِ ذميواريون حصيداري ڪرڻ. ۽ هن طريقي سان لوهه ۾ اهم بچت هڪ واضح پلس آهي.

پاڇو ڪلستر پڻ اسان جي مدد ڪري ٿو: اسان خدمتون ٺاهي سگهون ٿا، انهن کي پروسيس ۾ جانچ ڪري سگهون ٿا ۽ صارف کي پريشان نه ڪندا.

خير، پيداوار ۾ جاچ، يقينا. هزارين سرورن تي ترتيب تبديل ڪرڻ جي ضرورت آهي؟ آسان، اسٽاپ ٽيپ استعمال ڪريو. انهي طريقي سان توهان فوري طور تي تيار ڪيل پيچيده حل ڪڍي سگهو ٿا ۽ هڪ مستحڪم ورزن ڏانهن واپس رول ڪري سگهو ٿا جيڪڏهن مسئلا پيدا ٿين ٿا.

مون کي اميد آهي ته مان اهو ڏيکارڻ جي قابل ٿي چڪو آهيان ته اسان مارڪيٽ کي تيز ۽ مستحڪم بڻائيندا آهيون پيشڪش جي هميشه وڌندڙ بنياد سان. اسان ڪيئن سرور جا مسئلا حل ڪريون ٿا، وڏي تعداد ۾ درخواستن سان ڊيل ڪريو، خدمت جي لچڪ کي بهتر بڻايون ۽ ڪم جي عمل ۾ مداخلت ڪرڻ کان سواءِ ائين ڪريو.

جو ذريعو: www.habr.com