מדידת מרכזי שליטה ובקרה NOC metrics

מדידה והערכה של גוף ה- NOC \ מרכז התפעול היא משימה קשה. זאת עקב העובדה שבמובן מסויים לגוף ה- NOC עצמו אין ממש שליטה על פעולותיו.
במונח NOC התכוונה כאן Network Operation Center כלומר ל-"חדר המחשב" או "הפעלה" או "מפעילים" או "הגשר" או "תפעול", כלומר הגוף אשר נמצא 7*24, מקורו בהרבה ארגונים במפעילי ה- MF. תפקיד גוף זה לדאוג לפקח על פעולת ה"ייצור" בארגון ה- IT ובמידה ויש תקלה לטפל בה. במידת האפשר בעצמו ואם לא להפעיל את הגורמים המתאימים.כלומר לא מדובר רק על תחום התקשורת.

כאמור חלק מהמדדים כאן הם מדדים שמתאימים רק ל- NOC וחלק מהמדדים הנם מדדים שמתאימים גם לגופים אחרים ב- IT.


פעולות ה- NOC מתחלקות (באופן גס) ל:
1. טיפול בתקלות – CASES – בד"כ לפי נוהל שהוגדר מראש ב- Run Book - ההוראות למפעילים.
2. ביצוע משימות עזר שוטפות – TASKS - (לדוגמה, מעבר על LOGS לוודא שגיבוי התבצע כשורה, התקנת PATCH של WIN על רשימה של שרתים).
בשני המקרים מי שמגדיר ל- NOC את הפעולות לביצוע הוא גוף התשתיות ולכן גם אם יש NOC נהדר לפעמים מדידת גוף זה תתן תוצאות לא טובות – זאת בגלל שגוף התשתיות לא העביר מספיק משימות\אחריות ל- NOC.

להלן מספר רעיונות\הצעות למדידה והערכה של ה- NOC ועובדיו:

1. מדדי זמינות וביצועים – לווא דווקא קשורים ספציפית ל- NOC

• זמינות המערכות. גם תשתיות וגם שירותים תוך התייחסות ל- SLA (זמינות שהובטחה ללקוחות הסופיים) ו- OLA – operation level agreement (זמינות שהובטחה בתוך הארגון בין הגופים השונים– לדוגמה OLA של סביבת האחסון).
• מדידת ביצועי מערכות (זמני תגובה של האפליקציות)
• כמה זמן עבר עד לתיקון התקלה (אפילו אם טופלה מחוץ ל- NOC ) – time to repair.
• d. Monitoring coverage - כמה מהתקלות התגלו על ידי מערכות השליטה והבקרה וכמה על ידי המשתמשים הסופיים.

2. מדדים לכמות ואיכות הטיפול ב- CASES על ידי ה- NOC

• מתוך הזמן לטיפול בתקלה (MTTR) איזה חלק מהזמן היה בטיפול של ה- NOC.
• % סגירה ב- NOC. כלומר איזה אחוז מהקריאות נסגרו ב- NOC ללא צורך להפעיל גורמים חיצוניים.
• יש ארגונים שבהם ה-NOC לוקח שליטה על עבודת HD בשעות הלילה אז נכלל פה גם מדידות HD. כמו כמות תקלות שלא נפתרו והועברו לצוות PC ללא צורך להגיע ללקוח. (שיפור הידע)
• כמה זמן מאז שהתרחשה התקלה ה- NOC התחיל לטפל (ערנות).
• כמות תקלות שנבעו מטעיות ב-NOC (בד"כ טעויות אנוש)
• איכות ה- follow up של תקלות שנפתחו במשמרת. עד כמה עוקבים אחרי התקלות בתדירות רצוייה.

3. איכות כללית של ה- NOC

• תהליך של incident מול problem. כמה פעמים ה-NOC או התומך מצאו דרך למנוע את התקלה בפעם הבאה (על ידי פעולות פרואקטיביות) או לגלות את התקלה בצורה מהירה יותר.
• עד כמה מבצע את הפעולות השוטפות (TASKS) בצורה טובה.
• איכות התעוד גם מבחינת פרטים וגם בהיבט של מועד עדכון המערכת (הזנת הפרטים בזמן הקריאה ולא בסוף המשמרת).
• איכות ה"אסקלציה" (התקשורת) – עד כמה התקשורת שבצע ה- NOC (בדרך כלל ה- MAIL ששלח או הודעות SMS ) הייתה מתאימה מבחינת בהירות המסר וניסוחו, סוג הנמענים, תוך כמה זמן התבצעה התקשורת וכד'.
• תמיכה בתהליכים חדשים (בתקופה מסויימת) ועד כמה התהליכים נקלטו בצורה טובה על ידי ה- NOC
• עד כמה צוות ה- NOC מעורב בתהליך של capacity planning בארגון והאם בצע מעקב בצורה טובה (לדוגמא התריעה מספיק זמן שהאחסון מתמלא).

4. איכות ה- run book ,ביצועו ואטומציה

• אחוז כיסוי ב- run book. לכמה מהתקלות שהתרחשו בתקופה יש run book
• עד כמה ה- run book מלא (מטפל בכל ההיבטים והאינפוטים של התקלה).
• כמה מה- run books מוטפלים בצורה אוטומטית (מדד נוסף בתחום זה – ניסויים ל- run book האוטומטיים).
• עבודה לפי run book – עד כמה ה- CASE טופל בצורה מלאה לפי מה שמופיע ב- run book.