זה היה פוסט שמאד אהבתי, בעיקר בגלל הכותרת המתחכמת שלו שהבטיחה למות ובמקום לדבר על בהמת משא דרום אמריקאית שיורקת, עסקה בכלי לשוני פופולרי לביצוע תחקירי RCA או Root Cause Analysis ובכן לא מזמן נתקלתי בציוץ הזה:
ג'ון אלפסו מציג כאן טיעון מרכזי אחד נגד שיטת חמשת הלמות כי הרבה פעמים, כך הוא טוען, ה"למה" מתורגמת מהר מאד ל"מי" ואם אנחנו, כמו שאנחנו טוענים, לא מחפשים אשמים אלא מחפשים ללמוד ולהתפתח הרי ה"מי" לא יקדם אותנו לשם ובמקום זאת כדי לנו לחפש את ה"איך", את התיאור של ההתרחשות ולא את ההסבר להתרחשות. ההסבר להתרחשות עשוי להיות מוטה על ידי נקודת מבטו של המסביר ואילו תיאור ההתרחשות אמור להיות ברור יותר.
חמשת הלמות, אלפסו ממשיך להסביר, היא שיטה שעשויה לספק לנו תחושה שגויה של הצלחה, היא עשויה לתת לנו את התחושה שהנה, עברנו חוליה אחרי חוליה בשרשרת האירועים, הגענו לשורש הבעיה וזהו, אנחנו בטוחים שזה לא יקרה לנו יותר. אבל לפעמים התחקיר הזה צר מדי, סוגר לנו את הדיון במקום לפתח אותו וככה אולי הצלחנו לספק את הדו"ח שלנו על מה שקרה אבל לא באמת פתרנו את הבעיה.
מי שרוצה להרחיב בקריאה מוזמן לקרוא את הפוסט המלא כאן אבל אני חושב שאנחנו יכולים לתת דוגמא שאולי תסייע להבין את הרעיון. האייטם הזה בווירד מדבר על הקשר בין התרסקות מטוסים במלחמת העולם השניה ובין מחשבי מקינטוש ולדעתי הוא יכול לתת לנו דוגמא ליתרון ה"איך" על ה"למה" כי כל עוד חיל האויר האמריקאי חקר את התרסקויות מטוסי ה B-17 שלו באמצעות "למה" המטוסים המשיכו להתרסק למרות שבוצעו תחקירים ונותחו ניתוחים. זה היה מטוס נהדר שטייסים וצוותים מאד אהבו, המטוס היה מאד אמין והציל את הצוותים שלו מהרבה מאד מתקפות אש נגד מטוסים, המטוסים האלו שרדו את התופת של ההגנה האוירית מעל אירופה אבל כמה מאות מטוסים כאלו התרסקו בסופו של דבר בזמן הנחיתה. מטוסים סופר אמינים, ששורדים את התקריות הקשות ביותר ובסופו של דבר מתרסקים על הקרקע בזמן נחיתה בגלל מה שנראה בכל התחקירים כמו טעות אנוש זה מאד מוזר ויותר מזה, זה לא יעיל. "טעות טייס" היא משהו שקשה ללמוד ממנו וקשה להפיק ממסקנה כזו Action Items. מדובר בטייסים מנוסים, שהביאו את המטוס לקצה היכולת שלו, שטסו אל היעדים הכי קשים והכי מסוכנים והחזירו את המטוס והצוות הביתה בשלום ורק בנחיתה פתאום הפכו להיות טייסים גרועים שלא מסוגלים להנחית את המטוס? רק כשהלכו לבדוק את "איך" בעצם הבינו שיש בעיה מאד פשוטה שאפשר לפתור, הידית לפתוח את כני הנחיתה והידית לפתוח מדפים היו זהות וקרובות אחת לשניה, הטייסים פתחו את הידית הלא נכונה ולא הבינו שאין להם כני נחיתה עם שהיה מאוחר מדי ולפעמים גם אחרי שהתרסקו לא הבינו זאת. זו היתה אמנם "טעות טייס" אבל לא כזו שהטייס יכל היה למנוע כי מבחינתו הוא אכן הוריד את כני הנחיתה בזמן.
שינוי בצורת הידיות צמצם משמעותית את האופציה לקיומה של טעות טייס שכזו וזו תוצאה הרבה יותר משמעותית מהענשתו של טייס זה או אחר על "טעות" שעשה במהלך נחיתה.
אגב, כקוריוז, טעויות תכנוניות כאלו אינן אירוע נדיר. גם במערכות יקרות ומושקעות כמו מטוסים. באותה התקופה בערך, בעשור וחצי שקדמו למלחמת העולם השניה ובעשור לאחריה, חיל האויר האמריקאי התמודד עם בעיה דומה אך שונה. מטוסי ה B-17 שהתרסקו בנחיתה אבל היו להם הרבה מאד מטוסים אחרים שנראה היה שפשוט נופלים מהשמים ומסתבר שכשתכננו את המטוסים, את תאי הטייס, תכננו אותם עבור "הטייס הממוצע" ובמציאות פשוט לא היה דבר כזה, אף טייס לא עמד בקריטריונים של "טייס ממוצע" בגובה, באורך הידיים, ברוחב הכתפיים, תא הטייס שתוכנן להיות נוח לכולם לא היה נוח לאף אחד.
דיון כזה, על האיך במקום הלמה, יכול להביא לשינוי ארגוני של ממש ולסייע ביצירה של "תרבות צודקת" כמו שקורא לזה סידני דקר, תרבות ארגונית שרותמת את כל העובדים בארגון אל מטרה משותפת.
דקר עוסק המון בנושא של בטיחות בארגונים ותרבות צודקת בה לכל אחד יש את הכוח להצביע על ליקויים, לכל אחד ניתנת הלגיטימציה לפעול לתיקון ליקויים ולכל אחד ניתן גיבוי בעת התמודדות עם אירוע כשל היא תרבות שמאפשרת לארגונים באמת להיות בטוחים ויציבים יותר ולא רק ליצור מצג שווא של בטיחות.
הפוסט הזה לא פושט מושלם, הוא פוסט של התחלת דיון שאני לא מבין בעצמי עד הסוף על שינוי בתפיסת ההתאוששות מאסון בעולמות שלנו, עולמות ה IT.
זה מתגלגל לי בראש מאז שראיתי את הציוץ הזה של ג'אסטין וורן:
והניסוח הזה שלו, Always Be Falling מסקרן אותי אבל אני לא מצליח לשים את האצבע על המקור של הניסוח הזה ועל הכוונה המלאה שלו. בתשובה לשאלה שלי, הוא מפנה לחומר קריאה, גם לזה של סידני דקר, ובשורה תחתונה מפנה לחפש חומר על Resilient Design ולכאן ננסה לחזור לדעתי בפוסט הבא כי כאן אני חושב נמצאת הפואנטה, כאן עוברים מהרוח לחומר וכאן יורדים מהפילוסופיה של תכנון שריד חדש אל הארכיטקטורה של MS SQL שמוגדר עם Always ON מעל שרתים של VMware שמוגדרים עם HA מעל מערכות אחסון יתירות עם רפליקציה והכל ארוז בפתרון סטייל Continuity שיודע לוודא עבורנו את הקונפיגורציה של כל ה Stack ארוז ביחד ומוגדר נכון.
מחכה לשמוע מה דעתכם,
תשטפו ידיים ואם לצטט את דניאל פאר באמירה קלאסית שנשארה רלוונטית גם בימי קורונה, שמרו מרחק, שנוכל להיפגש!
ניר מליק
ניר מליק 