Incident response הוא תרבות, לא פרוצדורה

כשמערכת נשברת, רוב הארגונים רצים לאותו מקום: נהלים, runbooks ו-checklists.

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

האשליה: “אם נכתוב נוהל טוב - נהיה מוכנים”

Incident response נתפס לעיתים כבעיה תהליכית. ההנחה היא שאם נגדיר מי עושה מה ובאיזה סדר במקרה של תקלה - המערכת תתנהג כמצופה.

אבל תקלות אמיתיות לא מגיעות לפי תסריט.

ב-Incident אמיתי:

• המידע חלקי
• הזמן לוחץ
• וההשפעה אינה ברורה

במצב כזה, נוהל הוא לכל היותר נקודת התחלה - לא מנגנון הצלה.

מה באמת נחשף בזמן תקלה

Incident אינו רק כשל טכני. הוא רגע שבו הארגון נחשף.

בזמן תקלה מתברר:

• מי מרגיש אחראי גם כשזה “לא אצלו”
• מי מפחד לטעות ולכן שותק
• מי מוכן לפעול בלי ודאות מלאה

אלה אינם מאפיינים של מערכת. אלה מאפיינים של תרבות.

Blame או Learning - הבחירה השקטה

רוב הארגונים לא אומרים “אנחנו מאשימים”. אבל הם שואלים שאלות שמרגישות כך:

• מי דחף את הקוד?
• למה לא בדקת?
• איך זה עבר review?

אלו אינן שאלות של למידה. אלו שאלות של התקפה.

והתוצאה כמעט תמיד זהה:

• מידע לא נאמר
• סיכונים מוסתרים

דוגמה פשוטה: אותו Incident, שני ארגונים

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

אחרי האירוע שואלים: “למה לא אמרת קודם?”

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

ההבדל לא היה בטכנולוגיה. הוא היה בתחושת הביטחון לדבר.

Incident response כיכולת ארגונית

ארגון אחראי אינו שואל רק “איזה נוהל נכתוב”.

הוא שואל:

• האם מותר לטעות בקול רם
• האם אפשר לעצור נזק לפני שמבינים הכול
• והאם למידה חשובה יותר מהצדקה

נהלים יכולים לתמוך בזה - אבל הם לא מחליפים תרבות.

השורה התחתונה

אפשר ללמד אנשים נהלים. קשה הרבה יותר לבנות תרבות.

אבל רק תרבות נכונה מאפשרת למערכת:

• לשרוד תקלות
• להשתפר מהן
• ולא לחזור עליהן שוב ושוב

Incident response טוב נבנה הרבה לפני ה-Incident.

מבט קדימה

אחרי שראינו איך ארגונים פועלים תחת לחץ, נגיע לשאלה הבוגרת ביותר:

מתי לעצור. מתי לוותר. ומתי “טוב מספיק” הוא ההחלטה הנכונה.

בפוסט הבא: Good Enough Engineering - ולמה שלמות היא לפעמים הסיכון הגדול ביותר.