טיפ לכתיבת מכרז שליטה ובקרה

תחום השליטה והבקרה הוא אחד התחומים הבעייתים בתחום מערכות המידע. כאמור בפוסט קודם בתחום זה נכשלים יותר פרוייקטים מבכל תחום אחר במערכות המידע. מעבר לכך בניה של פרוייקט מחייבת בחירה בין תחומי כלים רבים שקימים בתחום. כפי שציינתי במצגת שהעברתי בכנס השנתי שלנו, החל משקף 122 ישנם בתחום טכנולוגיות סטנדרטיות (AGENTS שמדווחים למרכז), כלים לחויית משתמש, כלים המוגדרים כ- Transacation Management המפעילים Sniffing מתוחכם, כלים המוגדרים כ- APM - Application Performance Management , כלים שאני מגדיר בקטגוריה "ספציפית" (לדוגמה כלים לתחום JAVA , תחום רשתות תקשורת, תחום SAP , מסדי נתונים וכד') ועוד.
באיזה טכנולוגיה יש לבחור? כל טכנולוגיה בתחום מציעה את עצמה כ"טכנולוגיה האולטימטיבית" לתחום.
הנקודה היא שעל הארגון להגדיר בצורה מדוייקת מה הוא רוצה להשיג מפרוייקט זה. מדוייקת אינה להצהיר הצהרה "המערכת תאתר תקלות בארגון" כי אמירה זו כללית מידי. האם תקלות בתחום התשתיות? האם תקלות בעולם האפליקטיבי\עסקי? האם תקלות ברמת המשתמש הסופי? כל בחירה כזו משליכה על הפתרון המתאים. גם אמירה "תגלה תקלות בעולם האפליקטיבי \עסקי" היא אמירה כללית מידי.
ולכן, לשם הגדרה מדוייקת של מטרות הפרוייקט אנו ממליצים לעבור על התקלות המהותיות שהיו בארגון ולקבוע מה אמורה מערכת שליטה ובקרה לבצע או יותר נכון כיצד מערכת השליטה והבקרה הייתה אמורה לטפל בין הייתר בגלוי העובדה שיש תקלה, מניעה מוקדמת, מציאת הגורמים לתקלה, טיפול טוב יותר בתקלה לאחר שהתרחשה וכד'.
במכרז יש לציין גם כיצד יש לתפעל את המערכת במובן של שמירה על עדכניות ורלוונטיות. מה יהיו המשאבים לתחזוקת המערכת וכיצד תתבצענה פעולות התחזוקה.
רק תהליך כזה יכול לכוונן את הארגון למטרות ספציפיות בתוך האלטרנטיבות הרבות שקיימות בתחום. תהליך כזה מניח (ובצדק) שבניית סביבה לשליטה ובקרה הוא תהליך מתמשך ולא ניתן בשלב אחד למפות את כל הנקודות העתידיות.

לא מודדים - לא עושים

אחד מהלקוחות אמור לצאת בקרוב למכרז DRP. בישיבה שהתקיימה לאחרונה בנושא זה (הערות למכרז לפני סגירתו) עלתה סוגייה של פגיעה בביצועים. משהו כמו "יש לוודא שהטכנולוגיה שתותקן לטובת ה- DRP לא תפגע בביצועים הנוכחיים של המערכת ברמת משתמשי הקצה וברמת השרתים". הערה זו נראית טובה ומתאימה. אולם, בפועל הסתבר שנכון להיום לא מתבצעת מדידה של ביצועי המערכת - ולכן לא ניתן יהיה לקבוע האם יש פגיעה כזו. לכן ויתרנו על הוספת סעיף זה למכרז וזאת על פי "לא מודדים - לא עושים".
לסיכום, מערכת שמודדת ביצועים - end user expeience היא נדבר חשוב בתפעול יום יומי של סביבת ה- IT.

על תחום השליטה והבקרה- מגמות טכנולוגיות חדשות

להלן התייחסות קצרה לתחום השליטה והבקרה העדכנתי - CMDB ו- ITIL
ברמה הטכנולוגית CMDB הנו מסד נתונים של "configuration items - CI - שנמצאים בארגון כמו, שרת, שירות ב- windows , אחסון, אפליקציה וכד' ואפילו גם אנשים ומבנה ארגוני. כאשר ה- CI אמורים להתגלות בצורה אוטומטית כולל הקשרים ביניהם (אני ארחיב עוד מעט). המידע ששומרים על כל CI הוא רב מימדי:
1. Configuration management – מה מותקן עליו, איזה רמה של PATHES , איזה שינויים בצעו ב- registry וכד'.
2. Asset management – באיזה פקודת רכש נרכש ה- CI, עם איזה אחריות, באיזה רמת תגובה וכד'. במידה ותוכנה – כמה רשיונות תוכנה נוספים יש בארגון וכמה נוצלו וכד'.
3. מידע שקשור ל- service desk – איזה קריאות נפתחו על הCI לאחרונה וכד'.
4. כל המידע שקשור לחווים של מערכת השליטה והבקרה.
5. קשר לקונסול של אבטחת המידע. וכד'.


מכיוון שה- CMDB אמור להתגלות בצורה אוטומטית, כולל הקשרים בין ה- CI, הרי שזה אמור להקל על העבודה השוטפת של צוותי השליטה והבקרה. אולם ה – CMDB אמור לאפשר מיכון של תהליכי ITIL – פתיחת קריאות ב- service desk, ניהול בעיות (תקלות שחוזרות על עצמן) , capacity planning וכד' והכי חשוב change managment, אחד הנושאים הכואבים ביותר בארגון.

הכלי מאזין ל-PORT ואז רואה לאן זה מתנתבת התקשורת – לאיזה IIS ואז גם רואה לפי ה- ODBC לאן זה מתחבר. כלומר נותן מיפוי. זה נותן autodiscovery. צריך לקנות sensors לכל דבר- windows websphere weblogic שמים על השרת הראשי SSH ואז secure shell . וזה ניגש לcall ה- windows. ואז ניגש לכל השרתים עם סיסמת ADMIN. ה= SENSORS זה משהו שרץ בשרת הראשי וזה כמו סט של SCRIPTS שיודע להפעיל API ב- oracle applications (או אחרים) בצד שהוא מנטר. בזמן שעושה discovery אפילו מעתיק configuration files.
הרמות הן:
1. רמה פיזית – איזה חומרה מחוברת למה
2. רמה אפליקטיבית – איזה אפליקציה (כמו SAP ) מחובר לאיזה אפליקציה אחרת. צריך SENSOR ל- SAP. איך יודע – מסתכל על JDBC בתוך האפליקציה.
3. רמת business application - תהליך הוספת לקוח זה חלק מ- SAP וחלק מאפליקציה ספציפית.

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

על תחום השליטה והבקרה המסורתי

התחום המסורתי של סביבת השליטה והבקרה מדבר על AGENTS שמותקנים על הציודים השונים שמדווחים לקונסול מרכזי. כאשר בקונסול המרכזי מקבלים:
1. דיווח בסיסי פיזי (סטטוס של השרתים, routers , אחסון וכד').
2. מעבר לסטטוס הפיזי, ניתן לשייך כמה פריטים פיזיים ולקבל תמונה לוגית (business view של CA), לדוגמה, תמונת דואר אלקטרוני, תמונת ERP וכד'. כאשר ייצוג זה ידע ששלושה שרתים הם ב- load balance ואם אחד נופל אז הוא לא יצבע את הכל באדום.
בתצורה הזו יש מספר בעיות - קשה כל הזמן לעדכן את המערכת כי צריך להתקין AGNETS כל הזמן וגם לקנפג אותם בצורה מתאימה. אגב, מספר שלנו מדבר על כך שבצוות השליטה והבקרה שאחראי על בניית ותחזוקת מערכת השליטה והבקרה צריך להיות עובד במשרה מלאה על כ- 200 שרתים בערך. בעיה נוספת היא שאם רכיב בסיסי נופל מקבלים "אדום" בכל המערכת ולעיתים תכופות קשה לדעת מה באמת הסיבה לתקלה. לדוגמה, אם דיסק ב- FIREWALL נופל אז כל המערכות "צועקות" כולל התקשורת והאפליקציות , לפעמים לפני ששרת ה- FIREWALL דיווח על בעיה. כלומר יש בעיה של root cause analyses ולתחום זה יש כלים משלימים כמו לדוגמה smarts של EMC , או http://www.xplg.com/.
בעיה נוספת היא שתצורה זו מדברת במקרים רבים על מערכות "ERP" "דואר אלקטרוני" ולא על תהליכים עסקיים שמערבים כמה מערכות. כלומר תצוגה כזו לעיתים לא מעניינת את ה- business. זאת רמה שאמורה להיות גבוהה יותר. התחום נקרא BSM.

במקביל למה שתארתי עד כאן התפתח במקביל הנושא של end user experience עם המוצר המוביל hp-mercury- BAC (לשעבר TOPAZ) אבל יש גם תחרות בכמה רמות עם מוצרים כמו http://www.optier.com/ , http://www.aternity.com/ ועוד. כלים שאמורים גם הם לדווח לקונסול המרכזי. ישנם מוצרים רבים נוספים בתחום