وقتی که برنامه‌نویسی بد، تبدیل به یک اتفاق مهلک می‌شود

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

Therac-25: تمام غفلت‌های آن

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

Therac-25 یک دستگاه درمان تشعشع بود که در سال ۱۹۸۲ برای درمان انواع سرطان ساخته شد. Therac-25 که از روی مدل‌های پیش‌تر خود، یعنی Therac-6 و Therac-20 ساخته شده بود، از یک پیکربندی دو حالته استفاده می‌کرد. یکی برای دوز خفیف‌تر تشعشعات الکترون، و یکی دیگر که به طور قابل توجهی صدها برابر دوز قوی‌تری بود.

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

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

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

پس به جای این که این دستگاه یک انفجار عظیم از تشعشعات را بر روی یک بشقاب فلزی شلیک کنند، که اشعه‌های X-ray را در طی یک ناحیه عظیم پخش می‌کرد، Therac-25 گاهی اوقات یک پرتوی باریک متشکل از تشعشعاتی صداها برابر قوی‌تر از آنچه که مد نظر بود را به یک بیمار شلیک می‌کرد. به اندازه کافی قوی که بر روی بسیاری از بیماران سوختگی‌های تشعشعاتی به جای بگذارد و حداقل در ۵ مورد، آن‌ها را بکشد.

موشک وطن پرستی که نتوانست شلیک شود

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

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

یک توپخانه موشک وطن‌پرست ارتش ایالات متحده در داران، عربستان سعودی از ۲۵ فوریه ۱۹۹۱، در اواسط اولین جنگ خلیجی، در حال انجام عملیات به مدت ۱۰۰ ساعت بدون راه‌اندازی مجدد بود. این توپخانه وطن‌پرست بخشی از دفاع ارتش ایالات متحده علیه موشک‌های SCUD قابل حمل که توسط ارتش عراق استفاده می‌شدند بود، و برنامه مسئول ردگیری موشک‌های SCUD ورودی، به مجموعه‌ای از محاسبات وابسته بود که پیش‌بینی می‌کردند موشک در حال ردگیری، در فاصله بعدی، و تابعی از سرعت و زمانش در کجا خواهد بود.

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

برچسب زمان در یک بلوک حافظه ۲۴ بیتی ذخیره شده بود، پس هر عدد باینری‌ای که بزرگ‌تر از ۲۴ بیت بود، باید کوتاه می‌شد تا در حافظه جا شود. یک دهم، یک نمایش بدون توقف باینری است؛ پس بریدن عدد در ۲۴ بیت، یک رانش ۰.۰۰۰۰۰۰۰۹۵ ثانیه‌ای را نمایش می‌دهد.

و تمام این خطاها در طی ۱۰۰ ساعتی که برنامه در حال اجرا بود و زمانی که برنامه استفاده می‌کرد، در مجموع ۰.۳۴ ثانیه از جایی که سیستم بود، عقب مانده بود.

پس وقتی که توپخانه وطن‌پرست یک موشک SCUD را در تاریخ ۲۵ فوریه ردگیری کرد، با در آوردن موقعیت آن با استفاده از دو سیگنال رادار، که یکی زمان صحیح و دیگری خطای ۰.۳۴ ثانیه‌ای را منعکس می‌کردند، مکان موشک را پیش‌بینی کرد. این توپخانه اعداد را به دست آورد و به مختصاتی که انتظار داشت موشک مورد نظر برخورد کند نگاه کرد، اما در آنجا فقط یک آسمان خالی بود.

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

توهمات دیجیتال

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

چنین موقعیتی در شهر Panama، وقتی که دکترها در موسسه سرطان ملی در حال استفاده از نرم‌افزار پزشکی ساخته شده توسط یک شرکت ایالات متحده، یعنی Multidata Systems International بودند، پیش آمد. این نرم‌افزار، یک تلاش پس از فروش برای نگه داشتن عملکرد رادیورلوژی Cobalt-60 قدیمی بود.

جدا از تجهیزات بی کیفیت، دکترها هم خسته، مضطرب و به شدت وابسته به نرم‌افزار Multidata برای تعیین دوز صحیح تشعشعات برای دادن به بیماری که با سرطان در مبارزه بود، بودند.

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

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

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

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

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

از میان ۲۸ نفری که ما می‌‌دانیم به خاطر برنامه‌نویسی بد نرم‌‌افزار Multidata دوز اضافی را دریافت کرد، ۸ نفر مردند و باقی آن‌ها به شدت توسط درمانی که دریافت کرده بودند، آسیب دیدند. با در نظر گرفتن این که تمام بیمارها در این موسسه داشتند با سرطان می‌جنگیدند، به هیچ وجه نمی‌توان دانست که چند نفر دیر توسط دوز اشتباه خارج شده از نرم‌افزار Multidata مریض شده، یا مردند.

اهمیت عادت‌ها و روش‌ها در برنامه‌نویسی

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

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

منبع