עלות תחזוקת תוכנה - מספרים מקובלים

ברצוננו לציין שישנה שונות רבה בנושא של דמי תחזוקת התוכנה. בד"כ מקובל לכלול תחת תחזוקת תוכנה נושאים של תיקונים (patches) , שירות ותמיכה טלפונית (לעיתים גם באתר הלקוח) , וזכות לשימוש בגרסאות חדשות של המוצר שיוצאות במהלך ההסכם. אחד הפרמטרים המשפיעים על העלות היא התחייבות הספק לתיקון (patch) תוך זמן מסוים וגם חלון השירות (7*24 או 8*5 וכד').
נושא זה מועד לתהליכי משא ומתן מורכבים כאשר בסופו של דבר טווח המחירים שאנחנו רואים בשוק הוא בין 10% לבין 20% ולפעמים יותר לשנה מעלות הרכש (לא מחירון). כאמור זהו כלל אצבע וישנה שונות.
לחברת STKI מידע לגבי עלות תחזוקת תוכנה של מספר לא מבוטל של מוצרים. לקוחות STKI מוזמנים לבדוק איתנו נושא חשוב זה.

דוגמה לתהליך ניהול שינויים אצל לקוח מהמגזר הפיננסי

להלן רשמים לגבי תהליך ניהול השינויים אצל לקוח מהמגזר הפיננסי .
ב- MF "העולם יחסית מסודר" – יש טופס שינויים – כולל מעקב אחורה.
לגבי סביבת ה- OPEN, פתחו בארגון מערכת ספציפית מבוססת .net לניהול השינויים ותזמונם בארגון. זאת עקב העובדה שיש בארגון מערכות שעובדות 24 שעות. אחרי הצהריים יש שידורים גיבויים – עובדים 24 שעות. כלומר יש צורך לתאום ההשבתה מבחינת הלו"ז ומימד נוסף הוא התייחסות לגורמים שמעורבים בהשבתה. המשתמשים השונים מה- IT נגשים למערכת דרך ה- outlook – כלומר workflow שעובד דרך outlook. והכל מתועד בתוך מסד נתונים של המערכת. לדוגמה יש תעוד איזה PORTS ב- FW נפתחו בגלל דרישה לאיזה שינוי. הנוהל בארגון הוא שאם יש שינוי טכני –לדוגמה איש תקשורת סגר PORT – הוא חייב לעדכן את מסד הנתונים. זה הנוהל שתבצע באופן עקרוני אבל ישנם מקרים שהגורמים (בדרך כלל הסיסטם) שוכחים לעדכן בגלל עומס. בזמן תהליך השינוי –גם צוות השו"ב מעורב וגם צוות ה- DRP.
ההגדרות במערכת מתבצעות לפני שמכניסים לייצור. ולאחר השינוי ישנו עדכון שהדברים התבצעו. כל זאת גם בכדי להכין את צוות ההפעלה שמגיע בתחילת הבוקר (השינויים מתבצעים בדרך כלל בלילות). לדעת הלקוח, המערכת משקפת את המצב בפועל (מה מותקן על איזה דיסק ועל איזה שרת, איזה PORTS פתוחים ומדוע, וכד') במידה של כ- 97%.
בארגון קיימת מערכת שליטה ובקרה של IBM-מוצר השליטה והבקרה כאשר מערכת ניהול השינויים ( .net ) מעדכנת את ה- מוצר השליטה והבקרה. מתבצע גם עדכון לרמת ה- DRP. נכון להיום יש אפשרות גם ב- מוצר השליטה והבקרה – לבדוק מה תהייה ההשפעה על שינוי\השבתה של רכיב מסוים. הלקוח העיקרי של מוצר השליטה והבקרה \ שו"ב– הוא service desk כאשר יש דגש על כך שלא רוצים להתיש אותם בהרבה הודעות (לא תמיד מסתכלים על הצבעים).
לדוגמה, אם CONTROL-M – נפל ואז מערכת סניפית לא מעודכנת לגמרי ואז ה- מוצר השליטה והבקרה מקבל חיווי ומודיע על הבעיתיות ל- service desk. כל זאת לפני שמתחיל היום וזה מתבצע בגלל המפה העסקית של התהליך שנמצא בשו"ב – מוצר השליטה והבקרה.
גודל צוות השו"ב הוא 3.5 משרה מלאה שלהם.
בסביבת השו"ב יש אפשרות להכניס את המערכת למצב של תחזוקה. וזאת מכיוון שללא פונקציה זו יש בעיה – כאשר עושים שינוי – מקבלים המון חיווים של תקלות. ולכן יש להם אופציה של הכנסת המערכת למצב תחזוקה- ואז לא מקבלים חיווים (כולל שליחת SMS וכד')

ניהול שינויים

להלן רשמים ראשוניים ממפגש שולחן עגול בנושא ניהול שינויים.

התמונה הכללית שעולה היא שארגונים מקיימים תהליך מסודר של ניהול שינויים – תאום השינוי, בדיקה לגבי השפעות השינוי, דרכים לביצוע failback וכד'. אצל רובם של הארגונים התהליך מתבצע באמצעות מערכת ממוכנת.
אולם, אצל רובם המכריע של הארגונים, כל שינוי מתבצע בצורה פרטנית ללא הסתכלות מערכתית וללא הסתכלות על היסטוריה. לכן ישנם מקרים של תקלות בעייתיות – לדוגמה אחד הלקוחות תאר מצב בו הורד קו גיבוי של תקשורת והסתבר שאחת האפליקציות בייצור הפסיקה לעבוד.
בגדול, לקוחות התייחסו ל-4 סוגים של בעיות (חלקן קשורות) במצב הנוכחי:
1. התייחסות למשאבים – אין התייחסות כוללנית למשאבי ה-IT לדוגמה, אין רישום מרכזי של "באיזה שטחי דיסק משתמשת אפליקציה X" או לחילופין "איזה אפליקציות יושבות על דיסק Y". לעיתים מידע זה נמצא אבל בתור יוזמה פרטית \ שיטת ניהול של מנהל המשאב (בדוגמה שציינתי – מנהל האחסון).
2. כאשר ישנה תקלה, קשה לזהות את מקור התקלה כלומר ישנה בעיה של Problem determination או root cause analyses .
3. בעיה שקשורה לבעיה הקודמת – אם מסתמכים על הזנה ידנית של מהות השינויים והקינפוג, טעות או פיספוס בהזנה יגרום לכך שזיהוי תקלה יהיה כמעט בלתי אפשרי. לדוגמה אם מתקינים switch חדש ברשת אבל טועים בהזנת כתובות ה- IP, המשתמשים יעבדו ללא בעיה אבל ברגע של תקלה לא ידעו כלל כיצד להתחיל לטפל כי לא מכירים כלל את כתובות ה- IP.
4. גם אם יש תיעוד של הפרטים הטכניים אצל (לדוגמא) איש האחסון או איש האבטחה, בזמן תקלה לא ניתן להגיע לתיעוד זה ולהשתמש בו.
5. ישנן גם בעיות נוספות שפחות הוזכרו בסיטואציה של ניהול שינויים - capacity planning , עמידה ברגולציה מבחינת רשיונות תוכנה, DRP וכד'.
תחת תמונה זו רצוי לציין לטובה את ה"ארגון הפיננסי" שמופיע לקראת סוף הסיכום, ואשר פיתח מערכת ייחודית לסביבת ה- OPEN שבה ישנו רישום כולל של כל המאפיינים הנדרשים של "עץ המערכות" בארגון עם workflow מלא לביצוע השינויים האפליקטיביים והתשתיתיים. בארגון מתקדם זה כל השינויים נרשמים ונשמרים במקום אחד.
לקוחות רבים מצפים להטמעה של סביבת CMDB אשר גם תנהל את השינויים בצורה אחודה וגם תוודא את ביצוע השינויים. לדוגמה, אם מחליטים לפתוח PORT ב- FireWall מסוים, השינוי יופיע במערכת ולאחר מכן המערכת תוודא שהשינוי אכן התבצע כאשר התועלת העקרית שלקוחות מצפים מסביבת CMDB היא שבזמן תקלה ניתן יהיה בקלות לאתר את המקור.

ביום א' ה- 14 לספטמבר יתקיים מפגש שולחן עגול בנושא של ניהול שינויים ITIL CMDB

הנושא של ניהול שינויים בסביבת ה- IT הנו אחד הנושאים המורכבים והמשפיעים ביותר על המציאות היום יומית של העוסקים בתחום. על פי מחקרים, בניהול שינויים בעייתי הנו אחד הגורמים המשמעותיים שמשביתים מערכות.

במקביל, ישנה חדירה לשוק של טכנולוגיות שאמורות להקל במשימה בעייתית זו. החל ממוצרים המוגדרים כ- Configuration Management אשר מסייעים לאנשי הסיסטם לשמור על מצאי טכנולוגי ואפליקטיבי עדכני, המשך במוצרי CMDB Population אשר בונים את ה-CMDB וכלה במוצרים שמשתמשים ב- CMDB לניהול תהליכי השינוי תוך שימוש בסביבות workflow מתקדמות.

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



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

1. באיזה תדירות מתבצעים שינויים במערכות הייצור.

2. מהו נוהל הכנסת השינויים

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

4. האם ישנו קשר בין סביבת פיתוח התוכנה – SCM- software configuration management לסביבת הייצור?

5. איזה מוצר משמש בארגון כ- configuration management וכיצד משתלב המוצר בתהליך ניהול השינויים?

6. מה מדיניות הארגון מבחינת בדיקות לקראת שינויים בייצור?

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





המפגש יערך ביום א' ה- 14 לספטמבר בשעה 09:30 עד 13:00 לערך במשרדנו אשר בבני ציון. במפגש יוגש כיבוד קל.



אם ברצונכם להשתתף אנא הירשמו במייל חוזר או בטלפון: 09-7907000 אתי או שמרית.

אנו מזכירים שמדיניות STKI אינה מאפשרת לספקים\יצרנים להשתתף במפגשים מסוג זה.

כמו כן, ישנה הגבלת השתתפות של שני אנשים מאותו ארגון.

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

להלן מספר מגמות רלוונטיות בתחום של שליטה ובקרה, CMDB וניהול שינויים:
Cmdb אכלוס בתחילת הדרך – כבר מקבלים תוצאות
Cmdb ניהול פעולות שלם כולל change management ממש בתחילת הדרך
Run Book Automation - RBA טכנולוגיה שיכולה לשדרג את התפעול. שווה בדיקה. בתחילת הדרך.
Real End User Monitoring מוצרים כמו optier או bristole (כיום חלק מ- HP). יכולים לעזור מאוד באפליקציות בעייתיות.

מגמות בתחום תחנות הקצה

להלן מספר מגמות בתחום של תחנות קצה
VDI מתחיל להכנס. שווה לבדוק נישות מתאימות
Application Streaming מוצר כמו softgrid . מתחיל להכנס. שווה לבדוק נישות מתאימות
Virtual Software Appliances בעתיד התוכנות יגיעו לתחנות הקצה כ- virtual machine וירוצו על ה- hyperV של תחנת הקצה. בתחילת הדרך
VISTA –Windows 7 VISTA מתקדם לאט מהצפוי. יש לקוחות שנמצאים ב- XP ושוקלים לדלג על VISTA ל- Windows 7.
Office 2007 בשלבי כניסה לארגונים

מגמות רלוונטיות בתחום האחסון

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

Solid stage drives - תחילת הדרך- יגיע כחלק מהמארזים המהירים. נכון להיום יחסית יקר.
אחסון ירוק - שמכבה את עצמו כאשר אין שימוש בדיסקים – יגיע כחלק מהמארזים החדשים
Fiber Channel over Ethernet סטנדרט בתחילת הדרך
Thin provisioning הקצאה של over booking ברמת האחסון. מתחיל להיות סטנדרט במארזים. רצוי להתחיל לבדוק. ספקים שונים מתייחסים בצורה שונה לנושא.
Deduplication – גיבויים בתחילת\אמצע הדרך אבל שווה להכנס לבדיקה. כבר יש שינויים גדולים בשוק - רכישות של ספקים כמו Diligent בסופו של דבר רוב התכונות יתקבלו דרך תוכנת הגיבוי.
Deduplication – באחסון רק בטווח הארוך
CDP – Continuous Data Protection שווה בדיקה כאופציה לגיבוי בסיסים רחוקים

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

להלן התייחסות קצרה למספר מגמות רלוונטיות למנהלי תשתיות

Open source . מגמה ענקית. שימוש בכלי open source באופן כללי (לא רק linux ) כמו bpm etl כלי פיתוח שונים וכד'. – מגמה בתחילת הדרך בחלק המתחומים אבל בחלק מהתחומים כבר אלטרנטיבות גם לארגוני IT בוגרים. שווה לעקוב.

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

הערה טקטית - תמחור תוכנות לפי CORE ולא לפי CPU. מומלץ לבנות מערך שיאפשר לדעת האם מותקנים CPU או יש שימוש ב- CORES וגם מומלץ להנחות את גורמי הרכש לביצוע רכש לפי CPU ולא לפי CORES

דרישות ממערכת email archiving

• צמצם גודל תיבות דואר – צמצום גודל מסד נתונים. כמה מצמצם? לבדוק בניסוי.
• שהמידע יהיה דחוס ויוכל להשמר על מדיה זולה. ברמה של הביצועים שצריך.
• מנגנון של archiving פנימי = כלומר העברה של מידע אוטומטית לקלטות – ללא שימוש בתוכנת גיבוי כלומר ארכיון לתוך קלטות.
• הורדת עומס משרתי ה- email. בכמה מוריד?
• שחזור וגיבוי – במערכת הטובות ניתן לשחזר הפריטים שאורכבו ברמת פריט בודד (ללא שימוש ב- BRICK LEVEL).
• זמינות. מה קורה כשה- exchange נפל – האם ניתן לגשת לארכיון ישירות דרך ממשק WEB
• PST -למוצרים הטובים יש סריקה של רשת, מציאה של PST זיהוי וטעינה של קבצי ה- PST (לפי קריטריונים) לתוך הארכיון.
• Single instance גם ל- mail וגם ל- attachments.
• האם יש אופציה של מרכוז או ביזור של הסביבה. וגם של האפליקציה וגם של שרת ה- SQL שם יושבים הנתונים.
• האם יש אופציות של cache בכדי לשפר את הביצועים?
• חיפוש בתוך ארכיון האם multithread .
• כיצד המוצר מטפל בדואר (או מסמכים מצורפים) מוצפנים.
• האם חיפוש של multi mail box.
• האם ניתן להשתמש במידע שנמצא בארכיון באמצעות כלי תשתית שונים – לדוגמה שמנוע ה- Sharepoint ישתמש במידע שנמצא בארכיון.
• כמובן – חיפוש בפורמטים שונים – pdf וכד'.
• סינכרון מלא מול active directory שקוף ! לא צריך להגדיר משתמשים פעמיים.
• מה הפרמטרים לארכוב \ Policy – בסיסי - לפי פריטים תאריך, גודל . מתקדם - ברמה של שאילתות SQL לדוגמה, בצע ארכיב אם "נשלח מחיים בגודל 100K " "מכיל את המילה שיווק אבל לא מכיל את המילה חשבונית או תשלום" "אם משתמש ממחלקת הכספים שלח email או שהמנכ"ל מופיע במכותבים" וכד' לפי זה לעשות ארכיב או שחזור או מחיקה מתוך הארכיון.
• ביצועים – באיזה מהירות המערכת יכולה להתמודד עם הודעות כולל אינדוקס שלהם. לדוגמה האם המערכת יכולה להתמודד עם קצב של 100K הודעות בשעה?
• בדיקה של וירוסים או compliance. כלומר להפנות email עם תוכן "פסול" לכ"א.
• לוודא מצב שבו אם מתנתק הקשר בין ה- exchange לבין הארכיון, ובדיוק באותו רגע ישנה מחיקה של פריט דואר שחלקו יושב בארכיון. האם ברגע שמתחדש הקשר , הארכיון יודע למחוק את הפריט (מניעה מצב של orphans).
• תמחור – לפי תיבה, לפי גודל, וכד'.
• מהן יכולות הניהול של הכלי (מידע על ביצועים, errors, capacity planning כלומר "עוד 10 ימים מתמלא").
• איפה נשמר האירכוב והאם הוא מוגן מפני מפריצה?
• רגולציה- התייחסות ספציפית ל- SOX וכד'.
• עברית – בעיקר לכל מה שקשור לחיפוש ולתצוגה. שיהיה אפשר לשלב בין עברית לאנגלית בחיפוש.
• ארכיון מתוך ה- public folders
• תמיכה ב- LAPTOPS – כלומר שיווצר עותק של הארכיון גם ב- LAPTOP
• ביצוע journaling – כל email שמגיע לתיבה מסויימת נכתב לארכיון לצרכי רגולציה. זה חלק בסיסי מתמיכה ב- רגולציה.
• מנוע ארגוני לחיפוש רגולטיבי - מיועד לחיפוש מעמיק בחתכים מתקדמים על פני כל הארגון לצורך הפקת דוחות ובמידה ונדרשים לעמידה בתקנים רגולטיביים

• התאוששות מאסון.
• Dual homing – חומרה.
• הרשאות לכמה תיבות ביחד (באותו זסמן)

• מה קורה אם יש אסון ניתן ? האם אפשר להתאושש?