نوٽ. ترجمو: هي آرٽيڪل AWS ٽيڪنالاجي جي مبشر ايڊريان هورنسبي جي مضمونن جو هڪ وڏو سلسلو جاري رکي ٿو، جيڪو IT سسٽم ۾ ناڪامين جي نتيجن کي گهٽائڻ لاءِ تجربن جي اهميت کي آسان ۽ واضح انداز ۾ بيان ڪري ٿو.
"جيڪڏهن توهان هڪ منصوبو تيار ڪرڻ ۾ ناڪام ٿيو، ته توهان ناڪام ٿيڻ جو منصوبو ٺاهيو." - بنيامين فرينڪلن
В مضمونن جي هن سلسلي ۾، مون افراتفري انجنيئرنگ جو تصور متعارف ڪرايو ۽ وضاحت ڪئي ته اهو ڪيئن مدد ڪري ٿو سسٽم ۾ خاميون ڳولڻ ۽ ان کي درست ڪرڻ کان اڳ اهي پيداوار جي ناڪاميءَ جو سبب بڻجن. اهو پڻ بحث ڪيو ته ڪيئن افراتفري انجنيئرنگ تنظيمن جي اندر مثبت ثقافتي تبديلي کي وڌايو.
پهرئين حصي جي آخر ۾، مون ”سسٽم ۾ ناڪامين کي متعارف ڪرائڻ جا اوزار ۽ طريقا“ بابت ڳالهائڻ جو واعدو ڪيو. افسوس، منهنجي سر ان سلسلي ۾ پنهنجون منصوبا هئا، ۽ هن آرٽيڪل ۾ آئون سڀ کان وڌيڪ مشهور سوال جو جواب ڏيڻ جي ڪوشش ڪندس جيڪي ماڻهن جي وچ ۾ پيدا ٿين ٿا جيڪي افراتفري انجنيئرنگ ۾ حاصل ڪرڻ چاهيندا آهن: پهرين ٽوڙڻ لاء ڇا؟
عظيم سوال! بهرحال، هو هن پانڊا کان خاص طور تي پريشان ٿيڻ نٿو لڳي ...
افراتفري پانڊا سان گند نه ڪريو!
مختصر جواب: درخواست جي رستي سان نازڪ خدمتن کي ھدف ڪريو.
ڊگهو پر واضح جوابسمجھڻ لاءِ ته ڪٿي افراتفري سان تجربو شروع ڪيو وڃي، ٽن علائقن تي ڌيان ڏيو:
- ڏس حادثي جي تاريخ ۽ نمونن جي سڃاڻپ؛
- فيصلو ڪر نازڪ انحصار;
- نامياري استعمال ڪريو وڌيڪ اعتماد جو اثر.
اهو مذاق آهي، پر اهو حصو صرف آساني سان سڏيو وڃي ٿو "خود دريافت ۽ روشنيءَ جو سفر". ان ۾ اسان ”کيڏڻ“ شروع ڪنداسين ڪجهه ٿڌي اوزارن سان.
1. جواب ماضي ۾ آهي
جيڪڏهن توهان کي ياد هجي ته، پهرين حصي ۾ مون متعارف ڪرايو هو Correction-of-Errors (COE) - هڪ طريقو جنهن ذريعي اسان پنهنجي غلطين جو تجزيو ڪريون ٿا - ٽيڪنالاجي، عمل يا تنظيم ۾ غلطيون - انهن جي سببن کي سمجهڻ ۽ روڪڻ لاءِ. مستقبل ۾ ٻيهر ورجائي. عام طور تي، هي آهي جتي توهان کي شروع ڪرڻ گهرجي.
"موجوده کي سمجهڻ لاء، توهان کي ماضي کي ڄاڻڻ جي ضرورت آهي." - ڪارل ساگن
ناڪامين جي تاريخ ڏسو، انهن کي COE يا پوسٽ مارٽم ۾ ٽيگ ڪريو ۽ انهن کي درجه بندي ڪريو. عام نمونن جي سڃاڻپ ڪريو جيڪي اڪثر ڪري مسئلا پيدا ڪن ٿا، ۽ هر COE لاءِ، پاڻ کان هيٺين سوال پڇو:
"ڇا اها اڳڪٿي ڪئي وئي هئي ۽ تنهنڪري غلطي انجيڪشن ذريعي روڪيو ويو؟"
مون کي پنهنجي ڪيريئر جي شروعات ۾ هڪ ناڪامي ياد آهي. اهو آساني سان روڪي سگهجي ها جيڪڏهن اسان ڪجهه سادي افراتفري تجربا ڪيا ها:
عام حالتن ۾، پس منظر مثالن کان صحت جي چڪاس جو جواب ڏين ٿا ). ELB انهن چيڪن کي استعمال ڪري ٿو درخواستن کي صحت مند مثالن ڏانهن موٽڻ لاءِ. جڏهن اهو ظاهر ٿئي ٿو ته هڪ مثال "غير صحت مند" آهي، ELB ان ڏانهن درخواستون موڪلڻ بند ڪري ٿو. هڪ ڏينهن، هڪ ڪامياب مارڪيٽنگ مهم کان پوء، ٽرئفڪ جو حجم وڌي ويو ۽ پٺتي پيل صحت جي چيڪن کي معمول کان وڌيڪ سست جواب ڏيڻ شروع ڪيو. چوڻ گهرجي ته اهي صحت جا چيڪ هئا ، اهو آهي، انحصار جي حالت چيڪ ڪيو ويو.
بهرحال، ڪجهه وقت لاء سڀ ڪجهه ٺيڪ هو.
ان کان پوء، اڳ ۾ ئي دٻاء واري حالتن ۾، هڪ مثالن مان هڪ غير نازڪ، باقاعده اي ٽي ايل ڪرون ڪم تي عمل ڪرڻ شروع ڪيو. اعلي ٽرئفڪ ۽ ڪرونجوب جو ميلاپ سي پي يو جي استعمال کي لڳ ڀڳ 100٪ تائين پهچايو. سي پي يو اوور لوڊ صحت جي چڪاس جي جوابن کي وڌيڪ سست ڪيو، ايتري قدر جو ELB فيصلو ڪيو ته مثال ڪارڪردگي جي مسئلن جو تجربو ڪري رهيو هو. جيئن توقع ڪئي وئي، بيلنس ان کي ٽرئفڪ کي ورهائڻ بند ڪري ڇڏيو، جنهن جي نتيجي ۾، گروپ ۾ باقي واقعن تي لوڊ وڌائي ٿي.
اوچتو، ٻيا سڀئي مثال پڻ صحت جي چڪاس ۾ ناڪام ٿيڻ شروع ٿي ويا.
ھڪڙو نئون مثال شروع ڪرڻ لاءِ پيڪيجز کي ڊائون لوڊ ۽ انسٽال ڪرڻ جي ضرورت آھي ۽ ELB کان گھڻو وقت ورتو انھن کي غير فعال ڪرڻ ۾ - ھڪڙي ھڪڙي - آٽو اسڪيلنگ گروپ ۾. واضح رهي ته جلد ئي سڄو عمل انتهائي نازڪ موڙ تي پهچي ويو ۽ درخواست تباهه ٿي وئي.
پوءِ اسان هميشه لاءِ هيٺيان نقطا سمجھندا هئاسين:
- سافٽ ويئر انسٽال ڪرڻ جڏهن هڪ نئون مثال ٺاهي گهڻو وقت وٺندو آهي؛ اهو بهتر آهي ته ترجيح ڏني وڃي بدلجندڙ انداز ۽ .
- مشڪل حالتن ۾، صحت جي چڪاس ۽ اي ايل بي جي جوابن کي ترجيح ڏيڻ گهرجي - آخري شيء جيڪا توهان چاهيو ٿا اهو آهي زندگي کي پيچيده ڪرڻ باقي مثالن لاء.
- صحت جي چڪاس جي مقامي ڪيشنگ تمام گھڻي مدد ڪري ٿي (جيتوڻيڪ ڪجھ سيڪنڊن لاءِ).
- مشڪل صورتحال ۾، ڪرون ڪمن ۽ ٻين غير نازڪ عملن کي نه هلايو - سڀ کان اهم ڪمن لاءِ وسيلن کي بچايو.
- جڏهن خودڪار اسڪيلنگ، ننڍا مثال استعمال ڪريو. 10 ننڍن نمونن جو هڪ گروپ 4 وڏن جي هڪ گروپ کان بهتر آهي. جيڪڏهن هڪ مثال ناڪام ٿئي ٿو، پهرين صورت ۾ ٽريفڪ جو 10٪ 9 پوائنٽس تي ورهايو ويندو، ٻئي ۾ - 25٪ ٽرئفڪ جو ٽن پوائنٽن تي.
۽ ائين، ڇا اهو اڳڪٿي ڪري سگهجي ٿو، ۽ تنهنڪري مسئلو متعارف ڪرائڻ کان روڪيو ويو؟
ته، ۽ ڪيترن ئي طريقن سان.
پهريون، اوزار استعمال ڪندي اعلي سي پي يو جي استعمال کي نقل ڪندي جيئن يا :
❯ stress-ng --matrix 1 -t 60s
د stressاء- ng
ٻيو، مثال سان اوور لوڊ ڪندي ۽ ٻيون ملندڙ سهولتون:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
تجربا نسبتاً سادا آهن، پر حقيقي ناڪاميءَ جي دٻاءَ مان گذرڻ کان سواءِ سوچڻ لاءِ ڪجهه سٺو کاڌو مهيا ڪري سگهن ٿا.
جڏهن ته، اتي نه رکو. آزمائشي ماحول ۾ حادثي کي ٻيهر تيار ڪرڻ جي ڪوشش ڪريو ۽ پڙتال ڪريو پنھنجي سوال جو جواب "ڇا اهو اڳڪٿي ٿي سگهي ٿو ۽ تنهنڪري غلطي متعارف ڪرائڻ کان روڪيو ويو؟" هي هڪ ننڍڙو افراتفري تجربو آهي افراتفري جي تجربن جي اندر اندر فرضن کي جانچڻ لاء، پر ناڪامي سان شروع ٿئي ٿو.
ڇا اهو هڪ خواب هو، يا اهو حقيقت ۾ ٿيو؟
تنهن ڪري ناڪامين جي تاريخ جو مطالعو ڪريو، تجزيو ڪريو ڪيو, ٽيگ ڪريو ۽ انهن کي درجه بندي ڪريو "هٽ ريڊيس" يا وڌيڪ صحيح طور تي، متاثر ٿيل گراهڪن جو تعداد - ۽ پوء نمونن لاء ڏسو. پنهنجو پاڻ کان پڇو ته ڇا اهو ٿي سگهي ٿو اڳڪٿي ڪئي وئي آهي ۽ مسئلي کي متعارف ڪرائڻ سان روڪيو وڃي ها. توهان جو جواب چيڪ ڪريو.
پوء سڀ کان وڏي رينج سان سڀ کان وڌيڪ عام نمونن کي تبديل ڪريو.
2. هڪ انحصار نقشو ٺاهيو
توهان جي درخواست بابت سوچڻ لاء هڪ لمحو وٺو. ڇا ان جي انحصار جو هڪ واضح نقشو آهي؟ ڇا توهان کي خبر آهي ته انهن جو اثر ڇا ٿيندو جيڪڏهن ڪو ناڪامي آهي؟
جيڪڏهن توهان پنهنجي ايپليڪيشن جي ڪوڊ کان تمام گهڻو واقف نه آهيو يا اهو تمام وڏو ٿي ويو آهي، اهو سمجهڻ ڏکيو ٿي سگهي ٿو ته ڪوڊ ڇا ڪندو آهي ۽ ان جو انحصار ڇا آهي. انهن انحصارن کي سمجهڻ ۽ انهن جي ايپليڪيشن ۽ استعمال ڪندڙن تي ممڪن اثر ڄاڻڻ لاءِ اهم آهي ته افراتفري انجنيئرنگ سان ڪٿي شروع ڪجي: شروعاتي نقطو سڀ کان وڏو اثر ريڊيس وارو جزو آهي.
انحصار جي سڃاڻپ ۽ دستاويز کي سڏيو ويندو آهي "هڪ انحصار نقشو تعمير ڪرڻ» (انحصار نقشو). اهو عام طور تي ايپليڪيشنن لاءِ ڪيو ويندو آهي وڏي ڪوڊ بيس سان ڪوڊ پروفائلنگ ٽولز استعمال ڪندي. (ڪوڊ پروفائلنگ) ۽ اوزار (آواز). توهان نيٽ ورڪ ٽرئفڪ جي نگراني ڪندي هڪ نقشو پڻ ٺاهي سگهو ٿا.
بهرحال، سڀ انحصار هڪجهڙا نه آهن (جيڪو وڌيڪ پيچيدگي واري عمل کي). ڪجھ نازڪ، ٻيا - ثانوي (گهٽ ۾ گهٽ نظريي ۾، ڇاڪاڻ ته حادثا اڪثر ڪري ٿين ٿا انحصار جي مسئلن جي ڪري جيڪي غير نازڪ سمجهيا ويندا هئا).
نازڪ انحصار کان سواء، خدمت ڪم نٿو ڪري سگهي. غير نازڪ انحصار "نه هئڻ گهرجي» زوال جي صورت ۾ خدمت کي متاثر ڪرڻ لاء. انحصار کي سمجھڻ لاءِ، توھان کي توھان جي ايپليڪيشن پاران استعمال ڪيل APIs جي واضح سمجھڻ جي ضرورت آھي. اهو تمام گهڻو ڏکيو ٿي سگهي ٿو ان کان وڌيڪ لڳي ٿو - گهٽ ۾ گهٽ وڏي ايپليڪيشنن لاءِ.
سڀني APIs ذريعي وڃڻ سان شروع ڪريو. سڀ کان وڌيڪ نمايان ڪريو اهم ۽ نازڪ. وٺڻ зависимости ڪوڊ جي مخزن مان، ان کي چيڪ ڪريو ڪنيڪشن لاگ، پوءِ ڏسو دستاويز (يقينا، جيڪڏهن اهو موجود آهي - ٻي صورت ۾ توهان وٽ اڃا تائين آهيоوڏا مسئلا). اوزار استعمال ڪرڻ لاء پروفائلنگ ۽ ٽريڪنگ، خارجي ڪالن کي فلٽر ڪريو.
توھان پروگرام استعمال ڪري سگھو ٿا جهڙوڪ netstat - هڪ ڪمانڊ لائن افاديت جيڪا ڏيکاري ٿي سسٽم ۾ سڀني نيٽ ورڪ ڪنيڪشن (فعال ساکٽس) جي فهرست. مثال طور، سڀني موجوده ڪنيڪشن کي لسٽ ڪرڻ لاء، ٽائپ ڪريو:
❯ netstat -a | more
AWS ۾ توهان استعمال ڪري سگهو ٿا (فلو لاگز) VPC هڪ طريقو آهي جيڪو توهان کي IP ٽريفڪ جي باري ۾ معلومات گڏ ڪرڻ جي اجازت ڏئي ٿو VPC ۾ نيٽ ورڪ انٽرفيس ڏانهن يا وڃڻ کان. اهڙا لاگ ٻين ڪمن ۾ پڻ مدد ڪري سگھن ٿا - مثال طور، ان سوال جو جواب ڳولڻ ڇو ته ڪجهه ٽرئفڪ مثال تائين نه پهچندي آهي.
توهان پڻ استعمال ڪري سگهو ٿا . X-ray توهان کي تفصيلي حاصل ڪرڻ جي اجازت ڏئي ٿي، "حتمي" (آخر کان آخر تائين) درخواستن جو جائزو جيئن اهي ايپليڪيشن ذريعي منتقل ٿين ٿا، ۽ ايپليڪيشن جي بنيادي حصن جو نقشو پڻ ٺاهي ٿو. تمام آسان جيڪڏهن توهان کي انحصار جي سڃاڻپ ڪرڻ جي ضرورت آهي.
AWS X-ray ڪنسول
هڪ نيٽ ورڪ انحصار نقشو صرف هڪ جزوي حل آهي. ها، اهو ڏيکاري ٿو ته ڪهڙي اپليڪيشن سان رابطو ڪري ٿي، پر ٻيا انحصار آهن.
ڪيتريون ئي ايپليڪيشنون DNS استعمال ڪن ٿيون انحصار سان ڳنڍڻ لاءِ، جڏهن ته ٻيا استعمال ڪري سگهن ٿا سروس دريافت يا حتي هارڊ ڪوڊ ٿيل IP پتي کي ترتيب ڏيڻ واري فائلن ۾ (مثال طور. /etc/hosts).
مثال طور، توهان ٺاهي سگهو ٿا مدد سان iptables ۽ ڏسو ته ڇا ٽوڙيو. هن کي ڪرڻ لاء، هيٺ ڏنل حڪم داخل ڪريو:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS ڪارو سوراخ
جيڪڏهن اندر /etc/hosts يا ٻيون ڪانفيگريشن فائلون، توهان کي IP پتي ملندا جن بابت توهان ڪجھ به نه ڄاڻندا آهيو (ها، بدقسمتي سان، اهو پڻ ٿئي ٿو)، توهان ٻيهر بچاء لاء اچي سگهو ٿا iptables. اچو ته چئو ته توهان دريافت ڪيو 8.8.8.8 ۽ خبر ناهي ته هي گوگل جو عوامي DNS سرور ايڊريس آهي. استعمال ڪندي iptables توھان ھيٺ ڏنل حڪمن کي استعمال ڪندي ھن پتي تي ايندڙ ۽ نڪرڻ واري ٽرئفڪ کي بلاڪ ڪري سگھو ٿا:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
رسائي بند ڪرڻ
پهريون قاعدو گوگل جي عوامي ڊي اين ايس مان سڀني پيڪن کي ڇڏي ٿو: ping ڪم ڪري ٿو، پر پيڪٽس واپس نه ڪيا ويا آهن. ٻيو قاعدو توهان جي سسٽم مان نڪرندڙ سڀني پيڪن کي ڇڏي ٿو گوگل جي عوامي DNS ڏانهن - جواب ۾ ping اسان حاصل ڪريون ٿا آپريشن جي اجازت ناهي.
نوٽ: هن خاص صورت ۾ ان کي استعمال ڪرڻ بهتر ٿيندو whois 8.8.8.8، پر هي صرف هڪ مثال آهي.
اسان خرگوش جي سوراخ کان به وڌيڪ اونهي وڃي سگهون ٿا، ڇاڪاڻ ته هر شي جيڪا TCP ۽ UDP استعمال ڪري ٿي اصل ۾ IP تي منحصر آهي. اڪثر ڪيسن ۾، IP سان ڳنڍيل آهي ARP. فائر والز جي باري ۾ نه وساريو ...
جيڪڏهن توهان ڳاڙهي گولي کڻندؤ، توهان ونڊلينڊ ۾ رهو، ۽ مان توهان کي ڏيکاريندس ته خرگوش جو سوراخ ڪيترو اونهو آهي.
هڪ وڌيڪ بنيادي طريقو آهي ڪٽي ڇڏڻ گاڏيون هڪ هڪ ڪري ۽ ڏسو ته ڇا ڀڄي ويو آهي ... هڪ "افراتفري بندر." يقينن، ڪيترائي پيداوار سسٽم اهڙي قسم جي طاقت جي حملي لاء ٺهيل نه آهن، پر گهٽ ۾ گهٽ ان کي آزمائشي ماحول ۾ آزمائي سگهجي ٿو.
هڪ انحصار نقشو تعمير ڪرڻ اڪثر ڪري هڪ تمام ڊگهو ڪم آهي. مون تازو ئي هڪ ڪلائنٽ سان ڳالهايو جنهن تقريباً 2 سال گذاريا هڪ ٽول تيار ڪرڻ ۾ جيڪو نيم پاڻمرادو ٺاهي ٿو انحصار نقشن جي سوين مائڪرو سروسز ۽ حڪمن لاءِ.
نتيجو، بهرحال، انتهائي دلچسپ ۽ مفيد آهي. توھان توھان جي سسٽم، ان جي انحصار ۽ عملن بابت گھڻو ڪجھ سکندا. ٻيهر، صبر ڪر: اهو سفر پاڻ آهي جيڪو سڀ کان وڌيڪ اهم آهي.
3. حد کان وڌيڪ اعتماد کان بچو
"جيڪو به خواب ڏسي ٿو، ان تي يقين رکي ٿو." - Demosthenes
ڇا توهان ڪڏهن ٻڌو آهي وڌيڪ اعتماد جو اثر?
وڪيپيڊيا جي مطابق، وڌيڪ اعتماد جو اثر "هڪ سنجيدگي واري تعصب آهي جنهن ۾ هڪ شخص جو انهن جي عملن ۽ فيصلن تي اعتماد انهن فيصلن جي مقصد جي درستگي کان گهڻو وڌيڪ آهي، خاص طور تي جڏهن اعتماد جي سطح نسبتا بلند آهي."
جبلت ۽ تجربي جي بنياد تي...
منهنجي تجربي ۾، هي تحريف هڪ وڏو اشارو آهي جتي افراتفري انجنيئرنگ سان شروع ڪيو وڃي.
بي اعتمادي آپريٽر کان خبردار:
چارلي: "هي شيء پنجن سالن ۾ نه ٿي آهي، سڀ ڪجهه ٺيڪ آهي!"
حادثو: "انتظار ڪريو ... مان جلد ئي اتي ايندس!"
حد کان وڌيڪ اعتماد جي نتيجي ۾ تعصب هڪ خطرناڪ ۽ خطرناڪ شيءِ آهي ڇاڪاڻ ته مختلف عنصر جيڪي ان تي اثرانداز ٿين ٿا. اهو خاص طور تي سچ آهي جڏهن ٽيم جي ميمبرن پنهنجي دل کي ٽيڪنالاجي ۾ وجهي ڇڏيو آهي يا گهڻو وقت گذاريو آهي "فيڪسنگ" ان کي.
اختصار ڪرڻ
افراتفري انجنيئرنگ لاءِ شروعاتي نقطي جي ڳولا هميشه توقع کان وڌيڪ نتيجا آڻيندي آهي، ۽ ٽيمون جيڪي شين کي تمام جلدي ٽوڙڻ شروع ڪن ٿيون (افراتفري-) جي وڌيڪ عالمي ۽ دلچسپ جوهر کي نظر انداز ڪن ٿيون.انجنيئرنگ - تخليقي استعمال سائنسي طريقا и تجرباتي ثبوت (سافٽ ويئر) سسٽم جي ڊيزائن، ترقي، آپريشن، سار سنڀال ۽ بهتري لاءِ.
اهو ٻيو حصو ختم ڪري ٿو. مهرباني ڪري تبصرا لکو، راءِ ڏيو يا صرف پنهنجا هٿ تاڙيون وڄايو . ايندڙ حصي ۾ I حقيقت آهي آئون سسٽم ۾ ناڪامين کي متعارف ڪرائڻ لاء اوزار ۽ طريقن تي غور ڪندس. جيستائين!
پي ايس مترجم کان
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com