האתר הישראלי להנדסת תכנה

ארכיטקטורות סובלות תקלות

סבולת לתקלות היתה דרישה ממערכות חומרה זמן רב בטרם הפכה לדרישה ממערכות תכנה. עולם החומרה פתר את הבעיה על ידי עבודה בשיטת "יתירות מודולרית משולשת":



בשיטה זו במקום רכיב אחד עושים שימוש בשלושה רכיבים הפועלים במקביל.שלושת הרכיבים מקבלים את אותו הקלט, ואמורים להחזיר את אותו הפלט. הרעיון הוא לקיים מעין "הצבעה". שלושת הרכיבים צריכים להסכים על התוצאה. במקרה שאחד מהם לא מסכים עם השניים האחרים, משווה הפלטים דואג להכריז עליו כתקול ולהעביר את המערכת לעבודה בתצורה של שני רכיבים בלבד. ההנחה היא שכשל בחומרה אינו אירוע שסביר שיתרחש בשני מקומות בו זמנית.
בעיה מיידית העולה בשיטה זו היא בעייה העקביות: אם שלושת הרכיבים זהים זה לזה, סביר לצפות שכשל בהם יארע באותם תנאים: אם, למשל, רכיב מסוים נוטה להכשל עקב כניסת קלט מסוים, מדוע שלא יכשלו באותו אופן כל העתקיו ? סוג כזה של כשלון ייזקף כמובן לזכות כשל בתכן הרכיב ולא לתקלה מקרית באחד ממרכיביו.
כדי למנוע בעיה זו מגבילים את זהות הרכיבים השונים לנושא הדרישות בלבד, כלומר – הדרישה מהרכיבים היא לעמוד באותו מפרט דרישות. מעבר לכך, עליהם להיות מתוכננים ואף מיוצרים על ידי צוותים שונים (לעתים אף חברות שונות) שאין ביניהם כל קשר.

עולם התכנה אימץ לעצמו גישה זו, בשינויים קלים, וכינה אותה "תכנות רב-גרסאות". בשיטה זו מפתחים מספר צוותים שונים את אותו רכיב תחת מגבלות פיתוח חמורות: לעתים נדרשים הצוותים לעשות שימוש במתודולוגיות פיתוח שונות ואף באלגוריתמים שונים כדי להבטיח שוני מספק בין הגרסאות שלהם לרכיב. שיטה זו מיושמת למשל במחשבי טיסה, עבורם מצב בו מחשב הטיסה מפסיק לפעול הוא בלתי נסבל.

שיטה מעט שונה מכונה "אזורי התאוששות". גם כאן קיימות מספר גרסאות שונות לקוד, אבל הןאינן מורצות במקביל, אלא באופן סדרתי, ורק כאשר מתרחש כשלון. כשלון בעבודת הגרסאות לרכיב מוגדר על ידי הגרסאות עצמן. כל גרסה מכילה בדיקה עצמית הקובעת אם הריצה הנוכחית הסתיימה בהצלחה. כאשר גרסה המדווחת כי נכשלה בריצה הנוכחית מועבר הקלט לגרסה הבאה אחריה, עד למציאת גרסה שאינה נכשלת בעיבוד הקלט, או עד למיצוי כל הגרסאות.

מסתבר שלמרות הדרישות המחמירות של עקרון הגיוון, שתי השיטות עלולות לייצר בכל זאת רכיבים הנכשלים באותם תנאים. בכל זאת, ככל שהגיוון רב יותר, כך גדלה מהימנות המערכת.