מחקר STKI קובע ששנת 2009 הייתה השנה הגרועה ביותר בתפעול השוטף של מערכות מידע בישראל. בשנה זו היו תקלות רבות במערכות מידע קריטיות אשר גרמו להשבתה של תהליכי עבודה מרכזיים בארגונים בישראל.
גם בנק ישראל עד לתופעה זו ולכן פרסם הוראה בשם "ניהול נכסי טכנולוגיית מידע". בהוראה זו מתאר המפקח על הבנקים את המצב ולאחר מכן נותן מספר הוראות חשובות.
בתאור המצב מאפיין המפקח את הכשלים במערכות המחשב במגוון היבטים (ציטוט מהמסמך):
1. קושי באיתור מיידי של הרכיב שכשל.
2. קושי בזיהוי מיידי של נסיבות התרחשות הכשל- מאפיין התקלה, מקור התקלה וכד'.
3. קושי במיפוי כלל התהליכים העסקיים המושפעים מהכשל.
כאשר התוצאה של מאפיינים אלו היא עיכוב בטיפול בתקלה. (עד כאן הציטוט).
חברת STKI מזהה שני גורמים מרכזיים לתקלות רבות אלו. מצד אחד ישנה סיבוכיות רבה בארכיטקטורות המחשב – חומרה, תוכנה ותפעול. הסיבוכיות גדלה מאוד בשנים האחרונות וממשיכה לגדול. אם בזמנו היה מדובר על מחשב MF המכיל את כל התשתיות וכל התוכניות הרי שהיום מדובר על ארכיטקטורה אשר משלבת גם מערכות MF גם מערכות פתוחות המכילות עשרות מוצרים ורכיבים.
הסיבה השנייה שגרמה לנפילות מחשב היא המשבר הכלכלי שאותו חווינו ובמידה מסויימת עדיין חווים. המשבר גרם לכך שישנו קיצוץ מתמיד בתחום התשתיות ובתחום הניהול והניטור. לקוחות דוחים שדרוגים של חומרה ותוכנה, מעכבים פרוייקטים לשיפור השירות ומצמצמים בכ"א והתוצאה הבלתי נמנעת היא נפילות מחשב.
למניעה או צימצום כשלים אלו מנחה המפקח על הבנקים את הבנקים בצורה זו (שוב ציטוט מההוראה ):
1. למפות עבור כל תהליך עסקי מהותי את נכסי טכנולוגיית המידע שתומכים בו לרבות: מאגרי מידע, מערכות מידע, מערכות הפעלה , תשתיות חומרה, תוכנה ותקשורת וכד'. המיפוי יכלול את כל רכיבי ה- IT הרלוונטיים ברמה הפרטנית ככל הניתן (לדוגמה, עד לרמת נתב, switch וכד').
2. להטמיע כלי ניטור, שליטה ובקרה על כל נכסי ה- IT שמופו כאמור בסעיף הקודם על מנת לוודא תקינותם של נכסי ה- IT ובאופן שיתאפר במקרה של כשל זיהוי הנכס ואף הרכיב הספציפי שכשל, ונסיבות הכשל, סמוך ככל שניתן למועד האירוע.
3. עבור נכסי ה- IT שמופו, יקבעו הסדרי גיבוי שאיפשרו את המשך פעילות התהליך העסקי המהותי שכשל. יש לפעול למניעת מצב של נקודת כשל יחידה (single point of failure). עד כאן הציטוט.
המפקח גם קובע לוח זמנים לטיפול בהנחיות אלו.
יש לציין שהנחיות אלו ברוכות ורצוי שגם ארגונים אחרים אשר מסתמכים בצורה מהותית על מערכות המידע יטמיעו הנחיות אלו. ההנחיה הראשונה היא הנחיה יוצאת דופן וחדשנית. נכון להיום בגלל המורכבות הרבה ישנו ברובם המכריע של הארגונים "ספגטי". קשרים מורכבים בין מערכות כך שלמשל קורה לא מעט פעמים שלקוח מוריד שרת לצורכי תחזוקה ומסתבר שמערכת אחרת ש"לא קשורה" מפסיקה לעבוד. זאת מכיוון שאין בארגונים תמונה עדכנית של המערכות והקשרים ביניהם. ההנחיה הראשונה מורה לבנקים לבצע מיפוי של הנכסים ושל הקשרים בינהם. עם זאת, כבמקרים נוספים, הבנק נותן הנחיה כללית אשר יכולה להתפרש על ידי הבנקים בצורה שונה. כאשר המפקח מורה לבנקים לבצע "מיפוי תהליכים" יכולים הבנקים להציב אפילו "סטודנט" אשר יבצע מיפוי פעם בשנה של המערכות ושל הקשרים בינהם. זאת כמובן בעלות זניחה. עם זאת בנקים אשר רוצים לבצע את ההוראה בצורה עמוקה יותר יכולים לבצע אוטומציה של המיפוי עד למצב של automatic discovery שבו תהליך ממוכן ממפה בעצמו את הרכיבים של כל מערכת מחשב ואת הקשרים בין המערכות. פרוייקטים מסוג זה המוגדרים בתעשיה כ- CMDB עלולים לעלות מליוני דולארים הן ברמת רישוי התוכנה והן ברמת הטמעת המערכות. עם זאת רק ביצוע של מיפוי אוטומטי יכול לעמוד בהוראות המפקח על הבנקים בצורה עמוקה וזאת מכיוון שגם אם מבצעים תהליך ידני של מיפוי – לאחר ערב אחד – שבו בגלל תקלה מבצעים תיקון מיידי ושוכחים לעדכן את התיקון במיפוי המערכות – מקבלים מצב שבו בזמן התקלה הבאה אין תמונה אמיתית של מיפוי המערכות והקשרים ביניהם. רק מיפוי אוטומטי יכול להתקרב למיפוי אמיתי כהנחיית המפקח. עמידה בתנאי זה לעומקו תגרור את הבנקים לפרוייקטים של שנה עד שלוש שנים ולעיתים אף יותר.
לגבי שתי ההנחיות האחרות – ביצוע ניטור וביצוע כלי גיבוי, רובם המכריע של הבנקים ושל ארגוני ה- IT באופן כללי מקיימים הנחיה זו – עם כי קבלת הנחייה רשמית מהמפקח תתרום לקבלת תקציבים ועדיפות גם לתחומים אלו. גם לגבי ביצוע ניטור המפקח נותן הנחייה כללית ולא מפרט באיזה סוג ניטור. כיום קיימים מספר סוגים של מערכות ניטור. מערכות הניטור הותיקות המורכבות מ- agnet שמשדר למרכז קיימות ברוב רובם של הארגונים. אולם לביצוע ניטור אמיתי אשר מגלה גם את הרכיב התקול בצורה המהירה ביותר יש גם להשתמש במערות מהסוג של "ניטור חויית משתמש" ומערכות לגילוי מקור תקלה "root cause" ו- Business Transaction Management הפועלות בין הייתר בטכנולוגיה של sniffing. כלומר גם כאן ישנו חופש פעולה גדול של הבנקים בביצוע הוראת המפקח, חופש פעולה שישפיע על הוצאות הבנקים למילוי הוראה זו.
לסיכום מדובר בהוראה חשובה שרצוי שתהיה על שולחנם של מקבלי החלטות רבים – לא רק בתחום הבנקאי.
גם בנק ישראל עד לתופעה זו ולכן פרסם הוראה בשם "ניהול נכסי טכנולוגיית מידע". בהוראה זו מתאר המפקח על הבנקים את המצב ולאחר מכן נותן מספר הוראות חשובות.
בתאור המצב מאפיין המפקח את הכשלים במערכות המחשב במגוון היבטים (ציטוט מהמסמך):
1. קושי באיתור מיידי של הרכיב שכשל.
2. קושי בזיהוי מיידי של נסיבות התרחשות הכשל- מאפיין התקלה, מקור התקלה וכד'.
3. קושי במיפוי כלל התהליכים העסקיים המושפעים מהכשל.
כאשר התוצאה של מאפיינים אלו היא עיכוב בטיפול בתקלה. (עד כאן הציטוט).
חברת STKI מזהה שני גורמים מרכזיים לתקלות רבות אלו. מצד אחד ישנה סיבוכיות רבה בארכיטקטורות המחשב – חומרה, תוכנה ותפעול. הסיבוכיות גדלה מאוד בשנים האחרונות וממשיכה לגדול. אם בזמנו היה מדובר על מחשב MF המכיל את כל התשתיות וכל התוכניות הרי שהיום מדובר על ארכיטקטורה אשר משלבת גם מערכות MF גם מערכות פתוחות המכילות עשרות מוצרים ורכיבים.
הסיבה השנייה שגרמה לנפילות מחשב היא המשבר הכלכלי שאותו חווינו ובמידה מסויימת עדיין חווים. המשבר גרם לכך שישנו קיצוץ מתמיד בתחום התשתיות ובתחום הניהול והניטור. לקוחות דוחים שדרוגים של חומרה ותוכנה, מעכבים פרוייקטים לשיפור השירות ומצמצמים בכ"א והתוצאה הבלתי נמנעת היא נפילות מחשב.
למניעה או צימצום כשלים אלו מנחה המפקח על הבנקים את הבנקים בצורה זו (שוב ציטוט מההוראה ):
1. למפות עבור כל תהליך עסקי מהותי את נכסי טכנולוגיית המידע שתומכים בו לרבות: מאגרי מידע, מערכות מידע, מערכות הפעלה , תשתיות חומרה, תוכנה ותקשורת וכד'. המיפוי יכלול את כל רכיבי ה- IT הרלוונטיים ברמה הפרטנית ככל הניתן (לדוגמה, עד לרמת נתב, switch וכד').
2. להטמיע כלי ניטור, שליטה ובקרה על כל נכסי ה- IT שמופו כאמור בסעיף הקודם על מנת לוודא תקינותם של נכסי ה- IT ובאופן שיתאפר במקרה של כשל זיהוי הנכס ואף הרכיב הספציפי שכשל, ונסיבות הכשל, סמוך ככל שניתן למועד האירוע.
3. עבור נכסי ה- IT שמופו, יקבעו הסדרי גיבוי שאיפשרו את המשך פעילות התהליך העסקי המהותי שכשל. יש לפעול למניעת מצב של נקודת כשל יחידה (single point of failure). עד כאן הציטוט.
המפקח גם קובע לוח זמנים לטיפול בהנחיות אלו.
יש לציין שהנחיות אלו ברוכות ורצוי שגם ארגונים אחרים אשר מסתמכים בצורה מהותית על מערכות המידע יטמיעו הנחיות אלו. ההנחיה הראשונה היא הנחיה יוצאת דופן וחדשנית. נכון להיום בגלל המורכבות הרבה ישנו ברובם המכריע של הארגונים "ספגטי". קשרים מורכבים בין מערכות כך שלמשל קורה לא מעט פעמים שלקוח מוריד שרת לצורכי תחזוקה ומסתבר שמערכת אחרת ש"לא קשורה" מפסיקה לעבוד. זאת מכיוון שאין בארגונים תמונה עדכנית של המערכות והקשרים ביניהם. ההנחיה הראשונה מורה לבנקים לבצע מיפוי של הנכסים ושל הקשרים בינהם. עם זאת, כבמקרים נוספים, הבנק נותן הנחיה כללית אשר יכולה להתפרש על ידי הבנקים בצורה שונה. כאשר המפקח מורה לבנקים לבצע "מיפוי תהליכים" יכולים הבנקים להציב אפילו "סטודנט" אשר יבצע מיפוי פעם בשנה של המערכות ושל הקשרים בינהם. זאת כמובן בעלות זניחה. עם זאת בנקים אשר רוצים לבצע את ההוראה בצורה עמוקה יותר יכולים לבצע אוטומציה של המיפוי עד למצב של automatic discovery שבו תהליך ממוכן ממפה בעצמו את הרכיבים של כל מערכת מחשב ואת הקשרים בין המערכות. פרוייקטים מסוג זה המוגדרים בתעשיה כ- CMDB עלולים לעלות מליוני דולארים הן ברמת רישוי התוכנה והן ברמת הטמעת המערכות. עם זאת רק ביצוע של מיפוי אוטומטי יכול לעמוד בהוראות המפקח על הבנקים בצורה עמוקה וזאת מכיוון שגם אם מבצעים תהליך ידני של מיפוי – לאחר ערב אחד – שבו בגלל תקלה מבצעים תיקון מיידי ושוכחים לעדכן את התיקון במיפוי המערכות – מקבלים מצב שבו בזמן התקלה הבאה אין תמונה אמיתית של מיפוי המערכות והקשרים ביניהם. רק מיפוי אוטומטי יכול להתקרב למיפוי אמיתי כהנחיית המפקח. עמידה בתנאי זה לעומקו תגרור את הבנקים לפרוייקטים של שנה עד שלוש שנים ולעיתים אף יותר.
לגבי שתי ההנחיות האחרות – ביצוע ניטור וביצוע כלי גיבוי, רובם המכריע של הבנקים ושל ארגוני ה- IT באופן כללי מקיימים הנחיה זו – עם כי קבלת הנחייה רשמית מהמפקח תתרום לקבלת תקציבים ועדיפות גם לתחומים אלו. גם לגבי ביצוע ניטור המפקח נותן הנחייה כללית ולא מפרט באיזה סוג ניטור. כיום קיימים מספר סוגים של מערכות ניטור. מערכות הניטור הותיקות המורכבות מ- agnet שמשדר למרכז קיימות ברוב רובם של הארגונים. אולם לביצוע ניטור אמיתי אשר מגלה גם את הרכיב התקול בצורה המהירה ביותר יש גם להשתמש במערות מהסוג של "ניטור חויית משתמש" ומערכות לגילוי מקור תקלה "root cause" ו- Business Transaction Management הפועלות בין הייתר בטכנולוגיה של sniffing. כלומר גם כאן ישנו חופש פעולה גדול של הבנקים בביצוע הוראת המפקח, חופש פעולה שישפיע על הוצאות הבנקים למילוי הוראה זו.
לסיכום מדובר בהוראה חשובה שרצוי שתהיה על שולחנם של מקבלי החלטות רבים – לא רק בתחום הבנקאי.
2 תגובות:
שלום, אם אתה מתכוון להוראה 357, הרי שזו פורסמה בשנת 2003 ולא השנה. אם אתה מתכוון לעדכון ההוראה, הרי שהוא נשלח אך לא פורסם ולא הפך לרשמי עדיין.
לא
מדובר על הוראה שנשלחה ישירות לבנקים ולא פורסמה ברשומות
הוסף רשומת תגובה