CSP Networks

התאוששות מקומית, בענן או באתר שני?

בחירה לפי RTO/RPO אמיתי, תרחישי כשל ויכולת התאוששות אפליקטיבית, ולא לפי פתרון שכבר קיים בארגון.

בחירה לפי RTO/RPO אמיתי, תרחישי כשל ויכולת התאוששות אפליקטיבית, ולא לפי פתרון שכבר קיים בארגון.

החלטה ניהולית

פתרון DR נמדד בזמן אמת של חזרה לשירות ובאיכות הנתונים שחזרו, לא במספר העותקים או במיקום השרתים.

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

חלופות להשוואה

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

גורמי החלטה

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

שאלות שמנהל צריך לשאול

  1. איזה תרחיש כשל אנחנו באמת מתכננים לשרוד?
  2. מהו RTO/RPO לכל שירות קריטי ומי אישר אותו עסקית?
  3. אילו תלויות משותפות עלולות להפיל גם את האתר החלופי?
  4. כמה זמן לוקח להחזיר אפליקציה שלמה ולא רק שרת?
  5. האם אפשר לתרגל בלי לסכן את הייצור?
  6. איך חוזרים מהאתר החלופי לסביבה הרגילה לאחר האירוע?

ראיות שצריך לאסוף

  • BIA ויעדי RTO/RPO
  • מפת תלויות אפליקטיבית
  • ארכיטקטורת רשת וזהויות
  • תוצאות תרגילי DR
  • מדדי גיבוי ושחזור
  • תרחישי חירום ותהליכי הפעלה

סימני אזהרה

  • הארגון מצהיר על RTO שלא נבדק בתרגיל.
  • האתר הראשי ואתר ה-DR תלויים באותה קישוריות או מערכת זהויות.
  • השחזור נמדד ברמת VM ולא ברמת שירות עסקי.
  • אין נוהל חזרה לשגרה לאחר הפעלת אתר ההתאוששות.

איך נראית החלטה טובה

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

שאלות ותשובות

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

הגישה של CSP

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