Disaster Recovery למערכות SaaS: RTO, RPO ותוכנית שבאמת עובדת כשצריך אותה

מאת צוות מדיה דיל · 06.08.2026 · SaaS Architecture · 9 דק׳

תוכנית Disaster Recovery ש'קיימת במסמך' אבל אף פעם לא נבדקה, היא לא תוכנית - היא תקווה. הנה איך בונים DR אמיתי סביב RTO/RPO ובודקים אותו לפני שהוא נדרש בפועל.

ב-2017, שירות S3 של אמזון חווה תקלה של כמה שעות שהפילה חלקים גדולים מהאינטרנט - כולל חברות שהיו בטוחות שהן "בענן, אז אנחנו מוגנים". הבעיה לא הייתה שהן לא היו בענן - הבעיה הייתה שהתשתית הענן שלהן הייתה בנויה על region בודד, בלי תוכנית ממשית למה קורה כשהregion הזה נופל. Disaster Recovery (DR) הוא בדיוק התשובה לשאלה הזו: לא "מה קורה אם שרת בודד נופל" (זו שאלת High Availability), אלא "מה קורה אם כל מרכז הנתונים, כל הregion, או אפילו כל הספק נופל". זו שאלה שרוב הצוותים דוחים לטפל בה עד שהיא כבר קרתה, ואז מגלים שהתוכנית שהייתה כתובה במסמך מעולם לא נבדקה בפועל ולא עובדת כמצופה. במאמר הזה נבנה DR שבאמת אפשר לסמוך עליו.

RTO ו-RPO: שתי ההגדרות שקובעות הכל

לפני שבונים אסטרטגיית DR כלשהי, צריך להגדיר במפורש שני מספרים. RTO (Recovery Time Objective) - כמה זמן מותר שיעבור מרגע האסון ועד שהמערכת חוזרת לתפקד. RPO (Recovery Point Objective) - כמה נתונים מותר לאבד, נמדד כזמן: אם ה-RPO הוא 15 דקות, המשמעות היא שאחרי שחזור, אפשר לאבד עד 15 דקות של נתונים אחרונים שנכתבו לפני האסון. שני המספרים האלה לא נקבעים "טכנית" - הם החלטה עסקית שצריכה לבוא מלמעלה, כי הם קובעים ישירות את העלות. RTO של דקות בודדות ו-RPO של אפס דורשים תשתית active-active מלאה עם replication סינכרוני - יקר ומורכב. RTO של כמה שעות ו-RPO של שעה מאפשרים גישות פשוטות וזולות משמעותית כמו backup-restore. הטעות הנפוצה ביותר היא לדלג על ההגדרה המפורשת הזו ולתת לצוות ההנדסה "לנחש" מה סביר - מה שכמעט תמיד מסתיים באחד משני קצוות: השקעת יתר במקום שלא הצדיק אותה, או תוכנית לא מספקת במקום שהיה קריטי.

ארבע אסטרטגיות DR: מהזולה ליקרה

Backup and Restore - הזולה והפשוטה ביותר: גיבויים תקופתיים נשמרים (רצוי ב-region נפרד), ובמקרה אסון בונים תשתית חדשה מאפס ומשחזרים מהם. RTO גבוה (שעות עד ימים), RPO תלוי בתדירות הגיבויים. Pilot Light - גרסה מוקטנת של המערכת רצה כל הזמן ב-region המשני (בדרך כלל רק מסד הנתונים עם replication פעיל, בלי שכבת אפליקציה), כך שבזמן אסון צריך רק "להצית" את שאר התשתית סביב הליבה שכבר קיימת - RTO בינוני (עשרות דקות). Warm Standby - עותק מוקטן אך פעיל של המערכת המלאה רץ כל הזמן ב-region המשני, מסוגל לטפל בחלק מהתעבורה, ומוגדל בזמן אסון לקיבולת מלאה - RTO נמוך (דקות). Multi-Site Active-Active - שני מקומות פעילים במלואם בו-זמנית, כל הזמן - RTO כמעט אפס, אך העלות והמורכבות (בעיקר סביב עקביות נתונים) הגבוהות ביותר מבין כל האסטרטגיות. הבחירה הנכונה נגזרת ישירות מה-RTO/RPO שהוגדרו, לא מ"מה שנשמע הכי בטוח".

DR Strategy       RTO           RPO           Cost
Backup/Restore    Hours-Days    Hours         $
Pilot Light       ~30 min       Minutes       $
Warm Standby      Minutes       Seconds-Min   $$
Active-Active     ~Seconds      ~Zero         $$

Runbooks: תוכנית שלא נכתבת פעם אחת

תוכנית DR שקיימת רק כרעיון בראש של מהנדס בכיר אחד היא לא תוכנית - היא סיכון. Runbook הוא מסמך פעולה מפורט וממוספר: מי מוסמך להכריז על מצב אסון, מה בדיוק הצעדים הטכניים לביצוע failover (כולל פקודות מדויקות, לא רק תיאור כללי), איך מודיעים ללקוחות ולצוותים פנימיים, ובאיזה סדר. Runbook טוב כתוב כך שמהנדס שלא בנה את המערכת יוכל לעקוב אחריו תחת לחץ - כי בזמן אסון אמיתי, המהנדסים שבנו את המערכת המקורית לא תמיד יהיו זמינים (חופשה, שינה, עזבו את החברה), והרוגע שנדרש כדי לזכור פרטים טכניים מדויקים תחת לחץ הוא בדיוק מה שנעדר בשעת משבר אמיתית. חשוב באותה מידה לתעד גם את תהליך ה-failback - החזרת המערכת ל-region המקורי אחרי שהוא חוזר לתקינות - שלרוב מתעלמים ממנו לגמרי בתכנון, ומגלים שהוא מורכב לא פחות מה-failover עצמו.

DR Drills: הבדיקה היחידה שבאמת סופרת

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

מיהו "אסון" בכלל: קטגוריות סיכון

לפני שממשיכים לפרטי המימוש, שווה להבחין בין סוגי אסון שונים, כי כל אחד מהם דורש תגובה שונה. כשל תשתיתי - מרכז נתונים שלם שנופל, region שחווה תקלת חשמל או רשת - נענה טוב על ידי האסטרטגיות שתוארו למעלה. שחיתות נתונים (data corruption) - באג בקוד או פעולה שגויה שכותבת נתונים שגויים למסד הנתונים - הוא סוג אסון שונה לגמרי, כי replication (סינכרוני או א-סינכרוני) פשוט מעתיק את הנתונים המושחתים ל-region המשני גם הוא, ולא מגן מפני זה בכלל. ההגנה היחידה מפני שחיתות נתונים היא גיבויים היסטוריים עם point-in-time recovery, שמאפשרים לחזור לרגע לפני שהשחיתות קרתה. טעות אנושית או תקיפה זדונית - מחיקת נתונים בכוונה או בטעות, או השתלטות עוינת על החשבון - דורשת שכבות הגנה נוספות כמו immutable backups שאי אפשר למחוק גם עם הרשאות מנהל מלאות. תוכנית DR שמטפלת רק בכשל תשתיתי ומתעלמת מהשניים האחרים מכסה רק חלק מהסיכון האמיתי.

אסטרטגיות Replication לנתונים

הליבה הטכנית של כל תוכנית DR היא איך הנתונים עצמם עוברים ל-region המשני. Replication סינכרוני (כפי שתואר במאמר על High Availability) נותן RPO אפסי אך מוסיף latency לכל כתיבה ודורש שני האזורים להיות קרובים מספיק כדי שה-latency יהיה סביר - מה שלעיתים מנוגד למטרה של DR, שרוצה מרחק גיאוגרפי משמעותי בין האזורים כדי להגן מפני אסון אזורי. Replication א-סינכרוני נותן RPO קטן אך לא אפסי, ומאפשר מרחק גיאוגרפי גדול יותר בלי לפגוע ב-latency של הכתיבה הרגילה. לצד replication ברמת מסד הנתונים, יש גם צורך ב-replication של כל שאר הנכסים - קבצים שנשמרים ב-object storage, secrets וקונפיגורציה, ואפילו תמונות container שהתשתית תלויה בהן - כל אלה חייבים להיות זמינים ב-region המשני מראש, לא "להוריד אותם כשצריך", כי בדיוק בזמן אסון אמיתי, ייתכן שהחיבור לספק החיצוני שמארח אותם לא זמין.

התלות המסוכנת בספק ענן יחיד

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

תקשורת ומוכנות ארגונית בזמן אסון

ההיבט הטכני של DR מקבל את מרבית תשומת הלב, אבל ברגע אמת, תקשורת לקויה בין הצוותים יכולה לגרום נזק לא פחות מתקלה טכנית. תוכנית DR שלמה כוללת גם פרוטוקול תקשורת ברור: מי בדיוק מוסמך להכריז רשמית על מצב אסון (declaration authority), באיזה ערוץ מתואמת התגובה כשהמערכות הרגילות (כמו כלי צ'אט פנימי שרץ באותה תשתית שקרסה) עצמן עלולות להיות לא זמינות, ומה בדיוק מתקשרים ללקוחות ומתי - עמוד סטטוס (status page) שאינו תלוי באותה תשתית שעלולה ליפול הוא כלי בסיסי כאן. ארגונים שמתעלמים מההיבט הזה מגלים שגם כשהתגובה הטכנית עבדה מצוין, חוסר ודאות ותקשורת מבולבלת כלפי לקוחות במהלך האסון פגעו באמון לא פחות מזמן ה-downtime עצמו.

טעויות נפוצות בפרודקשן

תוכנית DR שאף פעם לא נבדקה - מסמך שנכתב פעם אחת בזמן ההקמה ומעולם לא הורץ בפועל, שמתגלה כלא רלוונטי בדיוק כשצריך אותו.
גיבויים בלי בדיקת שחזור - הרצת גיבוי אוטומטי מדי לילה בלי לוודא שהוא בכלל ניתן לשחזור - נושא שנדון בהרחבה במאמר הייעודי לארכיטקטורת גיבויים.
RTO/RPO שלא הוגדרו במפורש - השארת ההחלטה "לניחוש הנדסי" במקום דיון עסקי מפורש עם בעלי עניין שמבינים את העלות של downtime בפועל.
תלות נסתרת ברכיב שלא שוכפל - שירות עזר, סקריפט תחזוקה, או אינטגרציית צד שלישי שהצוות שכח שהוא חלק מהמסלול הקריטי, ומתגלה רק בזמן אסון אמיתי.
הזנחת תהליך ה-failback - תכנון מפורט ל-failover אך לא לחזרה למצב רגיל, מה שהופך את השלב השני של האסון לכאוטי לא פחות מהראשון.

מתי כן ומתי לא כדאי להשקיע ב-DR מתקדם

כל מוצר SaaS צריך לפחות אסטרטגיית Backup and Restore בסיסית - זו לא בחירה, זו דרישת מינימום. מעבר לזה, ההשקעה צריכה להיות פרופורציונלית לעלות אסון בפועל: מוצר עם לקוחות ארגוניים שדורשים SLA קשיח, או מוצר שבו downtime ממושך משמעו איבוד לקוחות באופן בלתי הפיך, מצדיק השקעה ב-Warm Standby או אפילו Active-Active. מוצר בשלב מוקדם עם בסיס לקוחות סובלני יותר יכול להסתפק ב-Pilot Light, ולשדרג כשהעסק גדל וההשלכות של downtime ממושך גדלות איתו.

DR ו-HA: איפה הגבול ביניהם

קל לבלבל בין High Availability ל-Disaster Recovery, אבל ההבדל חשוב לתכנון נכון. HA מטפל בכשלים ברמת רכיב בודד או מרכז נתונים בודד, בתוך אותה תשתית ואותו region - ומטרתו זמינות רציפה כמעט בלי הפרעה מורגשת. DR מטפל בכשל בקנה מידה גדול משמעותית - region שלם, ספק שלם - ומטרתו לא בהכרח "בלי הפרעה מורגשת", אלא התאוששות בזמן סביר (ה-RTO שהוגדר) גם אם יש הפרעה זמנית. ארגונים בשלים בונים את שתי היכולות זו לצד זו: HA שנותן חוסן שוטף לתקלות היומיומיות הנפוצות, ו-DR שנותן רשת ביטחון לתרחישים הקיצוניים והנדירים יותר שHA לבדו לא מספיק כדי להתמודד איתם.

סיכום

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

תגיות: Disaster Recovery · RTO · RPO · SaaS Architecture · Multi-Region · Backup and Restore · Business Continuity

← חזרה לבלוג · צור קשר