מנהיגות בהייטק #20—תפקיד המנהל/ת בתחקור אירוע
תפקיד המנהל.ת בתחקור אירוע
בגיליון הקודם דיברתי על תפקיד המנהל.ת בניהול אירוע – מצב שבו המערכת לא מתפקדת כרגיל. כזכור, במצב זה ישנה מטרה אחת בלבד: החזיר את המערכת לתפקוד תקין כמה שיותר מהר. לצורך כך, לא משנה בכלל מדוע המערכת איננה מתפקדת כרגיל. אבל, לאחר שהחזרנו את המערכת למצב תקין ורמת הלחץ ירדה, אנחנו יכולים לחקור את נסיבות האירוע כדי לשפר את ביצועי המערכת – המערכת הטכנית והמערכת הארגונית. כמו בגיליון הקודם, נתחיל בסקירה כללית של איך לבצע תחקור אפקטיבי ונסיים בדגשים מנקודת המבט הספציפית של המנהל.ת.
בתחקור האירוע אנחנו רוצים לשפר את המערכת. ישנן כמה מטריקות קלאסיות שיכולות לעזור לנו לכמת את השיפור:
- הזמן שלוקח להתאושש מתקלות, MTTR, או Mean Time to Recover.
- הזמן שעובר בין תקלות, MTBF, או Mean Time Between Failures.
בהחלט ניתן להשתמש במטריקות אחרות, אבל חשוב שיהיה לנו מדד כלשהו כדי שנוכל להבין האם התחקורים בכלל עוזרים לנו, והאם הם שווה להשקיע בכלל בשיפור המערכת. בהחלט יכול להיות מצב שבו הגדרנו מטריקה כSLA, Software License Agreement, או כהסכם ביננו לבין הלקוח, לגבי רמת הזמינות של המערכת. אם המערכת עומדת בתנאי ההסכם, גם בהינתן התקלה האחרונה, בהחלט יכול להיות שניתן תיעדוף נמוך יותר למשימות ספציפיות שיצוצו בתחקור האירוע. אולם, פרמטר אחד שקשה מאוד לכמת אותו הוא ההשפעה התרבותית של ביצוע תחקיר רציני. (ויש עוד המון מה לומר על תרבות ארגונית בעתיד). לכן, אני ממליץ תמיד לבצע תחקיר מעמיק בכל מקרה שבו המערכת לא מתפקדת.
הכלל הראשון הוא להגיע לגורם השורש. במבט ראשון יצוצו מייד על התסמינים של התקלה. אבל עליכם לשאול ״למה?״ פעם אחר פעם עד שתגיעו לגורם השורש. הנה דוגמא:
- המערכת קרסה כי פרמטר הקונפיגורציה היה לא תקין. למה הקונפיגורציה הייתה לא תקינה?
- הקונפיגורציה הייתה לא תקינה כי המודול X ששוחרר לפרודקשיין לא תאם לגרסה של המודול Y. למה?
- המודולים לא תאמו כי הייתה טעות בהגדרת קובץ התלויות בין מודולים. למה?
- הגדרת התלויות נעשית באופן ידני, ובסביבת הבדיקות התלויות עודכנו. למה?
- סביבת הבדיקות וסביבת הפרודקשיין משתמשים בגרסאות שונות של קבצי הגדרת תלויות.
זאת אולי דוגמא שהמצאתי, אבל היא לא מופרכת לגמרי. אם לפני התחקור עומק המסקנה הייתה לנזוף במפתח שהגדיר קובץ קונפיגורציה, הרי שלאחר התחקיר המסקנה תהיה לשפר את התאימות בין סביבת הבדיקות לסביבת הפרודקשיין. במקרה הראשון, הלימוד יסתיים כשאותו מפתח יעזוב את החברה או כשמפתחת אחרת תחזור על אותה טעות. במקרה השני, לא רק שהמערכת תמנע ממקרים כאלה לחזור ללא קשר לזהויות המפתחים.ות, אלא שהיא תמנע גם מתקלות אחרות לחלוטין מלהגיע לפרודקשיין.
בסופו של דבר התחקיר חייב לאפשר לנו לזהות שינויים מעשיים שאנחנו יכולים לבצע במערכת שיאפשרו לנו לפחות אחד משלושת הפרמטרים הבאים:
- MTTD, Mean Time to Detection: תוך כמה זמן אנחנו מזהים שיש בכלל בעיה במערכת.
- בהינתן שזיהינו את התקלה, תוך כמה זמן החזרנו את המערכת לכשירות.
- כמה זמן עובר בין תקלות, או איך ניתן למנוע תקלות באופן כללי.
לשם כך, חשוב מאוד שבתחקיר נתחיל מאיסוף המידע הגולמי. מתי בדיוק התקלה בתחילה? מתי זיהינו את התקלה? איך זיהינו את התקלה (מהתראה אוטומטית ועד לקוח שמתלונן בתקשורת)? מתי זיהינו איך להחזיר את המערכת לכשירות? כמה זמן הלך לכיוונים לא נכונים? מתי התיקון הגיע לפרודקשיין? מתי המערכת חזרה לכשירות?
איסוף המידע הגולמי עוד בטרם מתחילים את שאילת ה5-whys עוזר למרכז את החקירה והדיון סביב העובדות ולהרחיק את הדיון ממקום אמוציונלי אל הטחת האשמות.
וכמה דגשים מנקודת המבט של המנהל.ת:
- חשוב לשמור על התהליך מרוכז בלמידה. לכן, וודאו שלא משתמשים בשמות של א.נשים בתחקיר. ברגע שיתחיל להאשים אחד את השנייה, א.נשים ייכנסו למגננה ורמת הלימוד תרד. לכן, התערבו מיידית ברגע שמתחילים האשמות. הסבירו שאנחנו מתרכזים בלימוד ומציאת אשמים זה פשוט לא רלוונטי לתחקור.
- בתחקור עומק, בשאילת ה5-why, יש נקודה שרבים מפספסים. התשובה לרוב שאלות ה״למה?״ איננה תשובה יחידה. החקירה איננה חושפת רשימה לינארית, היא חושפת עץ שגדל אקספוננציאלית בתהליך החקירה. לכן, עליכם.ן לוודא שמקבלים החלטות מושכלות בתהליך החקירה – על איזה ענף מתרכזים ואת איזה ענפים עוזבים? ולאחר מכן, עזרו למפתחים.ות לשמור על ריכוז ומנעו התבדרות. שימו זאת תחת הקטגוריה של ניהול זמן, או מיצוי מיטבי של הזמן שהוקדש לתחקור.
- אם הגורם העיקרי לתחקיר הוא גורם אנוש, סימן שלא סיימתם לחקור. **גורם השורש בעולם התוכנה הוא לעולם לא גורם אנוש**. ישנה **מערכת** שלמה שאמורה לתפקד. זה נכון שבמקרי קיצון היה מישהו עם כוונות זדון או פשוט חוסר בכישורים. אבל האם ישנם מנגנוני בקרה מתאימים? איך נראה תהליך הגיוס? מה ניתן לשפר בהינתן שיש א.נשים כאלה בעולם?
- בסיום התחקיר, אתם.ן צריכים לייצר תרבות ומנגנונים שמאפשרים ודורשים יישום של הלקחים מהתחקיר. אם כל תחקיר מסתיים במשימות להמשך שמעולם לא מיושמים, אז לא רק שכל התחקיר מאבד מערכו, אלא נוצר נזק אמיתי לתרבות הארגונית. מפתחים ומפתחות הם בדרך כלל א.נשים ציניים. כשהם רואים תהליך בירוקרטי ללא תכלית הם.ן מאבדים אמון במערכת.
- אבל, כמנהלים.ות עליכם גם לתווך את המשמעות העסקית של יישום הלקחים. כמעט תמיד חלק מהמשימות לא יהיו מספיק חשובות, במיוחד כשהן באות על חשבון משימות אחרות. במצב זה עליכם.ן לוודא שגם המפתחים.ות מבינים את הרציונל של על מה עובדים ועל מה לא. זה נושא לפסט שלם, אבל בקצרה – בנו מערכת תיעדוף פתוחה, שתגדיר באופן כללי איך מחליטים על מה לעבוד ועל מה לא. מהם הקריטריונים שעל פיהם מקבלים את ההחלטות.