[מאמר]אסונות בתכנות
טילים שהתרסקו, מחשבים שנפלו - איך גרמה טעות תכנות פשוטה לכמה מאסונות המחשוב (או כמעט אסונות) הגדולים בהיסטוריה?
דמיינו לעצמכם שאתם מתכנתי מחשבים אי-שם בשנות הששים או השבעים. כל מחשב הוא בגודל חדר, הזיכרון שלו נמדד בקילובייטים וכדי לטעון תוכנה צריך ללכת לארון, להוציא משם סליל מגנטי בגודל הגה של מכונית ולמקם אותו בזהירות בתוך מנגנון הקריאה המכני. במילים אחרות, כל בייט שאתם חוסכים בקוד או במסד הנתונים חוסך לכם מאמץ פיזי של ממש. כעת, מבקשים מכם לכתוב תוכנה לבנק, ששומרת בזיכרון פעולות שנעשו ואת התאריך שלהן. כל תאריך מורכב מיום (עד שתי ספרות), חודש (כנ"ל) ושנה. בהנחה שלא מבצעים כיווץ נתונים – כי בכל זאת, המעבד איטי להדהים ופעולות כיווץ ופענוח ייקחו שעות – נתון השנה לבדו דורש ארבע ספרות שלמות. איזה בזבוז!
דיסק קשיח מוקדם: כל בייט מיותר עלה בבריאות צילום : gizmodo.com
זה נשמע לי כמו באג 2000
אך אז עולה בדעתכם רעיון גאוני: הרי כל השנים הן אלף תשע-מאות ומשהו, לא? אז בשביל מה צריך את שתי הספרות הראשונות הקבועות? ממילא איש לא משתמש בהן ביומיום, ועד שתגיע שנת 2000 התוכנה שלכם בוודאי תוחלף כמה וכמה פעמים בתוכנות מתקדמות יותר. ובכלל, שנת 2000 עבורכם היא רק חלום רחוק, בו יהיו ערים על הירח, רובוטים דמויי-אדם בכל פינה וחיי נצח.
למרבה ההפתעה, התוכנות שלכם שרדו. פה ושם היו מי ששכתבו אותן או יצרו חדשות לאותה מטרה, אך גם אלה שמרו את הפורמט הקיים מטעמי נוחות, תאימות ו/או עצלנות. לאט לאט התקרבה שנת 2000, ופתאום כולם שמו לב שיש בעיה ממשית. בשנה זו, התוכנות הישנות יניחו שהנתון "00" עבור שנה פירושו 1900 ולא 2000, ויבצעו המון טעויות: למשל בחישובי גילאים, ריביות ושאר דברים קריטיים. האזהרות הופיעו עשרים וחמש שנים מראש, אך מקבלי ההחלטות – שהונעו בעיקר משיקולים תקציביים – לא מיהרו לפעול: תיקונים לוקחים הרבה זמן וכסף, ועדיף לדחות אותם לרגע האחרון או לזה שיבוא אחריהם בתפקיד. בקיצור, יום אחד העולם התעורר וגילה ששנת 2000 אוטוטו כאן, והמון מערכות מחשב כלל אינן מוכנות לשינוי הקידומת. הכאוס הצפוי זכה לשם "באג 2000" והסעיר, בזמנו, את דמיונו של העולם כולו. האם רמזורים יתקלקלו בכל הצמתים בעולם? האם כל רשתות התקשורת והבנקאות יקרסו, ובעקבותיהן הכלכלה והתשתיות, וכולנו נאלץ לגור במערות ולהילחם זה בזה במקלות ואבנים?
וכך התחיל המרוץ נגד הזמן. מתכנתים קשישים, שתכנתו לפני עשרות שנים בשפות תכנות נידחות שאיש אינו זוכר, נקראו לדגל וזכו לעדנה מחודשת: רק הם הצליחו לפענח ולשפץ את הקוד העתיק. סכומי עתק הושקעו, ובליל הסילבסטר המונים עצרו את נשימתם: האם זהו סוף העולם? בדיעבד, כידוע, לא קרה כמעט כלום. אולי המצב היה פחות גרוע משחשבו, ואולי כל התיקונים שבוצעו אכן השתלמו. בכל אופן, אפשר היה להירגע: העולם בטוח. האמנם?
נעים להכיר: באג 2038
באג 2000 היה דוגמה מצוינת לאופן בו שרשרת של החלטות, כל אחת מהן הגיונית לחלוטין בשעתה, מצטברות והופכות עם הזמן לסכנה אמיתית. במבט לאחור קל להאשים את המתכנתים ההם, הראשונים, ברשלנות – אבל היום אנו עושים את אותו הדבר בדיוק וביתר שאת. מערכות הפעלה מתחלפות מדי שנים ספורות; תוכנות שנכתבו לסביבת DOS לפני פחות מעשרים שנה אינן יכולות לרוץ על גרסאות Windows האחרונות. הסתכלו על לוח השנה של המחשב או של הסלולרי: רוב הסיכויים שהוא מגיע רק עד שנת 2099. מה יהיה אחר כך?
באג 2038
אם אתם חושבים שהנינים שלכם פשוט יצטרכו לדאוג לעצמם, צפויה לכם הפתעה לא נעימה: באג 2038. במערכות Unix רבות, נתוני תאריך ושעה נשמרים כברירת מחדל במשתנה בן 32 ביטים, שמייצג את מספר השניות שעברו מאז הראשון בינואר 1970. ב-32 ביטים אפשר לייצג כל מספר בין 0 ל-4.3 מיליארד לערך, אך כיוון שהנתון הזה ספציפית מוגדר כמספר בעל סימן, ביט אחד מוקדש לסימן עצמו – פלוס או מינוס. מצד אחד זה מאפשר לייצג תאריכים מלפני 1970, ומצד שני זה מקטין את מספר השניות המרבי ל-2.15 מיליארד. חישוב מהיר יגלה שמדובר בששים ושמונה שנים וקצת, ופירוש הדבר שבתשעה-עשר בינואר 2038, בשעה 03:14:07, הייצוג המספרי "יתמלא" ויחזור להתחלה: מינוס 2.15 מיליארד, כלומר 13 בדצמבר 1901. בעולם קיימות המון מערכות מחשב כאלה, והחלפה או "תיקון" שלהן הן פעולות לא טריוויאליות כלל. הגיוני שעד אז יוחלפו רבות מהן במערכות 64 ביט או אף יותר, אבל שיקולים הגיוניים שכאלה הם שהובילו, כאמור, לבאג 2000. אגב, גם 64 ביטים לא חסינים לחלוטין לשגיאות: מערכות כאלה יהיו צפויות לבאג 292,277,026,596.
הבאגים שריסקו טילים
קיימים עוד מספר באגים שוליים דומים שקשורים לתאריכים. המכנה המשותף לכולם הוא חוסר ההתחשבות של המתכנתים באפשרות של ערך גבוה יותר ממה שהמשתנים מסוגלים להכיל, ולמעשה זהו אחד מהבאגים המוכרים בתכנות: שימוש במשתנה מסוג קטן מדי עבור טווח הערכים הרלוונטיים. שפות התכנות אינן מזהות חריגות שכאלה מעצמן, ובסוגים מסוימים של תכנות, המתכנתים אינם נוטים להוסיף בדיקות כיוון שהן מכבידות על המעבד שצריך לתת מקסימום ביצועים – למשל, בהנחיה של טיל.
במלחמת המפרץ הראשונה – עוד לפני שמישהו חשב ברצינות על באג 2000 – הובאו לישראל סוללות טילי פטריוט להגנה מפני הסקאדים העיראקיים. טילים דומים הוצבו כדי להגן על הכוחות האמריקניים בסעודיה. לפי המפרט, הפטריוט אמורים היו לפגוע ב-90% מהסקאדים. בפועל, המספר היה קרוב יותר ל-10% ואנשים רבים איבדו את חייהם. בבדיקות לאחר מעשה התברר שהאשם היה טמון בתוכנה של מערכת היירוט, שנועדה לחשב את מהירות וכיוון הטילים המתקרבים: אי-שם בקוד, התוכנה המירה יחידות זמן שלמות למספרים עשרוניים, וכאשר המערכות הופעלו לפרקי זמן רצופים של שבועות – הרבה יותר ממה שנבדק בניסויים – הצטברו יותר מדי יחידות זמן והמספרים "קוצצו" במהלך ההמרה. השגיאה התגלגלה הלאה לכל החישובים, והדיוק של טילי היירוט הלך ופחת.
דגם של הטיל אריאן 5
צילום : האתר הרשמי של ה-ESA
בעיה דומה בתוכנה גרמה, בשנת 1996, להתפוצצות של טיל מסוג אריאן 5, שאמור היה להטיס לחלל מספר לוויינים של סוכנות החלל האירופית. קוד תוכנה שנועד לייצב את הטיל במעופו קיבל נתוני אינרציה מחיישנים פנימיים וביצע כוונונים עדינים כדי לנטרל את הסטיות הנוצרות. אלא שהחומרה של החיישנים אספה נתונים עשרוניים במשתנים בני 64 ביטים, ואילו התוכנה המירה אותם למספרים שלמים בני 16 ביטים בלבד. שלושים ושבע שניות לאחר ההמראה התרחשה סטיה גדולה שלא ניתן היה לייצג ב-16 ביטים. מכיוון שמדובר במשימה חשובה ויקרה כל כך, המחשב המזועזע לא התבלבל והעביר את הפיקוד למחשב גיבוי – אך כמובן, גם במחשב הגיבוי הותקנה אותה תוכנה בדיוק, וההתרסקות היתה בלתי נמנעת. ולשאלה המתבקשת, איך לא צפו מראש אפשרות של נתונים קיצוניים כאלה, התשובה פשוטה: כדי לחסוך זמן וכסף הותקנה בטילי אריאן 5 אותה התוכנה ששימשה בנאמנות את הטילים מהדור הקודם, אריאן 4, שבהם לא היתה אפשרות כזו.
תהנו, ותפנימו
קרדיט לנענע 10 , www.nana10.co.il .
נכתב במקור על ידי אושרי
ציטוט ההודעה
