דגשים לביקורת הממשקים במערכות המידע הארגוניות
לא ליפול בין הכסאות
קשה למצוא ארגון שבו כלל הפעילויות העסקיות מתקיימות ומנוהלות במערכת אחת. לרוב מדובר במספר מערכות, תפעוליות ופיננסיות (המשפיעות על הדיווח הכספי).על מנת להעביר נתונים בין מערכות יש צורך בהקמת ממשק.
לדוגמה: מערכת תפעולית שרושמת שימוש של הלקוחות בשירותים שחברה מעניקה. בסוף החודש יש לתרגם את השימוש למונחים כספיים ולחייב את הלקוח. המערכת התפעולית שולחת את הנתונים הנדרשים למערכת הכספית.
בעידן BIG DATA ותעבורת נתונים מקצה לקצה של הארגון, ישנה חשיבות לבחון את היכולות של הארגון בפעילות הממשקים. חברות משקיעות משאבים על מנת לבחון את המערכות ממגוון היבטים כדוגמת תהליך הפיתוח, אבטחת מידע, תהליך מתן הרשאות והסרתן, ועוד. עם זאת, לעיתים לא ניתנת התייחסות הולמת לנושא הממשקים. גם הביקורת בדרך כלל מתמקדת בבדיקות של המערכות עצמן, כגון תהליכי פיתוח, אבטחת מידע, בקרות לוגיות וכו', ללא התמקדות ועריכת ביקורת מקיפה בנושא ממשקים. במאמר זה אתן כלים פרקטיים למבקר בבואו לבדוק ממשקים בין מערכות.
אי העברת נתונים על ידי ממשק, או העברת נתונים בצורה לא תקינה או חלקית, עלולה לגרום לחיוב שגוי של לקוחות, לעזיבת לקוחות, לפגיעה במוניטין, לתביעות ייצוגיות ועוד.
על מנת להתמודד עם הסיכון, ישנם ארבעה נושאים מרכזיים שעל המבקר לבחון בעת בדיקת ממשקים בארגון:
- שלמות ואיכות המידע שמבצעים הממשקים.
- אמצעי הניטור והבקרה על תשתיות המערכות ופעילות הממשקים.
- יכולות הממשקים להתאושש מכשלים.
- שרידות תשתיות הממשקים.
ראשית, יש לוודא כי קיים מיפוי של כלל הממשקים הקיימים/הרצים בחברה, הפנימיים והחיצוניים. במיפוי יש להתייחס לרשימת הממשקים היוצאים ממערכת; רשימת הממשקים הנכנסים למערכת; שיטת העבודה בהעברת מידע בממשקים (כספות/ FTP/ SFTP/ מערכות דיודה/ מערכות קבצים בענן/ ממשקים בקווים ישירים). לאחר מכן יש לבצע את הבדיקות המפורטות בכל אחד מההיבטים:
- שלימות ואיכות המידע שמבצעים הממשקים
השאלה המרכזית שנשאלת בבדיקה זו היא: מה יקרה אם המידע שיתקבל מהמערכת השולחת אינו שלם? האם המערכת המקבלת את המידע תזהה שהמידע אינו שלם? האם תמשיך בתהליך העיבוד או שתחזיר שגיאה בפניית תשאול סטטוס למערכת השולחת?
הפרקטיקה המקובלת בפיתוח תהליכי ממשק היא לבדוק את כמות הרשומות שהתקבלו בשלושה היבטים:
- מספר הרשומות שהתקבלו במשלוח המידע הנוכחי ביחס למספר שמדווח השולח.
- כמות הרשומות הכוללת שהתקבלה מהשולח בחלון זמן נתון.
- איכות המידע שעבר בממשק.
- על המבקר לבחון האם מתבצעת בדיקה על מספר הרשומות שהתקבלו מהמערכת השולחת. גם במקרים בהם נשלחים קבצים, יש לבדוק האם מצורף, כמקובל, Header הכולל את מספר הרשומות שנשלחו. ערך זה והבדיקה המתבצעת עליו נדרשים על מנת לוודא שכל הרשומות שנשלחו אכן התקבלו.
- לבחון האם מתבצעת בדיקת סבירות על מספר הרשומות הכולל שהתקבל מהמערכת השולחת בחלון זמן נתון.
- כדי לוודא שהמידע עבר במלואו ושתכנים לא שובשו, מומלץ לבצע השוואה כמותית של רשומות המידע במערכות השונות וכן לבצע השוואת ערכים עבור שדות משמעותיים לתקינותו של התהליך, בעצם ההמלצה היא למחשב תהליך אוטומטי שיבצע השוואה של כמות הרשומות במערכות השונות.
- אמצעי הניטור והבקרה על תשתיות המערכות ופעילות הממשקים
תהליכי הדיווח, הניטור והבקרה נדרשים בכדי לוודא פעילות תקינה של התהליכים השונים ובכדי לוודא שתקלות דווחו לגורמים הרלוונטיים. בנוסף, תהליכים אלו מאפשרים הסקת מסקנות הנוגעות לאיכות התהליכים ובכך מסייעים לשיפור מתמיד.
יש להתייחס לניטור והבקרה בהיבטים הבאים:
- ניטור תשתיות.
- דיווח האפליקציה וניטור שוטף על תקלות אפליקטיביות.
- השלב הבסיסי כולל ניטור שוטף של התשתיות עליהן "רצה" האפליקציה. תשתיות אלו כוללות רכיבי תשתית כדוגמת מערך האחסון (Storage), שרתים, מסדי נתונים, קווי תקשורת ועוד. רכיב בסיסי נוסף אותו נדרש לנטר הוא הזמינות של התהליכים (Processes) השונים מהם בנויה המערכת, ובמקרה של ריצת ממשקים, את תחילת וסיום ריצת הממשק ע"פ הגדרות תזמון הריצה.
- דיווח וניטור שוטף של תקלות בהן נתקלת האפליקציה נדרשים בכדי להתריע על כשלים שאינם מנוטרים ע"י מערכות ניטור התשתית. לדוגמה, שינויי הגדרות של רכיב חומת האש באתר המארח של האפליקציה עלול לגרום לתקלות במעברי המידע בין רכיבי המערכת. במקרה זה נדרשת האפליקציה לדווח על השגיאה שארעה.
בנוסף לכך, יהיה צורך לבחון האם נרשמות שגיאות אפליקטיביות לטבלת לוג ונשמרות במשך תקופה, וכן האם מתבצע תהליך ניטור על השגיאות שנרשמו.
- יכולות הממשקים להתאושש מכשלים
תכנית המשכיות עסקית נועדה להבטיח רציפות תפעולית של התהליכים העסקיים הקריטיים של הארגון בשעת חירום. התכנית מתייחסת לאירועי חירום שונים ומגדירה תכניות פעולה לצורך התאוששות. לדוגמה, מצב כשל של מסד נתונים מרכזי (SQLSERVER) במערכת ; זיהוי הכשל, מהן הפעולות שיש לנקוט, מהן הבדיקות שיש לבצע לאחר אישוש המערכת, אלו פעולות יש לבצע ידנית, למי נדרש לדווח על המצב בשלבים השונים של הטיפול בתקלה וכדומה.
עבור מערכות חיוניות מקובל להגדיר אתר חלופי (DR) שיאפשר המשך הפעילות העסקית מול האתר החלופי במקרה של כשל הראשי. כאשר למערכת קיים אתר DR, כוללת התוכנית התייחסות לזיהוי המצבים בהם נדרש מעבר לאתר המשני, נהלי המעבר והחזרה לאתר הראשי. התוכנית להמשכיות עסקית מתבססת על תיק אתר הממפה את תשתיות המחשוב השונות אותן נדרש לאושש.
- שרידות תשתיות הממשקים
בפרק זה, נדרש להתייחס לנושאים הבאים:
- ארכיטקטורת המערכת לטובת התמודדות עם עומסים ותקלות
- הגדרות ובדיקות עמידות בעומסים
- גיבויים ושחזורי המידע
- יש לבחון האם המערכות נבנו בצורה שתאפשר עבודה אסינכרונית[1] על המידע שמתקבל מבלי להפריע בתהליך קליטת המידע מהמערכת השולחת. המערכות מבצעות באופן סינכרוני אימות בסיסי למידע המתקבל. המשך פעילות עיבוד וטיוב המידע מתבצעים בצורה אסינכרונית.
- עבור מערכות הנדרשות לעבוד בעומסי מידע גבוהים וגדלים, בהתאם לכמויות המידע הנשלחות, יש לבחון האם הוגדרו העומסים בהם צריכות המערכות לעמוד בטרם עליה לאוויר. בנוסף, יש לתעד מסמך דרישות עמידה בעומסים המהווה חלק מאפיון אשר נבדק ומאושר כחלק מתהליך הבדיקות.
- פעילות הגיבוי השוטפת נדרשת כדי להבטיח יכולת שחזור המידע במקרה של פגיעה. ללא פעילות גיבוי קיימת חשיפה לאובדן כל המידע התפעולי הנצבר. בנוסף, ישנה חשיבות גבוהה לגיבוי השרתים ולכלל קונפיגורציה התשתיות של המערכת. ללא גיבוי הקונפיגורציה זמן ההתאוששות במקרה של פגיעה באתר עלול לקחת זמן רב.
לסיכום,
עם ריבוי המערכות בארגון וריבוי תהליכים הרצים במערכות שונות, המבקר חייב לכלול בתכנית העבודה שלו גם ביקורות מקיפות בנושא ממשקים בין מערכות ותפקודם. במאמר כללתי את הדגשים החשובים ביותר לבדיקה על מנת לסייע למבקר בביקורות אלה.
[1] מערכות אסינכרוניות להעברת מסרים מעבירות מסרים מהשולח למקבל, מבלי לחכות שהמקבל יהיה מוכן. היתרון של תקשורת אסינכרונית הוא בכך שהשולח והמקבל יכולים לעבוד במקביל מכיוון שהם לא מחכים האחד לשני.
