حشرات صفر و یکی

رادیو‌ فرامتن - شماره سه - این قسمت: حشرات صفر و یکی

فاجعه موشک آریان-۵

۴ ژوئن سال ۱۹۹۶ ساعت ۹:۳۴ صبح و بالاخره موشک ۷۸۰ تنی آریان-۵ (Ariane-5) از مرکز فضایی گویان (Guiana Space Centre) به پرواز در میاد. این موشک، ماهواره علمی بسیار باارزشی رو با خودش حمل می‌کنه. همه چیز، به‌نظر خوب میاد ولی ۲۹ ثانیه بعد: ...

به سومین شماره از پادکست رادیو فرامتن خوش اومدید. در این شماره می‌خوایم درمورد باگ‌ها صحبت کنیم. اون‌ها در همه نرم‌افزارها وجود دارن و منتظر هستن تا خودشون رو نشون بدن.
صدایی که شنیدین متعلق به موشک آریان-۵(Ariane-5) بود. موشکی که به خاطر یک باگ، منفجر شد. برای شنیدن داستان این موشک و شناخت بیشتر باگ‌ها با ما همراه باشید.

موشک آریان-۵ (Ariane-5) پس از طی ۳۷۰۰ متر دچار سانحه و فروپاشی می‌شه. چه اتفاقی توی اون ۲۹ ثانیه افتاد؟ این سوالی بود که کارشناسان بعد از چند روز جست‌و‌جو، پاسخش رو بین کدهای موشک پیدا می‌کنن!

در سیستم‌ کنترل‌کننده موشک، کامپیوتر اصلی پرواز، همه پارامترها رو طبق یک برنامه مشخص و دقیق به کامپیوتر هدایت پرواز می‌فرستاد. اون هم بر اساس این پارامترها سرعت، شتاب و بقیه المان‌ها رو تنظیم می‌کرد. اما مشکل اینجا بود که این دستورات باید از سیستم ۶۴ بیتی به ۱۶ بیتی تبدیل می‌شدن. بیاید یکم دقیق‌تر به این قضیه نگاه کنیم.

کامپیوترهای ۱۶بیتی توانایی پردازش اعدادی بزرگ‌تر از حدود شصت و پنج هزار رو ندارن و برای خوندن مقادیر بیش‌تر به مشکل می‌خورن و به اصطلاح کامپیوتری overflow رخ می‌ده. اما کامپیوترهای ۶۴ بیتی می‌تونن بدون هیچ مشکلی، حتی اعداد ۳۰۸ رقمی رو هم پردازش کنن.

برگردیم به موشک. سیستم کنترل، سرعت افقی رو به صورت ۶۴ بیتی به دست می‌آورد و بعدش اون رو در قالب ۱۶ بیتی به کامپیوتر هدایت پرواز می‌فرستاد تا مطابق با اون سرعت تنظیم بشه. در زمان شروع پرواز که مقدار سرعت کم بود، هیچ مشکلی به وجود نیومد اما بعد چند ثانیه مقدار اون، چنان بزرگ می‌شه که پردازشش از توانایی کامپیوتر ۱۶ بیتی خارج می‌شه و overflow رخ می‌ده. کامپیوترها با هم چندتا ارور رد و بدل می‌کنن و در آخر سیستم بطور کلی خاموش می‌شه.

کامپیوتر هدایت و پشتیبانی هم که دیگه مدیریت نمی‌شد، از کار افتاد و همین باعث شد سرعت موشک به شدت کاهش پیدا کنه. خوش‌بختانه سیستم هدایت پرواز، طوری برنامه‌نویسی شده بود که تونست در همون ارتفاع بوسترهای خودش رو آتیش بزنه و موشک ۸۰۰ تنی رو در هوا منفجر کنه. قابل تصور نیست که اگر موشک، کامل به زمین می‌افتاد ممکن بود چه فاجعه‌ای رخ بده.

این مشکل، که با چند خط کدنویسی و تست به راحتی قابل تشخیص بود، در صورت اصلاح می‌تونست از چند صد میلیون خسارت جلوگیری کنه.

به هر اشکال و عیبی که در نرم‌افزارها وجود داره و باعث می‌شه به نتایج دلخواهمون نرسیم باگ می‌گن. حالا اصلا چرا باگ؟ مثلا چرا fault نه؟ برای پاسخ دادن به این سوال باید به گذشته برگردیم.

اولین باگ

طبق اسناد تاریخی، در روز نهم سپتامبر سال ۱۹۴۷(Grace Hopper) گریس هاپر برای اولین بار از واژه باگ به معنی نقص و عیب نرم‌افزاری استفاده می‌کنه. خانم هاپر که در اون زمان مشغول عیب‌یابی ماشین‌حساب مارک-۲ (Mark‌II) در دانشگاه هاروارد بوده، بعد از یک جست‌وجوی طولانی متوجه می‌شه که یک شاپرک در بین قطعات الکترونیکی این دستگاه گیر کرده.

اما شاید این اتفاق، اولین استفاده از کلمه باگ به معنی عیب نباشه. ماجرا از اونجایی شروع می‌شه که توماس ادیسون در نامه‌ای خطاب به دوستش تئودور پوشکاش در سال ۱۸۷۸ از این واژه در همین معنا استفاده می‌کنه و این نامه نشون می‌ده که واژه باگ حتی از سال‌های قبل‌تر هم متداول بوده.

باگ‌ها همه جا هستن. گاهی یک موشک رو سرنگون می‌کنن و گاهی زندگی یه انسان رو به خطر میندازن. در ادامه سری به دنیای پزشکی می‌زنیم و می‌بینیم که چطور باگ‌ها تونستن راهشون رو به یکی از حساس‌ترین صنایعی که با کامپیوتر در ارتباطه، پیدا کنن.

باگ در صنعت پزشکی

یک نمونه از این باگ‌ها،‌ مشکل نرم‌افزاری‌ای هست که در دستگاه رادیوتراپی تِراک-۲۵ (therac-25) وجود داشت. شرکت AECL که در زمینه ساخت دستگاه‌های رادیوتراپی فعالیت می‌کرد قبل از عرضه کردن تراک-۲۵ دو دستگاه تراک-۶ (therac-6) و تراک-۲۰ (therac-20) رو برای درمان توده‌های سرطانی با استفاده از اشعه‌های متمرکز ساخته بود. هر دوی این دستگاه‌ها همراه با یک کامپیوتر برای آسان‌تر شدن استفاده عرضه می‌شدن. در کنار این کامپیوتر از یک سری قفل سخت‌افزاری هم برای اطمینان از مضر نبودن میزان اشعه خروجی استفاده می‌شد.

وقتی که دستگاه تراک-۲۵ به بازار اومد به دلیل یک سری تغییرات که در ساختارش ایجاد شده بود قفل‌های سخت‌افزاری، حذف شدن و دستگاه برای اطمینان از امنیتش فقط به نرم‌افزار اتکا می‌کرد.

اما این نرم‌افزار که فقط یک نفر روش کار می‌کرد و در محیط شبیه‌سازی شده تست نشده بود، باگ‌های زیادی داشت. مثلا اگر اپراتور بعد از وارد کردن دستورها و در حین آماده سازی دستگاه، دستوراتش رو تغییر می‌داد دستورات جدید وارد دستگاه نمی‌شدن و فقط پیغام تایید نمایش داده می‌شد. علاوه بر وجود باگ‌های زیاد، اخطارهایی که در مواقع برخورد با مشکل نمایش داده می‌شدن، اغلب توضیحات کافی نمی‌دادن و گنگ بودن. همین باعث می‌شد که اپراتورهای دستگاه متوجه وجود مشکلات جدی نشن و کارشون رو ادامه بدن. این باگ‌ها که در گذشته به خاطر وجود قفل‌های سخت افزاری پنهان مونده بودن حالا با حذف شدن این قفل‌ها آماده قربانی گرفتن بود.

بعد از هر کدوم از این حوادث شرکت AECL وجود مشکل در دستگاه‌های خودش رو رد کرد. اما با افزایش تعداد قربانی‌ها این شرکت شروع به تحقیق درباره منبع این مشکل کرد. پس از مشخص شدن باگ‌های موجود،‌ AECL مسئولیت مشکلات رو به گردن گرفت و در کنار نصب قفل‌های سخت‌افزاری، مشکلات نرم‌افزاری تراک-۲۵ رو هم حل کرد و دوباره اون‌ها رو به کار بازگردوند و خوشبختانه پس از حل مشکلات حادثه جدیدی اتفاق نیفتاد.

بعد از هر کدوم از این حوادث شرکت AECL وجود مشکل در دستگاه‌های خودش رو رد کرد. اما با افزایش تعداد قربانی‌ها این شرکت شروع به تحقیق درباره منبع این مشکل کرد. پس از مشخص شدن باگ‌های موجود،‌ AECL مسئولیت مشکلات رو به گردن گرفت و در کنار نصب قفل‌های سخت‌افزاری، مشکلات نرم‌افزاری تراک-۲۵ رو هم حل کرد و دوباره اون‌ها رو به کار بازگردوند و خوشبختانه پس از حل مشکلات حادثه جدیدی اتفاق نیفتاد.

ردپای باگ‌ها حتی در دستگاه‌های نظامی هم دیده می‌شه. با وجود حساسیت بالایی که در این حوزه هست، باز هم باگ‌ها تونستن از طریق خطاهای انسانی، بهش وارد بشن.
گذری به تاریخ، مارو به یکی از خطرناک‌ترین باگ‌های نظامی می‌رسونه که ممکن بود وجودش به جنگ اتمی و پایان دنیا ختم بشه.

۷ دقیقه تا انفجار

پس از پایان جنگ جهانی دوم و با شروع جنگ سرد، ایالات متحده آمریکا و اتحاد جماهیر شوروی شروع به ساخت کلاهک‌های هسته‌ای کردن تا در صورت وقوع یک جنگ دیگه هر کدوم توانایی دفاع از خودشون رو داشته باشن. چند ماه مونده به شروع دهه هشتاد میلادی، ایالات متحده، شروع به کاهش دادن تعداد کلاهک‌های هسته‌ای خودش کرد، اما در همون زمان خبرها حاکی از افزایش تعداد کلاهک‌های هسته‌ای اتحاد جماهیر شوروی بود.

با توجه به قدرت بسیار بالای بمب‌های اتمی در صورت شروع یک جنگ اتمی، برنده اون تنها چند دقیقه بعد مشخص می‌شه. با دانش به این نکته ایالات متحده میلیاردها دلار رو صرف ساخت رادارها، ماهواره‌ها و زیردریایی‌هایی کرد تا در هر لحظه اتحاد جماهیر شوروی رو زیر نظر داشته باشه و در صورت دیدن نشونه‌هایی از پرتاب موشک‌های اتمی به سرعت برای دفاع و حمله متقابل آماده بشه.

کنترل تمام این تجهیزات در دست سازمان NORAD بود که وظیفه داشت همواره تمام نقاط دنیا رو برای استفاده احتمالی از موشک‌های اتمی کنترل کنه. ساعت۲:۵۹صبحِ روز نهم نوامبر سال ۱۹۷۹ یکی از کارمندان این سازمان نواری رو در کامپیوتر گذاشت. سه ثانیه بعد صفحه اصلی مرکز شروع به نشون دادن اخطار حمله‌هایی از طرف اتحاد جماهیر شوروی می‌کنه. به سرعت تمامی نیروهای ارتش آمریکا شروع به آماده شدن برای حمله می‌کنن. بمب افکن‌های B52 به روی باندهای فرودگاه می‌رن و هواپیمای مخصوص رئیس جمهور برای دور کردن اون از واشنگتن دی. سی. آماده می‌شه.

حالا چند دقیقه از اخطار اولیه می‌گذره. کامپیوترهای سازمان هنوز هم خبر از پرتاب موشک‌ها می‌دن اما دیتای مستقیم گرفته شده از ماهواره‌ها و رادارهای زمینی هیچ اثری از حمله پیدا نمی‌کنن. در این موقعیت حساس رئیس جمهور تصمیم به متوقف کردن حمله‌ها می‌گیره.

حالا مهندسان NORAD با عجله مشغول به بررسی سیستم‌ها برای پیدا کردن منشا خطا می‌شن. پس از مدتی جست‌وجو عامل خطا پیدا می‌شه، عاملی که برای همه دور از ذهنه، نواری که چند دقیقه پیش به‌وسیله یکی از مهندسان در کامپیوتر گذاشته شده بود. بررسی‌های بیشتر نشون می‌دن این نوار حاوی یک سری دیتای آزمایشی برای شبیه سازی یک حمله از طرف اتحاد جماهیر شوروی بوده و خطای انسانی به همراه یک باگ در کامپیوترهای NORAD که این دیتا رو روی سیستم‌های اصلی به نمایش درآورده بودن باعث اخطارهای اشتباه شدن.

احتمالا باگ‌ها هیچوقت از بین نرن و حتی با پیچیده‌تر شدن نرم‌افزارها باگ‌های بزرگ‌تری هم به وجود بیان. اما به موازات ایجاد مشکل، برنامه‌نویس‌ها هم تجربه بیشتری پیدا می‌کنن. در کنار افزایش تجربه با استفاده از متدهای تست و شبیه سازی نرم‌افزار و ابزارهایی که در این حوزه به وجود اومدن می‌شه خیلی از باگ‌های خطرناک رو قبل از اینکه مشکل ایجاد کنن شناسایی و رفع کرد.

به پایان سومین شماره از رادیو فرامتن رسیدیم؛ من فاطمه قدم‌زاده هستم و این پادکست توسط اعضای انجمن علمی کامپیوتر دانشگاه صنعتی اصفهان آماده سازی و تدوین شده. تشکر می‌کنم از محمد مهدی برقی و مرصاد حسنجانی و سپهر شیرانی در تیم دیتا؛ دانیال خراسانی زاده و محمد حسن نساج‌ پور در تیم نویسندگان؛ شیرین بهنامی نیا و سنا محراب بیگی در تیم ویراستاری؛ محمدرضا میردامادیان و محمد جلالی در تیم تدوین و همچنین از سپهر گنجی و رسول بوسعیدی که در کنارمون بودن.

رادیو فرامتن رو می‌تونین از کانال‌های ما در تلگرام و کست‌باکس دنبال کنید. اگه این پادکست براتون مفید بود با معرفی ما به دوستاتون می‌تونید برای ادامه راه به ما انرژی بدید. منتظر شماره‌های بعدی رادیو فرامتن باشید :)