תפריט נגישות

BCP אפקטיבי

ברור לכולם שהמציאות כנראה תהיה קשה להתמודדות, מכל מה שהארגון יחווה בכל ניסוי ולכן חשוב להפוך את נושא ה BCP כחלק קבוע ממטלות ה IT עליהם הוא נמדד ונדרש לבצע

מבוא

 מטרת תוכנית ה-Business Continuity Plan  (BCP) לאפשר המשכיות של הפעילות העסקית, במקרים של פגיעה במתקנים/אנשים,  בהתאם לשיקול הדעת של הנהלת הארגון. בבניית  התכנית נדרש מנהל מערכות המידע לקבל החלטות , בשיתוף עם המנהלים הרלוונטיים בארגון,  בהתאם לקריטיות של שני פרמטרים:

 RPO - Recovery Point Objective
נקודת הזמן המאוחרת ביותר, לאחר האירוע, שבה הנתונים מעודכנים. לדוגמא
RPO של 12 שעות מציין שביישום אליו מתייחס הנתון, יהיו הנתונים מעודכנים לכל היותר  12 שעות לפני מועד הארוע.

     RTO -Recovery TIme Objective
מציין את הזמן ההתאוששות המרבי לחידוש פעולת היישום בארגון.

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

 בהקשר לפתרונות High availability  יש להבחין  בין פתרון באותו קמפוס שאינו נותן מענה ל-BCP לבין פתרונות הנותנים מענה להמשך פעילות עסקית באתר DRP מרוחק . גם שימוש במערכות "ענן" חיצוניות אינו פוטר מחשיבה על BCP מאחר וקו האינטרנט הופך לחוליה קריטית ואף יתכן שהספק החיצוני אינו מחויב חוזית להתאוששות ברמה המספקת את הארגון. 

 איך ניגשים לתהליך

 בשלב הראשון יש למפות ולדרג את היישומים מבחינת רמת החשיבות והעדיפות לפרמטרים של RPO ו-RTO.לדוגמא, בכל ארגון האימייל מאד קריטי (משמש לתקשורת עם גורמי חוץ ופנים) ולכן סביר שיישום זה ידורג בעדיפות ראשונה, עם RPO ו-RTO קצרים. מאידך, מערכת לגיוס עובדים לדוגמא  כנראה תהיה בעדיפות נמוכה, מאחר וניתן למחלקת משאבי האנוש לפעול בדרך חלופית עד להתאוששות.

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

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

 לאחר הגדרת היישומים, דרגת החשיבות והפרמטרים להתאוששות, יש לפעול בהתאם לשלבים הבאים:

שלב 1 -בניית צוות BCP  לכל אגף בחברה באחריות חבר הנהלה

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

שלב 2 - בניית רשימת   תרחישים - Scenarios  planning 

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

שלב 3 - גזירת פעילויות לכל תרחיש  

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

שלב 4 - תיעוד טכני לכל משימת התאוששות      

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

             התיעוד יכלול: 

·רשימת משאבים (חדרי שירותים, DRP, קווי תקשורת...)

·כ"א מקצועי – רשימת עובדים הכוללת התמחות מקצועית, אמצעי קשר...

·כ"א חלופי -  במקרה זה לרוב השענות על קבלני משנה

·תיעוד המיועד לאנשי מקצוע חיצוניים שאינם מכירים את סביבת העבודה בארגון

דוגמא לתכנון ראשוני של סדר ההתאוששות לאחר ארוע.


תכנון זה מציג את הקדימויות ע"פ העדיפויות שנקבעו , תוך ציון משאבים עיקריים.

אדום – משימה פנימית של מח' IT

כחול- משימה מבוצעת ע"י קבלן חוץ. 

 לסיכום

 בכדי לשמר בצורה אפקטיבית את היכולת להפעיל את תוכנית ה-BCP, יש לבצע בשגרה פעולות מתמשכות: עריכת ניסויים (כל פעם נושא אחר הקשור לתוכנית), תחזוקת מסמכים (קביעת אחראי – Owner לכל מערכת), הגדרת הנושא בהתקשרויות עם ספקים חדשים ועוד. חשוב  להציג להנהלה, באופן עדכני את הערכת הסיכונים ואת המשמעויות של הפחתת הסיכון.

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

כותב המאמר: אבי ונגר, סמנכ"ל מערכות מידע, רד תקשורת
ליצירת קשר: avi_w@rad.com