2.15 ডিবাগিং ও সমস্যা নিরসন

পরিচিতি ও প্রেরণা

ডিবাগিং হলো একটি সিস্টেম কেন এমন কিছু করে যা তার করা উচিত নয়, তা খুঁজে বের করার শৃঙ্খলাবদ্ধ কাজ, আর সমস্যা নিরসন হলো সময়ের চাপে একটি চলমান প্রোডাকশন সিস্টেমের ওপর প্রয়োগ করা একই দক্ষতা। দুটিই ত্রুটির ওপর প্রয়োগ করা বৈজ্ঞানিক পদ্ধতি: আপনি একটি বিস্ময়কর আচরণ পর্যবেক্ষণ করেন, তার কারণ সম্পর্কে একটি অনুমান গঠন করেন, তা নিশ্চিত বা খণ্ডন করবে এমন একটি পরীক্ষা নকশা করেন, এবং আপনার আন্দাজ নয়, প্রমাণকে বলতে দেন কী বদলাবেন। এভাবে করলে ডিবাগিং একটি শেখা-যায়, শেখানো-যায় প্রকৌশল দক্ষতা। লোককথা হিসেবে করলে তা কুসংস্কারে পরিণত হয়: এলোমেলো লাইন বদলানো, সার্ভার পুনরায় চালু করা এবং আশা করা।

বড় দলের জন্য পার্থক্য ব্যয়বহুল। একটি কঠিন ত্রুটি কয়েকটি সার্ভিস জুড়ে ইঞ্জিনিয়ারদের টেনে আনতে, অন-কলের ঘণ্টা খেয়ে ফেলতে এবং একটি রিলিজ থামিয়ে দিতে পারে। প্রত্যেকে সহজাত বোধে ডিবাগ করলে সেই পরিশ্রম চক্রবৃদ্ধি হয় না, কারণ কেউ পুনরুৎপাদন বা ব্যাখ্যা করতে পারে না অন্যরা কী চেষ্টা করেছেন। দল যখন একটি পদ্ধতি ভাগ করে (আগে পুনরুৎপাদন, অনুসন্ধানে বিচ্ছিন্ন করা, ত্রুটিটি একটি ব্যর্থ টেস্টে ধরা, তারপর সারানো), তখন একই পরিশ্রম পুনরাবৃত্তিযোগ্য প্রক্রিয়া ও ক্রমবর্ধমান রিগ্রেশন স্যুটে পরিণত হয়। ডিবাগিং টেস্টিং কৌশল (অধ্যায় 2.4), সফটওয়্যারের গুণমান (অধ্যায় 2.11) এবং কোডকে প্রথম থেকেই নির্ণয়-যোগ্য করা নির্মাণ অভ্যাসের (অধ্যায় 2.9) সঙ্গে আঁটসাঁটভাবে যুক্ত।

এন্টারপ্রাইজ ও সরকারি পরিবেশে ঝুঁকি বাড়ে। এন্টারপ্রাইজ ত্রুটি সার্ভিস ও দলের সীমানা পেরোয়, তাই উপসর্গ দেখা মানুষটি কদাচিৎ কারণের মালিক। সরকারি সিস্টেম এমন সীমাবদ্ধতা যোগ করে যা বেশিরভাগ ইঞ্জিনিয়ার কখনো দেখেননি: এয়ার-গ্যাপড বা সীমিত পরিবেশ যেখানে আপনি প্রোডাকশনে ডিবাগার জুড়তে পারেন না, পুনরুৎপাদনযোগ্য বিল্ড যা সামগ্রী থেকে নির্ণয় করতে হবে, এবং অডিট ট্রেইল যা লিপিবদ্ধ করতে হবে আপনি কী বদলেছেন ও কেন। তিনটিতেই লক্ষ্য এক: অনুমানের জায়গায় প্রমাণ।

মূল নীতিসমূহ

• তত্ত্ব দেওয়ার আগে পুনরুৎপাদন করুন। যে ত্রুটি আপনি চাহিদামতো ঘটাতে পারেন না তা একটি গুজব, ত্রুটি নয়।
• ডিবাগিং অনুমান পরীক্ষা। আপনি যা বিশ্বাস করেন বলুন, তারপর সবচেয়ে সস্তা পরীক্ষা নকশা করুন যা আপনাকে ভুল প্রমাণ করতে পারে।
• আগে ত্রুটি ও স্ট্যাক ট্রেস পড়ুন। সিস্টেম সাধারণত একটি লাইন বদলানোর আগেই বলে কোথায় ভেঙেছে।
• সমস্যার জায়গা অনুসন্ধান করুন, স্ক্যান করবেন না। ওপর থেকে নিচে পড়ার বদলে প্রতিটি ধাপে সন্দেহজনক অঞ্চল অর্ধেক করুন।
• ন্যূনতমে কমান। কেস ছেঁটে ফেলুন যতক্ষণ না কেবল অপরিহার্য ট্রিগার থাকে।
• একবারে একটি পরিবর্তন। এলোপাতাড়ি সম্পাদনা সেই প্রমাণ নষ্ট করে, যা বলত কোন পরিবর্তন গুরুত্বপূর্ণ ছিল।
• সারানোর আগে ত্রুটিটি একটি ব্যর্থ টেস্টে ধরুন। সমাধান কেবল তখনই প্রমাণিত যখন সেই টেস্ট সবুজ হয় এবং সবুজ থাকে।
• নিকটতম উপসর্গ নয়, মূল কারণ খুঁজুন। উপসর্গ লুকানো প্যাচ ত্রুটিকে ফিরে আসতে ছেড়ে দেয়।

সুপারিশ

কিছু বদলানোর আগে ত্রুটিটি নির্ভরযোগ্যভাবে পুনরুৎপাদন করুন

আপনার প্রথম কাজ একটি নির্ভরযোগ্য পুনরুৎপাদন: ধাপের একটি সেট বা স্বয়ংক্রিয় কেস, যা চাহিদামতো ত্রুটিটি ঘটায়। এটি ছাড়া আপনি প্রকৃত সমাধান ও কাকতালীয়তার পার্থক্য বলতে পারেন না, কারণ আপনি কখনো নিয়ন্ত্রণ না করা কারণে উপসর্গ আসতে-যেতে পারে। ইনপুট, পরিবেশ, সংস্করণ ও সময় নির্দিষ্ট করুন। ত্রুটি বিরতিহীন হলে সেই লুকানো চলকটি খুঁজুন যা তাকে দেখা দেওয়ায় (একটি নির্দিষ্ট ডেটা রেকর্ড, ঘড়ির সীমানা, একসঙ্গে অনুরোধ) যতক্ষণ না পুনরুৎপাদন নির্ভরযোগ্য হয়। একটি নির্ভরযোগ্য পুনরুৎপাদন ডিবাগিংয়ের একক সবচেয়ে মূল্যবান সামগ্রী, কারণ এরপর সবকিছু মাপযোগ্য হয়ে ওঠে।

কোডে হাত দেওয়ার আগে ত্রুটি, লগ ও স্ট্যাক ট্রেস পড়ুন

একটি তত্ত্ব গঠনের আগে সিস্টেম আপনাকে ইতিমধ্যে যা বলেছে তা পড়ুন। স্ট্যাক ট্রেস (ব্যর্থতার মুহূর্তে কল-শৃঙ্খলের নথি) সাধারণত ফাইল, লাইন ও ব্যর্থ হওয়া ক্রমের নাম দেয়। এক্সেপশন বার্তা, তার চারপাশের লগ লাইন এবং পরিসরের মান আপনি কিছু বদলানোর আগেই অনুসন্ধান সংকুচিত করে। ইঞ্জিনিয়াররা সেই কারণ নিয়ে তত্ত্ব দিয়ে ঘণ্টা নষ্ট করেন, যা ট্রেসব্যাক প্রথম লাইনেই বাতিল করেছে। ত্রুটির আউটপুটকে প্রথম সাক্ষী ভাবুন, সতর্কভাবে ও সম্পূর্ণ পড়ুন, তারপরই ঠিক করুন কী তদন্ত করবেন।

সমস্যার জায়গার বাইনারি অনুসন্ধানে বিচ্ছিন্ন করুন

কোড ওপর থেকে নিচে স্ক্যান করবেন না। অনুসন্ধান করুন। বাইনারি অনুসন্ধান ব্যবহার করুন: এমন একটি বিন্দু খুঁজুন যেখানে অবস্থা এখনো ভালো এবং এমন একটি যেখানে ইতিমধ্যে খারাপ, তারপর মধ্যবিন্দু যাচাই করুন, এবং পুনরাবৃত্তি করুন, প্রতিবার সন্দেহজনক অঞ্চল অর্ধেক করে। এতে এক হাজার লাইনের অনুসন্ধান দশটি প্রশ্নে নামে। রিগ্রেশন কমিটের একটি পরিসর জুড়ে দেখা দিলে ইতিহাসে একই ধারণা প্রয়োগ করুন বাইসেকশনে: git bisect কমিট পরিসর হেঁটে যায়, আর আপনি প্রতিটি সংশোধন ভালো বা খারাপ চিহ্নিত করেন যতক্ষণ না ত্রুটিটি যে পরিবর্তন এনেছে তার ঠিক নাম পায়। ভালো-বা-খারাপ পরীক্ষা স্বয়ংক্রিয় করুন, আর বাইসেকশন নিজেই চলে।

একটি ন্যূনতম পুনরুৎপাদনযোগ্য উদাহরণে কমান

ত্রুটি ঘটাতে পারলে তা ছোট করুন। একটি ন্যূনতম পুনরুৎপাদনযোগ্য উদাহরণ হলো ক্ষুদ্রতম ইনপুট ও কোড-পথ যা এখনো ব্যর্থ হয়: ডেটা, ফিচার ও ধাপ সরান যতক্ষণ না আরও সরালে ত্রুটিটি উধাও হয়। কমানো ব্যস্ততা নয়; আপনার সরানো প্রতিটি উপাদান একটি বাতিল করা কারণ, তাই ন্যূনতম কেস প্রায়ই সরাসরি ত্রুটির দিকে নির্দেশ করে। ইনপুট বড় বা কাঠামোবদ্ধ হলে ডেল্টা ডিবাগিং দিয়ে ছোট করা স্বয়ংক্রিয় করুন, একটি অ্যালগরিদম যা ন্যূনতম ব্যর্থ উপসেট খুঁজতে ব্যর্থ ইনপুটের টুকরো পদ্ধতিগতভাবে সরায়। একটি ছোট, স্বয়ংসম্পূর্ণ পুনরুৎপাদন আরেকটি দলের হাতে দেওয়ার সর্বোত্তম সম্ভাব্য ত্রুটি-প্রতিবেদনও।

লগ দিয়ে যন্ত্রসজ্জিত করুন, তারপর ইন্টারঅ্যাক্টিভ ডিবাগার ব্যবহার করুন

টুলকে ত্রুটির সঙ্গে মেলান। লগিং ও লক্ষ্যভেদী যন্ত্রসজ্জা সবচেয়ে ভালো যখন আপনাকে সময়ের সঙ্গে, প্রসেস জুড়ে, বা থামাতে পারেন না এমন পরিবেশে আচরণ দেখতে হয়। ইন্টারঅ্যাক্টিভ ডিবাগার, যা আপনাকে ব্রেকপয়েন্ট বসাতে, লাইন ধরে ধরে ধাপে চলতে এবং জীবন্ত অবস্থা পরিদর্শন করতে দেয়, সবচেয়ে ভালো যখন আপনি স্থানীয়ভাবে কোড চালাতে পারেন এবং একটি একক এক্সিকিউশন ঘনিষ্ঠভাবে দেখতে হয়। যন্ত্রসজ্জা যোগ করুন একটি অনুমানের সঙ্গে বাঁধা সুচিন্তিত পরীক্ষা হিসেবে, ছড়ানো প্রিন্ট স্টেটমেন্ট হিসেবে নয়, এবং ত্রুটি সমাধান হলে তা সরান বা স্থায়ী কাঠামোবদ্ধ লগিংয়ে উন্নীত করুন। প্রোডাকশনে অবজার্ভেবিলিটি-চালিত ডিবাগিংয়ের ওপর ঝুঁকুন: উচ্চ-কার্ডিনালিটি ইভেন্ট ও বিতরিত ট্রেসিং (অধ্যায় 9.2) আপনাকে অনেক সার্ভিস জুড়ে একটি অনুরোধ অনুসরণ করতে দেয়, যা প্রায়ই একটি বিতরিত সিস্টেম ডিবাগ করার একমাত্র উপায় যাতে আপনি ডিবাগার জুড়তে পারেন না।

সারানোর আগে ত্রুটিটি ধরা একটি ব্যর্থ টেস্ট লিখুন

সমাধান লেখার আগে এমন একটি টেস্ট লিখুন যা ত্রুটির কারণে ব্যর্থ হয়। এটি একসঙ্গে তিনটি কাজ করে: প্রমাণ করে আপনি সত্যিই কারণ বোঝেন, ঠিক সংজ্ঞায়িত করে “সারানো” মানে কী, এবং স্থায়ী প্রহরী হয়ে ওঠে। তারপর সমাধান করুন এবং টেস্ট সবুজ হতে দেখুন। সেই টেস্ট এখন রিগ্রেশন টেস্টিং প্রহরী হিসেবে আপনার স্যুটে যোগ দেয়, যাতে একই ত্রুটি অলক্ষ্যে ফিরতে না পারে। এই চর্চা ডিবাগিংকে সরাসরি আপনার টেস্টিং কৌশলের (অধ্যায় 2.4) সঙ্গে যুক্ত করে: আপনার সমাধান করা প্রতিটি কঠিন ত্রুটি স্যুটকে পাওয়ার চেয়ে শক্তিশালী রেখে যায়, এবং একটি অস্থির টেস্ট একই আচরণ পায় (অনির্ধারিততা পুনরুৎপাদন করুন, তারপর তার বিরুদ্ধে রক্ষা করুন), রিট্রাই অ্যানোটেশনের বদলে।

মূল কারণ খুঁজুন এবং বিশ্লেষণ দোষারোপহীন রাখুন

উপসর্গ সারানো ত্রুটি সারানো নয়। ব্যর্থতাকে তার প্রকৃত উৎসে অনুসরণ করুন, প্রতিটি স্তরে কেন জিজ্ঞেস করে যতক্ষণ না এমন কারণে পৌঁছান যা আপনি মুখোশ পরানোর বদলে সরাতে পারেন। প্রোডাকশনে পৌঁছানো ত্রুটির জন্য ঘটনা ব্যবস্থাপনার (অধ্যায় 9.3) অংশ হিসেবে একটি দোষারোপহীন মূল-কারণ বিশ্লেষণ চালান: ত্রুটিটি পাঠাতে ও টিকে থাকতে দেওয়া ব্যবস্থা ও প্রক্রিয়ার শর্তের ওপর মনোযোগ দিন, লাইনটি লেখা ব্যক্তির ওপর কখনো নয়। দোষারোপ তথ্যকে মাটির নিচে পাঠায়, আর ডিবাগিং চলে তথ্যে। ফলাফল একটি সমাধান এবং পরের বার সেই শ্রেণির ত্রুটি আগে ধরার পদ্ধতিতে পরিবর্তন, দুটিই।

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতি	সুবিধা	অসুবিধা
লগিং ও যন্ত্রসজ্জা	প্রোডাকশন ও বিতরিত সিস্টেমে কাজ করে; সময়ের সঙ্গে আচরণ ধরে	গোলমাল, খরচ ও লগের ছড়াছড়ি; সময়-সংক্রান্ত ত্রুটিকে বিঘ্নিত করতে পারে
ইন্টারঅ্যাক্টিভ ডিবাগার	নির্ভুল, জীবন্ত অবস্থা পরিদর্শন; স্থানীয় ত্রুটিতে দ্রুত	সীমিত বা এয়ার-গ্যাপড প্রোডাকশনে অকেজো; কনকারেন্সি ত্রুটি লুকাতে পারে
আগে-পুনরুৎপাদন শৃঙ্খলা	অনুমানকে পরিমাপে রূপ দেয়; ব্যর্থ টেস্ট সম্ভব করে	অগ্রিম ধীর; কিছু ত্রুটি সত্যিই ঘটানো কঠিন
বাইনারি অনুসন্ধান ও বাইসেকশন	অপরিচিত কোডেও দ্রুত বিচ্ছিন্নকরণ	নির্ভরযোগ্য ভালো-বা-খারাপ পরীক্ষা লাগে; ত্রুটি পারস্পরিক ক্রিয়া করলে কঠিন
ডেল্টা-ডিবাগিং হ্রাস	বিশাল ইনপুটকে স্বয়ংক্রিয়ভাবে ট্রিগারে ছোট করে	সেটআপ খরচ; ধরে নেয় ব্যর্থতা নির্ধারিত
এখনই উপসর্গ সারানো	চাপের মধ্যে সেবা দ্রুত ফেরায়	মূল কারণ ফিরে আসতে ছাড়ে; ঋণ জমায়

কেন্দ্রীয় টানাপোড়েন গতি বনাম নিশ্চয়তা। একটি প্রোডাকশন ঘটনায় সেবা ফেরাতে আপনাকে আগে রক্তপাত থামাতে হতে পারে (একটি রোলব্যাক বা উপসর্গ প্যাচ), এবং তা বৈধ। ভুল হলো সেখানেই থামা। দুটি কাজ আলাদা করে টানাপোড়েন মেটান: ব্যবহারকারীদের রক্ষা করতে দ্রুত প্রশমন করুন, তারপর ত্রুটিটি বন্ধ গণ্য করার আগে পুনরুৎপাদন করুন, মূল কারণ খুঁজুন এবং রিগ্রেশন প্রহরী যোগ করুন। ফলো-আপ ছাড়া উপসর্গ সমাধান এমন একটি ত্রুটি, যার সঙ্গে আপনি আবার দেখা করতে সম্মত হয়েছেন।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. কেউ একটি কঠিন ত্রুটিতে পড়লে প্রথম কী করেন, এবং তা কি পুনরুৎপাদন নাকি আন্দাজ? সৎ উত্তর প্রকাশ করে আপনার দলের একটি ভাগ করা পদ্ধতি আছে নাকি ঘরভর্তি ব্যক্তিগত লোককথা। মানুষকে তাঁদের শেষ কঠিন ত্রুটি জোরে বর্ণনা করতে বলুন: আগে কি নির্ভরযোগ্য পুনরুৎপাদন পেয়েছিলেন, নাকি কোড বদলানো ও জিনিস পুনরায় চালু করা শুরু করেছিলেন? যে দল আগে পুনরুৎপাদন করে সে ত্রুটি মানুষের মধ্যে হস্তান্তর করতে পারে, কারণ পুনরুৎপাদন সঙ্গে চলে; যে দল আন্দাজ করে সে পারে না, কারণ প্রতিটি চেষ্টা পুনরাবৃত্তি-অযোগ্য। দল বড় হলে এটি আরও গুরুত্বপূর্ণ, কারণ উপসর্গ দেখা মানুষটি ক্রমশ সেই মানুষ নন, যিনি তা সারাতে পারেন। ডিফল্ট আন্দাজ হলে আগে-পুনরুৎপাদনকে রীতিতে একমত হন এবং একটি পরিচ্ছন্ন পুনরুৎপাদনকে একটি ত্রুটি টিকেটের প্রবেশমূল্য করুন।

2. আমরা যে ত্রুটি সারাই তা কি ফিরে আসে, এবং এলে আমরা কি জানতাম? যে ত্রুটি ফিরে আসে তার মূল কারণ কখনো সরানো হয়নি এবং সমাধান কখনো টেস্টে প্রহরীযুক্ত হয়নি। গত ত্রৈমাসিকের ঘটনা ও পুনরায় খোলা টিকেট টেনে গুনুন কতগুলো আগের ত্রুটির পুনরাবৃত্তি বা কাছাকাছি আত্মীয়। প্রতিটি পুনরাবৃত্তি প্রমাণ যে দল উপসর্গ প্যাচ করেছে, ব্যর্থ টেস্ট এড়িয়ে গেছে বা মূল-কারণ বিশ্লেষণ খুব আগে থামিয়েছে। সমাধান একটি নিয়ম: কোনো ত্রুটি বন্ধ নয় যতক্ষণ না পুরোনো আচরণে ব্যর্থ হওয়া একটি টেস্ট নতুন আচরণে উত্তীর্ণ হয় এবং স্যুটে যোগ দেয়। একটি সাম্প্রতিক পুনরাবৃত্ত ত্রুটি আনুন এবং জিজ্ঞেস করুন কোন প্রহরী তা ধরত, কারণ সেই প্রহরীই আপনার অনুপস্থিত জিনিস ছিল।

3. আমরা যেভাবে আমাদের প্রোডাকশন সিস্টেম ছুঁতে অনুমতি পাই তাতে কি আমরা আদৌ সেগুলো ডিবাগ করতে পারি? এন্টারপ্রাইজ এবং বিশেষত সরকারি পরিবেশে আপনি প্রায়ই ডিবাগার জুড়তে পারেন না, প্রকৃত ডেটা দিয়ে পুনরুৎপাদন করতে পারেন না, এবং অডিট ট্রেইল ছাড়া একটি চলমান সিস্টেম বদলাতে পারেন না। আপনার একমাত্র ডিবাগিং কৌশল যদি স্থানীয় ইন্টারঅ্যাক্টিভ ডিবাগার হয়, তাহলে আপনি ঠিক সেখানে অন্ধ যেখানে কঠিনতম ত্রুটিগুলো বাস করে। জিজ্ঞেস করুন একটি প্রোডাকশন ব্যর্থতা আসলে কী প্রমাণ রেখে যায়: কাঠামোবদ্ধ লগ, বিতরিত ট্রেস (অধ্যায় 9.2), কোর ডাম্প বা পুনরুৎপাদনযোগ্য বিল্ড সামগ্রী। এখনই ঠিক করুন ডিফল্টে কী ধরতে হবে যাতে ভবিষ্যৎ ঘটনা নির্ণয়-যোগ্য হয়, কারণ ইতিমধ্যে ঘটে যাওয়া ব্যর্থতায় আপনি যন্ত্রসজ্জা যোগ করতে পারেন না। নিয়ন্ত্রিত পরিবেশে নিশ্চিত করুন একই ট্রেইল আপনার অডিট বাধ্যবাধকতাও পূরণ করে।

4. একটি প্রোডাকশন ঘটনা যখন আমাদের দ্রুত রক্তপাত থামাতে বাধ্য করে, তখন পরে মূল কারণ খুঁজে পাওয়া কীভাবে নিশ্চিত করব? ঘটনার সময় রোলব্যাক বা উপসর্গ প্যাচ ব্যবহারকারীদের রক্ষা করার সঠিক প্রথম পদক্ষেপ, কিন্তু বিপদ হলো সেবা ফিরে আসামাত্র টিকেট বন্ধ হয় এবং অন্তর্নিহিত ত্রুটি কখনো নির্ণয় হয় না। বড় দলের জন্য এখানেই ঋণ অদৃশ্যে জমে, কারণ একই শ্রেণির ব্যর্থতা মাসের পর মাস পরে ভিন্ন সার্ভিসে ও ভিন্ন অন-কল ইঞ্জিনিয়ারের কাছে ফিরে আসে। আপনার শেষ কয়েকটি তীব্রতা-এক ঘটনা আনুন এবং প্রতিটি যাচাই করুন: প্রশমনের পর কি পুনরুৎপাদন, মূল-কারণ বিশ্লেষণ ও রিগ্রেশন প্রহরী এসেছিল, নাকি গল্প “সেবা ফিরেছে”-তে শেষ হয়েছিল? একটি সুস্পষ্ট নিয়মে একমত হন যে প্রশমিত ঘটনা খোলা থাকে যতক্ষণ না মূল কারণ বোঝা ও প্রহরীযুক্ত হয়, এবং সেই ফলো-থ্রু কার তার নাম দিন। এন্টারপ্রাইজ ও সরকারি পরিবেশে এটি আপনার ঘটনা-ব্যবস্থাপনা প্রক্রিয়ার (অধ্যায় 9.3) সঙ্গে বাঁধুন, যাতে ঘটনা-পরবর্তী পর্যালোচনা সৌজন্য নয়, একটি আবশ্যক, নিরীক্ষণযোগ্য ধাপ হয়, যা পরবর্তী আগুন লাগলে পিছলে যায় না।

5. ঘটনার পরে আমরা একটি ব্যর্থতার কতটা আসলে পুনর্গঠন করতে পারি, এবং ডিফল্টে কী ধরা হবে তা কে ঠিক করেছিল? ইতিমধ্যে ঘটে যাওয়া ব্যর্থতায় আপনি যন্ত্রসজ্জা যোগ করতে পারেন না, তাই যেকোনো ঘটনার নির্ণয়-যোগ্যতা আগেই ঠিক হয় আপনার বাছা লগ, ট্রেস, মেট্রিক ও ডাম্প দিয়ে। প্রতিদ্বন্দ্বী বিবেচনা খরচ ও গোলমাল: উচ্চ-কার্ডিনালিটি ইভেন্ট ও পূর্ণ ট্রেসিং বিনামূল্যে নয়, আর অতি-লগিং সংকেত চাপা দেয়, সঙ্গে সংরক্ষণ বাড়ায় এবং নিয়ন্ত্রিত প্রেক্ষাপটে আপনার ডেটা-ধারণের ঝুঁকিও। একটি প্রকৃত সাম্প্রতিক ঘটনা আনুন এবং জিজ্ঞেস করুন তা কী প্রমাণ রেখে গেছে, তারপর পিছিয়ে কাজ করুন আপনি কী ধরে রাখতে চাইতেন এবং তা রাখতে কত খরচ। কোন সংকেত ডিফল্টে চালু বনাম নমুনা-করা বা ঐচ্ছিক তা সুচিন্তিতভাবে ঠিক করুন এবং সেই সিদ্ধান্ত লিপিবদ্ধ করুন যাতে তা দুর্ঘটনা নয়, নীতি হয়। একটি এন্টারপ্রাইজ বা সরকারি সিস্টেমে সেই অবজার্ভেবিলিটি বাজেটের জন্য কে জবাবদিহিযোগ্য এবং ধরা ট্রেইল গোপনীয়তা ও ডেটা-বাসস্থানের বাধ্যবাধকতা মেটায় কি না তাও যোগ করুন।

6. আমরা কি ডিবাগিংকে শেখানো, মাপযোগ্য দক্ষতা হিসেবে দেখি, নাকি নতুন ইঞ্জিনিয়াররা আপনা-আপনি তা আত্মস্থ করেন? ডিবাগিং শেখা-যায়, তবু বেশিরভাগ দল কখনো সুস্পষ্টভাবে তা শেখায় না, তাই জুনিয়ররা কাছাকাছি যে লোককথা পান তাই উত্তরাধিকার পান, আর আগে-পুনরুৎপাদন পদ্ধতি অসমভাবে বা একেবারেই ছড়ায় না। টানাপোড়েন হলো সুচিন্তিত শেখানো (কঠিন ত্রুটিতে পেয়ারিং, ঘটনা-পরবর্তী পর্যবেক্ষণ লেখা, মেট্রিক অনুসরণ) জ্যেষ্ঠ সময় খরচ করে যা সবসময় অন্যত্র দরকারি মনে হয়। আলোচনায় দুটি সংখ্যা আনুন: আপনার পুনরাবৃত্ত-ত্রুটির হার এবং নির্ণয়ের সময়, কারণ মাপতে না পারলে আপনার পদ্ধতি উন্নত হচ্ছে না ক্ষয় হচ্ছে তা বলতে পারবেন না। ভাবুন অনবোর্ডিংয়ে একটি প্রকৃত ডিবাগিং অনুশীলন আছে কি না এবং মূল-কারণের পর্যবেক্ষণ আসলে আগের শনাক্তকরণে জোগান দেয় কি না। বড় বা সরকারি প্রতিষ্ঠানে নথিবদ্ধ, মাপা ডিবাগিং চর্চা প্রকৌশল কঠোরতার প্রমাণও হয়, যা নিরীক্ষক, নিয়ন্ত্রক ও তদারকি সংস্থা ক্রমশ দেখার প্রত্যাশা করে।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। মুষ্টিমেয় ইঞ্জিনিয়ার ও কোনো বাড়তি সময় না নিয়ে আপনার লক্ষ্য ত্রুটিকে পুনরুৎপাদনে সস্তা এবং ভুলে যাওয়া অসম্ভব করা, ভারী প্রক্রিয়া গড়া নয়। git bisect, একটি দ্রুত স্থানীয় পুনরুৎপাদন এবং প্রতিটি সারানো ত্রুটির জন্য একটি ব্যর্থ টেস্টের ওপর ভরসা করুন, কারণ সেই অভ্যাস মিনিটে খরচ হয় এবং আপনি পাঠানোর চেষ্টায় থাকার সময় একই ত্রুটির জন্য আবার দাম দেওয়া ঠেকায়। আনুষ্ঠানিক পোস্টমর্টেম এড়িয়ে যান, কিন্তু রিগ্রেশন টেস্ট কখনো এড়াবেন না: এটি সেই একটি সামগ্রী যা সবসময় কেনার মতো ছোট এবং সবসময় রাখার মতো মূল্যবান।

ছোট ব্যবসা। আপনার সম্ভবত কোনো নিবেদিত নির্ভরযোগ্যতা বা অবজার্ভেবিলিটি বিশেষজ্ঞ নেই এবং টুলিং বাজেট কম, তাই আপনার স্ট্যাক ইতিমধ্যে যা দেয় তা পছন্দ করুন: পাঠযোগ্য স্ট্যাক ট্রেস, কাঠামোবদ্ধ লগ, এবং আপনার কেনা ফ্রেমওয়ার্ক ও হোস্টেড সেবায় ইনবিল্ট ট্রেসিং। নতুন প্ল্যাটফর্ম মূল্যায়নের সময় ওজন করুন তা ব্যর্থতা কতটা নির্ণয়-যোগ্য করে, কারণ যে সস্তা টুল কী ভুল হয়েছে তা লুকায় তা লাইসেন্সে বাঁচানোর চেয়ে অনেক বেশি আন্দাজের সময়ে আপনাকে খরচ করায়। আগে-পুনরুৎপাদন ও একবারে-একটি-পরিবর্তন বিনামূল্যের শৃঙ্খলা, যা সবচেয়ে দ্রুত ফল দেয় যখন কারও হাতে ঘণ্টা নেই।

এন্টারপ্রাইজ। আপনার কঠিন ত্রুটি সার্ভিস ও দলের সীমানা পেরোয়, তাই উপসর্গ দেখা মানুষ কদাচিৎ কারণের মালিক, এবং কোনো ব্যক্তির দক্ষতার চেয়ে একটি ভাগ করা পদ্ধতি বেশি গুরুত্বপূর্ণ। দলগুলো জুড়ে আগে-পুনরুৎপাদন, বাইনারি-অনুসন্ধানে বিচ্ছিন্নকরণ, সারানোর আগে ব্যর্থ টেস্ট, এবং দোষারোপহীন পোস্টমর্টেম প্রমিত করুন, এবং বিতরিত ট্রেসিংয়ে (অধ্যায় 9.2) বিনিয়োগ করুন যাতে একটি অনুরোধ সার্ভিস জুড়ে অনুসরণ করা যায়। ডিবাগিংকে মাপা সামর্থ্য হিসেবে পরিচালনা করুন: পুনরাবৃত্ত-ত্রুটির হার ও নির্ণয়ের সময় অনুসরণ করুন, এবং মূল-কারণের পর্যবেক্ষণ আগের শনাক্তকরণে ফিরিয়ে দিন, যাতে একই শ্রেণির ব্যর্থতা আপনার সার্ভিস মানচিত্রে ঘুরে না বেড়ায়।

সরকার। ক্রয়-বিধি, সীমিত পরিবেশ এবং জনগণের কাছে জবাবদিহি আপনি আদৌ কীভাবে ডিবাগ করতে পারেন তা আকার দেয়। আপনি প্রায়ই প্রোডাকশনে ডিবাগার জুড়তে বা নাগরিক ডেটা ল্যাপটপে কপি করতে পারেন না, তাই যা অনুমোদিত তা থেকে নির্ণয়ের জন্য নকশা করুন: পুনরুৎপাদনযোগ্য বিল্ড, একটি বিচ্ছিন্ন এনক্লেভে কৃত্রিম রেকর্ড, এবং ডিফল্টে ধরা কাঠামোবদ্ধ লগ ও ট্রেস। প্রতিটি নির্ণয় ধাপ ও প্রতিটি পরিবর্তন অডিট ট্রেইলে লিপিবদ্ধ করুন, এবং দাবি করুন যে বিক্রেতারা সরবরাহকারীর কথার ওপর নির্ভর না করে স্বাধীনভাবে ব্যর্থতা তদন্ত করতে যথেষ্ট টেলিমেট্রি ও বিল্ড পুনরুৎপাদনযোগ্যতা প্রকাশ করবে।

উদাহরণ

স্টার্টআপ। চারজন ইঞ্জিনিয়ারের একটি দল দেখে ব্যবহারকারীদের একটি ভগ্নাংশের জন্য চেকআউট ব্যর্থ হচ্ছে, কিন্তু টেস্টিংয়ে কখনো নয়। আন্দাজের বদলে একজন ইঞ্জিনিয়ার ঠিক ব্যর্থ অনুরোধের পেলোড পুনরায় চালিয়ে একটি নির্ভরযোগ্য পুনরুৎপাদন ধরেন, তারপর যে স্ট্যাক ট্রেস তিনি উপেক্ষা করছিলেন তা পড়েন, যা একটি তারিখ-পার্সিং কলের দিকে নির্দেশ করে। সপ্তাহের কমিট জুড়ে একটি দ্রুত git bisect একটি তারিখ লাইব্রেরি বদলানো পরিবর্তনের নাম দেয়। তাঁরা আপত্তিকর টাইমস্ট্যাম্পসহ একটি ব্যর্থ টেস্ট লেখেন, পার্সার সারান, টেস্ট সবুজ হতে দেখেন এবং তা স্যুটে রাখেন। পুরো তদন্তে একটি বিকেল লাগে কারণ তাঁরা তত্ত্ব দেওয়ার আগে পুনরুৎপাদন করেছিলেন, এবং ত্রুটিটি কখনো ফিরে আসে না।

এন্টারপ্রাইজ। একটি পেমেন্ট প্ল্যাটফর্ম বিরতিহীন টাইমআউট দেখে যা কোনো একক দল ব্যাখ্যা করতে পারে না, কারণ উপসর্গ চেকআউটে দেখা যায় কিন্তু কারণ তিনটি সার্ভিস দূরে বাস করে। অন-কল ইঞ্জিনিয়াররা সার্ভিসের সীমানা জুড়ে একটি ব্যর্থ অনুরোধ অনুসরণ করতে বিতরিত ট্রেসিং (অধ্যায় 9.2) ব্যবহার করেন এবং একটি নিম্নধারার কল খুঁজে পান যা একসঙ্গে লোডে মাঝেমধ্যে ডেডলক হয়, একটি ক্লাসিক রেস কন্ডিশন, যেখানে ফল থ্রেডগুলোর মধ্যে দুর্ভাগ্যজনক সময়ের ওপর নির্ভর করে। তাঁরা একটি লোড টেস্ট দিয়ে তা পুনরুৎপাদন করেন, একটি ব্যর্থ ইন্টিগ্রেশন টেস্টে ধরেন, লকিং সারান, এবং একটি দোষারোপহীন পোস্টমর্টেম (অধ্যায় 9.3) চালান যা একটি ট্রেসিং স্প্যান ও অ্যালার্ট যোগ করে, যাতে পরবর্তী ঘটনা দিনে নয়, মিনিটে ধরা পড়ে।

সরকার। একটি সুবিধা সংস্থা তার কেস সিস্টেম একটি এয়ার-গ্যাপড পরিবেশে চালায়, যেখানে ইঞ্জিনিয়াররা প্রোডাকশনে ডিবাগার জুড়তে পারেন না এবং নাগরিক ডেটা ল্যাপটপে কপি করতে পারেন না। মিলকরণে একটি গণনার ত্রুটি দেখা দেয়। দল পরিবেশ যা অনুমতি দেয় তা থেকে ডিবাগ করে: কাঠামোবদ্ধ লগ, একটি পুনরুৎপাদনযোগ্য বিল্ড যা তারা একটি বিচ্ছিন্ন টেস্ট এনক্লেভে দাঁড় করাতে পারে, এবং ব্যর্থ কেস পুনরায় তৈরি করা কৃত্রিম রেকর্ড। প্রতিটি নির্ণয় ধাপ অডিট ট্রেইলে লিপিবদ্ধ হয়, সমাধান প্রমাণ হিসেবে ব্যর্থ-তারপর-উত্তীর্ণ টেস্টসহ যায়, এবং মূল-কারণ বিশ্লেষণ একটি নতুন প্রি-রিলিজ পরীক্ষায় জোগান দেয়। পুনরুৎপাদন কৃত্রিম ডেটা ব্যবহার করেছিল বলে কোনো নাগরিক রেকর্ড কখনো সীমানা ছেড়ে যায়নি।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

শৃঙ্খলাবদ্ধ ডিবাগিংয়ের প্রতিদান মাপা হয় আন্দাজে নষ্ট না হওয়া ইঞ্জিনিয়ার-ঘণ্টায় এবং ফিরে না আসা ত্রুটিতে। একটি অনির্ণীত বিরতিহীন ত্রুটি জ্যেষ্ঠ সময়ের দিনের পর দিন এবং পুনরাবৃত্ত অন-কল উত্তরণ খেয়ে ফেলতে পারে; আগে-পুনরুৎপাদন পদ্ধতি তাকে একটি সীমিত, হস্তান্তরযোগ্য কাজে পরিণত করে, আর ব্যর্থ-টেস্ট অভ্যাস একই ত্রুটিকে আগামী ত্রৈমাসিকে আবার বিল করা ঠেকায়। একটি বড় প্রতিষ্ঠান জুড়ে একই ত্রুটির জন্য কখনো আবার দাম না দেওয়ার চক্রবৃদ্ধি প্রভাব উল্লেখযোগ্য, এবং তা সরাসরি নেতৃত্বের ইতিমধ্যে অনুসরণ করা পরিবর্তন-ব্যর্থতার হার ও পুনরুদ্ধারের গড় সময় উন্নত করে।

মালিকানার মোট খরচ মূলত প্রশিক্ষণ ও টুলিং, এবং তা মাঝারি। আপনার দরকার ভাগ করা রীতি (আগে পুনরুৎপাদন, একবারে একটি পরিবর্তন, সারানোর আগে একটি ব্যর্থ টেস্ট), টুলচেইনে ইতিমধ্যে সাধারণ ডিবাগার ও ট্রেসিং, এবং অধ্যায় 9.2-এ বর্ণিত অবজার্ভেবিলিটি বিনিয়োগ। বড়, লুকানো খরচ হলো বিকল্প: কুসংস্কারের সংস্কৃতি যেখানে ইঞ্জিনিয়াররা এলোপাতাড়ি পরিবর্তন প্রয়োগ করেন, উপসর্গ প্যাচ করা হয় আর ফিরে আসে, এবং অন-কলের বোঝা সীমাহীন বাড়ে। শুধু অন-কলের একঘেয়ে খাটুনি কমানোই প্রায়ই বিনিয়োগকে যুক্তিসঙ্গত করে, এবং নেতৃত্বের কাছে যুক্তি সবচেয়ে সরলভাবে বলা যায়: অভ্যাস ও যন্ত্রসজ্জায় একবারের খরচে কম পুনরাবৃত্ত ঘটনা ও দ্রুত পুনরুদ্ধার।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• এলোপাতাড়ি ডিবাগিং: একসঙ্গে অনেক কিছু বদলানো, ফলে একটি সমাধানও কারণ সম্পর্কে কিছু শেখায় না।
• পুনরুৎপাদন ছাড়া সারানো: যে ত্রুটি আপনি কখনো চাহিদামতো ঘটাতে পারেননি তার ওপর জয় ঘোষণা করা।
• ত্রুটির আউটপুট উপেক্ষা: স্ট্যাক ট্রেস ইতিমধ্যে বাতিল করা কারণ নিয়ে তত্ত্ব দেওয়া।
• উপসর্গ প্যাচ করা: উপসর্গ দমন করা, যখন মূল কারণ ফিরে আসতে টিকে থাকে।
• প্রিন্ট-স্টেটমেন্টের ছড়াছড়ি: অনুমানের সঙ্গে বাঁধা পরীক্ষার বদলে কোডে ফেলে রাখা ছড়ানো ডিবাগ আউটপুট, যা গোলমাল যোগ করে।
• রিগ্রেশন টেস্ট এড়ানো: ত্রুটি সারানো কিন্তু কোনো প্রহরী না রেখে, ফলে তা নিঃশব্দে ফিরতে পারে।
• অস্থির টেস্ট রিট্রাই: অন্তর্নিহিত রেস কন্ডিশন বা হাইজেনবাগ, যে ত্রুটি আপনি পর্যবেক্ষণ করতে চাইলেই বদলে যায় বা উধাও হয়, ডিবাগ করার বদলে রিট্রাই দিয়ে অনির্ধারিততা লুকানো।
• দোষারোপ-চালিত পোস্টমর্টেম: রচয়িতাকে শাস্তি দেওয়া, যা ডিবাগিং যে তথ্যের ওপর নির্ভর করে তা মাটির নিচে পাঠায়।

পরিপক্বতা মডেল

• স্তর ১, সূচনা: ডিবাগিং ব্যক্তিগত লোককথা ও প্রতিক্রিয়া। ইঞ্জিনিয়াররা আন্দাজ করেন, এলোপাতাড়ি পরিবর্তন প্রয়োগ করেন এবং জিনিস পুনরায় চালু করেন। ত্রুটি উপসর্গে সারানো হয়, পুনরুৎপাদন বিরল, এবং একই ত্রুটি ফিরে আসে। প্রোডাকশন কদাচিৎ নির্ণয়-যোগ্য, এবং কেউ কোনো ত্রুটি কারও হাতে দিতে পারে না কারণ কোনো চেষ্টাই পুনরাবৃত্তিযোগ্য নয়।
• স্তর ২, বিকাশ: কিছু ইঞ্জিনিয়ার নির্ভরযোগ্যভাবে পুনরুৎপাদন করেন, স্ট্যাক ট্রেস পড়েন এবং ডিবাগার ব্যবহার করেন, কিন্তু চর্চা অসঙ্গত এবং ব্যক্তি ও দল ভেদে ভিন্ন। লগিং আছে কিন্তু গোলমালপূর্ণ ও অকাঠামোবদ্ধ। সমাধান কখনো কখনো ব্যর্থ টেস্টসহ যায়, প্রায়ই নয়, আর মূল-কারণ বিশ্লেষণ ঘটে কেবল কেউ জোর দিলে।
• স্তর ৩, মানসম্মতকরণ: আগে-পুনরুৎপাদন, বাইনারি-অনুসন্ধানে বিচ্ছিন্নকরণ, একবারে একটি পরিবর্তন এবং সারানোর আগে একটি ব্যর্থ টেস্ট নথিবদ্ধ দলের রীতি, প্রতিষ্ঠানজুড়ে বলবৎ। বাইসেকশন ও ডেল্টা-ডিবাগিং হ্রাস সাধারণ চর্চা। প্রোডাকশনে কাঠামোবদ্ধ লগিং ও ট্রেসিং (অধ্যায় 9.2) আছে, এবং দোষারোপহীন পোস্টমর্টেম (অধ্যায় 9.3) পালিয়ে যাওয়া প্রতিটি ত্রুটির প্রমিত সাড়া।
• স্তর ৪, ব্যবস্থাপনা: ডিবাগিং চর্চা ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। পুনরাবৃত্ত-ত্রুটির হার, নির্ণয়ের সময়, পুনরায় খোলা টিকেটের সংখ্যা এবং রিগ্রেশন টেস্টসহ পাঠানো সমাধানের অংশ প্রতি দলে অনুসরণ ও নির্দিষ্ট বিরতিতে পর্যালোচিত হয়। পুনরুৎপাদন ও মূল-কারণ সমাপ্তি শুভ উদ্দেশ্যের বদলে গেট হিসেবে দেখা হয়, এবং ভিত্তিরেখার বিপরীতে প্রবণতা ঠিক করে আপনি টুলিং, প্রশিক্ষণ ও অবজার্ভেবিলিটিতে কোথায় বিনিয়োগ করবেন।
• স্তর ৫, সমন্বয়: ডিবাগিং একটি শেখানো দক্ষতা, গুণমান (অধ্যায় 2.11) ও ঘটনা ব্যবস্থাপনার (অধ্যায় 9.3) সঙ্গে একীভূত, এবং পুরো চক্র নিরন্তর খাপ খাইয়ে নেয়। অবজার্ভেবিলিটি এমনভাবে নকশা করা যে বেশিরভাগ প্রোডাকশন ত্রুটি ডিবাগার ছাড়াই নির্ণয়-যোগ্য, প্রতিটি সমাধান করা ত্রুটি রিগ্রেশন স্যুটকে শক্তিশালী করে, এবং মূল-কারণের পর্যবেক্ষণ আগের শনাক্তকরণে জোগান দেয় যাতে ত্রুটির শ্রেণি পুনরায় নির্ণয়ের বদলে প্রতিরোধ হয়। সিস্টেম ও ব্যর্থতার ধরন বিবর্তিত হলে প্রতিষ্ঠান প্রচেষ্টা পুনর্ভারসাম্যে আনে, এবং পুনরাবৃত্ত-ত্রুটির হার কমতেই থাকে।

আলোচনার ভাবনা

1. আপনার সাম্প্রতিক ত্রুটির কত অংশ কেউ কোড বদলানোর আগে নির্ভরযোগ্যভাবে পুনরুৎপাদন করা হয়েছিল, এবং সেই অংশ আপনার পদ্ধতি সম্পর্কে কী বলে?
2. একটি রিগ্রেশন দেখা দিলে আপনার দল কি বাইসেকশনের কাছে যায়, নাকি কেউ চোখে না পড়া পর্যন্ত হাতে কোড পড়ে?
3. আজ আপনার প্রোডাকশন সিস্টেম কতটা নির্ণয়-যোগ্য, এবং ইতিমধ্যে ঘটে যাওয়া একটি ব্যর্থতা সম্পর্কে আপনি কী ধরে রাখতে চাইতেন?
4. আপনার সমাধান কি ধারাবাহিকভাবে ব্যর্থ-তারপর-উত্তীর্ণ টেস্টসহ যায়, এবং না গেলে সেই শৃঙ্খলা কোথায় ভাঙে?
5. আপনি অস্থির টেস্ট কীভাবে সামলান: অনির্ধারিততা ডিবাগ করে, নাকি রিট্রাই দিয়ে ঢেকে?
6. নতুন ইঞ্জিনিয়ারদের কি সুচিন্তিতভাবে ডিবাগিং শেখানো হয়, নাকি তাঁদের আপনা-আপনি লোককথা আত্মস্থ করতে ছেড়ে দেওয়া হয়?

প্রধান শিক্ষা

• ডিবাগিং অনুমান পরীক্ষা: নির্ভরযোগ্যভাবে পুনরুৎপাদন করুন, ত্রুটি ও স্ট্যাক ট্রেস পড়ুন, তারপর স্ক্যান করার বদলে বাইনারি অনুসন্ধান ও বাইসেকশনে বিচ্ছিন্ন করুন।
• ব্যর্থতাকে একটি ন্যূনতম পুনরুৎপাদনযোগ্য উদাহরণে কমান, বড় ইনপুটের জন্য ডেল্টা ডিবাগিং ব্যবহার করে, কারণ সরানো প্রতিটি উপাদান একটি বাতিল করা কারণ।
• টুলকে ত্রুটির সঙ্গে মেলান: প্রোডাকশন ও বিতরিত সিস্টেমের জন্য যন্ত্রসজ্জা ও ট্রেসিং (অধ্যায় 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 ও Ralf Hildebrandt, “Simplifying and Isolating Failure-Inducing Input” (ডেল্টা ডিবাগিং অ্যালগরিদম)
• Brian W. Kernighan ও Rob Pike, The Practice of Programming (ডিবাগিং অধ্যায়)
• Andrew Hunt ও David Thomas, The Pragmatic Programmer (ডিবাগিং ও অ্যাসারশন অধ্যায়)
• Steve McConnell, Code Complete: A Practical Handbook of Software Construction (ডিবাগিং অধ্যায়)
• John Regehr, “Reducers Are Fuzzers” এবং টেস্ট-কেস হ্রাস বিষয়ক সম্পর্কিত লেখা
• Charity Majors, Liz Fong-Jones ও George Miranda, Observability Engineering (উচ্চ-কার্ডিনালিটি টেলিমেট্রি ও ট্রেসিং দিয়ে প্রোডাকশন ডিবাগিং)
• Betsy Beyer, Chris Jones, Jennifer Petoff ও Niall Richard Murphy (সম্পা.), Site Reliability Engineering (দোষারোপহীন পোস্টমর্টেম ও প্রোডাকশন ডিবাগিং)