نوٹ. ترجمہ: یہ مضمون AWS ٹیکنالوجی کے مبشر ایڈرین ہورنسبی کے مضامین کا ایک بڑا سلسلہ جاری رکھتا ہے، جو آئی ٹی سسٹمز میں ناکامیوں کے نتائج کو کم کرنے کے لیے تجربات کی اہمیت کو سادہ اور واضح انداز میں بیان کرتا ہے۔
"اگر آپ منصوبہ تیار کرنے میں ناکام رہتے ہیں، تو آپ ناکام ہونے کا ارادہ رکھتے ہیں۔" - بینجمن فرینکلن
В مضامین کی اس سیریز میں، میں نے افراتفری انجینئرنگ کا تصور متعارف کرایا اور بتایا کہ یہ کس طرح سسٹم میں خامیوں کو تلاش کرنے اور ان کو درست کرنے میں مدد کرتا ہے اس سے پہلے کہ وہ پیداواری ناکامیوں کا باعث بنیں۔ اس نے یہ بھی بتایا کہ کس طرح افراتفری انجینئرنگ تنظیموں کے اندر مثبت ثقافتی تبدیلی کو فروغ دیتی ہے۔
پہلے حصے کے آخر میں، میں نے "سسٹم میں ناکامیوں کو متعارف کرانے کے لیے ٹولز اور طریقے" کے بارے میں بات کرنے کا وعدہ کیا۔ افسوس، اس سلسلے میں میرے سر کی اپنی منصوبہ بندی تھی، اور اس مضمون میں میں ان لوگوں میں پیدا ہونے والے سب سے زیادہ مقبول سوال کا جواب دینے کی کوشش کروں گا جو افراتفری انجینئرنگ میں جانا چاہتے ہیں: پہلے کیا توڑنا ہے؟
بہت اچھا سوال! تاہم، وہ اس پانڈا سے خاص طور پر پریشان نظر نہیں آتے...
افراتفری پانڈا کے ساتھ گڑبڑ نہ کرو!
مختصر جواب: درخواست کے راستے میں اہم خدمات کو نشانہ بنائیں۔
طویل لیکن واضح جوابیہ سمجھنے کے لیے کہ افراتفری کا تجربہ کہاں سے شروع کیا جائے، تین شعبوں پر توجہ دیں:
- دیکھو حادثے کی تاریخ اور پیٹرن کی شناخت؛
- فیصلہ کریں۔ اہم انحصار;
- نام نہاد استعمال کریں۔ زیادہ اعتماد کا اثر.
یہ مضحکہ خیز ہے، لیکن اس حصے کو آسانی سے کہا جا سکتا ہے "خود کی دریافت اور روشن خیالی کا سفر". اس میں ہم کچھ ٹھنڈے آلات کے ساتھ "کھیلنا" شروع کریں گے۔
1. جواب ماضی میں ہے۔
اگر آپ کو یاد ہے، پہلے حصے میں میں نے غلطیوں کی اصلاح (COE) کا تصور متعارف کرایا تھا - ایک ایسا طریقہ جس کے ذریعے ہم اپنی غلطیوں کا تجزیہ کرتے ہیں - ٹیکنالوجی، عمل یا تنظیم میں ہونے والی غلطیاں - ان کی وجہ کو سمجھنے اور روکنے کے لیے۔ مستقبل میں تکرار عام طور پر، یہ وہ جگہ ہے جہاں سے آپ کو شروع کرنا چاہئے۔
"حال کو سمجھنے کے لیے آپ کو ماضی کو جاننا ہوگا۔" - کارل ساگن
ناکامیوں کی تاریخ دیکھیں، انہیں COE یا پوسٹ مارٹم میں ٹیگ کریں اور ان کی درجہ بندی کریں۔ عام نمونوں کی نشاندہی کریں جو اکثر مسائل کا باعث بنتے ہیں، اور ہر COE کے لیے، اپنے آپ سے درج ذیل سوال پوچھیں:
"کیا اس کی پیشن گوئی کی جا سکتی تھی اور اس وجہ سے غلطی کے انجیکشن سے روکا جا سکتا تھا؟"
مجھے اپنے کیریئر کے شروع میں ایک ناکامی یاد ہے۔ اسے آسانی سے روکا جا سکتا تھا اگر ہم افراتفری کے چند سادہ تجربات کرتے:
عام حالات میں، پسدید مثالیں صحت کی جانچ کا جواب دیتی ہیں۔ )۔ ELB درخواستوں کو صحت مند مثالوں پر بھیجنے کے لیے ان چیکوں کا استعمال کرتا ہے۔ جب یہ پتہ چلتا ہے کہ کوئی مثال "غیر صحت مند" ہے، تو ELB اسے درخواستیں بھیجنا بند کر دیتا ہے۔ ایک دن، ایک کامیاب مارکیٹنگ مہم کے بعد، ٹریفک کا حجم بڑھ گیا اور بیک اینڈز نے معمول سے زیادہ آہستہ آہستہ صحت کی جانچ کا جواب دینا شروع کیا۔ بتایا جائے کہ یہ ہیلتھ چیکس تھے۔ ، یعنی، انحصار کی حالت کی جانچ کی گئی۔
تاہم، کچھ دیر کے لئے سب کچھ ٹھیک تھا.
پھر، پہلے سے ہی کافی دباؤ والے حالات میں، ایک مثال نے ایک غیر اہم، باقاعدہ ETL کرون ٹاسک کو انجام دینا شروع کیا۔ ہائی ٹریفک اور کرون جاب کے امتزاج نے CPU کے استعمال کو تقریباً 100% تک دھکیل دیا۔ CPU اوورلوڈ نے صحت کی جانچ کے جوابات کو مزید سست کردیا، اتنا کہ ELB نے فیصلہ کیا کہ مثال کو کارکردگی کے مسائل کا سامنا ہے۔ جیسا کہ توقع کی گئی تھی، بیلنسر نے اس پر ٹریفک کو تقسیم کرنا بند کر دیا، جس کے نتیجے میں، گروپ میں باقی مثالوں پر بوجھ میں اضافہ ہوا۔
اچانک، دیگر تمام واقعات بھی صحت کی جانچ میں ناکام ہونے لگے۔
ایک نئی مثال شروع کرنے کے لیے پیکجز کو ڈاؤن لوڈ اور انسٹال کرنے کی ضرورت ہوتی ہے اور آٹو اسکیلنگ گروپ میں ELB کو ان کو غیر فعال کرنے میں جتنا زیادہ وقت لگتا ہے واضح رہے کہ جلد ہی پورا عمل ایک نازک موڑ پر پہنچ گیا اور ایپلیکیشن کریش ہو گئی۔
پھر ہم نے ہمیشہ کے لیے درج ذیل نکات کو سمجھا:
- ایک نئی مثال بناتے وقت سافٹ ویئر کو انسٹال کرنے میں کافی وقت لگتا ہے؛ بہتر ہے کہ غیر تبدیل شدہ طریقہ کو ترجیح دی جائے اور .
- پیچیدہ حالات میں، صحت کی جانچ پڑتال اور ELBs کے جوابات کو ترجیح دی جانی چاہیے - آخری چیز جو آپ چاہتے ہیں وہ ہے باقی صورتوں کے لیے زندگی کو پیچیدہ بنانا۔
- صحت کی جانچ کی مقامی کیشنگ بہت مدد کرتی ہے (یہاں تک کہ چند سیکنڈ کے لیے بھی)۔
- مشکل صورت حال میں، کرون ٹاسک اور دیگر غیر اہم عمل نہ چلائیں - اہم ترین کاموں کے لیے وسائل بچائیں۔
- آٹو اسکیلنگ کرتے وقت، چھوٹی مثالیں استعمال کریں۔ 10 چھوٹے نمونوں کا ایک گروپ 4 بڑے نمونوں کے گروپ سے بہتر ہے۔ اگر ایک مثال ناکام ہو جاتی ہے، تو پہلی صورت میں 10% ٹریفک 9 پوائنٹس پر تقسیم کی جائے گی، دوسری میں - 25% ٹریفک تین پوائنٹس پر۔
اس طرح، کیا اس کی پیشین گوئی کی جا سکتی تھی، اور اس لیے مسئلہ کو متعارف کروا کر روکا جا سکتا تھا؟
جی ہاں، اور کئی طریقوں سے۔
سب سے پہلے، ٹولز کا استعمال کرتے ہوئے اعلی سی پی یو کے استعمال کی نقل کرتے ہوئے جیسے یا :
❯ stress-ng --matrix 1 -t 60s
کشیدگی-این جی
دوم، مثال کے ساتھ اوور لوڈ کرکے اور اسی طرح کی دیگر سہولیات:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
تجربات نسبتاً آسان ہیں، لیکن کسی حقیقی ناکامی کے دباؤ سے گزرے بغیر سوچ کے لیے کچھ اچھی خوراک فراہم کر سکتے ہیں۔
لیکن وہاں مت روکو. آزمائشی ماحول میں کریش کو دوبارہ پیش کرنے کی کوشش کریں اور سوال کا اپنا جواب چیک کریں "کیا اس کی پیشین گوئی کی جا سکتی تھی اور اس لیے غلطی کو متعارف کروا کر روکا جا سکتا تھا؟" یہ مفروضوں کو جانچنے کے لیے افراتفری کے تجربے کے اندر ایک چھوٹا افراتفری کا تجربہ ہے، لیکن اس کا آغاز ناکامی سے ہوتا ہے۔
کیا یہ ایک خواب تھا، یا واقعی ایسا ہوا؟
اس لیے ناکامیوں کی تاریخ کا مطالعہ کریں، تجزیہ کریں۔ ای او سی، ٹیگ کریں اور انہیں "ہٹ رداس" کے لحاظ سے درجہ بندی کریں — یا زیادہ درست طریقے سے، متاثرہ صارفین کی تعداد — اور پھر پیٹرن تلاش کریں۔ اپنے آپ سے پوچھیں کہ کیا اس کی پیش گوئی کی جا سکتی تھی اور مسئلہ کو متعارف کروا کر روکا جا سکتا تھا۔ اپنا جواب چیک کریں۔
پھر سب سے بڑی رینج کے ساتھ سب سے عام پیٹرن پر سوئچ کریں۔
2. انحصار کا نقشہ بنائیں
اپنی درخواست کے بارے میں سوچنے کے لیے ایک لمحہ نکالیں۔ کیا اس کے انحصار کا کوئی واضح نقشہ ہے؟ کیا آپ جانتے ہیں کہ اگر ناکامی ہوتی ہے تو ان کا کیا اثر ہوگا؟
اگر آپ اپنی درخواست کے کوڈ سے زیادہ واقف نہیں ہیں یا یہ بہت بڑا ہو گیا ہے، تو یہ سمجھنا مشکل ہو سکتا ہے کہ کوڈ کیا کرتا ہے اور اس کے انحصار کیا ہیں۔ ان انحصارات کو سمجھنا اور ایپلیکیشن اور صارفین پر ان کے ممکنہ اثرات کو سمجھنا یہ جاننے کے لیے اہم ہے کہ افراتفری انجینئرنگ کے ساتھ کہاں سے آغاز کیا جائے: نقطہ آغاز وہ جزو ہے جس میں سب سے زیادہ اثر والے رداس ہیں۔
انحصار کی شناخت اور دستاویز کرنا کہلاتا ہے "انحصار کا نقشہ بنانا» (انحصار کی نقشہ سازی). یہ عام طور پر کوڈ پروفائلنگ ٹولز کا استعمال کرتے ہوئے بڑے کوڈ بیس والی ایپلی کیشنز کے لیے کیا جاتا ہے۔ (کوڈ پروفائلنگ) اور آلات (آلہ سازی). آپ نیٹ ورک ٹریفک کی نگرانی کرکے نقشہ بھی بنا سکتے ہیں۔
تاہم، تمام انحصار ایک جیسے نہیں ہیں (جو عمل کو مزید پیچیدہ بناتا ہے)۔ کچھ تنقیدیدیگر - ثانوی (کم از کم تھیوری میں، چونکہ کریش اکثر انحصار کے مسائل کی وجہ سے ہوتے ہیں جنہیں غیر اہم سمجھا جاتا تھا).
اہم انحصار کے بغیر، سروس کام نہیں کر سکتی۔ غیر اہم انحصار "نہیں کرنا چاہئے» گرنے کی صورت میں سروس کو متاثر کرنا۔ انحصار کو سمجھنے کے لیے، آپ کو اپنی ایپلیکیشن کے ذریعے استعمال کیے جانے والے APIs کی واضح تفہیم کی ضرورت ہے۔ یہ لگتا ہے اس سے کہیں زیادہ مشکل ہوسکتا ہے - کم از کم بڑی ایپلی کیشنز کے لیے۔
تمام APIs سے گزر کر شروع کریں۔ سب سے زیادہ نمایاں کریں۔ اہم اور اہم. لے لو انحصار کوڈ کے ذخیرے سے، اسے چیک کریں۔ کنکشن لاگز، پھر دیکھیں دستاویزات (یقینا، اگر یہ موجود ہے - دوسری صورت میں آپ کے پاس اب بھی موجود ہے۔оبڑے مسائل)۔ ٹولز کا استعمال کریں۔ پروفائلنگ اور ٹریسنگ، بیرونی کالوں کو فلٹر کریں۔
جیسے پروگرام استعمال کر سکتے ہیں۔ netstat - ایک کمانڈ لائن یوٹیلیٹی جو سسٹم میں تمام نیٹ ورک کنکشنز (ایکٹو ساکٹ) کی فہرست دکھاتی ہے۔ مثال کے طور پر، تمام موجودہ کنکشن کی فہرست کے لیے، ٹائپ کریں:
❯ netstat -a | more
AWS میں آپ استعمال کر سکتے ہیں۔ (فلو لاگز) VPC ایک ایسا طریقہ ہے جو آپ کو VPC میں نیٹ ورک انٹرفیس پر جانے یا جانے والے IP ٹریفک کے بارے میں معلومات جمع کرنے کی اجازت دیتا ہے۔ اس طرح کے لاگز دوسرے کاموں میں بھی مدد کر سکتے ہیں - مثال کے طور پر، اس سوال کا جواب تلاش کرنا کہ مخصوص ٹریفک مثال تک کیوں نہیں پہنچتی۔
آپ بھی استعمال کر سکتے ہیں۔ . ایکس رے آپ کو تفصیلی، "حتمی" حاصل کرنے کی اجازت دیتا ہے (آخر سے آخر تک) درخواستوں کا جائزہ جیسے ہی وہ ایپلیکیشن کے ذریعے منتقل ہوتی ہیں، اور درخواست کے بنیادی اجزاء کا نقشہ بھی بناتی ہے۔ اگر آپ کو انحصار کی شناخت کرنے کی ضرورت ہو تو بہت آسان۔
AWS ایکس رے کنسول
نیٹ ورک پر انحصار کا نقشہ صرف ایک جزوی حل ہے۔ ہاں، یہ ظاہر کرتا ہے کہ کون سی ایپلیکیشن کس کے ساتھ بات چیت کرتی ہے، لیکن دیگر انحصار بھی ہیں۔
بہت سی ایپلیکیشنز انحصار سے جڑنے کے لیے 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"
رسائی بند کرنا
پہلا اصول گوگل کے عوامی DNS سے تمام پیکٹوں کو چھوڑ دیتا ہے: ping کام کرتا ہے، لیکن پیکٹ واپس نہیں کیے جاتے ہیں. دوسرا قاعدہ آپ کے سسٹم سے شروع ہونے والے تمام پیکٹ کو گوگل کے عوامی DNS کی طرف چھوڑ دیتا ہے - جواب میں ping ہم حاصل آپریشن کی اجازت نہیں ہے۔.
نوٹ: اس خاص معاملے میں استعمال کرنا بہتر ہوگا۔ whois 8.8.8.8، لیکن یہ صرف ایک مثال ہے۔
ہم خرگوش کے سوراخ کے نیچے اور بھی گہرائی میں جا سکتے ہیں، کیونکہ ہر وہ چیز جو TCP اور UDP استعمال کرتی ہے دراصل IP پر بھی منحصر ہوتی ہے۔ زیادہ تر معاملات میں، IP کو ARP سے جوڑا جاتا ہے۔ فائر والز کے بارے میں مت بھولنا...
اگر آپ سرخ گولی لیتے ہیں، تو آپ ونڈر لینڈ میں رہیں گے، اور میں آپ کو دکھاؤں گا کہ خرگوش کا سوراخ کتنا گہرا ہے۔"
ایک زیادہ بنیاد پرست نقطہ نظر ہے منقطع ہوجائیں ایک ایک کرکے کاریں اور دیکھیں کہ کیا ٹوٹا ہے... "افراتفری کا بندر" بنیں۔ بلاشبہ، بہت سے پیداواری نظام ایسے وحشیانہ طاقت کے حملے کے لیے نہیں بنائے گئے ہیں، لیکن کم از کم اسے آزمائشی ماحول میں آزمایا جا سکتا ہے۔
انحصار کا نقشہ بنانا اکثر ایک بہت طویل کام ہوتا ہے۔ میں نے حال ہی میں ایک ایسے کلائنٹ سے بات کی جس نے ایک ٹول تیار کرنے میں تقریباً 2 سال گزارے جو سیکڑوں مائیکرو سروسز اور کمانڈز کے لیے نیم خودکار طور پر انحصار کے نقشے تیار کرتا ہے۔
تاہم، نتیجہ انتہائی دلچسپ اور مفید ہے۔ آپ اپنے سسٹم، اس کے انحصار اور آپریشنز کے بارے میں بہت کچھ سیکھیں گے۔ ایک بار پھر، صبر کریں: یہ سفر ہی ہے جو سب سے زیادہ اہمیت رکھتا ہے۔
3. حد سے زیادہ اعتماد سے بچو
"جو کوئی خواب دیکھتا ہے، اس پر یقین رکھتا ہے۔" - ڈیموسٹینیز
کیا آپ نے کبھی سنا ہے؟ زیادہ اعتماد کا اثر?
ویکیپیڈیا کے مطابق، حد سے زیادہ اعتماد کا اثر "ایک علمی تعصب ہے جس میں کسی شخص کا اپنے اعمال اور فیصلوں پر اعتماد ان فیصلوں کی معروضی درستگی سے نمایاں طور پر زیادہ ہوتا ہے، خاص طور پر جب اعتماد کی سطح نسبتاً زیادہ ہو۔"
جبلت اور تجربے کی بنیاد پر...
میرے تجربے میں، یہ تحریف اس بات کا ایک بہت بڑا اشارہ ہے کہ افراتفری انجینئرنگ کے ساتھ کہاں سے آغاز کیا جائے۔
زیادہ پراعتماد آپریٹر سے ہوشیار رہیں:
چارلی: "یہ چیز پانچ سالوں میں نہیں گری، سب ٹھیک ہے!"
کریش: "رکو... میں جلد ہی وہاں پہنچ جاؤں گا!"
حد سے زیادہ اعتماد کے نتیجے میں تعصب اس پر اثر انداز ہونے والے مختلف عوامل کی وجہ سے ایک کپٹی اور خطرناک چیز ہے۔ یہ خاص طور پر سچ ہے جب ٹیم کے اراکین نے اپنا دل کسی ٹیکنالوجی میں ڈال دیا ہے یا اسے "ٹھیک" کرنے میں کافی وقت صرف کیا ہے۔
خلاصہ کرنا
افراتفری انجینئرنگ کے لیے نقطہ آغاز کی تلاش ہمیشہ توقع سے زیادہ نتائج لاتی ہے، اور جو ٹیمیں بہت تیزی سے چیزوں کو توڑنا شروع کر دیتی ہیں وہ (افراتفری-) کے زیادہ عالمی اور دلچسپ جوہر سے محروم ہو جاتی ہیں۔انجینئرنگ - تخلیقی درخواست سائنسی طریقے и شاہی گواہی (سافٹ ویئر) سسٹمز کے ڈیزائن، ترقی، آپریشن، دیکھ بھال اور بہتری کے لیے۔
یہ دوسرا حصہ ختم کرتا ہے۔ براہ کرم تجزیے لکھیں، رائے کا اشتراک کریں یا صرف تالیاں بجائیں۔ . اگلے حصے میں I واقعی میں سسٹمز میں ناکامیوں کو متعارف کرانے کے لیے ٹولز اور طریقوں پر غور کروں گا۔ جب تک!
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com