רציפות עסקית / Business Continuity Program הינה תוכנית רחבה שמטרתה לאפשר לארגון לעבוד בצורה רציפה ככל הניתן וזאת בהתאם ליעדים שנקבעו מבעוד מועד. תכנית התאוששות מאסון (Disaster Recovery Plan) היא חלק מתוך התהליך הגדול יותר של בניית רציפות עסקית. עולם המחשוב כיום הינו חלק בלתי נפרד מכל פעילות עסקית באשר היא, ישנם עסקים שנעזרים במערכות מחשוב אך יכולים גם להתקיים בלעדיהם לפרק זמן כזה או אחר וישנם עסקים אשר כל הליבה העסקית מושתתת על מערכות המחשוב והפסקת פעילות של דקות ספורות ולעיתים שניות עשויה להיות בעלת משמעות עסקית גדולה.
התפיסה הרווחת כיום היא בניית מערכות חכמות הכוללות הגנה ויכולת המשכיות רציפה ו/או התאוששות מאסון כזה או אחר ובעולמנו הדרכים לפגיעה במערכות מחשוב הן רבות ומגוונות.
ישנם שני מושגים חשובים הקשורים להתאוששות מאסון שכדאי להכיר:
RTO : Recovery Time Objective:
טווח הזמן הנדרש לטובת הפעלה מחדש של הפעילות העסקית, כלומר, כמה זמן ייקח לארגון לחזור לפעילות תקינה ומלאה ו/או עפ"י תכנית ההמשכיות העסקית. מדד זה נקבע בתהליך האפיון של הקמת פתרון המחשוב בארגון או בתהליך בנית תכנית ההמשכיות.
הגדרת הזמן יכולה להיות אפס, כלומר, הארגון אינו מסוגל לחוות Downtime כלל ויש לבנות את המערכות בהתאם לכך, או מספר שעות/ימים, בהתאם לצרכי ההמשכיות העסקית ויכולת ההשקעה הכלכלית בפתרון
החשיבות הגדולה היא לבצע בדיקה יסודית בשלב האפיון ובהתאם לצורכי הארגון יש להתאים את מערכות המחשוב ואת הפתרון שבמבחן התוצאה יעמוד ביעד שנקבע.
RPO: Recovery Point Objective:
טווח הזמן שנצטברו בו נתונים שאותם ניתן לאבד בעת אירוע אסון. טווח הזמן משתנה ומוגדר בהתאם לצרכי הארגון.
לדוגמא: ארגון מסוים יכול להגדיר שבעת התאוששות מאסון סביר בעיניו לאבד חומר של שלוש שעות עבודה, ארגון אחר יכול להגדיר טווח שעות רחב יותר או אי יכולת לאבד כלל.
מדדים אלו עשויים להשפיע על:
- אופן בניית מערכות המחשוב ב DAY1
- אילו מערכות גיבוי יש להתאים ללקוח לרבות פתרון DR (disaster recovery) קר או חם, אקטיבי או פאסיבי.
- רמת השרות הנדרשת (SLA) מהמערכות התומכות, מצוות ה-IT ומהספקים הרלוונטיים.
דוגמא לתהליך מלא:
- בשלב אפיון הפתרון ללקוח מתייחסים לנתונים הבאים:
- מהי רמת ה Uptime הדרושה למערכת?
- כמה זמן של כשל טוטאלי מסוגל לסבול הארגון?
- כמה זמן איבוד מידע יכול הארגון להכיל (RPO)?
- מהו הזמן הנדרש לארגון כדי לבצע חזרה מגיבוי (RTO)?
כל אחד מהפרמטרים הנ"ל עשוי להיות רלוונטי לכלל המערכות או להיקבע באופן פרטני לכל מערכת בהתאם לרמת חשיבותה.
- בהתאם לתשובות יאופיין פתרון אשר יענה על הצרכים הנ"ל, לדוגמא:
- רמתUptime נדרשת 99.99% בשנה – יש לוודא שמערכות הספק אכן עומדות בתקן ומסוגלות לספק את הדרישה.
- כשל טוטאלי של עד 9 שעות בשנה.
- איבוד מידע של יום עבודה אחד.
- חזרה מגיבוי תוך 4 שעות.
הנתונים יועברו למהנדס בחברה אשר ימליץ על פתרון ענן שיוכל לספק מענה. יש לציין שקיימת היכולת לספק כל פתרון וכל מענה, החל מפתרון ענן רגיל הכולל יתירות ועד לפתרון הכולל DR חם מלא העובד בתצורת Active-Active.
שלב האפיון הוא קריטי וחשוב שכן עליו להתאים בדיוק לצרכי הלקוח בצד התפעולי/טכנולוגי אך לא פחות חשוב גם בצד הפיננסי.
ייעוץ והכוונה הם חלק בלתי נפרד בתהליך, חשוב מאוד להציג ללקוח את היתרונות והחסרונות בכל סוג של פתרון ולסייע לו להגיע להחלטה הנכונה אשר הומלצה על ידי האנשים הטכניים.
יש לזכור שהמערכת נבנית ומוכנה ל"יום הדין", ליום שבו יהיה כשל ואז יהיה מבחן האמת שבו הכול חייב לעבוד, מומלץ מאוד לבצע מעת לעת ביחד עם הלקוח, תרחישי אמת, לדמות מספר תרחישים קיצוניים ולראות כיצד המערכת מגיבה. מבחנים אלו יאפשרו ללקוח ולצוות הטכני להיות בטוחים ורגועים שביום הדין הכול יעבוד כפי שתוכנן.
סיכום:
במציאות הקיימת אף אחד אינו יכול לחזות במדויק מתי יהיה אסון ועל מה הוא ישפיע.
בהחלט ניתן ומומלץ לבצע הכנה מראש על מנת שנוכל להתמודד בצורה מיטבית ברגע שהאסון "ידפוק בדלת". ערכי RTO & RPO עשויים להשתנות מארגון לארגון, אך תמיד הם יהיו כפשרה בין הצרכים העסקיים והזמינות שהארגון צריך לבין ההשקעה התקציבית הנדרשת ב IT.
אומדן זה צריך להיקבע בהתלבטות בין אנשי ההנהלה אשר מבינים את הצורך העסקי, הזמינות והפגיעה האפשרית בכל סיטואציה לבין מומחי ה IT שתפקידם לשקף את הסיכונים הטכניים ולבנות את הפתרון הטכני שייתן מענה לצורך העסקי, ומשם להתכנס לתקציב מתאים.
בסופו של דבר תתקבל החלטה והיא תועבר לגורם המבצע בין אם הוא פנימי או חיצוני לחברה, מרגע זה והלאה חובת ההוכחה היא על ספק הפתרון ומתפקידו לבצע בדיקות תקופתיות ולשקף ללקוח את הממצאים.
זווית נוספת להבנת הנושא: ניתן לדמות את הפתרון כולו לביטוח עבור מבנה מורכב, נניח מגדל עסקים גדול באזור מסחרי. מרגע שנחתם ההסכם, הוא הופך ללא רלוונטי עד ליום שבו בגלל סיבה כזו או אחרת חברת הביטוח תידרש לתת מענה, אם בוצע אפיון מדיוק ונכון, ובהמשך הדרך תחזוקה ובדיקות נכונות, יסופק המענה עפ"י הציפיות.
שי גינדי הוא סמנכ"ל פיתוח עסקי ומכירות בקבוצת y-tech. בעבר מנכ"ל ומייסד Sage שנרכשה ע"י y-tech.
