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

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

אוטומציה של פעולות סיסטם system automation

לאחרונה אנחנו נתקלים בהתעניינות מחודשת בתחום של automation לפעולות אנשי הסיסטם. ההתעניינות נובעת ככל הנראה מהקפאת התקנים בגופי התשתיות ועקב כך ברצון להקל על הצוותים תוך ביצוע אוטומציה עד כמה שאפשר של פעולותיהם. לפעמים יש התייחסות לכלים של שרתים בלבד ולעיתים מתייחסים גם לתחנות עבודה.
בתחום זה חשוב באופן ספציפי להגדיר "מה רוצים" כשבגדול הקטגוריות של המטרות האפשריות של הכלי הן:
1. גילוי וזיהוי של מה שיש (כולל קשרים) ללא ביצוע פעולות.
2. ביצוע אוטומטי של פעולות הקשורות להפצת תוכנה.
3. כל מה שקשור לביצוע אוטומטי של פעולות - באופן כללי.


להלן מספר נקודות למחשבה בהגדרת דרישות מכלי בתחום זה:
1. טיפול בהתקנה של תוכנה כולל מערכת הפעלה, PATCHES, ואפליקציות באמצעות
• הגדרה וניהול של IMAGES
• הגדרה וניהול של קבצי התקנה באמצעות סקריפטים
• לאיזה רכיבים יודע להתחבר לדוגמה, אחסון, רשת, שינוי סיסמאות (דוגמה לא טריוויאלית -"דרישה לשינוי סיסמה מ- 6 ל- 7 תווים" כיצד הכלי מאתר את הרכיבים שדורשים שינוי ומבצע זאת).
2. מידת האוטמציה שהכלים מספקים מבחינת השימוש ב- Workflow. עד כמה עשירה אופציית ה- Workflow בכלי והאם היא ממומשת באמצעות SCRIPTS או באמצעות API. לדוגמה, ישנם כלים שמאפשרים ל-device להרשם כ-"מנוי" ל- policy מסויים ואז כאשר מבצעים את ה- policy כל המנויים עוברים את השינוי \ בדיקה. ואז נשאלת השאלה אם ניתן להיות מנויים לכמה policies ומה קורה אם יש התנגשויות. מבחינת האוטומציה צריך לבדוק איך מבצעים בדיקה של הלוגיקה שלא על הציוד עצמו (קל יותר לבצע דרך API). כמובן האם ניתן להשתמש ב"שגרות" בבניית ה- workflow. טיפול בשגיאות וביצוע rollback לכל התהליך.
3. עד כמה יש בכלי מידע על התנהגות של חבילות תוכנה מבחינת כיצד יש לבצע התקנה או PATHES בחבילה עם התייחסות ליחסי התלויות השונים בחבילה זו (לדוגמה, כלי שיודע לגבי חבילת SAP מה וכיצד יש להתקין). ניתן לתאר תכונה זו כ- application logic.
4. אפשרות לבצע משימות AD HOC -(כלומר שלא כ- SCRIPT שמופץ פעם בתקופת זמן) לדוגמה - שינוי משתני מערכת של שרת דרך ה- console של הכלי. בתכונה זו חשוב לשים לב לבחור כלי שמאפשר ביצוע פעולות כאלו ישירות ולא על ידי הגדרה של SCRIPT שמבצע את הפעולה המדוייקת שרוצים ואז הרצתו של אותו SCRIPT בשרת המיועד. מצד שני כן צריכים אפשרות לצור SCRIPTS כאלו.
5. סריקה של הקונפיגורציה של השרת והחלטה האם הקונפיגורציה עונה על הנדרש (מגדירים מראש כיצד נראת חוקים לקונפיגורציה של שרת רצוי). במידה והכלי מגלה שיש סטייה ממצב רצוי יש שתי אפשרויות. אפשרות אחת היא לדווח. אפשרות שנייה היא שהכלי מתקן בעצמו את המצב. (מדובר גם על אפליקציות וגם על סיסטם).
6. עבודה בסביבה וירטואלית- עד כמה הכלי יודע לעבוד בסביבה וירטואלית.
7. טיפול אוטומטי במקרים של עומסים - עד כמה הכלי יודע במידה ויש עומס להתקין שרת נוסף ולהפעיל אותו או לנייד משאבים \ אפליקציה משרת אחר.
8. מטריצת קונפיגורציה ותלויות - כיצד הכלי שומר מידע על התלויות השונות בין רכיבי מערכת המידע - הרכיבים הפיזיים, הרכבים הלוגיים. האם ניתן לקבל את מטריצת התלויות ממקורות אחרים (שכבר קיימים בארגון), האם הכלי מייצר בעצמו מטריצה זו והאם המטרציה משתנה עם הפעולה של הכלי. במחשבה שנייה מדובר על "מיני CMDB" . ונשאלת השאלה האם הכלי ידע להתממשק ל- CMDB אחר.
9. האם המטריצה שהוזכרה קודם מסייעת לארגון (בצורה אוטומטית עד כמה שניתן) לבנות את הסביבה מחדש במקרה של הפעלת מצב של DRP
10. טיפול ב- patches. הכלי אמור לקבל מידע מ(כמה שיותר) ספקים לגבי PATCHES שקיימים למוצרים שלהם ואז על פי המידע שקיים בכלי , הכלי בעצמו מקבל החלטה איפה (אם בכלל) צריך להתקין את ה- PATCHES כולל כל התלויות של אותם PATCHES.
11. עבודה של הכלי על מספר אתרים פיזיים - כולל תאום פעולות בין אתרים.
12. דוחות של הכלי - גם לגבי משאבים, ניצולום ועמידה בתקנים.
13. אבטחת מידע ובדיקות- מי יכול לתת איזה הוראה על איזה שרתים וגם באיזה שלב מבצעים איזה סוג של בדיקה.
14. קשר עם מערכות בארגון - לדוגמה השו"ב.

אלו כאמור נקודות למחשבה כאשר בוחנים כלים בתחום זה.

תנאי מספיק להצלחת פרוייקט שליטה ובקרה

בכניסה קודמת התייחסתי לבעייתיות של פרוייקטי שליטה ובקרה. כאמור, פרוייקט שליטה ובקרה נוטים להיכשל הרבה יותר מפרוייקטי IT אחרים.
ואולם, קיים לפחות תנאי מספיק אחד להצלחה של פרוייקטים בתחום זה. תנאי מספיק על פי ההגדרה הוא תנאי שקיומו מבטיח מצב מסויים והתנאי עליו אני מדבר הוא שימוש של מנהל מערכות המידע במערכת השליטה והבקרה.
כאשר מנהל מערכות המידע הוא אחד הצופים בקונסול של מערכת השליטה והבקרה, אפילו אם הדבר לא מתבצע ברמה יום יומית אלא ברמה מזדמנת, הדבר יבטיח שהמערכת תהיה "חיה ונושמת".
באחד הביקורים האחרונים שלי אצל לקוח מתקדם מהמגזר הפיננסי, הוזמנתי למשרד מנהל מערכות המידע ובו הודגמה לי מערכת השליטה והבקרה של הארגון. בפרוייקט זה מעבר לפרמטרים תשתיתיים ואפליקטיביים (מערכת למעלה או למטה, זמני תגובה, תקלות פתוחות וכד') הוכנסו למערכת גם פרמטרים עסקיים טהורים - סכומי עיסקה מצטברים בתחום מסויים לעומת הסכומים המצופים. לפיכך מדובר במערכת BAM - Business Activity Monitoring שלקוחותיה הם המנהלים העסקיים (מחוץ ל- IT). דבר זה מחזק עוד יותר את מעמדה של מערכת השליטה והבקרה.
לחילופין, בארגונים שבהם אפילו מנהל התשתיות או מנהל התפעול לא משתמשים במערכת השליטה והבקרה - גורלו של הפרוייקט נחרץ והמערכת לא תפעל במשך זמן רב...

מדוע נכשלים פרויקטים של שליטה ובקרה?

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

תחום השליטה והבקרה הנו תחום המועד לפורענות ולכישלון, יותר מתחומים אחרים בתחום ה- IT למרות שתחום זה הנו תחום בשל יציב ואשר טכנולוגית אינו מורכב. באופן עקרוני יישום פרוייקטים מסוג זה מתבצעים על ידי הצבה של agents ברכיבי המחשוב השונים אשר מדווחים למרכז נתונים חיוניים (האם השרת עובד, האם יש מקום בדיסק, האם ביצועי התקשורת סבירים וכד'). בשנים האחרונות ישנה נטייה גם ליצור "מפות עסקיות" של רכיבי המחשוב השונים.
הסיבה החמקמקה לכישלונות בתחום זה קשורה לאופיו הייחודי של הפרוייקט.
באופן טבעי, מוטל עומס רב על צוותי ה- IT השונים. ולכן, לעיתים תכופות, צוותי ה-IT שאחראים לתחזוקת הפרוייקטים אינם יכולים לבצע את כל שנדרש מהם בצורה מלאה ולכן הפרוייקט נפגע בצורה חלקית. כך למשל, אם במידה וצוות הממשקים קיבל תפקיד נוסף, ולכן משקיע 5% פחות מזמנו בטיפול השוטף בממשקים, הרי ש- 5% מפרוייקט הממשקים נפגע. באופן ברור הצוות יכוון את הפגיעה בממשקים הפחות חיוניים. כנ"ל הדבר גם בפרוייקטי IT אחרים כגון CRM, ERP, אחסון ועוד. ואולם, בתחום השליטה והבקרה, המצב שונה בתכלית. אם צוות השליטה והבקרה עמוס, ולכן משקיע בתפקידו פחות מהרצוי, אפילו ב- 5%, הרי שלאחר תקופת זמן של מספר חודשים ישנה פגיעה ב- 100% מתפקוד מערכת השליטה והבקרה. זאת מכיוון שבמידה ואפילו שינויים מעטים במערכות הייצור אינן מעודכנות לסביבת השליטה והבקרה (לדוגמה, התווסף שרת חדש, לדוגמה, הוחלפו שני routers לדוגמה השתנה מספר IP וכד') הרי שהחיוויים במערכת השליטה והבקרה אינם אמינים, משתמשי הפרוייקט אינם מאמינים למערכת ולכן יעדכנו אותה פחות, ותוך תקופה לא ארוכה, ישנה התמוטטות מוחלטת של כל פרוייקט השליטה והבקרה.
בארגוני IT לא גדולים, צוות השליטה והבקרה מונה אדם אחד (או אפילו לא משרה שלמה) וכאשר אותו אדם לא נמצא בעבודה או קיבל תפקיד נוסף ולכן לא יכול לבצע את כל העדכונים, הרי שהדרך להתמוטטות סביבת השליטה והבקרה כמעט מובטחת.

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