ניהול אירועים (Event Management), ניהול תקלות (Incident Management), ניהול בעיות (Problem Management)

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

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

danbert מידע (Information) – אירועים אלו נשמרים לידיעה בלבד (לרוב בקובץ לוגים על המחשב או השרת) לטובת תחקור אוחר.

danbert אזהרה (Warning) – אירועים המתריעים מפני חריגה צפויה מסף שהוגדר. אירועים אלו מנוטרים ומנוהלים על ידי מערכת ניהול האירועים (Event Management System).

danbert חריגה (Exception) – אירועים המתריעים כי הייתה חריגה מסף שהוגדר. אירועים אלו מנוטרים ומנוהלים על ידי מערכת ניהול האירועים (Event Management System).

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

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

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

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

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

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

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

שיטות לביצוע I2P

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