Quay.io جي دستيابي تي پوسٽ مارٽم

نوٽ. ترجمو: آگسٽ جي شروعات ۾، ريڊ Hat عوامي طور تي پهچ جي مسئلن کي حل ڪرڻ جي باري ۾ ڳالهايو جيڪي هن جي خدمت جي استعمال ڪندڙن کي گذريل مهينن ۾ سامهون آيا هئا Quay.io (اهو ڪنٽينر تصويرن جي رجسٽري تي ٻڌل آهي، جيڪا ڪمپني CoreOS جي خريداري سان گڏ ملي ٿي). هن خدمت ۾ توهان جي دلچسپي کان سواءِ، اهو رستو جيڪو ڪمپني جي SRE انجنيئرن حادثن جي سببن جي تشخيص ۽ ان کي ختم ڪرڻ لاءِ ورتو اهو سبق آموز آهي.

19 مئي تي، صبح جو سوير (اڀرندي ڏينهن جي روشني جو وقت، EDT)، quay.io سروس تباهه ٿي وئي. حادثي ٻنهي quay.io صارفين ۽ اوپن سورس منصوبن کي متاثر ڪيو quay.io کي سافٽ ويئر جي تعمير ۽ تقسيم لاءِ پليٽ فارم طور استعمال ڪيو. Red Hat ٻنهي جي اعتماد جو قدر ڪري ٿو.

SRE انجنيئرن جي هڪ ٽيم فوري طور تي شامل ٿي وئي ۽ ڪوشش ڪئي ته Quay سروس کي جلد کان جلد مستحڪم ڪرڻ جي. بهرحال، جڏهن اهي هي ڪري رهيا هئا، گراهڪ نئين تصويرن کي دٻائڻ جي صلاحيت وڃائي ڇڏيو، ۽ صرف ڪڏهن ڪڏهن اهي موجود هئا انهن کي ڇڪڻ جي قابل. ڪجھ اڻڄاتل سببن لاء، quay.io ڊيٽابيس کي بلاڪ ڪيو ويو مڪمل ظرفيت تائين خدمت کي اسڪيل ڪرڻ کان پوء.

«ڇا تبديلي آئي آهي؟"- اهو پهريون سوال آهي جيڪو عام طور تي اهڙين ڪيسن ۾ پڇيو ويندو آهي. اسان ڏٺو ته مسئلي کان ٿورو اڳ، OpenShift وقف ٿيل ڪلستر (جيڪو هلندو آهي quay.io) ورزن 4.3.19 ڏانهن اپڊيٽ ڪرڻ شروع ڪيو. جيئن ته quay.io هلندي آهي Red Hat OpenShift Dedicated (OSD) تي، باقاعده تازه ڪاريون معمولي هيون ۽ ڪڏهن به مسئلا پيدا نه ٿيون. ان کان علاوه، گذريل ڇهن مهينن دوران، اسان ڪيئي ڪلستر کي اپ گريڊ ڪيو آهي ڪيترائي ڀيرا بغير ڪنهن به خدمت ۾ مداخلت.

جڏهن اسان سروس کي بحال ڪرڻ جي ڪوشش ڪري رهيا هئاسين، ٻين انجنيئرن سافٽ ويئر جي پوئين ورزن سان هڪ نئون OSD ڪلستر تيار ڪرڻ شروع ڪيو، ته جيئن جيڪڏهن ڪجهه ٿئي، اهي ان تي هر شي کي ترتيب ڏئي سگهن.

روٽ سبب تجزيو

ناڪامي جي بنيادي نشاني هزارين ڊيٽابيس ڪنيڪشن جو هڪ برفاني طوفان هو، جنهن MySQL مثال کي مؤثر طور تي غير فعال ڪيو. اهو مسئلو تشخيص ڪرڻ ڏکيو ڪيو. اسان SRE ٽيم کي مسئلي جو جائزو وٺڻ ۾ مدد ڏيڻ لاءِ ڪلائنٽ کان وڌ کان وڌ ڪنيڪشن جي حد مقرر ڪئي آهي. اسان ڊيٽابيس ڏانهن ڪا به غير معمولي ٽرئفڪ محسوس نه ڪئي: حقيقت ۾، اڪثر درخواستون پڙهيا ويا، ۽ صرف ڪجهه لکيا ويا.

اسان ڊيٽابيس جي ٽرئفڪ ۾ ھڪڙي نموني کي سڃاڻڻ جي ڪوشش ڪئي جيڪا ھن برفاني طوفان جو سبب بڻجي سگھي ٿي. بهرحال، اسان لاگن ۾ ڪو به نمونو نه ڳولي سگهيا آهيون. او ايس ڊي 4.3.18 سان گڏ نئين ڪلستر جي تيار ٿيڻ جي انتظار ۾، اسان quay.io پوڊز کي لانچ ڪرڻ جي ڪوشش جاري رکي. هر دفعي ڪلستر مڪمل ظرفيت تي پهچي، ڊيٽابيس منجمد ٿي ويندي. ان جو مطلب اهو ٿيو ته سڀني quay.io پوڊز کان علاوه RDS مثال کي ٻيهر شروع ڪرڻ ضروري هو.

شام تائين، اسان سروس کي صرف پڙھڻ واري موڊ ۾ مستحڪم ڪيو ۽ ڊيٽابيس تي لوڊ گھٽائڻ لاءِ جيترو ٿي سگھي غير ضروري ڪمن کي (مثال طور، نالي جي جاءِ تي ڪچرو گڏ ڪرڻ) کي غير فعال ڪيو. منجمد ٿيڻ بند ٿي ويا آهن پر سبب ڪڏهن به نه مليو. نئون OSD ڪلستر تيار ٿي ويو، ۽ اسان سروس کي منتقل ڪيو، ٽرئفڪ سان ڳنڍيل ۽ مسلسل نگراني ڪئي.

Quay.io نئين او ايس ڊي ڪلستر تي مستحڪم طور تي ڪم ڪيو، تنهنڪري اسان ڊيٽابيس لاگز ڏانهن واپس ويا، پر هڪ باهمي تعلق نه ڳولي سگهيا جيڪي بلاڪ جي وضاحت ڪن. OpenShift انجنيئر اسان سان گڏ ڪم ڪيو ته ڇا Red Hat OpenShift 4.3.19 ۾ تبديليون Quay سان مسئلا پيدا ڪري سگھن ٿيون. بهرحال، ڪجھ به نه مليو، ۽ ليبارٽري جي حالتن ۾ مسئلو ٻيهر پيدا ڪرڻ ممڪن نه هو.

ٻيو ناڪامي

28 مئي تي، دوپہر EDT کان ٿورو اڳ، quay.io ساڳئي علامت سان ٻيهر تباهه ٿي ويو: ڊيٽابيس کي بلاڪ ڪيو ويو. ۽ ٻيهر اسان پنهنجي سموري ڪوشش کي تحقيق ۾ اڇلائي ڇڏيو. سڀ کان اول، ان جي خدمت کي بحال ڪرڻ ضروري هو. بهرحال هن ڀيري RDS کي ريبوٽ ڪرڻ ۽ quay.io پوڊس کي ٻيهر شروع ڪرڻ ڪجهه به نه ڪيو: ڪنيڪشن جو هڪ ٻيو برفاني طوفان بيس کي ختم ڪري ڇڏيو آهي. پر ڇو؟

Quay Python ۾ لکيل آهي ۽ هر پوڊ هڪ واحد واحد ڪنٽينر طور ڪم ڪري ٿو. ڪنٽينر رن ٽائيم ڪيترن ئي متوازي ڪمن کي گڏ ڪري ٿو. اسان لائبريري استعمال ڪندا آهيون gevent هيٺ gunicorn ويب درخواستن تي عمل ڪرڻ لاء. جڏهن ڪا درخواست Quay ۾ اچي ٿي (اسان جي پنهنجي API ذريعي، يا Docker's API ذريعي)، ان کي مقرر ڪيو ويو آهي هڪ جيونٽ ورڪر. عام طور تي هن ڪم ڪندڙ کي ڊيٽابيس سان رابطو ڪرڻ گهرجي. پهرين ناڪامي کان پوء، اسان دريافت ڪيو ته جيويٽ ورڪرز ڊفالٽ سيٽنگون استعمال ڪندي ڊيٽابيس سان ڳنڍي رهيا هئا.

Quay pods جي اهم تعداد ۽ هزارين ايندڙ درخواستن جي في سيڪنڊ کي ڏنو ويو، ڊيٽابيس ڪنيڪشن جو هڪ وڏو تعداد نظرياتي طور تي MySQL مثال کي ختم ڪري سگهي ٿو. مانيٽرنگ جي مهرباني، اهو معلوم ٿيو ته Quay في سيڪنڊ جي اوسط 5 هزار درخواستن تي عمل ڪري ٿو. ڊيٽابيس سان ڪنيڪشن جو تعداد لڳ ڀڳ ساڳيو هو. 5 هزار ڪنيڪشن اسان جي آر ڊي ايس مثال جي صلاحيتن جي اندر اندر هئا (جنهن جي باري ۾ نه ٿو چئي سگهجي هزارين). ڪجهه سببن لاءِ ڪنيڪشن جي تعداد ۾ اڻڄاتل اسپيڪس هئاجڏهن ته، اسان کي ايندڙ درخواستن سان ڪو به لاڳاپو نظر نه آيو.

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

اسان فوري طور تي هن نئين نسخي کي پيداوار تي لڳايو ۽ ڊيٽابيس ڪنيڪشن شيڊول جي نگراني ڪرڻ شروع ڪيو. ماضي ۾، بنيادي طور تي 20 منٽن کان پوء بند ڪيو ويو. 30 مصيبتن کان خالي منٽن کان پوءِ اسان کي اميد هئي، ۽ هڪ ڪلاڪ بعد اسان کي اعتماد هو. اسان سائيٽ تي ٽرئفڪ بحال ڪئي ۽ پوسٽ مارٽم تجزيو شروع ڪيو.

بلاڪ ٿيڻ واري مسئلي کي بائي پاس ڪرڻ ۾، اسان ان جا حقيقي سبب نه ڳولي سگهيا آهيون. اها تصديق ڪئي وئي ته اهو OpenShift 4.3.19 ۾ ڪنهن به تبديلي سان لاڳاپيل ناهي، ڇاڪاڻ ته ساڳيو شيء ورزن 4.3.18 تي ٿيو، جيڪو اڳ ۾ Quay سان بغير ڪنهن مسئلن جي ڪم ڪيو.

ڪلستر ۾ واضح طور تي ٻيو ڪجهه لڪي رهيو هو.

تفصيلي مطالعو

Quay.io ڇهن سالن تائين ڊيٽابيس سان ڳنڍڻ لاءِ ڊفالٽ سيٽنگون استعمال ڪيون بغير ڪنهن پريشاني جي. ڇا بدلجي ويو؟ اهو واضح آهي ته هن وقت quay.io تي ٽرئفڪ مسلسل وڌي رهي آهي. اسان جي حالت ۾، اهو ڏسڻ ۾ اچي ٿو ڄڻ ته ڪجهه حد جي قيمت پهچي چڪي هئي، جيڪا ڪنيڪشن جي برفاني طوفان لاء ٽرڪ طور ڪم ڪيو. اسان ٻئين ناڪامي کان پوءِ ڊيٽابيس لاگز جو مطالعو جاري رکيو، پر ڪو به نمونو يا واضح تعلق نه مليو.

ساڳئي وقت ۾، SRE ٽيم Quay جي درخواست جي مشاهدي ۽ مجموعي سروس جي صحت ۾ بهتري تي ڪم ڪري رهي آهي. نوان ميٽرڪ ۽ ڊيش بورڊ لڳايا ويا آهن، ڏيکاريو ته Quay جا ڪهڙا حصا گراهڪن کان تمام گهڻي طلب ۾ آهن.

Quay.io 9 جون تائين ٺيڪ ڪم ڪيو. اھا صبح (EDT) اسان وري ڏٺو آھي ھڪ اھم اضافو ڊيٽابيس ڪنيڪشن جي تعداد ۾. هن ڀيري ڪو به بند نه هو، ڇاڪاڻ ته نئين پيٽرولر انهن جو تعداد محدود ڪيو ۽ انهن کي اجازت نه ڏني ته MySQL throughput کان وڌيڪ. جڏهن ته، اٽڪل اڌ ڪلاڪ لاء، ڪيترن ئي صارفين quay.io جي سست ڪارڪردگي کي نوٽ ڪيو. شامل ڪيل مانيٽرنگ ٽولز استعمال ڪندي اسان جلدي سڀ ممڪن ڊيٽا گڏ ڪيو. اوچتو هڪ نمونو ظاهر ٿيو.

ڪنيڪشن ۾ اضافو ٿيڻ کان پهريان، درخواستن جو هڪ وڏو تعداد ايپ رجسٽري API ڏانهن ڪيو ويو. ايپ رجسٽري quay.io جي ٿوري سڃاتل خصوصيت آهي. اهو توهان کي شين کي ذخيرو ڪرڻ جي اجازت ڏئي ٿو هيلم چارٽس ۽ ڪنٽينرز سان گڏ امير ميٽاداٽا. اڪثر quay.io استعمال ڪندڙ هن خصوصيت سان ڪم نٿا ڪن، پر Red Hat OpenShift ان کي فعال طور تي استعمال ڪري ٿو. OperatorHub OpenShift جي حصي طور ايپ رجسٽري ۾ سڀني آپريٽرن کي اسٽور ڪري ٿو. اهي آپريٽر OpenShift ڪم لوڊ ايڪو سسٽم ۽ پارٽنر سينٽرڪ آپريٽنگ ماڊل (ڏينهن 2 آپريشنز) لاءِ بنياد ٺاهيندا آهن.

هر OpenShift 4 ڪلستر استعمال ڪري ٿو بلٽ ان OperatorHub مان آپريٽرز کي انسٽاليشن لاءِ موجود آپريٽرز جي فهرست شايع ڪرڻ ۽ انهن کي اپڊيٽ مهيا ڪرڻ لاءِ جيڪي اڳ ۾ ئي انسٽال ٿيل آهن. OpenShift 4 جي وڌندڙ مقبوليت سان، سڄي دنيا ۾ ان تي ڪلسٽرز جو تعداد پڻ وڌي ويو آهي. انهن مان هر هڪ ڪلسٽر آپريٽر مواد کي ڊائون لوڊ ڪري ٿو بلٽ ان OperatorHub کي هلائڻ لاءِ، ايپ رجسٽري اندر quay.io کي پس منظر طور استعمال ڪندي. مسئلي جي ماخذ جي ڳولا ۾، اسان ان حقيقت کي وساري ڇڏيو ته جيئن OpenShift بتدريج مقبوليت ۾ وڌندي وئي، تيئن ئي استعمال ٿيندڙ quay.io افعال مان هڪ تي لوڊ به وڌي ويو..

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

سببن جي خاتمي

ايندڙ هفتي دوران اسان ايپ رجسٽري جي ڪوڊ کي پاڻ ۽ ان جي ماحول کي بهتر ڪرڻ ۾ گذاريو. واضح طور تي غير موثر SQL سوالن کي ٻيهر ڪم ڪيو ويو ۽ غير ضروري ڪمانڊ ڪالز کي ختم ڪيو ويو tar (اهو هر وقت هليو ويو جڏهن بلب ٻيهر حاصل ڪيا ويا)، ڪيشنگ شامل ڪيو ويو جتي ممڪن هجي. اسان پوءِ وسيع ڪارڪردگي جاچ ڪئي ۽ تبديلين کان اڳ ۽ پوءِ ايپ رجسٽري جي رفتار جو مقابلو ڪيو.

API جون درخواستون جيڪي اڳ ۾ اڌ منٽ لڳنديون ھيون ھاڻي مليس سيڪنڊن ۾ مڪمل ٿيون. ايندڙ هفتي اسان پيداوار ۾ تبديلين کي ترتيب ڏنو، ۽ ان کان پوء quay.io مستحڪم ڪم ڪري رهيو آهي. هن عرصي دوران، ايپ رجسٽري جي آخري پوائنٽ تي ٽرئفڪ ۾ ڪيترائي تيز اسپيڪس هئا، پر بهتر ڪيل ڊيٽابيس جي بندش کي روڪيو ويو.

اسان ڇا سکيو آهي؟

اهو واضح آهي ته ڪنهن به خدمت جي ڪوشش ڪرڻ کان بچڻ جي ڪوشش ڪري ٿي. اسان جي حالت ۾، اسان يقين رکون ٿا ته تازو بندش quay.io کي بهتر بنائڻ ۾ مدد ڪئي آهي. اسان ڪجھ اھم سبق سکيو آھي جيڪي اسين حصيداري ڪرڻ چاھيون ٿا:

1. ڊيٽا بابت جيڪو توهان جي خدمت کي استعمال ڪري ٿو ۽ ڪيئن ڪڏهن به ضرورت کان وڌيڪ ناهي. ڇاڪاڻ ته Quay "صرف ڪم ڪيو،" اسان کي ڪڏهن به وقت گذارڻ جي ضرورت نه هئي ٽرئفڪ کي بهتر ڪرڻ ۽ لوڊ کي منظم ڪرڻ. هي سڀ سيڪيورٽي جو غلط احساس پيدا ڪيو ته خدمت اڻڄاتل طور تي ماپ ڪري سگهي ٿي.
2. جڏهن خدمت گهٽجي ويندي آهي، ان کي واپس وٺڻ ۽ هلائڻ هڪ اعلي ترجيح آهي.. ڇاڪاڻ ته Quay پهرين بندش دوران هڪ بند ٿيل ڊيٽابيس کان متاثر ٿي رهيو آهي، اسان جي معياري طريقيڪار جو ارادو اثر نه هو ۽ اسان انهن کي استعمال ڪندي سروس بحال ڪرڻ جي قابل نه هئاسين. انهي جي نتيجي ۾ هڪ اهڙي صورتحال پيدا ٿي جتي وقت جو تجزيو ڪرڻ ۽ ڊيٽا گڏ ڪرڻ ۾ خرچ ڪرڻو پوندو بنيادي سبب ڳولڻ جي اميد ۾ - ڪارڪردگي جي بحالي تي سڀني ڪوششن تي ڌيان ڏيڻ بدران.
3. هر خدمت جي خاصيت جي اثر جو اندازو لڳايو. ڪلائنٽ گهٽ ۾ گهٽ ايپ رجسٽري استعمال ڪندا آهن، تنهنڪري اها اسان جي ٽيم لاءِ ترجيح نه هئي. جڏهن ڪجھ پراڊڪٽ جون خاصيتون مشڪل سان استعمال ڪيون وينديون آهن، انهن جا ڪيڙا تمام گهٽ ظاهر ٿيندا آهن، ۽ ڊولپرز ڪوڊ جي نگراني کي روڪيندا آهن. اها غلط فهمي جو شڪار ٿيڻ آسان آهي ته اهو طريقو اهو ئي هجڻ گهرجي- جيستائين اوچتو اهو فنڪشن پاڻ کي هڪ وڏي واقعي جي مرڪز ۾ ڳولي.

ايندڙ ڇا آهي؟

خدمت جي استحڪام کي يقيني بڻائڻ جو ڪم ڪڏهن به نه روڪيو ۽ اسان ان کي مسلسل بهتر ڪري رهيا آهيون. جيئن ته ٽرئفڪ جي مقدار quay.io تي وڌندي رهي ٿي، اسان تسليم ڪريون ٿا ته اسان جي ذميواري آهي ته اسان پنهنجي گراهڪن جي اعتماد تي قائم رهڻ لاءِ سڀ ڪجهه ڪريون. تنهن ڪري، اسان هن وقت هيٺ ڏنل ڪمن تي ڪم ڪري رهيا آهيون:

1. پرائمري RDS مثال سان مسئلن جي صورت ۾ مناسب ٽريفڪ کي سنڀالڻ ۾ خدمت جي مدد لاءِ صرف پڙهڻ لاءِ ڊيٽابيس ريپليڪس کي ترتيب ڏيو.
2. آر ڊي ايس مثال کي اپڊيٽ ڪرڻ. موجوده نسخو پاڻ مسئلو ناهي. بلڪه، اسان صرف ان غلط پيچري کي هٽائڻ چاهيون ٿا (جيڪو اسان ناڪامي دوران پٺيان ڪيو)؛ سافٽ ويئر کي اپڊيٽ رکڻ سان مستقبل ۾ بند ٿيڻ جي صورت ۾ هڪ ٻيو عنصر ختم ٿي ويندو.
3. پوري ڪلستر ۾ اضافي ڪيشنگ. اسان علائقن کي ڳولڻ جاري رکون ٿا جتي ڪيشنگ ڊيٽابيس تي لوڊ گھٽائي سگھي ٿي.
4. ويب ايپليڪيشن فائر وال (WAF) کي شامل ڪرڻ ڏسڻ لاءِ ته ڪير quay.io سان ڳنڍي رهيو آهي ۽ ڇو.
5. ايندڙ رليز سان شروع ڪندي، Red Hat OpenShift ڪلسٽرز quay.io تي موجود ڪنٽينر تصويرن جي بنياد تي آپريٽر ڪيٽلاگ جي حق ۾ ايپ رجسٽري کي ڇڏي ڏيندا.
6. ايپ رجسٽري لاءِ هڪ ڊگھي مدي واري متبادل ٿي سگهي ٿي اوپن ڪنٽينر انيشيٽو (OCI) آرٽيڪل وضاحتن لاءِ. اهو في الحال مقامي Quay ڪارڪردگي جي طور تي لاڳو ڪيو ويو آهي ۽ صارفين لاء دستياب هوندو جڏهن وضاحت پاڻ کي حتمي شڪل ڏني ويندي.

مٿيون سڀ شيون quay.io ۾ Red Hat جي جاري سيڙپڪاري جو حصو آهن جيئن اسان هڪ ننڍي ”شروعاتي طرز“ ٽيم مان هڪ بالغ SRE-هلائيندڙ پليٽ فارم ڏانهن وڃون ٿا. اسان ڄاڻون ٿا ته اسان جا ڪيترائي گراهڪ پنهنجي روزاني ڪم ۾ quay.io تي ڀروسو ڪندا آهن (بشمول Red Hat!) ۽ اسان ڪوشش ڪندا آهيون جيترو ٿي سگهي شفاف ٿيڻ جي باري ۾ تازو بندش ۽ بهتر ڪرڻ لاءِ جاري ڪوششون.

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

• «CoreOS ڪنٽينر تصويرن لاءِ Red Hat اوپن سورس ٿيل رجسٽري ڪوڊ - Quay"؛
• «اسان جي SRE روزمره جي زندگي مان عملي ڪهاڻيون. حصو 2"؛
• «ڪبرنيٽس ۾ پوڊ جي ترجيحات ڪيئن گرافانا ليبز ۾ وقت جي گھٽتائي جو سبب بڻيون».

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