אירוע? תקלה? בעיה?

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

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

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

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

מן הראוי לציין שלא כל אירוע הוא תקלה – ישנן התרעות רבות על אירועים המתרחשים ואנו רוצים לקבל על כך התרעה לטובת יידוע ומעקב ואינן חורגות מהסף שהוגדר בארגון כתקלה (למשל: אם שרת מגיע למצב של צריכת 80% מהזיכרון של יחידת העיבוד המרכזית (CPU) נרצה לדעת על כך, אך רק אם הצריכה תעבור את רף ה-90% יוגדר המצב כתקלה). היכן, אם כן, יש לשרטט את הגבול? לפי קריטריון ההשפעה על השירות – אם השירות אינו נפגע (או עתיד להיפגע בטווח הזמן המיידי) כתוצאה מן האירוע – לא תדווח תקלה. פעולה מסויימת אינה מסווגת בהכרח כאירוע או תקלה, אלא מדובר בשתי ישויות המתקיימות זו לצד זו: תחילה צץ האירוע, כאשר מעבר לסף שהוגדר, נפתחת תקלה לטיפול הצוות הרלוונטי, בזיקה לאירוע. במילים אחרות, האירוע והתקלה מתנהלים במקביל, כאשר סיום התקלה הוא לאחר סיום הטיפול וקבלת אישור תקינות הלקוח (או נציגו) ואילו האירוע מסתיים ברגע שמערכת הניטור מזהה שתם האירוע. ברוב המקרים, סיום הטיפול בתקלה יגרום לסיום האירוע, כך שמשך התקלה הכולל יהיה קצר ממשך האירוע הכולל, אך ייתכן גם מצב שבו האירוע מסתיים בטרם התקבל תקינות מהלקוח, כך שהתקלה נסגרת רק לאחר סיום האירוע.

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

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

מושג חמקמק שלישי הוא בעיה (Problem). בניגוד למה שרבים חושבים, בעיה אינה תקלה חוזרת, אלא סיבת השורש של תקלה אחת או יותר. לרוב, התקלות נפתרות על ידי פתרון קל ומהיר ("פלסטר") מבלי לפתור את העניין מן השורש, אך למעשה מאחורי כל תקלה עומדת בעיה שורש הממתינה לפיתרון. עם זאת, בשל משאבים מוגבלים של הארגון (תקציב, כוח אדם, זמן), לרוב לא ניתן לנהל את כלל הבעיות. תהליך ניהול הבעיות הוא התהליך שבמסגרתו מטופלות אותן בעיות שבחרנו לנהל. כיצד בוחרים אילו בעיות לנהל? לשם כך הומצא מיני-תהליך בשם I2P (ראה מסגרת). להבדיל ממערכת היחסים שבין אירוע לתקלה שהוא גרם, סיום הטיפול בתקלה אינו ממתין לפתרון בעיית השורש, אלא מבוצע בזמן אמת, בעוד שהבעיה נחקרת ומטופלת באפיק נפרד. תכליתו של תהליך ניהול הבעיות היא למנוע מתקלות להישנות ובכך לשפר את זמינות השירות. לרוב פיתרון הבעיה יצריך ביצוע שינוי.

תפעול רשתי

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

תלות גומלין זו מתבטאת בכך שניתן ליצור קריאה אחת מתוך קריאה אחרת:

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

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

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

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