מנהיגות בהייטק #19—תפקיד המנהל/ת בניהול אירוע
באמצע הארוחה המשפחתית הטלפון מצלצל. המערכת נפלה ושום דבר לא עובד. חנה מנסה להבין מה הבעיה אבל עדיין תקועה וצריכה עזרה. מה עושים?
בפוסט הפעם אתרכז בתפקיד המנהל/ת *בזמן* ניהול האירוע, כאשר הפוסט הבא יתרכז בתפקיד המנהל/ת בזמן תחקור האירוע. ההפרדה בין שני השלבים היא קריטית, וערבוב ביניהם הוא מקור לטעויות קשות מאוד. בזמן האירוע, יש לנו מטרה אחת מעל לכל:להחזיר את המערכת לפעולה כמה שיותר מהר. בזמן תחקור האירוע, המטרה שלנו לימוד בצורה רחבה כמה שיותר – למנוע תקלות עתידיות.
ישנן שתי מטריקות רלוונטיות:
- הזמן שלוקח להתאושש מתקלות, MTTR, או Mean Time to Recover.
- הזמן שעובר בין תקלות, MTBF, או Mean Time Between Failures.
בזמן האירוע אנחנו מתרכזים אך ורק בהתאוששות מהתקלה. כל דבר אחר הוא הסחת דעת ותגרור בהכרח עליה בזמן ההתאוששות. לאחר שהחזרנו את המערכת לפעילות, ניתן לבצע תחקיר מעמיק, להבין איך ניתן לשפר בעתיד הן את זמני ההתאוששות (MTTR) והן את הזמנים בין תקלות (MTBF). על כך, כאמור, בגיליון הבא.
אוקי, אז עלינו לשיחת ועידה עם חנה כדי להבין איך אפשר להחזיר את המערכת לפעילות כמה שיותר מהר. מכיוון שכך, לא באמת מעניין אותנו מה באמת נשבר ולמה. אם נצליח להחזיר את המערכת לפעילו בלי באמת להבין למה, זה בסדר ל*כרגע*. אחרי שהמערכת תעבוד נוכל להבין מה נשבר ולמה התיקון עבד. מבחינה טכנית, יש עיקרון אחד חשוב במצבים כאלה:
בניגוד לדעתם של מיליוני מתכנתים, מחשבים הם מכונות דטרמיניסטיות. אם משהו עבד מקודם ועכשיו לא עובד, אז משהו השתנה. זה יכול להיות שינוי ב:
- inputs – לדוגמא, עלייה בכמות המשתמשים.
- environment – לדוגמא, תקלה פיזית שהפילה כמה שרתים.
- code – נכנס שינוי בהתנהגות המערכת.
- configuration – לדוגמא, בוצע שינוי בהגדרת הזמן בין retries.
הדרך הישירה ביותר להחזרת המערכת זה למפות את כלל השינויים שקרו בין הזמן שבו המערכת עבדה, לבין הזמן שבו המערכת קרסה, ואז לחזור אחורנית במידת האפשר. לדוגמא, עם שינויי קוד הגיעו לפרודקשיין, נחזור אחורנית לגרסה האחרונה שבה המערכת עבדה. עקב אכילס בארגונים רבים זה היכולת להבין איזה שינויי קונפיגורציה קרו. בכל מקרה, שווה לחזור על זה שוב: עדיף *מאוד* ללכת *אחורה*, ולא לנסות לתקן את הבעיה. התחושה בזמן האירוע היא שב50% מהמקרים זה אפשרי, למרות שבפועל ב90% מהמקרים זה אפשרי.
עכשיו, בוא נחזור אלינו כשנעלה לשיחת הועידה. התפקיד שלנו הוא לא לפתור את הבעיה, התפקיד שלנו הוא לעזור למפתחות ומפתחים לפתור את הבעיה. מה זה אומר בפועל:
- בראש ובראשונה, להעלות לשיחה את הא.נשים הנכונים/ות. חלק מתפקידי המנהל/ת הוא לדאוג לזרימת מידע יעילה בתוך הארגון. כדי שנוכל לעשות זאת, עלינו להכיר את המבנה הארגוני הרשמי, כגון איזה צוות אחראי על איזה תחום. בנוסף, עלינו להכיר את המבנה הארגוני האמיתי, ששונה בהכרח מהמבנה הארגוני שמופיע בתרשימים. זה אומר לדעת מי המומחה בכל תחום, זאתי שאליה כולם פונים כשיש בעיה בתחום מסוים. ע״ב הידע הזה, תפקידנו בזמן ניהול האירוע הוא להבין מי לא נמצא כרגע בשיחה, ולהביא אותם/ן.
- להכווין את הדיון לכיוון פרודוקטיבי. כאמור, המטרה בזמן ניהול האירוע הוא להחזיר את המערכת כמה שיותר מהר. אבל יש נטייה טבעית לנסות ולתחקר תוך כדי. לקיחת ״הצעד אחורה״ שלנו בזמן ניהול האירוע ומתן המקום למפתחים/ות לעבודה הטכנית מאפשרת לנו לשים לב שאנחנו סוטים מהעבודה על החזרת המערכת לפעילות. כשאנחנו עמוק בעבודה הטכנית לא נשים לב שאנחנו משקיעים זמן ומשאבים בהבנת ההתנהגות במקום בהבנת השינויים. לכן, כמנהלים/ות, נפקח עיניים ונתערב כשזה קורה. איפה עוד נתערב? כשאנחנו מזהים שהדיון עובד לפסים אישיים, או כשאנחנו מזהים שאחד הא.נשים לא מצליח להשחיל מילה.
- לאפשר מקבול עבודה מיטבי. אחת הדרכים לקצר זמנים היא להגדיל את המקבול. לכן, נוודא שכל פרק זמן קבוע, נעצור כדי לשתף תמונת מצב: מה קרה, מה ניסינו עד עכשיו, ומי עובד/ת על מה. אם אין בארגון כלים פנימיים מיוחדים לניהול אירוע, אני ממליץ מאוד לפתוח מסמך משותף שבראשו יש את תמונת המצב העדכנית ואת ערוצי העבודה השונים. בגוף המסמך כל מוביל/ה ירשום את הסטטוס, כיווני החקירה, וכו׳. מעבר לכך שזה יאפשר כמה כיווני עבודה מקביליים, זה יקל מאוד על הכנסים א.נשים חדשים לניהול האירוע (ראו את התפקיד הראשון שלנו).
עכשיו, בהחלט יכול להיות שבארגונים רבים המנהל/ת הוא גם הדמות הטכנולוגית הראשית. אם זה המצב, כנראה שאתם/ן תוכלו לתרום גם בצורה ישירה לפתרון הבעיה. כאן המטרה הראשית עומדת בעיניה: אנחנו רוצים להחזיר את המערכת לפעולה כמה שיותר מהר. במצב כזה בהחלט נכון להפשיל שרוולים ולתרום גם בפן הטכני. במצב כזה אתם/ן חייבים להשאיר זמן כל כחצי שעה לעצור את העבודה הטכנית ולבצע את העבודה הניהולית שעליה דיברנו. ובמידת האפשר, הייתי ממליץ לבצע את התחקור הטכני ״מאחורי הקלעים״ ולשלוח את ההמלצות ורשמים שלכם/ן למפתחים/ות בהודעות אישיות ולא בקבוצה. בסופו של דבר, אתם/ן צריכים לבנות ארגון שידע לתפקד בלעדיכם.
בגיליון הבא נדבר על תחקור האירוע. עד אז, מה הטיפים שלכם/ן לניהול אירועים?