מדריך לאבטחת חסינות מערכות - מבוא - עקרונות אבטחת החסינות

תוכן העניינים

סקירה כללית

המלחמה בביש המזל

פעילות תחת אילוצים

אחריות המפתח

אבטחת שלימות התכן

המלחמה בטעויות אנוש

תכן ממוקד מפעיל

הפחתת עומס מנטאלי

תיקוף ואימות

אחריות הארגון

 

 עקרון אחריות המפתח

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

יש למקד את הדיון בתכן שאיפשר את מצב הכשל.

מאפיינים של רשלנות המפתח

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

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

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

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

דוגמאות ישום

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

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

 

    אתר החסינות נערך ומתחוזק על ידי אבי הראל - ארגולייט. למידע נוסף, נא לשלוח אימייל לכתובת  ergolight@gmail.com . דף זה עודכן בתאריך 16 Dec 2013.