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

מתודולוגיה

עקרון המלחמה בביש המזל

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

אחריות המפתח

קוי הגנה בפני כשל

הגדרת קריטריונים

אוטומציה

אילוצי התפעול

בקרת הפעילות תחת אילוצים

יישום הבקרה העצמית

תהליך הבקרה העצמית

 

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

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

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

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

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

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

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

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

דוגמאות ישום

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

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

מידע נוסף בנושא
תכן לאבטחת חסינות מערכות:
אתר זה נערך ומתחוזק על ידי אבי הראל - ארגולייט  למידע נוסף ולמשוב, נא לשלוח אימייל לכתובת  ergolight@gmail.com   דף זה עודכן בתאריך 25/11/2014