2.15 ڈی بگنگ اور خرابی کی تشخیص

جائزہ اور محرکات

ڈی بگنگ یہ جاننے کا نظم و ضبط والا کام ہے کہ نظام وہ کام کیوں کرتا ہے جو اسے نہیں کرنا چاہیے، اور خرابی کی تشخیص وہی مہارت ہے جو وقت کے دباؤ میں چلتے پروڈکشن نظام پر لگائی جاتی ہے۔ دونوں نقائص پر لاگو سائنسی طریقہ ہیں: آپ حیران کن رویہ دیکھتے ہیں، اس کی وجہ کے بارے میں مفروضہ بناتے ہیں، ایسا تجربہ ڈیزائن کرتے ہیں جو اسے ثابت یا رد کرے، اور شواہد کو، اپنے اندازے کو نہیں، بتانے دیتے ہیں کہ کیا بدلنا ہے۔ اس طرح کی جائے تو ڈی بگنگ سیکھنے اور سکھانے کے قابل انجینئرنگ کی مہارت ہے۔ لوک داستان کے طور پر کی جائے تو وہ توہم پرستی بن جاتی ہے: بے ترتیب لائنیں بدلنا، سرور دوبارہ چلانا، اور امید رکھنا۔

بڑی ٹیم کے لیے فرق مہنگا ہے۔ ایک سخت نقص کئی سروسز کے انجینئروں کو کھینچ سکتا ہے، آن کال کے گھنٹے کھا سکتا ہے، اور ریلیز روک سکتا ہے۔ جب ہر شخص وجدان سے ڈی بگ کرتا ہے تو وہ محنت مرکب نہیں ہوتی، کیونکہ کوئی نہ دوبارہ پیدا کر سکتا ہے نہ وضاحت کر سکتا ہے کہ کسی اور نے کیا آزمایا۔ جب ٹیم مشترک طریقہ بانٹتی ہے (پہلے دوبارہ پیدا کریں، تلاش سے الگ کریں، نقص کو ناکام ہوتے ٹیسٹ میں گرفت کریں، پھر ٹھیک کریں) تو وہی محنت دہرائے جانے کے قابل عمل اور بڑھتے ہوئے ریگریشن سوٹ میں بدل جاتی ہے۔ ڈی بگنگ ٹیسٹنگ کی حکمت عملی (باب 2.4)، سافٹ ویئر کے معیار (باب 2.11)، اور ان تعمیر کی عادتوں (باب 2.9) سے سختی سے جڑی ہے جو کوڈ کو پہلی جگہ قابل تشخیص بناتی ہیں۔

انٹرپرائز اور سرکاری ترتیبوں میں داؤ بڑھ جاتے ہیں۔ انٹرپرائز کے نقائص سروس اور ٹیم کی حدود کے پار ہیں، اس لیے علامت دیکھنے والا شخص شاذ ہی وجہ کا مالک ہوتا ہے۔ سرکاری نظام وہ پابندیاں جوڑتے ہیں جن سے زیادہ تر انجینئر کبھی نہیں ملتے: ہوا سے الگ یا محدود ماحول جہاں آپ پروڈکشن میں ڈی بگر نہیں لگا سکتے، دوبارہ پیدا ہونے والے بلڈ جن کی تشخیص آرٹیفیکٹس سے کرنی ہے، اور آڈٹ ٹریلز جنہیں ریکارڈ کرنا ہے کہ آپ نے کیا اور کیوں بدلا۔ تینوں میں ہدف ایک ہے: اندازے کی جگہ شواہد رکھیں۔

بنیادی اصول

نظریہ بنانے سے پہلے دوبارہ پیدا کریں۔ جس نقص کو آپ طلب پر ٹرگر نہ کر سکیں وہ افواہ ہے، نقص نہیں۔
ڈی بگنگ مفروضوں کی جانچ ہے۔ بتائیں آپ کیا مانتے ہیں، پھر سب سے سستا تجربہ ڈیزائن کریں جو آپ کو غلط ثابت کر سکے۔
پہلے خرابی اور اسٹیک ٹریس پڑھیں۔ نظام عموماً کوئی لائن بدلنے سے پہلے بتا دیتا ہے کہ کہاں ٹوٹا۔
مسئلے کی جگہ کو تلاش کریں، اسکین نہ کریں۔ ہر قدم پر مشتبہ علاقہ آدھا کریں بجائے اوپر سے نیچے پڑھنے کے۔
کم سے کم تک گھٹائیں۔ معاملہ اتنا ہٹائیں کہ صرف ضروری محرک بچے۔
ایک وقت میں ایک تبدیلی۔ بے ترتیب ترامیم وہ شواہد تباہ کرتی ہیں جو بتاتے کہ کون سی تبدیلی اہم تھی۔
ٹھیک کرنے سے پہلے نقص کو ناکام ہوتے ٹیسٹ میں گرفت کریں۔ اصلاح تبھی ثابت ہوتی ہے جب وہ ٹیسٹ سبز ہو اور سبز رہے۔
قریب ترین علامت نہیں، بنیادی وجہ ڈھونڈیں۔ علامت چھپانے والا پیوند نقص کو واپس آنے کے لیے چھوڑ دیتا ہے۔

سفارشات

کچھ بدلنے سے پہلے نقص کو قابل اعتماد طور پر دوبارہ پیدا کریں

آپ کا پہلا کام قابل اعتماد دوبارہ پیدائش ہے: اقدامات کا سیٹ یا خودکار معاملہ جو طلب پر نقص ٹرگر کرے۔ اس کے بغیر آپ حقیقی اصلاح کو اتفاق سے الگ نہیں کر سکتے، کیونکہ علامت ان وجوہات سے آ جا سکتی ہے جنہیں آپ نے کبھی کنٹرول نہیں کیا۔ ان پٹس، ماحول، ورژن، اور وقت متعین کریں۔ اگر نقص وقفے وقفے سے ہو تو اس چھپے متغیر کی تلاش کریں جو اسے ظاہر کرتا ہے (مخصوص ڈیٹا ریکارڈ، گھڑی کی حد، ہم زمان درخواست) جب تک دوبارہ پیدائش قابل بھروسہ نہ ہو۔ قابل اعتماد دوبارہ پیدائش ڈی بگنگ میں واحد سب سے قیمتی آرٹیفیکٹ ہے، کیونکہ اس کے بعد ہر چیز قابل پیمائش ہو جاتی ہے۔

کوڈ کو چھونے سے پہلے خرابی، لاگز اور اسٹیک ٹریس پڑھیں

ایک بھی نظریہ بنانے سے پہلے وہ پڑھیں جو نظام نے آپ کو پہلے ہی بتایا ہے۔ اسٹیک ٹریس (ناکامی کے لمحے کال کی زنجیر کا ریکارڈ) عموماً فائل، لائن، اور ناکام ہونے والی ترتیب کا نام لیتا ہے۔ استثنا کا پیغام، اس کے ارد گرد کی لاگ لائنیں، اور دائرے میں قدریں آپ کے کچھ بدلنے سے پہلے تلاش کو محدود کرتی ہیں۔ انجینئر ان وجوہات کے بارے میں نظریات بنانے میں گھنٹے ضائع کرتے ہیں جنہیں ٹریس بیک نے پہلی لائن پر رد کر دیا۔ خرابی کے آؤٹ پٹ کو پہلا گواہ سمجھیں، اسے احتیاط اور مکمل پڑھیں، اور پھر طے کریں کہ کیا تحقیق کرنی ہے۔

مسئلے کی جگہ کی بائنری تلاش سے الگ کریں

کوڈ کو اوپر سے نیچے اسکین نہ کریں۔ اسے تلاش کریں۔ بائنری تلاش استعمال کریں: وہ نکتہ ڈھونڈیں جہاں حالت ابھی ٹھیک ہے اور وہ جہاں پہلے ہی بگڑ چکی ہے، پھر درمیانہ نکتہ جانچیں، اور دہرائیں، ہر بار مشتبہ علاقہ آدھا کرتے ہوئے۔ یہ ہزار لائنوں کی تلاش کو دس سوالوں میں بدل دیتا ہے۔ جب ریگریشن کمٹس کی کسی حد میں ظاہر ہوئی ہو تو وہی خیال تاریخ پر دو حصے کرنے سے لگائیں: git bisect کمٹ کی حد پر چلتا ہے، اور آپ ہر ریویژن کو اچھا یا برا نشان زد کرتے ہیں یہاں تک کہ وہ ٹھیک اس تبدیلی کا نام لے جس نے نقص متعارف کرایا۔ اچھے یا برے کے ٹیسٹ کو خودکار کریں اور دو حصے کرنے کا عمل خود چلتا ہے۔

کم سے کم دوبارہ پیدا ہونے والی مثال تک گھٹائیں

جب آپ نقص ٹرگر کر سکیں تو اسے سکیڑیں۔ کم سے کم دوبارہ پیدا ہونے والی مثال سب سے چھوٹا ان پٹ اور کوڈ کا راستہ ہے جو اب بھی ناکام ہو: ڈیٹا، فیچرز، اور اقدامات ہٹائیں جب تک مزید ہٹانے سے نقص غائب نہ ہو جائے۔ گھٹانا فالتو کام نہیں؛ ہر عنصر جو آپ ہٹاتے ہیں وہ وجہ ہے جسے آپ نے رد کر دیا، اس لیے کم سے کم معاملہ اکثر سیدھا نقص کی طرف اشارہ کرتا ہے۔ جب ان پٹ بڑا یا ساخت والا ہو تو گھٹانے کو ڈیلٹا ڈی بگنگ سے خودکار کریں، ایسا الگورتھم جو ناکام ان پٹ کے ٹکڑے منظم طور پر ہٹاتا ہے تاکہ کم سے کم ناکام ذیلی سیٹ ملے۔ چھوٹی، خود کفیل دوبارہ پیدائش کسی دوسری ٹیم کو دینے کے لیے بہترین ممکنہ نقص کی رپورٹ بھی ہے۔

لاگز سے آلہ کاری کریں، پھر انٹرایکٹو ڈی بگر استعمال کریں

ٹول کو نقص سے ملائیں۔ لاگنگ اور ہدف شدہ آلہ کاری تب بہترین ہیں جب آپ کو وقت کے ساتھ، پروسیسز کے پار، یا ایسے ماحول میں رویہ دیکھنا ہو جسے آپ روک نہیں سکتے۔ انٹرایکٹو ڈی بگر، جو آپ کو بریک پوائنٹس لگانے، لائن بہ لائن چلنے، اور زندہ حالت دیکھنے دیتا ہے، تب بہترین ہے جب آپ کوڈ مقامی طور پر چلا سکیں اور ایک عمل کو قریب سے دیکھنا ہو۔ آلہ کاری کو مفروضے سے جڑے سوچے سمجھے تجربے کے طور پر شامل کریں، بکھرے پرنٹ بیانات نہیں، اور نقص حل ہونے پر اسے ہٹائیں یا مستقل ساختہ لاگنگ میں ترقی دیں۔ پروڈکشن میں مشاہدہ پذیری پر مبنی ڈی بگنگ پر انحصار کریں: اعلیٰ کارڈینیلیٹی ایونٹس اور تقسیم شدہ ٹریسنگ (باب 9.2) آپ کو ایک درخواست کو بہت سی سروسز میں پیچھا کرنے دیتے ہیں، جو اکثر ایسے تقسیم شدہ نظام کو ڈی بگ کرنے کا واحد طریقہ ہے جس میں آپ ڈی بگر نہیں لگا سکتے۔

ٹھیک کرنے سے پہلے نقص کو گرفت میں لینے والا ناکام ٹیسٹ لکھیں

اصلاح لکھنے سے پہلے ایسا ٹیسٹ لکھیں جو نقص کی وجہ سے ناکام ہو۔ یہ تین کام ایک ساتھ کرتا ہے: یہ ثابت کرتا ہے کہ آپ واقعی وجہ سمجھتے ہیں، یہ ٹھیک متعین کرتا ہے کہ “ٹھیک ہوا” کا کیا مطلب ہے، اور یہ مستقل محافظ بن جاتا ہے۔ پھر اصلاح کریں اور ٹیسٹ کو سبز ہوتے دیکھیں۔ وہ ٹیسٹ اب آپ کے سوٹ میں ریگریشن ٹیسٹنگ کے محافظ کے طور پر شامل ہو جاتا ہے، تاکہ وہی نقص بغیر نوٹس واپس نہ آ سکے۔ یہ عمل ڈی بگنگ کو براہ راست آپ کی ٹیسٹنگ کی حکمت عملی (باب 2.4) سے جوڑتا ہے: ہر مشکل بگ جو آپ حل کرتے ہیں سوٹ کو اس سے مضبوط چھوڑتا ہے جیسا اسے ملا تھا، اور ناقابل اعتماد ٹیسٹ کے ساتھ وہی برتاؤ ہوتا ہے (غیر متعینیت دوبارہ پیدا کریں، پھر اس کے خلاف حفاظت کریں) بجائے دوبارہ کوشش کے حاشیے کے۔

بنیادی وجہ ڈھونڈیں، اور تجزیہ بلا الزام رکھیں

علامت ٹھیک کرنا نقص ٹھیک کرنا نہیں۔ ناکامی کو اس کے حقیقی ماخذ تک سراغ لگائیں، ہر تہہ پر کیوں پوچھتے ہوئے جب تک آپ ایسی وجہ تک نہ پہنچیں جسے آپ چھپانے کے بجائے ہٹا سکیں۔ جو نقائص پروڈکشن تک پہنچے ان کے لیے واقعہ مینجمنٹ (باب 9.3) کے حصے کے طور پر بلا الزام بنیادی وجہ کا تجزیہ چلائیں: نظام اور عمل کے حالات پر توجہ دیں جنہوں نے بگ کو ریلیز اور زندہ رہنے دیا، کبھی اس فرد پر نہیں جس نے وہ لائن لکھی۔ الزام معلومات کو زیر زمین دھکیلتا ہے، اور ڈی بگنگ معلومات پر چلتی ہے۔ نتیجہ اصلاح بھی ہے اور اس تبدیلی کا بھی کہ نقص کی اس قسم کو اگلی بار جلد کیسے پکڑا جائے۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
لاگنگ اور آلہ کاری	پروڈکشن اور تقسیم شدہ نظاموں میں کام کرتی ہے؛ وقت کے ساتھ رویہ گرفت میں لیتی ہے	شور، لاگت، اور لاگ کا پھیلاؤ؛ وقت کے نقائص کو متاثر کر سکتی ہے
انٹرایکٹو ڈی بگر	درست، زندہ حالت کی جانچ؛ مقامی نقائص کے لیے تیز	محدود یا ہوا سے الگ پروڈکشن میں بیکار؛ ہم زمانیت کے نقائص چھپا سکتا ہے
پہلے دوبارہ پیدا کرنے کا نظم و ضبط	اندازے کو پیمائش میں بدلتا ہے؛ ناکام ٹیسٹ ممکن کرتا ہے	آگے سست؛ کچھ نقائص ٹرگر کرنا واقعی مشکل
بائنری تلاش اور دو حصے کرنا	غیر مانوس کوڈ میں بھی تیز علیحدگی	قابل اعتماد اچھے یا برے ٹیسٹ کی ضرورت؛ نقائص کے آپس میں ٹکرانے پر مشکل
ڈیلٹا ڈی بگنگ سے گھٹانا	بڑے ان پٹس کو خود بخود محرک تک سکیڑتا ہے	ابتدائی لاگت؛ فرض کرتا ہے کہ ناکامی متعین ہے
ابھی علامت ٹھیک کرنا	دباؤ میں سروس تیزی سے بحال کرتا ہے	بنیادی وجہ کو واپس آنے کے لیے چھوڑتا ہے؛ قرض جمع کرتا ہے

مرکزی کھنچاؤ رفتار بمقابلہ یقین ہے۔ پروڈکشن واقعے کے دوران آپ کو سروس بحال کرنے کے لیے پہلے خون روکنے (واپسی یا علامت کا پیوند) کی ضرورت پڑ سکتی ہے، اور یہ جائز ہے۔ غلطی وہیں رک جانا ہے۔ دونوں کاموں کو الگ کر کے کشمکش حل کریں: صارفین کی حفاظت کے لیے تیزی سے تخفیف کریں، پھر نقص کو بند سمجھنے سے پہلے دوبارہ پیدا کریں، بنیادی وجہ ڈھونڈیں، اور ریگریشن کا محافظ جوڑیں۔ فالو اپ کے بغیر علامت کی اصلاح ایسا بگ ہے جس سے دوبارہ ملنے پر آپ نے اتفاق کر لیا۔

اپنی ٹیم کے ساتھ بحث کے سوالات

جب کسی کا سامنا سخت بگ سے ہوتا ہے تو وہ سب سے پہلے کیا کرتا ہے، اور کیا وہ دوبارہ پیدا کرنا ہے یا اندازہ؟ ایماندار جواب ظاہر کرتا ہے کہ آپ کی ٹیم کے پاس مشترک طریقہ ہے یا نجی لوک داستانوں سے بھرا کمرہ۔ لوگوں سے کہیں کہ اپنے آخری مشکل نقص کو بلند آواز میں بیان کریں: کیا انہوں نے پہلے قابل اعتماد دوبارہ پیدائش حاصل کی، یا انہوں نے کوڈ بدلنا اور چیزیں دوبارہ چلانا شروع کر دیا؟ جو ٹیم پہلے دوبارہ پیدا کرتی ہے وہ بگ لوگوں کے درمیان دے سکتی ہے، کیونکہ دوبارہ پیدائش ساتھ سفر کرتی ہے؛ جو اندازہ لگاتی ہے وہ نہیں دے سکتی، کیونکہ ہر کوشش ناقابل دہرائی ہے۔ یہ ٹیم کے بڑھنے کے ساتھ زیادہ اہم ہے، کیونکہ علامت دیکھنے والا شخص تیزی سے وہ شخص نہیں رہتا جو اسے ٹھیک کر سکے۔ اگر ڈیفالٹ اندازہ ہے تو پہلے دوبارہ پیدا کرنے کو اصول کے طور پر طے کریں اور صاف دوبارہ پیدائش کو بگ ٹکٹ میں داخلے کی قیمت بنائیں۔
کیا ہمارے ٹھیک کیے ہوئے بگ واپس آتے ہیں، اور کیا ہمیں معلوم ہوگا اگر آئیں؟ جو نقص واپس آتا ہے وہ ایسا نقص ہے جس کی بنیادی وجہ کبھی ہٹائی نہیں گئی اور جس کی اصلاح کی حفاظت کبھی ٹیسٹ نے نہیں کی۔ اپنی پچھلی سہ ماہی کے واقعات اور دوبارہ کھلے ٹکٹ کھینچیں اور گنیں کہ کتنے پچھلے نقائص کے دہرائے یا قریبی رشتہ دار تھے۔ ہر دہراؤ ثبوت ہے کہ ٹیم نے علامت کا پیوند لگایا، ناکام ٹیسٹ چھوڑ دیا، یا بنیادی وجہ کا تجزیہ بہت جلد روک دیا۔ حل ایک اصول ہے: کوئی بگ بند نہیں جب تک ایسا ٹیسٹ جو پرانے رویے پر ناکام ہو نئے پر پاس نہ ہو اور سوٹ میں شامل نہ ہو۔ ایک حالیہ بار بار آنے والا بگ لائیں اور پوچھیں کہ کون سا محافظ اسے پکڑ لیتا، کیونکہ وہی محافظ ہے جو آپ سے چھوٹ گیا۔
کیا ہم اپنے پروڈکشن نظاموں کو ڈی بگ کر سکتے ہیں، یہ دیکھتے ہوئے کہ ہمیں انہیں چھونے کی اجازت کیسے ہے؟ انٹرپرائز اور خاص طور پر سرکاری ماحول میں آپ اکثر ڈی بگر نہیں لگا سکتے، حقیقی ڈیٹا سے دوبارہ پیدا نہیں کر سکتے، اور آڈٹ ٹریل کے بغیر چلتا نظام نہیں بدل سکتے۔ اگر آپ کی واحد ڈی بگنگ تکنیک مقامی انٹرایکٹو ڈی بگر ہے تو آپ ٹھیک وہاں اندھے ہیں جہاں سخت ترین بگ رہتے ہیں۔ پوچھیں کہ پروڈکشن کی ناکامی دراصل کون سے شواہد چھوڑتی ہے: ساختہ لاگز، تقسیم شدہ ٹریس (باب 9.2)، کور ڈمپ، یا دوبارہ پیدا ہونے والے بلڈ آرٹیفیکٹس۔ ابھی طے کریں کہ آپ کو بذریعہ ڈیفالٹ کیا گرفت میں لینا ہے تاکہ آئندہ واقعہ قابل تشخیص ہو، کیونکہ آپ اس ناکامی پر آلہ کاری نہیں جوڑ سکتے جو پہلے ہو چکی۔ ضابطے کے پابند ترتیبوں میں تصدیق کریں کہ وہی ٹریل آپ کی آڈٹ کی ذمہ داریاں بھی پوری کرتا ہے۔
جب پروڈکشن واقعہ ہمیں تیزی سے خون روکنے پر مجبور کرے تو ہم کیسے یقینی بنائیں کہ بعد میں بھی بنیادی وجہ ڈھونڈی جائے؟ واقعے کے دوران واپسی یا علامت کا پیوند صارفین کی حفاظت کے لیے درست پہلا قدم ہے، لیکن خطرہ یہ ہے کہ ٹکٹ سروس لوٹتے ہی بند ہو جاتا ہے اور بنیادی نقص کی تشخیص کبھی نہیں ہوتی۔ بڑی ٹیم کے لیے یہ وہ جگہ ہے جہاں قرض غیر مرئی طور پر جمع ہوتا ہے، کیونکہ ناکامی کی وہی قسم مہینوں بعد کسی اور سروس اور کسی اور آن کال انجینئر پر دوبارہ ابھرتی ہے۔ اپنے آخری چند شدت ایک واقعات لائیں اور ہر ایک کو جانچیں: کیا تخفیف کے بعد دوبارہ پیدائش، بنیادی وجہ کا تجزیہ، اور ریگریشن کا محافظ آیا، یا کہانی “سروس بحال” پر ختم ہوئی؟ واضح اصول پر اتفاق کریں کہ تخفیف شدہ واقعہ تب تک کھلا رہتا ہے جب تک بنیادی وجہ سمجھی اور محفوظ نہ ہو، اور نام لیں کہ اس فالو تھرو کا مالک کون ہے۔ انٹرپرائز اور سرکاری ترتیبوں میں اسے اپنے واقعہ مینجمنٹ کے عمل (باب 9.3) سے جوڑیں تاکہ واقعے کے بعد کا جائزہ لازمی، قابل آڈٹ قدم ہو، ایسی رعایت نہیں جو اگلی آگ شروع ہونے پر کھسک جائے۔
ناکامی کے بعد ہم اس کا کتنا حصہ دوبارہ تعمیر کر سکتے ہیں، اور بذریعہ ڈیفالٹ کیا گرفت میں لینا ہے یہ کس نے طے کیا؟ آپ اس ناکامی پر آلہ کاری نہیں جوڑ سکتے جو پہلے ہو چکی، اس لیے کسی بھی واقعے کی تشخیص کی اہلیت پہلے سے ان لاگز، ٹریسز، میٹرکس، اور ڈمپس سے طے ہوتی ہے جنہیں آپ نے خارج کرنے کا انتخاب کیا۔ متصادم غور لاگت اور شور ہے: اعلیٰ کارڈینیلیٹی ایونٹس اور مکمل ٹریسنگ مفت نہیں، اور حد سے زیادہ لاگنگ اشارہ دفن کرتی اور اسٹوریج بڑھاتی ہے اور ضابطے کے پابند سیاق میں آپ کی ڈیٹا کی برقراری کی نمائش۔ حقیقی حالیہ واقعہ لائیں اور پوچھیں کہ اس نے کون سے شواہد چھوڑے، پھر الٹا چلیں کہ آپ کیا گرفت میں لینا چاہتے تھے اور اسے رکھنے کی کیا لاگت ہوگی۔ سوچ سمجھ کر طے کریں کہ کون سے اشارے بذریعہ ڈیفالٹ آن ہوں بمقابلہ نمونہ شدہ یا اختیاری، اور وہ فیصلہ ریکارڈ کریں تاکہ یہ اتفاق کے بجائے پالیسی ہو۔ انٹرپرائز یا سرکاری نظام کے لیے شامل کریں کہ اس مشاہدہ پذیری کے بجٹ کا جوابدہ کون ہے اور کیا گرفت شدہ ٹریل آڈٹ، رازداری، اور ڈیٹا کی رہائش کی ذمہ داریاں بھی پوری کرتی ہے۔
کیا ہم ڈی بگنگ کو سکھائی جانے والی، قابل پیمائش مہارت سمجھتے ہیں، یا نئے انجینئر اسے خود بخود جذب کرتے ہیں؟ ڈی بگنگ سیکھنے کے قابل ہے، پھر بھی زیادہ تر ٹیمیں اسے کبھی واضح طور پر نہیں سکھاتیں، اس لیے جونیئر قریب ترین لوک داستان وراثت میں پاتے ہیں، اور پہلے دوبارہ پیدا کرنے کا طریقہ ناہموار پھیلتا ہے یا بالکل نہیں۔ کھنچاؤ یہ ہے کہ سوچا سمجھا سکھانا (سخت بگز پر جوڑی، واقعے کے بعد کے نتائج لکھنا، اشاریے ٹریک کرنا) سینئر وقت لیتا ہے جو ہمیشہ کہیں اور درکار محسوس ہوتا ہے۔ بحث میں دو اعداد لائیں: آپ کے دہرائے گئے نقص کی شرح اور آپ کا تشخیص کا وقت، کیونکہ اگر آپ انہیں ناپ نہیں سکتے تو بتا نہیں سکتے کہ آپ کا طریقہ بہتر ہو رہا ہے یا بگڑ رہا ہے۔ غور کریں کہ کیا آغاز کار میں حقیقی ڈی بگنگ کی مشق شامل ہے اور کیا بنیادی وجہ کے نتائج دراصل جلد پتہ لگانے کو کھلاتے ہیں۔ بڑے یا عوامی ادارے میں دستاویزی، ناپا ہوا ڈی بگنگ کا عمل انجینئرنگ کی سختی کا ثبوت بھی بنتا ہے جسے آڈیٹرز، ریگولیٹرز، اور نگران ادارے تیزی سے دیکھنے کی توقع رکھتے ہیں۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ مٹھی بھر انجینئروں اور بغیر گنجائش کے آپ کا مقصد بھاری عمل بنانا نہیں بلکہ بگز کو دوبارہ پیدا کرنے میں سستا اور بھولنا ناممکن بنانا ہے۔ git bisect، تیز مقامی دوبارہ پیدائش، اور ہر ٹھیک کیے بگ کے لیے ایک ناکام ٹیسٹ پر انحصار کریں، کیونکہ وہ عادت منٹوں کی لاگت لیتی اور آپ کو ایک ہی نقص کی دوبارہ ادائیگی سے روکتی ہے جب آپ ریلیز کرنے کی کوشش کر رہے ہوں۔ رسمی پوسٹ مارٹم چھوڑ دیں، مگر ریگریشن ٹیسٹ کبھی نہ چھوڑیں: یہ وہ آرٹیفیکٹ ہے جو ہمیشہ برداشت کرنے کے لیے کافی چھوٹا اور ہمیشہ رکھنے کے لیے کافی قیمتی ہے۔

چھوٹا کاروبار۔ غالباً آپ کے پاس مخصوص قابل اعتمادی یا مشاہدہ پذیری کا ماہر اور تنگ ٹولنگ بجٹ نہیں، اس لیے وہ ترجیح دیں جو آپ کا اسٹیک پہلے ہی دیتا ہے: پڑھنے کے قابل اسٹیک ٹریس، ساختہ لاگز، اور ان فریم ورکس اور میزبانی والی سروسز میں بنی ٹریسنگ جو آپ نے خریدی۔ جب آپ نیا پلیٹ فارم جانچیں تو تولیں کہ وہ ناکامیوں کو کتنا قابل تشخیص بناتا ہے، کیونکہ سستا ٹول جو چھپائے کہ کیا غلط ہوا اندازے کے وقت میں لائسنس کی بچت سے کہیں زیادہ خرچ کرتا ہے۔ پہلے دوبارہ پیدا کرنا اور ایک وقت میں ایک تبدیلی مفت نظم و ضبط ہیں جو سب سے تیز ثمر دیتے ہیں جب کسی کے پاس فالتو گھنٹے نہ ہوں۔

بڑا ادارہ۔ آپ کے سخت بگ سروس اور ٹیم کی حدود کے پار ہیں، اس لیے علامت دیکھنے والا شاذ ہی وجہ کا مالک ہوتا ہے، اور مشترک طریقہ کسی بھی فرد کی مہارت سے زیادہ اہم ہے۔ ٹیموں میں پہلے دوبارہ پیدا کرنا، بائنری تلاش سے علیحدگی، اصلاح سے پہلے ناکام ٹیسٹ، اور بلا الزام پوسٹ مارٹم معیاری بنائیں، اور تقسیم شدہ ٹریسنگ (باب 9.2) میں سرمایہ کاری کریں تاکہ ایک درخواست سروسز کے پار پیچھا کی جا سکے۔ ڈی بگنگ کو ناپی جانے والی صلاحیت کے طور پر سنبھالیں: دہرائے گئے نقص کی شرح اور تشخیص کا وقت ٹریک کریں، اور بنیادی وجہ کے نتائج کو جلد پتہ لگانے کو واپس کھلائیں تاکہ ناکامی کی وہی قسم آپ کے سروس کے نقشے کا دورہ نہ کرے۔

حکومت۔ خریداری کے قواعد، محدود ماحول، اور عوامی جوابدہی شکل دیتے ہیں کہ آپ ڈی بگ کیسے کر سکتے ہیں۔ آپ اکثر پروڈکشن میں ڈی بگر نہیں لگا سکتے یا شہری ڈیٹا لیپ ٹاپ پر نقل نہیں کر سکتے، اس لیے جو اجازت ہے اس سے تشخیص کے لیے ڈیزائن کریں: دوبارہ پیدا ہونے والے بلڈ، الگ تھلگ انکلیو میں مصنوعی ریکارڈ، اور بذریعہ ڈیفالٹ گرفت شدہ ساختہ لاگز اور ٹریسز۔ ہر تشخیصی قدم اور ہر تبدیلی کو آڈٹ ٹریل میں ریکارڈ کریں، اور تقاضا کریں کہ فروخت کنندگان کافی ٹیلی میٹری اور بلڈ کی دوبارہ پیدائش ظاہر کریں تاکہ آپ سپلائر کی بات پر انحصار کرنے کے بجائے ناکامیوں کی آزادانہ تحقیق کر سکیں۔

مثالیں

اسٹارٹ اپ۔ چار انجینئروں کی ٹیم دیکھتی رہتی ہے کہ صارفین کے ایک حصے کے لیے چیک آؤٹ ناکام ہوتا ہے، مگر ٹیسٹنگ میں کبھی نہیں۔ اندازے کے بجائے ایک انجینئر ٹھیک ناکام درخواست کا پے لوڈ دوبارہ چلا کر قابل اعتماد دوبارہ پیدائش حاصل کرتا ہے، پھر وہ اسٹیک ٹریس پڑھتا ہے جسے وہ نظر انداز کر رہے تھے، جو تاریخ پارس کرنے کی کال کی طرف اشارہ کرتا ہے۔ ہفتے بھر کے کمٹس پر تیز git bisect اس تبدیلی کا نام لیتا ہے جس نے تاریخ کی لائبریری بدلی۔ وہ ناگوار ٹائم اسٹیمپ کے ساتھ ناکام ٹیسٹ لکھتے ہیں، پارسر ٹھیک کرتے ہیں، ٹیسٹ کو سبز ہوتے دیکھتے ہیں، اور اسے سوٹ میں رکھتے ہیں۔ پوری تحقیقات ایک دوپہر لیتی ہے کیونکہ انہوں نے نظریہ بنانے سے پہلے دوبارہ پیدا کیا، اور بگ کبھی واپس نہیں آتا۔

بڑا ادارہ۔ ایک ادائیگیوں کا پلیٹ فارم وقفے وقفے کے ٹائم آؤٹ دیکھتا ہے جن کی وضاحت کوئی ایک ٹیم نہیں کر سکتی، کیونکہ علامت چیک آؤٹ میں ظاہر ہوتی ہے مگر وجہ تین سروسز دور رہتی ہے۔ آن کال انجینئر ایک ناکام درخواست کو سروس کی حدود کے پار پیچھا کرنے کے لیے تقسیم شدہ ٹریسنگ (باب 9.2) استعمال کرتے ہیں اور ایسی نیچے کی کال ڈھونڈتے ہیں جو ہم زمان بوجھ تلے کبھی کبھار ڈیڈ لاک ہوتی ہے، کلاسیکی ریس کنڈیشن جہاں نتیجہ تھریڈز کے درمیان بدقسمت وقت پر منحصر ہے۔ وہ اسے لوڈ ٹیسٹ سے دوبارہ پیدا کرتے ہیں، ناکام انضمامی ٹیسٹ میں گرفت کرتے ہیں، لاکنگ ٹھیک کرتے ہیں، اور بلا الزام پوسٹ مارٹم (باب 9.3) چلاتے ہیں جو ٹریسنگ اسپین اور الرٹ جوڑتا ہے تاکہ اگلا واقعہ دنوں کے بجائے منٹوں میں پکڑا جائے۔

حکومت۔ فوائد کی ایجنسی اپنا کیس نظام ہوا سے الگ ماحول میں چلاتی ہے جہاں انجینئر پروڈکشن میں ڈی بگر نہیں لگا سکتے اور شہری ڈیٹا اپنے لیپ ٹاپ پر نقل نہیں کر سکتے۔ مصالحت میں حساب کا نقص ابھرتا ہے۔ ٹیم اس سے ڈی بگ کرتی ہے جو ماحول اجازت دیتا ہے: ساختہ لاگز، دوبارہ پیدا ہونے والا بلڈ جسے وہ الگ ٹیسٹ انکلیو میں کھڑا کر سکتے ہیں، اور مصنوعی ریکارڈ جو ناکام کیس دوبارہ بناتے ہیں۔ ہر تشخیصی قدم آڈٹ ٹریل میں ریکارڈ ہوتا ہے، اصلاح ثبوت کے طور پر ناکام-پھر-پاس ہونے والے ٹیسٹ کے ساتھ جاتی ہے، اور بنیادی وجہ کا تجزیہ نئی ریلیز سے پہلے کی جانچ کو کھلاتا ہے۔ چونکہ دوبارہ پیدائش نے مصنوعی ڈیٹا استعمال کیا، کوئی شہری ریکارڈ حد سے باہر نہیں گیا۔

کاروباری جواز: محرکات، ROI اور TCO

نظم و ضبط والی ڈی بگنگ کی واپسی ان انجینئر گھنٹوں میں ناپی جاتی ہے جو اندازے میں ضائع نہیں ہوئے اور ان نقائص میں جو واپس نہیں آئے۔ غیر تشخیص شدہ وقفے وقفے کا بگ سینئر وقت کے دن اور آن کال کے بار بار بالا دست رجوع کھا سکتا ہے؛ پہلے دوبارہ پیدا کرنے کا طریقہ اسے محدود، سونپے جانے کے قابل کام میں بدل دیتا ہے، اور ناکام ٹیسٹ کی عادت اسی نقص کو اگلی سہ ماہی میں دوبارہ بل کرنے سے روکتی ہے۔ بڑے ادارے میں ایک ہی بگ کی دوبارہ ادائیگی نہ کرنے کا مرکب اثر نمایاں ہے، اور یہ براہ راست تبدیلی کی ناکامی کی شرح اور بحالی کے اوسط وقت کو بہتر کرتا ہے جنہیں قیادت پہلے ہی ٹریک کرتی ہے۔

ملکیت کی کل لاگت زیادہ تر تربیت اور ٹولنگ ہے، اور معتدل ہے۔ آپ کو مشترک اصول چاہییں (پہلے دوبارہ پیدا کریں، ایک وقت میں ایک تبدیلی، اصلاح سے پہلے ناکام ٹیسٹ)، ٹول چین میں پہلے سے عام ڈی بگرز اور ٹریسنگ، اور باب 9.2 میں بیان کردہ مشاہدہ پذیری کی سرمایہ کاری۔ بڑی، چھپی لاگت متبادل ہے: توہم پرستی کی ثقافت جہاں انجینئر بے ترتیب تبدیلیاں لگاتے ہیں، علامتوں کا پیوند لگتا اور وہ لوٹ آتی ہیں، اور آن کال کا بوجھ بغیر حد کے بڑھتا ہے۔ اکیلے آن کال کی بے کار مشقت کم کرنا اکثر سرمایہ کاری کا جواز دیتا ہے، اور قیادت کے سامنے دلیل سب سے سادہ طور پر یوں بیان ہوتی ہے: عادتوں اور آلہ کاری میں ایک بار کی لاگت کے بدلے کم دہرائے گئے واقعات اور تیز بحالی۔

ضد نمونے اور خامیاں

بے ترتیب ڈی بگنگ: ایک ساتھ بہت سی چیزیں بدلنا، اس لیے اصلاح بھی آپ کو وجہ کے بارے میں کچھ نہیں سکھاتی۔
دوبارہ پیدا کیے بغیر ٹھیک کرنا: ایسے نقص پر فتح کا اعلان جسے آپ طلب پر ٹرگر کرنے کے قابل کبھی نہ تھے۔
خرابی کے آؤٹ پٹ کو نظر انداز کرنا: ان وجوہات کے بارے میں نظریات بنانا جنہیں اسٹیک ٹریس پہلے ہی رد کر چکا۔
علامت کا پیوند: علامت خاموش کرنا جبکہ بنیادی وجہ زندہ رہ کر لوٹتی ہے۔
پرنٹ بیانات کا پھیلاؤ: کوڈ میں چھوڑا گیا بکھرا ڈی بگ آؤٹ پٹ، مفروضے سے جڑے تجربے کی جگہ شور جوڑتا ہے۔
ریگریشن ٹیسٹ چھوڑنا: بگ ٹھیک کرنا مگر کوئی محافظ نہ چھوڑنا، اس لیے وہ خاموشی سے واپس آ سکتا ہے۔
ناقابل اعتماد ٹیسٹوں کی دوبارہ کوشش: بنیادی ریس کنڈیشن یا ہائزن بگ (ایسا نقص جو مشاہدہ کرنے کی کوشش کرتے ہی بدل یا غائب ہو جاتا ہے) کی ڈی بگنگ کے بجائے دوبارہ کوششوں سے غیر متعینیت چھپانا۔
الزام پر مبنی پوسٹ مارٹم: مصنف کو سزا دینا، جو اس معلومات کو زیر زمین دھکیلتا ہے جس پر ڈی بگنگ منحصر ہے۔

پختگی کا ماڈل

سطح 1، آغاز: ڈی بگنگ انفرادی لوک داستان اور ردعمل ہے۔ انجینئر اندازہ لگاتے، بے ترتیب تبدیلیاں کرتے، اور چیزیں دوبارہ چلاتے ہیں۔ بگ علامت پر ٹھیک ہوتے ہیں، دوبارہ پیدائش شاذ ہے، اور وہی نقائص دہراتے ہیں۔ پروڈکشن بمشکل قابل تشخیص ہے، اور کوئی کسی کو بگ نہیں دے سکتا کیونکہ کوئی کوشش دہرائی نہیں جا سکتی۔
سطح 2، ترقی: کچھ انجینئر قابل اعتماد طور پر دوبارہ پیدا کرتے، اسٹیک ٹریس پڑھتے، اور ڈی بگرز استعمال کرتے ہیں، مگر عمل غیر مستقل ہے اور شخص سے شخص اور ٹیم سے ٹیم بدلتا ہے۔ لاگنگ موجود ہے مگر شور والی اور غیر منظم۔ اصلاحات کبھی کبھار ناکام ٹیسٹ کے ساتھ جاتی ہیں، اکثر نہیں، اور بنیادی وجہ کا تجزیہ صرف تب ہوتا ہے جب کوئی اصرار کرے۔
سطح 3، معیار بندی: پہلے دوبارہ پیدا کرنا، بائنری تلاش سے علیحدگی، ایک وقت میں ایک تبدیلی، اور اصلاح سے پہلے ناکام ٹیسٹ دستاویزی ٹیم اصول ہیں جو پورے ادارے میں نافذ ہیں۔ دو حصے کرنا اور ڈیلٹا ڈی بگنگ سے گھٹانا عام عمل ہیں۔ پروڈکشن میں ساختہ لاگنگ اور ٹریسنگ (باب 9.2) ہے، اور بلا الزام پوسٹ مارٹم (باب 9.3) ہر فرار شدہ نقص کا معیاری ردعمل ہے۔
سطح 4، انتظام: ڈی بگنگ کا عمل بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ دہرائے گئے نقص کی شرح، تشخیص کا وقت، دوبارہ کھلے ٹکٹوں کی گنتی، اور وہ حصہ جس کی اصلاحیں ریگریشن ٹیسٹ کے ساتھ گئیں فی ٹیم ٹریک اور تال پر ریویو ہوتی ہیں۔ دوبارہ پیدائش اور بنیادی وجہ کی تکمیل کو اچھے ارادوں کے بجائے دروازے سمجھا جاتا ہے، اور بنیادی خط کے مقابل رجحانات ٹولنگ، تربیت اور مشاہدہ پذیری میں سرمایہ کاری کی رہنمائی کرتے ہیں۔
سطح 5، ہم آہنگی: ڈی بگنگ سکھائی جانے والی مہارت ہے جو معیار (باب 2.11) اور واقعہ مینجمنٹ (باب 9.3) سے مربوط ہے، اور پورا چکر مسلسل ڈھلتا ہے۔ مشاہدہ پذیری اس طرح ڈیزائن کی گئی ہے کہ زیادہ تر پروڈکشن بگ ڈی بگر کے بغیر قابل تشخیص ہیں، ہر حل شدہ بگ ریگریشن سوٹ کو مضبوط کرتا ہے، اور بنیادی وجہ کے نتائج جلد پتہ لگانے کو کھلاتے ہیں تاکہ نقص کی اقسام دوبارہ تشخیص کے بجائے روکی جائیں۔ ادارہ نظاموں اور ناکامی کے طریقوں کے ارتقا کے ساتھ محنت کا توازن بدلتا ہے، اور دہرائے گئے نقص کی شرح گرتی رہتی ہے۔

بحث کے لیے خیالات

کسی نے کوڈ بدلنے سے پہلے آپ کے حالیہ بگز کا کتنا حصہ قابل اعتماد طور پر دوبارہ پیدا کیا گیا، اور یہ حصہ آپ کے طریقے کے بارے میں کیا بتاتا ہے؟
جب ریگریشن ظاہر ہو تو کیا آپ کی ٹیم دو حصے کرنے تک پہنچتی ہے، یا کوڈ ہاتھ سے پڑھتی ہے جب تک کوئی نہ دیکھ لے؟
آج آپ کا پروڈکشن نظام کتنا قابل تشخیص ہے، اور جو ناکامی پہلے ہو چکی اس کے بارے میں آپ کیا گرفت میں لینا چاہتے تھے؟
کیا آپ کی اصلاحات مسلسل ناکام-پھر-پاس ٹیسٹ کے ساتھ جاتی ہیں، اور اگر نہیں تو وہ نظم و ضبط کہاں ٹوٹتا ہے؟
آپ ناقابل اعتماد ٹیسٹوں کو کیسے سنبھالتے ہیں: غیر متعینیت کی ڈی بگنگ، یا اسے دوبارہ کوششوں سے ڈھانپنا؟
کیا ڈی بگنگ نئے انجینئروں کو سوچ سمجھ کر سکھائی جاتی ہے، یا انہیں لوک داستان خود بخود جذب کرنے کے لیے چھوڑ دیا جاتا ہے؟

اہم نکات

ڈی بگنگ مفروضوں کی جانچ ہے: قابل اعتماد طور پر دوبارہ پیدا کریں، خرابی اور اسٹیک ٹریس پڑھیں، پھر اسکین کرنے کے بجائے بائنری تلاش اور دو حصے کرنے سے الگ کریں۔
نقص کو کم سے کم دوبارہ پیدا ہونے والی مثال تک گھٹائیں، بڑے ان پٹس کے لیے ڈیلٹا ڈی بگنگ سے، کیونکہ ہر ہٹایا گیا عنصر رد کی گئی وجہ ہے۔
ٹول کو نقص سے ملائیں: پروڈکشن اور تقسیم شدہ نظاموں کے لیے آلہ کاری اور ٹریسنگ (باب 9.2)، مقامی تحقیق کے لیے انٹرایکٹو ڈی بگرز۔
ٹھیک کرنے سے پہلے نقص کو گرفت میں لینے والا ناکام ٹیسٹ لکھیں، تاکہ اصلاح ثابت ہو اور نقص کے خلاف ہمیشہ کے لیے حفاظت ہو (باب 2.4)۔
بنیادی وجہ ڈھونڈیں اور ہٹائیں، بلا الزام پوسٹ مارٹم (باب 9.3) چلائیں، اور ڈی بگنگ کو سیکھنے کی مہارت سمجھیں، لوک داستان نہیں۔
ایک وقت میں ایک چیز بدلیں؛ بے ترتیب تبدیلیاں اور علامت کے پیوند شواہد تباہ کرتے اور بگ کو واپس بلاتے ہیں۔

حوالہ جات اور مزید مطالعہ

David J. Agans, Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
Andreas Zeller, Why Programs Fail: A Guide to Systematic Debugging
Andreas Zeller and Ralf Hildebrandt, “Simplifying and Isolating Failure-Inducing Input” (the delta debugging algorithm)
Brian W. Kernighan and Rob Pike, The Practice of Programming (chapter on debugging)
Andrew Hunt and David Thomas, The Pragmatic Programmer (the chapters on debugging and assertions)
Steve McConnell, Code Complete: A Practical Handbook of Software Construction (the debugging chapter)
John Regehr, “Reducers Are Fuzzers” and related writing on test-case reduction
Charity Majors, Liz Fong-Jones, and George Miranda, Observability Engineering (debugging production with high-cardinality telemetry and tracing)
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (blameless postmortems and production debugging)