עופר עוז, Triple T: "בניגוד לדעה הרווחת, הענן לא מייתר את ה-DRP"

"יש דעה רווחת לפיה השימוש בענן מייתר את ה-DRP. זה לא נכון. ה-DRP יכול לעזור להפעיל נכון את המערכות ביום יום, הוא רק כלי ולא יעד. קיימים ותמיד יהיו לחצים רבים מאוד להקמת אתרי DRP, אבל אנשי ה-IT לא צריכים להיות לחוצים מכך, אלא לדעת מה לעשות", אמר עופר עוז, מנכ"ל Triple T.

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

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

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

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

כך תוודאו שאתרי ה-DRP פועלים היטב

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

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